排除第1天配置後未出現的SMF POD故障

簡介

本文檔描述了在SMF操作中心載入第1天配置後無法啟動的SMF NF POD問題。

必備條件

需求

思科建議您瞭解以下主題：

• 使用者微服務基礎架構(SMI)
• 多克
• 庫伯內特斯
• 5G

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• SMI
• 運營中心
• SMF

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

問題 

在客戶設定中，他們有兩個運行相同版本的SMF NF。昨晚這兩款絲路精靈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	使用者微服務基礎架構

意見

• Cluster Sync顯示部署成功。
• Kubernetes Master顯示PODS處於運行狀態且配置為「零日」。
• 載入第1天配置時，新的POD不會啟動。
• 在SMF操作中心內，您會看到舵在刪除狀態。
• 將系統模式更改為關閉，反之亦然，這沒有幫助。
• 新增新的第1天配置也沒有幫助。

症狀

• SMF-IMS NF顯示具有0天配置的POD。
• 運營中心允許我們登入。
• CEE運營中心已啟動並正在運行。
• SMF-DATA ops-center is up and running with day-1 config - this one is the another NF with working PODs.（SMF-DATA ops-center is up and running with day-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. 刪除Day-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

根據部署呼叫流程，SMI Deployer負責從儲存於其中的軟體包中提取POD的映像。

通常，下載的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也存在類似的問題，對其應用了解決方案部分中提到的類似解決方法。