Container Service for Kubernetes：儲存異常問題排查

1.檢查Pod異常是否由儲存問題導致

通過Pod或PVC事件，確認Pod無法啟動是由儲存問題導致。

1. 查看異常Pod的事件。

   kubectl describe pod <pod-name>

   • 若Events中存在相關事件表明是儲存問題（例如樣本的FailedScheduling的Message中表明是由於Volume與節點不匹配導致調度失敗），請參考下文繼續排查。

     Events:
       Type     Reason            Age    From               Message
       ----     ------            ----   ----               -------
       Warning  FailedScheduling  4m37s  default-scheduler  0/1 nodes are available: 1 node(s) had volume node affinity conflict. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.,

   • 若Events中存在相關事件表明Volume已成功掛載（例如樣本的SuccessfulAttachVolume），此時Pod未啟動（例如CrashLoopBackOff）不屬於儲存問題，請根據Events排查其他問題，或者提交工單處理。

     Events:
       Type    Reason                  Age   From                     Message
       ----    ------                  ----  ----                     -------
       Normal  Scheduled               97s   default-scheduler        Successfully assigned default/disk-test-0 to cn-shanghai.192.168.5.2
       Normal  SuccessfulAttachVolume  97s   attachdetach-controller  AttachVolume.Attach succeeded for volume "d-uf6b8s2l5ypf48*****"

2. 若Pod事件中未看到儲存相關事件，可查看所有事件。

   kubectl get events

   • 若Events中存在相關事件表明是儲存問題（例如樣本的FailedBinding表明PVC綁定PV失敗），請參考下文繼續排查。

     LAST SEEN   TYPE      REASON                 OBJECT                                                  MESSAGE
     2m56s       Normal    FailedBinding          persistentvolumeclaim/data-my-release-mariadb-0         no persistent volumes available for this claim and no storage class is set
     41s         Normal    ExternalProvisioning   persistentvolumeclaim/pvc-nas-dynamic-create-subpath8   waiting for a volume to be created, either by external provisioner "nasplugin.csi.alibabacloud.com" or manually created by system administrator
     3m31s       Normal    Provisioning           persistentvolumeclaim/pvc-nas-dynamic-create-subpath8   External provisioner is provisioning volume for claim "default/pvc-nas-dynamic-create-subpath8"

   • 若Events中沒有儲存相關事件，請根據Events排查其他問題，或者提交工單處理。

2.檢查儲存群組件是否正常

1. 檢查CSI儲存群組件是否正常工作。

   kubectl get pod -n kube-system |grep csi

   返回樣本如下。如果Pod狀態非Running，可執行kubectl describe pods <pod-name> -n kube-system查看具體Container退出的原因及Pod的Event。

   說明

   CSI儲存群組件包括csi-plugin和csi-provisioner，其中csi-provisioner預設安裝託管版。託管版組件由阿里雲負責營運，您在叢集中無法看到相關Pod。

   NAME                     READY   STATUS        RESTARTS   AGE
   csi-plugin-bpz28         4/4     Running       0          3d
   csi-plugin-h2tdg         4/4     Running       0          3d
   csi-plugin-qpnm4         4/4     Running       0          3d
   csi-plugin-wczgm         4/4     Running       0          3d

2. 檢查CSI儲存群組件是否為最新版本。

   kubectl get ds csi-plugin -n kube-system -o yaml |grep image

   在返回資訊的image中可以確認鏡像版本，樣本如下：

   image: registry-cn-shanghai-vpc.ack.aliyuncs.com/acs/csi-plugin:v1.33.1-67e8986-aliyun

   若儲存群組件不是最新版本，請升級csi-plugin和csi-provisioner。儲存群組件最新版本資訊，請參見csi-plugin。

   說明

   您也可以在控制台的組件管理頁面，找到csi-plugin和csi-provisioner組件，確認版本資訊並升級組件。

3. 檢查PV、PVC和StorageClass的YAML，確認驅動配置（driver或provisioner欄位）為使用CSI儲存群組件，與當前叢集使用的儲存群組件一致。

3.檢查PVC是否為Bound狀態

1. 查看PVC狀態。

   kubectl get pvc

