Introduction
Este documento descreve o problema dos PODs NF SMF que não aparecem depois que a configuração do Dia 1 é carregada no centro de operações SMF.
Pré-requisito
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Infraestrutura de microserviços de assinante (SMI)
- Docker
- Kubernetes
- 5G
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Problema
Na configuração do cliente, ele tem dois NF SMF executados com a mesma versão. Essas duas NFs SMF foram atualizadas para a versão mais recente ontem à noite. Antes da atualização, ambas as NF estavam com PODs em estado de execução. O problema é observado apenas com um SMF, ou seja, SMF-IMS. O outro POD SMF-DATA é atualizado e tem todos os PODs em estado de execução.
- Versão SMF antes da atualização: smf.2020.01.0-12
- Versão SMF após atualização: smf.2020.01.0-18
Abreviaturas
| SMF |
Função de gerenciamento de sessão |
| NF |
Função de rede |
| CEE |
Common Execution Environment |
| POD |
É a menor unidade possível no ambiente de Kubernetes, ou seja, pelo menos um contentor. |
| IMS |
Subsistema de multimídia IP |
| SMI |
Infraestrutura de microserviços do assinante |
Observações
- A Sincronização de Cluster mostra a Implantação Bem-sucedida.
- Kubernetes Master mostra o PODS em execução com configuração de Dia zero.
- Quando a configuração Dia 1 é carregada, o novo PODS não é ativado.
- Dentro do centro de operações SMF, você verá os caracteres de helm no estado excluído.
- Alterar os execuções do modo do sistema para desligar e vice-versa não ajudou.
- Adicionar uma nova configuração de dia 1 também não ajudou.
Sintomas
- A NF SMF-IMS mostra os PODs com configuração de Dia 0.
- O Ops-center está nos permitindo fazer login.
- O centro de operações CEE está funcionando.
- O centro de operações SMF-DATA está ativo e em execução com a configuração do dia 1 - Esta é a outra NF com PODs em funcionamento.
~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
- Status do gráfico de ajuda
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
- Execute a sincronização do cluster várias vezes por meio do SMI-Deployer sem êxito
- A configuração do dia 1 é verificada.
- Remova a configuração Dia 1 e adicione-a novamente.
- Exclua o centro de operações do mestre de Kubernetes.
- Toda a remoção da configuração é executada.
- Exclua os mapas de configuração (CM).
- Exclua os gráficos de helm do mestre.
- Exclua o namespace.
- Remova os arquivos de suporte do Implantador.
- Como a mesma nova construção de SMF funciona bem em outras implantações no ambiente do cliente, é desconsiderado que há qualquer problema com a imagem.
- SMF-DATA na mesma configuração foi exibido sem nenhum problema.
Solução
- Exclua a configuração de cluster do centro de operações SMF-IMS do implantador SMI.
- Sincronize o cluster.
- Adicione novamente a configuração.
- Sincronize o cluster.
Há mais uma solução alternativa para resolver esse problema:
Exclua a versão mais antiga do pacote SMF do diretório ao qual o Distribuidor SMI se refere durante a sincronização do cluster.
Aqui está a parte de configuração que foi removida e adicionada de volta do 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
De acordo com o fluxo de chamadas das implantações, é o SMI Deployer que cuida da extração das imagens para PODs do pacote que está armazenado nele.
Normalmente, o pacote de software baixado de SMF é um diretório local armazenado, do qual o implantador SMI extrai e os transfere sob este diretório: /data/software/packages/</strong >
Se a lista de pacotes disponíveis neste diretório estiver marcada, você poderá ver todos os pacotes mais antigos também disponíveis nele, juntamente com a nova lista de pacotes.
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
Nesta saída, você pode ver que há três pacotes SMF diferentes disponíveis. Embora a versão SMF correta (ou seja, smf.2020.01.0-18) esteja definida na configuração de execução do SMI-Deployer, ainda assim, de alguma forma o SMI-Deployer não consegue obter os arquivos de imagem corretos para esse pacote.
Após a execução da solução mencionada na seção Solução, o problema foi resolvido.
Note: Também é observado um problema semelhante com os PODs CEE, para os quais é aplicada uma solução alternativa semelhante mencionada na seção Solução.
Feedback