資料卷挂載問題快速恢複

Pod挂載、解除安裝資料卷出現問題的原因很多，有存儲卷設計的缺陷、有相關元件實作的bug、有使用方式不當的可能，面對複雜的應用、存儲互動系統，我們需要從兩個方面對待資料卷問題：

• 盡量别出問題：減少存儲元件的自身穩定性 && 規範的使用方式。
• 如何面對問題：首要是快速恢複業務，然後分析問題。

本文闡述的是業務快速恢複方案：當Pod因為資料卷挂載重新開機失敗時，暫不去解決節點挂載的問題，而是讓pod先在其他節點啟動成功，快速恢複業務，待業務恢複後再去分析出問題的節點。

更新一個Pod，卡在了 ContainerCreating 狀态：

例如：你在Deployment類型應用中挂載NAS資料卷，Pod在啟動的時候報錯為挂載失敗：

Warning  FailedMount  18s   kubelet, cn-shenzhen.192.168.1.24  Unable to mount volumes for pod "nas-static-796b49b5f8-svbvh_default(2d483078-1400-11ea-a9b7-00163e084110)": 
timeout expired waiting for volumes to attach or mount for pod "default"/"nas-static-796b49b5f8-svbvh". 
list of unmounted volumes=[pvc-nas]. list of unattached volumes=[pvc-nas default-token-9v9hl]           

更新前資料卷使用是正常的，而更新後pod啟動不了，并有上述資訊顯示資料卷挂載不上，有一個可能性為：目前pod所在節點對此pv/pvc出現狀态異常。具體異常原因暫不深究。

通過把pod排程到其他節點快速啟動pod，參考如下步驟：

1. 确定pod所在節點：

根據上述錯誤資訊即可拿到節點為：cn-shenzhen.192.168.1.24

也可以通過下面步驟拿到：
# podname="nas-static-796b49b5f8-svbvh"
# namespace="default"
#  kubectl describe pod $podname -n $namespace | grep Node: | awk '{print $2}'
cn-shenzhen.192.168.1.24/192.168.1.24           

2. 設定節點不可排程：

您可以使用控制台來配置節點排程狀态，參考

也可以使用下面指令行執行給目前挂載有問題的節點打上污點标簽，確定pod不會再往這個節點排程：

# kubectl taint nodes cn-shenzhen.192.168.1.24 key=value:NoSchedule
node/cn-shenzhen.192.168.1.24 tainted           

3. 重新開機問題Pod：

這時重新開機問題Pod，建立的Pod就不會排程到剛才有問題的節點了：

删除問題Pod：
# kubectl delete pod nas-static-796b49b5f8-svbvh
pod "nas-static-796b49b5f8-svbvh" deleted

新的pod啟動成功，且排程到新節點：
# kubectl get pod
NAME                          READY   STATUS        RESTARTS   AGE
nas-static-857b99fcc9-vvzkx   1/1     Running       0          14s
# kubectl describe pod nas-static-857b99fcc9-vvzkx | grep Node
Node:               cn-shenzhen.192.168.1.25/192.168.1.25           

4. 後續處理：

上述步驟目的是保證您您的業務快速恢複，但問題節點的問題還存在，您可以通過[存儲常見問題]()進行排查分析。

如果您無法解決節點問題，可以聯系阿裡雲容器服務技術支援。節點問題解決後，您可以通過控制台或者指令行将問題節點配置為可排程狀态；

# kubectl taint nodes cn-shenzhen.192.168.1.24 key:NoSchedule-
node/cn-shenzhen.192.168.1.24 untainted           

更新一個pod，卡在 Terminating 狀态：

例如：你使用statefulset建立應用，并挂載了雲盤資料卷；當更新應用的時候，pod一直處于Terminating狀态進而導緻新的pod無法正常啟動。

# kubectl delete pod web-0

# kubectl get pod
NAME    READY   STATUS        RESTARTS   AGE
web-0   0/1     Terminating   0          47m           

到pod所在節點檢視下面日志檔案：

# tailf /var/log/alicloud/flexvolume_disk.log
# tailf /var/log/messages | grep kubelet           

如果發現報錯原因為資料卷Umount/Detach等失敗，例如：

unmount command failed, status: Failure, reason:

device is busy 字樣
或
target is busy 字樣
或
Orphan Pod字樣
等等           

如果在沒有找到如何解決問題時急于恢複業務，可以先将問題pod強制删除，優先恢複業務。

1. 使用強制删除指令結束目前pod：

# kubectl delete pod web-0 --force=true --grace-period=0
pod "web-0" force deleted           

此指令會強制删除Etcd資料庫中的pod資訊，進而為建立新pod提供可能（StatefulSet中，老pod沒有删除前新pod不會重建）。

2. 如果建立pod啟動的時候失敗，卡在 ContainerCreating：

可以參考 “更新一個Pod，卡在了 ContainerCreating 狀态” 做法，為node配置不可排程，快速恢複pod運作。

3. 登陸問題節點，分析原因：

登陸問題所在節點，通過[存儲常見問題]()進行排查分析。無法解決時可能聯系阿裡雲容器服務技術支援。