Introduzione
In questo documento viene descritto il problema dei POD SMF NF che non viene visualizzato dopo il caricamento della configurazione del giorno 1 nell'ops-center SMF.
Prerequisito
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- SMI (Subscriber Microservices Infrastructure)
- Docker
- Kubernetes
- 5G
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Problema
Nell'impostazione del cliente, dispongono di due SMF NF che vengono eseguiti con la stessa versione. Entrambe queste NF SMF sono state aggiornate all'ultima versione la scorsa notte. Prima dell'aggiornamento, entrambi i dispositivi NF avevano POD in stato di esecuzione. Il problema si verifica solo con un SMF, ovvero SMF-IMS. L'altro POD SMF-DATA viene aggiornato e tutti i POD sono in stato di esecuzione.
- Versione SMF prima dell'aggiornamento: smf.2020.01.0-12
- Versione SMF dopo l'aggiornamento: smf.2020.01.0-18
Abbreviazioni
| SMF |
Funzione di gestione delle sessioni |
| NF |
Funzione di rete |
| CEE |
Ambiente di esecuzione comune |
| POD |
È la più piccola unità possibile nell'ambiente Kubernetes, cioè almeno un container. |
| IMS |
Sottosistema multimediale IP |
| SMI |
Infrastruttura microservizi per utenti |
Osservazioni
- Sincronizzazione cluster: distribuzione completata.
- Kubernetes Master mostra il PODS in stato di esecuzione con configurazione Giorno zero.
- Quando viene caricata la configurazione del giorno 1, il nuovo PODS non viene visualizzato.
- All'interno di SMF ops-center, le carte del timone sarebbero in stato cancellato.
- Cambiare la modalità di sistema in chiusura e viceversa non è stato di aiuto.
- L'aggiunta di una nuova configurazione del giorno 1 non è stata utile.
Sintomi
- SMF-IMS NF mostra i POD con configurazione Day-0.
- Ops-center ci consente di eseguire il login.
- Il centro operativo CEE è operativo.
- SMF-DATA ops-center è operativo con configurazione day-1: questo è l'altro NF con POD funzionanti.
~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
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
Risoluzione dei problemi
- Esecuzione della sincronizzazione del cluster più volte tramite SMI-Deployer senza esito
- La configurazione del giorno 1 è stata verificata.
- Rimuovere la configurazione del giorno 1 e aggiungerla nuovamente.
- Eliminare il centro operativo dal master Kubernetes.
- Viene eseguita la rimozione completa della configurazione.
- Eliminare le mappe di configurazione (CM).
- Eliminare i diagrammi a timone dal master.
- Eliminare lo spazio dei nomi.
- Rimuovere i file di supporto da Deployer.
- Poiché la stessa nuova build SMF funziona correttamente su altre installazioni nell'ambiente del cliente, è escluso che vi siano problemi con l'immagine.
- SMF-DATA nella stessa configurazione è stato generato senza alcun problema.
Soluzione
- Eliminare la configurazione cluster di ops-center SMF-IMS dal deployer SMI.
- Sincronizzare il cluster.
- Aggiungere nuovamente la configurazione.
- Sincronizzare il cluster.
Per risolvere questo problema, è disponibile un'altra soluzione:
Eliminare la versione precedente del pacchetto SMF dalla directory a cui fa riferimento SMI Deployer durante la sincronizzazione del cluster.
Di seguito è riportata la parte della configurazione che è stata rimossa e aggiunta nuovamente da 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
In base al flusso di chiamate delle distribuzioni, è SMI Deployer che si occupa dell'estrazione delle immagini per i POD dal pacchetto in esso memorizzato.
Normalmente, il pacchetto software scaricato di SMF è memorizzato nella directory locale, da cui il deployer SMI estrae e li sposta in questa directory: /data/software/packages/</strong >
Se è selezionato l'elenco dei package disponibili in questa directory, è possibile visualizzare anche tutti i package precedenti e il nuovo elenco.
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
In questo output, potete vedere che ci sono tre diversi pacchetti SMF disponibili. Anche se la versione SMF corretta (ad esempio smf.2020.01.0-18) è definita nella configurazione di esecuzione di SMI-Deployer, in qualche modo SMI-Deployer non è in grado di ottenere i file di immagine corretti per quel pacchetto.
Dopo aver eseguito la soluzione indicata nella sezione Soluzione, il problema è stato risolto.
Nota: Un problema simile si verifica anche con i POD CEE, per i quali viene applicata una soluzione simile a quella descritta nella sezione Soluzione.
Feedback