Introducción
Este documento describe el problema de los POD de NF SMF que no aparecen después de que la configuración de Día 1 se carga en el centro de operaciones SMF.
Requisito previo
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- Infraestructura de microservicios de suscriptor (SMI)
- Docker
- Kubernetes
- 5 G
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
- SMI
- Centro de operaciones
- SMF
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Problema
En la configuración del cliente, tienen dos SMF NF que se ejecutan con la misma versión. Ambos SMF NF fueron actualizados a la última versión anoche. Antes de la actualización, ambos NF tenían POD en estado de ejecución. El problema sólo se ve con un SMF, es decir, SMF-IMS. El otro POD SMF-DATA se actualiza y tiene todos los POD en estado de ejecución.
- Versión SMF antes de la actualización: smf.2020.01.0-12
- Versión de SMF después de la actualización: smf.2020.01.0-18
Abreviaturas
| SMF |
Función de administración de sesiones |
| NF |
Función de red |
| CEE |
Entorno de ejecución común |
| POD |
Es la unidad más pequeña posible en el entorno de Kubernetes, es decir, al menos un contenedor. |
| IMS |
Subsistema multimedia IP |
| SMI |
Infraestructura de microservicios del suscriptor |
‘Observaciones’
- La sincronización del clúster muestra la implementación correcta.
- Kubernetes Master muestra los PODS en estado de ejecución con configuración de día cero.
- Cuando se carga la configuración de Día 1, no se activa el nuevo PODS.
- Dentro del centro de operaciones SMF, verá los gráficos de casco en el estado eliminado.
- El modo de sistema de cambio se ejecuta para apagar y viceversa no ayudó.
- La adición de una nueva configuración de día 1 tampoco ayudó.
Síntomas
- SMF-IMS NF muestra los POD con la configuración de Día 0.
- Ops Center nos permite iniciar sesión.
- CEE ops-center está en funcionamiento.
- El centro de operaciones de SMF-DATA se encuentra en funcionamiento con la configuración de día 1 - Éste es el otro NF con POD en funcionamiento.
~ubuntu@crucs501-cnat-cnat-core-master1:~$ kubectl get pods -n smf-ims
NAME READY STATUS RESTARTS AGE
api-smf-ims-ops-center-69f4d8f47b-hsqnx 1/1 Running 0 162m
base-entitlement-smf-998c8b84f-79r8v 1/1 Running 0 162m
documentation-65484db875-n4ljq 1/1 Running 0 162m
ops-center-smf-ims-ops-center-6fb57bf79c-9dj29 5/5 Running 2 162m
smart-agent-smf-ims-ops-center-5dd679cf8b-hq4hs 1/1 Running 0 162m
swift-smf-ims-ops-center-745565bbf8-w5d7g 1/1 Running 0 162m
- Estado de la tabla de ayuda
crucs501-cnat/ims] smf# show helm
CHART INSTANCE STATUS VERSION REVISION RELEASE NAMESPACE
-------------------------------------------------------------------------------------------------------------------------------
infra-charts - DELETED 0.0.2-master-0031-200306111921-107580e 1 smf-ims-infra-charts smf-ims
smf-dashboard - DELETED 0.0.2-master-0018-200113112417-b028370 1 smf-ims-smf-dashboard smf-ims
smf-configuration - DELETED 0.0.6-master-1067-200303174113-9ee9665 1 smf-ims-smf-configuration smf-ims
li-ep - DELETED 0.0.1-master-0405-200306144054-3c56b02 1 smf-ims-li-ep smf-ims
smf-nodemgr - DELETED 0.0.2-master-3741-200304171906-5013914 1 smf-ims-smf-nodemgr smf-ims
smf-udp-proxy - DELETED 0.0.2-master-1420-200305182644-ebb4bc9 1 smf-ims-smf-udp-proxy smf-ims
gtpc-ep - DELETED 0.0.3-master-0926-200305203830-3306ff4 1 smf-ims-gtpc-ep smf-ims
smf-protocol - DELETED 0.0.2-master-4652-200304144735-d1e3798 1 smf-ims-smf-protocol smf-ims
smf-dns-proxy - DELETED 0.1.0-master-0541-200304144718-b028370 1 smf-ims-smf-dns-proxy smf-ims
smf-service - DELETED 0.0.5-master-18345-200305110040-5e8938b 1 smf-ims-smf-service smf-ims
smf-rest-ep - DELETED 0.3.3-master-6072-200304171221-7b0ff1a 1 smf-ims-smf-rest-ep smf-ims
etcd-cluster - DELETED 0.5.2-master-0046-200305044107-60d06f1 1 smf-ims-etcd-cluster smf-ims
ngn-datastore - DELETED 1.0.1-master-0619-200305030353-d255520 1 smf-ims-ngn-datastore smf-ims
Troubleshoot
- Realice la sincronización del clúster varias veces a través de SMI-Deployer sin éxito
- Se verifica la configuración del día 1.
- Quite la configuración de Día 1 y vuelva a agregarla.
- Borre el centro de operaciones del maestro de Kubernetes.
- Se realiza la eliminación completa de la configuración.
- Elimine los mapas de configuración (CM).
- Elimine los gráficos de timón del maestro.
- Elimine el espacio de nombres.
- Elimine los archivos de soporte del implementador.
- Como la misma nueva generación de SMF funciona bien en otras implementaciones en el entorno del cliente, se descarta que haya algún problema con la imagen.
- SMF-DATA en la misma configuración se había activado sin ningún problema.
Solución
- Elimine la configuración del clúster del centro de operaciones SMF-IMS del implementador SMI.
- Sincronice el clúster.
- Vuelva a agregar la configuración.
- Sincronice el clúster.
Hay una solución alternativa más para resolver este problema:
Elimine la versión anterior del paquete SMF del directorio al que se refiere el Implementador de SMI mientras se sincroniza el clúster.
Esta es la parte de configuración que se quitó y se agregó de vuelta de SMI Deployer ops-center running-config:
ops-centers smf ims
repository https://charts.10.192.1.xxx.nip.io/smf.2020.01.0-18
sync-default-repository true
netconf-ip 10.241.69.xx
netconf-port 2024
ssh-ip 10.241.69.xx
ssh-port 22
ingress-hostname 10.241.69.xx.nip.io
initial-boot-parameters use-volume-claims true
initial-boot-parameters first-boot-password <xxxyyyzzz>
initial-boot-parameters auto-deploy false
initial-boot-parameters single-node false
exit
Según el flujo de llamadas de la implementación, es el Implementador de SMI el que se encarga de la extracción de las imágenes para los POD del paquete que se almacena en él.
Normalmente, el paquete de software descargado de SMF se almacena en el directorio local, desde el cual el implementador SMI extrae y los cambia bajo este directorio: /data/software/packages/</strong >
Si se marca la lista de paquetes disponibles en este directorio, puede ver todos los paquetes más antiguos también disponibles en ella junto con la nueva lista de paquetes.
ubuntu@xxxxx501-cnat-smi-cm-core-cm1:/data/software/packages$ ls -lrt
total 24
drwxrwxr-x 3 root root 4096 Mar 23 13:15 sample
drwxrwxr-x 3 root root 4096 Mar 24 05:48 smf.2020.01.0-12 >>> Older version of SMF
drwxrwxr-x 3 root root 4096 Mar 24 05:48 cee.2020.01.0-1
drwxrwxr-x 3 root root 4096 Apr 13 19:48 smf.2020.01.0-18 >>> Newer version of SMF
drwxr-xr-x 3 root root 4096 May 4 10:10 smf.2020.02.0.i66 >>> Older version os SMF
drwxr-xr-x 3 root root 4096 May 8 12:02 cee.2020.02.0
En este resultado, puede ver que hay tres paquetes SMF diferentes disponibles. Aunque la versión SMF correcta (es decir, smf.2020.01.0-18) se define en la configuración de ejecución de SMI-Deployer, de todas maneras, el SMI-Deployer no puede obtener los archivos de imagen correctos para ese paquete.
Una vez realizada la solución mencionada en la sección Solución, el problema se resolvió.
Nota: También se observa un problema similar con los POD de CEE, para los que se aplica una solución alternativa similar que se menciona en la sección Solución.
Comentarios