排除第1天配置后未启动的SMF POD故障

简介

本文档介绍在第1天配置加载到SMF运营中心后未启动的SMF NF POD的问题。

先决条件

要求

Cisco 建议您了解以下主题：

• 用户微服务基础设施(SMI)
• Docker
• 库贝内特斯
• 5G

使用的组件

本文档中的信息基于以下软件和硬件版本：

• SMI
• 运营中心
• SMF

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

问题 

在客户设置中，他们有两个SMF NF，它们使用同一版本运行。这两个SMF NF均于昨晚升级到最新版本。升级之前，两个NF都使POD处于运行状态。仅在一个SMF（即SMF-IMS）中出现此问题。其他POD SMF-DATA已升级，且所有POD均处于运行状态。

• 升级前的SMF版本:smf.2020.01.0-12
• 升级后的SMF版本：smf.2020.01.0-18

缩写

SMF	会话管理功能
NF	网络功能
中东欧	常见执行环境
POD	它是Kubernetes环境中最小的可能单元，即至少一个容器。
IMS	IP多媒体子系统
SMI	用户微服务基础设施

观察结果

• 集群同步显示部署成功。
• Kubernetes Master显示POD处于运行状态，且第零天配置。
• 加载第1天配置时，新POD不会出现。
• 在SMF运营中心内，您将看到舵轮在已删除状态。
• 更改系统模式运行以关闭，反之亦然。
• 添加新的第1天配置也无济于事。

症状

• SMF-IMS NF显示具有第0天配置的POD。
• 运营中心允许我们登录。
• 中东欧运营中心已经启动并运行。
• SMF-DATA运营中心已启动并运行，并且已配置第1天 — 此配置是另一个具有工作POD的NF。

~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 

故障排除

1. 通过SMI-Deployer多次执行集群同步，但未成功
   
   
2. 验证第1天配置。
   
   
3. 删除第1天配置并重新添加。
   
   
4. 从Kubernetes大师级中删除运营中心。
   
   
5. 执行整个配置删除。
   
   
6. 删除配置映射(CM)。
   
   
7. 从主页删除舵面图表。
   
   
8. 删除命名空间。
   
   
9. 从Deployer中删除支持文件。
   
   
10. 由于相同的新SMF构建在客户环境中的其他部署上运行正常，因此不排除映像存在任何问题。
    
    
11. 同一设置上的SMF-DATA无任何问题。

解决方案

1. 从SMI部署器中删除SMF-IMS ops-center的集群配置。
   
   
2. 同步群集。
   
   
3. 重新添加配置。
   
   
4. 同步群集。

此问题还有一个解决方法：

从集群同步时SMI Deployer引用的目录中删除SMF软件包的旧版本。

以下是从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

根据部署呼叫流，负责从存储在其中的包中提取POD映像的是SMI Deployer。

通常，下载的SMF软件包存储在本地目录中，SMI部署器从中提取并将其移到此目录下：/data/software/packages/</strong >

如果选中此目录下可用的包列表，您可以查看其中所有旧的包以及新包列表。

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

在此输出中，您可以看到有三种不同的SMF包可用。尽管在SMI-Deployer运行配置中定义了正确的SMF版本（即smf.2020.01.0-18），但SMI-Deployer仍然无法获取该软件包的正确映像文件。

执行“解决方案”部分中提及的解决方法后，问题便得到解决。

注意：CEE POD也出现了类似问题，对此，我们采用了解决方案部分中提到的类似解决方法。