2. 如果PVC為非Bound狀態，參考以下方式進行排查和處理。

   問題原因

   • 靜態：由於PVC和PV之間的Selector無法滿足互相綁定的條件導致。例如：PVC中Selector配置與PV中的不一致，StorageClass Name不一致、PV狀態是Released等問題。

   • 動態：由於csi-provisioner組件的某種原因導致。

   解決方案

   • 靜態：請檢查相關的YAML書寫是否正確。相關參考如下：

     • 使用雲端硬碟靜態儲存卷

     • 使用NAS靜態儲存卷

     • 使用ossfs 1.0靜態儲存卷或使用ossfs 2.0儲存卷

     說明

     若PV狀態為Released，則該PV無法被複用，需要擷取PV中關於儲存資源的相關資訊，然後重新建立PV。

   • 動態：通過kubectl describe pvc <pvc-name> -n <namespace>查看PVC的Event。

     • 根據Event提示資訊進行處理。處理方法參考如下：

       • 雲端硬碟儲存卷FAQ

       • NAS儲存卷FAQ

       • ossfs 1.0儲存卷FAQ或ossfs 2.0儲存卷FAQ

     • 若沒有相關Event資訊，請提交工單處理。

   • 如果使用雲端硬碟儲存卷，可能是ECS OpenAPI建立雲端硬碟時出現了問題，請參見ECS錯誤中心進行排查。如果排查失敗，請提交工單處理。

4.檢查Pod是否為Running狀態

1. 查看Pod狀態。

   kubectl get pod

2. 如果PVC為Bound狀態，Pod為非Running狀態，請根據儲存卷類型，參考以下方式進行排查和處理。

   雲端硬碟儲存卷

   重要

   使用雲端硬碟儲存卷時，需確保待掛載雲端硬碟的Pod所調度到的ECS節點的規格支援掛載該類型雲端硬碟，並且Pod和雲端硬碟處於同一地區可用性區域。關於雲端硬碟類型和ECS執行個體規格的匹配關係，請參見執行個體規格類型系列。

   問題原因

   • 沒有滿足條件的節點可以調度。

   • 雲端硬碟掛載出現問題。

   • ECS節點和雲端硬碟類型不符。

   解決方案

   • 通過將Pod調度到其他節點快速恢複。具體操作，請參見調度應用至指定節點。

   • 通過kubectl describe pods <pod-name>查看Pod的Event。

     • 根據Event提示資訊進行處理。處理方法請參見雲端硬碟儲存卷FAQ。

     • 若沒有相關Event資訊，請提交工單處理。

   • 由於ECS節點和雲端硬碟類型不符導致的，請選擇合適類型的雲端硬碟。更多資訊，請參見執行個體規格類型系列。

   • 其他ECS OpenAPI類型問題的處理方法，請參見ErrorCode。

   NAS儲存卷

   重要

   • 節點與NAS必須在同一個VPC下。若不在同一VPC，請使用雲企業網打通。

   • NAS支援跨可用性區域掛載。

   • 極速型NAS的掛載目錄需要以/share開頭。

   問題原因

   • 掛載NAS時使用了fsGroups，檔案較多，導致chmod速度較慢。

   • 安全性群組中限制了2049連接埠，導致NAS無法掛載。

   • NAS和節點不在同一個VPC下。

   解決方案

   • 檢查是否設定fsGroups，如有，去掉後重啟Pod並重新掛載。

   • 確認Pod調度的節點是否限制了2049連接埠，如果該連接埠被限制，將2049連接埠放開後，重新掛載。具體操作，請參見添加安全性群組規則。

   • 確認NAS和節點在同一VPC下，若不在同一VPC，請使用雲企業網打通。

   • 其他問題，通過kubectl describe pods <pod-name>查看Pod的Event。

     • 根據Event提示資訊進行處理。處理方法請參見NAS儲存卷FAQ。

     • 若沒有相關Event資訊，請提交工單處理。

   OSS儲存卷

   重要

   • 節點掛載OSS時，PV中需填寫AccessKey資訊，可通過Secret方式使用 。

   • 跨地區使用OSS時，需將Bucket URL改成公網地址，同一地區建議使用內網地址。

   問題原因

   • 掛載OSS時使用了fsGroups，檔案較多，導致chmod速度較慢。

   • 跨地區使用了內網地址，導致無法串連到Bucket Endpoint。

   解決方案

   • 檢查是否設定fsGroups，如有，去掉後重啟Pod並重新掛載。

   • 檢查是否跨地區且使用內網訪問Bucket，如是，請改用公網地址。

   • 其他問題，通過kubectl describe pods <pod-name>查看Pod的Event。

     • 根據Event提示資訊進行處理。處理方法請參見ossfs 1.0儲存卷FAQ或ossfs 2.0儲存卷FAQ。

     • 若沒有相關Event資訊，請提交工單處理。

常見問題

0/x nodes are available: x pod has unbound immediate PersistentVolumeClaims. preemption: 0/x nodes are available: x Preemption is not helpful for scheduling