Inleiding
In dit document wordt het probleem beschreven van NF-POD's van SMF die niet verschijnen nadat de configuratie van Dag 1 is geladen in SMF-ops-Center.
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
- Subscriber Microservice-infrastructuur (SMI)
- Docker
- Kubernetes
- 5 G
Gebruikte componenten
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.
Probleem
Bij de instellingen van de klant hebben ze twee SMF NF die met dezelfde versie werken. Beide KMO's zijn gisteravond bijgewerkt tot de laatste versie. Voor de upgrade hadden beide NF's POD's in bedrijf. Het probleem wordt slechts met één SMF gezien, dat wil zeggen SMF-IMS. De andere POD SMF-DATA wordt bijgewerkt en heeft alle POD's in bedrijf.
- SMF-versie vóór de upgrade: smf.2020.01.0-12
- SMF-versie na upgrade: smf.2020.01.0-18
Afkortingen
| SMF |
Sessiebeheer |
| NF |
Netwerkfunctie |
| CEE |
Gemeenschappelijke executie-omgeving |
| POD |
Het is de kleinste eenheid in de Kubernetes-omgeving, d.w.z. ten minste één container. |
| IMS |
IP-multimediasysteem |
| SMI |
Subscriber Microservices infrastructuur |
Opmerkingen
- Cluster Sync laat de implementatie succesvol zien.
- Kubernetes Master laat de PODS zien in bedrijf met de configuratie op dag nul.
- Wanneer de Day-1-configuratie wordt geladen, komen de nieuwe PODS niet omhoog.
- In het SMF-ops-centrum zie je de helm-kaarten in de verwijderde staat.
- Wijzig de opties van het systeem door te draaien en vice versa hielp niet.
- Voeg ook een nieuwe configuratie van dag 1 toe, die niet hielp.
Symptomen
- SMF-IMS NF toont de POD's met de configuratie van dag 0.
- Met Ops-Center kunnen we inloggen.
- Het CEE ops-Center is in bedrijf.
- SMF-DATA ops-Center is in bedrijf en werkt met day-1 grotere configuratie - Deze laatste is de andere NF met werkende POD's.
~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
- De status van het Helpschema
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
Problemen oplossen
- Voer de cluster sync meerdere malen via SMI-Deployment uit zonder succes
- De configuratie van dag 1 wordt geverifieerd.
- Verwijder de Day-1-configuratie en voeg terug toe.
- Verwijdert het ops-centre van Kubernetes master.
- De volledige disatie van de configuratie wordt uitgevoerd.
- Verwijdert de Config Maps (CM).
- Verwijder de helm-kaarten van de kapitein.
- Verwijdert de naamruimte.
- Verwijder de ondersteunende bestanden van Deployer.
- Aangezien dezelfde nieuwe SMF bouwt, werkt fijn op andere implementaties in de klantomgeving, is het uitgesloten dat er een probleem is met de afbeelding.
- SMF-DATA van dezelfde installatie zijn zonder problemen naar voren gekomen.
Oplossing
- Verwijdert de clusterconfiguratie van SMF-IMS ops-Center van SMI-implementator.
- Sync the cluster.
- Voeg terug de configuratie.
- Sync the cluster.
Er is nog een oplossing voor dit probleem:
Verwijdert de oudere versie van het SMF-pakket uit de map waarnaar SMI Deployment verwijst tijdens de clustersync.
Hier is het configuratiegedeelte dat werd verwijderd en terugtoegevoegd van SMI Deployer ops-center run-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
Volgens de implementaties aanroep flow, is het de SMI Deployer die zorg draagt voor de extractie van de beelden voor POD's uit het pakket dat erin opgeslagen is.
Gewoonlijk wordt het gedownload Software pakket van SMF opgeslagen als lokale directory, waaruit SMI-implementaties haalt en deze onder deze map doorstuurt: /data/software/pakketten/</strong>
Als de lijst van pakketten die beschikbaar zijn onder deze folder is gecontroleerd, kunt u alle oudere pakketten samen met de nieuwe pakketlijst zien.
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 deze output kan je zien dat er drie verschillende SMF pakketten beschikbaar zijn. Hoewel de juiste SMF-versie (d.w.z. smf.2020.01.0-18) is gedefinieerd in de draaiende configuratie van SMI-Deployer, kan de SMI-Deployer op de een of andere manier niet de juiste beeldbestanden voor dat pakket krijgen.
Nadat het tijdelijke oplossing was gevonden in het gedeelte Solution.
Opmerking: Een soortgelijk probleem wordt ook waargenomen bij CEE-POD's, waarvoor een soortgelijke workround wordt toegepast die wordt vermeld in het gedeelte Solutions.
Feedback