摘要：社區在版本為了解決引入該問題。在上一步中，會有一個以開頭的目錄，之后需要手動刪除該目錄。具體限制如下普通云盤和云盤掛載要求必須與云主機處于相同可用區云盤掛載要求與云主機處于相同區域區域范圍小于可用區云盤僅可以掛

存儲常見問題

本篇目錄

1. PV PVC StorageClass 以及 UDisk 的各種關系？2. VolumeAttachment 的作用3. 如何查看 PVC 對應的 UDisk 實際掛載情況4. 磁盤掛載的錯誤處理5. UDisk-PVC 使用注意事項6. K8S 1.17 版本升級到 1.18 過程中云盤 Detach 問題7. Flexv 插件導致 pod 刪除失敗8. 其他常見存儲問題匯總9. 掛載Udisk的Pod調度問題10. CSI組件工作原理11 CSI常見問題排查流程

1. PV PVC StorageClass 以及 UDisk 的各種關系？

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: udisk-ssd-test
provisioner: udisk.csi.ucloud.cn #存儲供應方，此處不可更改。
---
apiVersion: v1
kind: PersistentVolumeClaim
spec:
  storageClassName: ssd-csi-udiskCopyErrorSuccess

用戶只需要設置好 StorageClass，在使用 pvc 時，csi-udisk 插件會自動完成 UDisk 的創建掛載 mount 等一系列的操作，主要流程如下

StorageClass 設置相關參數，與 CSI 插件綁定。pvc 與 StorageClass 進行綁定。K8S 觀察到使用 StorageClass 的新建 pvc，會自動創建 pv，并交給 CSI 插件完成新建 UDisk 的工作。pv 與 pvc 綁定完成，CSI 插件完成后續 UDisk 的掛載和 mount 等工作。UCloud 的 CSI 插件查看可以通過kubectl get pods -o wide -n kube-system |grep udisk 查看（一個總的 controller 及每個 node 對應的 pod）1.1 Statefulset 中使用 PVCStatefulset 控制器中的 pvctemplate 字段，可以設置 K8S 集群在對應 pvc 不存在時自動創建pvc，使得上述流程更加自動化(pvc和pv均由UK8S來建)。Statefulset 只負責創建不負責刪除 pvc，因此對應多余的 pvc 需要手動刪除

2. VolumeAttachment 的作用

VolumeAttachment 并不由用戶自己創建，因此很多用戶并不清楚它的作用，但是在 pvc 的使用過程中，VolumeAttachment 有著很重要的作用

VolumeAttachment所表示的，是 K8S 集群中記載的 pv 和某個 Node 的掛載關系。可以執行kubectl get volumeattachment |grep pv-name 進行查看這個掛載關系和 UDisk 與云主機的掛載關系往往是一致的，但是有時可能會出現不一致的情況。不一致的情況多見于 UDisk 已經從云主機卸載，但是 VolumeAttachment 記錄中仍然存在，UDisk 是否掛載在云主機上，可以通過如何查看 PVC 對應的 UDisk 實際掛載情況來查看對于不一致的情況，可用選擇手動刪除對應的 VolumeAttachment 字段，并新建一個相同的 VolumeAttachment（新建后 ATTACHED 狀態為 false）如果不能刪除，可以通過kubectl logs csi-udisk-controller-0 -n kube-system csi-udisk 查看 csi-controller 日志定位原因一般 kubelet 手動刪除不掉的情況，可能是對應的節點已經不存在了，此時直接  edit volumeattachment 刪除 finalizers 字段即可

[root@10-9-112-196 ~]# kubectl get volumeattachment |grep pvc-e51b694f-ffac-4d23-af5e-304a948a155a
NAME                                                                   ATTACHER              PV                                         NODE           ATTACHED   AGE
csi-1d52d5a7b4c5c172de7cfc17df71c312059cf8a2d7800e05f46e04876a0eb50e   udisk.csi.ucloud.cn   pvc-e51b694f-ffac-4d23-af5e-304a948a155a   10.9.184.108   true       2d2hCopyErrorSuccess

2.1 VolumeAttachment 文件示例

apiVersion: storage.k8s.io/v1
kind: VolumeAttachment
metadata:
  annotations:
    csi.alpha.kubernetes.io/node-id: 10.9.184.108 # 綁定的節點ip，填寫報錯pod所在節點
  finalizers:
  - external-attacher/udisk-csi-ucloud-cn
  name: csi-1d52d5a7b4c5c172de7cfc17df71c312059cf8a2d7800e05f46e04876a0eb50e # 名稱，按照pod報錯名稱填寫
spec:
  attacher: udisk.csi.ucloud.cn
  nodeName: 10.9.184.108 #綁定的節點ip，填寫報錯pod所在節點
  source:
    persistentVolumeName: pvc-e51b694f-ffac-4d23-af5e-304a948a155a # 綁定的pv，填寫pod使用的pvCopyErrorSuccess

3. 如何查看 PVC 對應的 UDisk 實際掛載情況

對應關系表

UK8S資源類型與主機對應關系PVUDisk的磁盤VolumeAttachment磁盤與主機的掛載關系(vdb,vdc的塊設備)PVC磁盤在主機上mount的位置pod使用磁盤的進程 kubectl get pvc -n ns pvc-name 查看對應的 VOLUME 字段，找到與 pvc 綁定的 pv，一般為（pvc-e51b694f-ffac-4d23-af5e-304a948a155a）kubectl get pv pv-name -o yaml 在 spec.csi.volumeHandle 字段，可以查看到改 pv 綁定的 UDisk盤(flexv 插件為 pv 的最后幾位)在控制臺查看該udisk盤的狀態,是否掛載到某個主機kubectl get volumeattachment |grep pv-name 查看 K8S 集群內記錄的磁盤掛載狀態ssh 到對應的主機上，lsblk可以看到對應的盤mount |grep pv-name 可用查看盤的實際掛載點，有一個 globalmount 及一個或多個 pod 的 mount 點

[root@10-9-184-108 ~]# mount |grep pvc-e51b694f-ffac-4d23-af5e-304a948a155a
/dev/vdc on /data/kubelet/plugins/kubernetes.io/csi/pv/pvc-e51b694f-ffac-4d23-af5e-304a948a155a/globalmount type ext4 (rw,relatime)
/dev/vdc on /data/kubelet/pods/587962f5-3009-4c53-a56e-a78f6636ce86/volumes/kubernetes.io~csi/pvc-e51b694f-ffac-4d23-af5e-304a948a155a/mount type ext4 (rw,relatime)CopyErrorSuccess

4. 磁盤掛載的錯誤處理

由于磁盤內容多流程長，建議在出現問題時，首先確定當前狀態如何查看 PVC 對應的 UDisk 實際掛載情況如果有UK8S中狀態和主機狀態不一致的情況，首先進行清理，刪除掉不一致的資源，之后走正常流程進行恢復 4.1 PV 和 PVC 一直卡在 terminating/磁盤卸載失敗怎么辦通過如何查看 PVC 對應的 UDisk 實際掛載情況確定當前 pv 和 pvc 的實際掛載狀態手動按照自己的需求進行處理，首先清理所有使用該 pv 和 pvc 的所有 pod（如果 pvc 已經成功刪除，則不需要這一步）如果刪除 pvc 卡在 terminating，則手動 umount 掉對應的掛載路徑如果刪除 VolumeAttachment 卡在 terminating，則手動在控制臺卸載掉磁盤（如果卡在卸載中找主機處理）如果刪除 pv 卡在 terminating，則手動在控制臺刪除掉磁盤（刪除 pv 前需要確保相關的 VolumeAttachment 已經刪除完成）確保手動釋放完成對應的資源后，可以通過kubectl edit 對應的資源,刪除掉其中的 finalizers 字段，此時資源就會成功釋放掉刪除 VolumeAttachment 后，如果 pod 掛載報錯，按照VolumeAttachment 文件示例中提供的yaml文件，重新補一個同名的 VolumeAttachment 即可4.2 Pod 的 PVC 一直掛載不上怎么辦？kubectl get pvc -n ns pvc-name 查看對應的 VOLUME 字段，找到與 pvc 綁定的 pv，一般為（pvc-e51b694f-ffac-4d23-af5e-304a948a155a）kubectl get pv pv-name -o yaml 在 spec.csi.volumeHandle 字段，可以查看到改 pv 綁定的 UDisk 盤(flexv 插件為 pv 的最后幾位)找到 UDisk 磁盤后，如果控制臺頁面中磁盤處于可用狀態或者掛載的主機不是 pod 所在主機，可以找技術支持，查看該 UDisk的掛載和卸載請求的錯誤日志，并聯系主機同時進行處理如果沒有 UDisk相關的錯誤日志，聯系UK8S值班人員，并提供kubectl logs csi-udisk-controller-0 -n kube-system csi-udisk的日志輸出及 pod 的event

5. UDisk-PVC 使用注意事項

由于 UDisk 不可跨可用區，因此在建立 StorageClass 時必須指定 volumeBindingMode: WaitForFirstConsumer由于 UDisk 不可多點掛載，因此必須在 pvc 中指定 accessModes 為 ReadWriteOnce基于 UDisk 不可多點掛載，多個 pod 不可共用同一個 udisk-pvc，上一個 pod 的 udisk-pvc 未處理干凈時，會導致后續 pod 無法創建，此時可以查看 VolumeAttachment 的狀態進行確認

6. K8S 1.17 版本升級到 1.18 過程中云盤 Detach 問題

我們發現在 UK8S 集群從 1.17 升級至 1.18 的過程中，部分掛載 PVC 的 Pod 會出現 IO 錯誤。查相關日志發現是因為掛載的盤被卸載導致 IO 異常。

社區在 1.18 版本為了解決 Dangling Attachments 引入該問題。參見 Recover CSI volumes from dangling attachments

K8S 處理掛盤和卸盤的實現中，單個 Node 可以選擇由 kubelet 和 controller-manager 進行管理掛盤和卸盤，上面的代碼在解決 dangling attachments 問題時引入了一個新的問題，由 kubelet 管理掛盤的 Node 節點，在 controller-manager 重啟后，該節點的磁盤會被強制卸載掉。

為了解決該問題，需要將由 kubelet 負責掛盤的節點改為由 controller-manager 負責掛盤。UK8S 添加的節點已經默認使用 controller-manager 負責掛盤，后續添加節點無需再手動更改

6.1 手動修改節點為controller-manager掛盤檢查 Kubelet 配置

檢查節點的 /etc/kubernetes/kubelet.conf 的配置。如果 enableControllerAttachDetach 的值為 false 則需要把該值修改為 true。

然后執行命令 systemctl restart kubelet 重啟 Kubelet。

檢查 Node 狀態

執行命令 kubectl get no $IP -o yaml 查看 Node 的 status 中 volumesAttached 是否有數據，且數據是否與 volumesInUse 的數據一致。

Node annotations 中應該有 volumes.kubernetes.io/controller-managed-attach-detach: "true" 的記錄。

如確認上述數據一致，且 Annotations 中有相應記錄，則可以正常進行升級。如有問題，請聯系技術支持。

7. Flexv 插件導致 pod 刪除失敗

7.1 現象描述

使用flexv插件自動創建pv綁定到pod，刪除pod時，有可能導致pod 處于Terminating狀態，不能正常刪除。

kubernetes版本: 1.13插件版本：Flexvolume-19.06.17.2 問題原因

kubelet重啟后找不到volume對應的Flexvolume插件。kubelet在重啟之后如果發現了orphan pod（正常的pod不會導致這個問題），就會通過pod記錄volume的路徑來推斷出使用的插件，但是flexv會在插件前面加入flexvolume-字段，導致kubelet推斷出的名字和flexv提供的名字匹配不上。kubelet日志中會報no volume plugin matched 的錯誤，進而導致pod卡在Terminating的狀態。

具體可以查看下面issue

https://github.com/kubernetes/kubernetes/issues/80972https://github.com/kubernetes/kubernetes/pull/809737.3 解決方案

手動umount掉當前pod使用的路徑，并進行清理操作。

謹慎操作，本操作是代替kubelet手動進行資源清理，請閱讀結束下面所有步驟再進行操作.

找到不能正常umount的pv。登錄到node節點上查看mount記錄。

mount | grep pv-nameCopyErrorSuccess

記錄上一步匹配到的所有路徑path,手動umount掉pv在當前節點下的路徑。

umount pathCopyErrorSuccess

在上一步umount中，會有一個以/var/lib/kubelet/pods開頭的目錄，umount之后需要手動刪除該目錄。

刪除pvc，刪除pvc之后需要手動在控制臺卸載掉對應的udisk。udisk的id為pv名字的最后幾位，例如pv名字是pvc-58f9978e-3133-11ea-b4d6-5254000cee42-bsm-olx0uqti， 則對應的udisk名字就是bsm-olx0uqti。也可以通過describe pv拿到spec.flexVolume.options中的diskId字段。

8. 其他常見存儲問題匯總

8.1 一個PVC可以掛載到多個 pod 嗎？

UDisk不支持多點讀寫，如需要多點讀寫請使用UFS。

8.2 Pod刪除后，如何復用原先的云盤？

可以使用靜態創建PV的方法進行原有云盤綁定的方法進行復用原有云盤，詳見在UK8S中使用已有UDISK

9. 掛載Udisk的Pod調度問題

相較于普通Pod，使用Udisk的Pod調度涉及到了UDisk自身掛載規則的限制，更為復雜。具體限制如下

普通云盤和SSD云盤掛載要求必須與云主機處于相同可用區RSSD云盤掛載要求與云主機處于相同RDMA區域（RDMA區域范圍小于可用區）RSSD云盤僅可以掛載到快杰云主機

?? RSSD UDisk調度要求同一個RDMA區域的快杰型云主機，RDMA區域范圍小于可用區，而主機目前不支持指定RDMA區域創建機器。因此使用RSSD UDisk，在Pod漂移的情況下，有可能出現Pod無法調度的問題。請您使用前務必確認可以接受該風險。

UDisk掛載限制在實際UK8S的使用中主要體現到以下兩個方面

自動創建PV的過程中，如何判定創建哪個可用區/RDMA區域的云盤當Pod需要重新調度時，如何保證新調度的節點滿足云盤掛載的要求

UK8S提供的csi-udisk插件，依賴K8S提供的CSI插件能力，幫助用戶實現了盡可能少的介入，下面以SSD UDisk為例進行講解。

9.1 創建PVC時自動創建UDisk

從上面的文檔中可以了解到，當PVC創建完成時，CSI會自動創建PV以及UDisk，并完成綁定工作。但是創建哪個可用區的UDisk呢，如果隨意選擇，則會導致后續Pod調度完成后無法掛載云盤。

為此K8S提供了WaitForFirstConsumer機制。當StorageClass中指定了volumeBindingMode: WaitForFirstConsumer參數時，CSI不會立刻創建PV及云盤，以下為WaitForFirstConsumer模式下的工作流程。

手動創建PVC創建Pod，并且在Pod綁定上一步中定義的PVC等待Pod進行調度，此時k8s會在PVC的Annotations中增加一個字段volume.kubernetes.io/selected-node,用以記錄Pod預計調度到的Node。注意此時查看Pod狀態仍然為Pending。CSI查詢Node云主機的可用區，創建相同可用區的云盤，并創建相應PV進行綁定CSI更新PV中的spec.csi.volumeHandle字段，記錄創建的云盤IDCSI更新PV中的spec.nodeAffinity字段，記錄云盤所在的可用區等信息

按照以上邏輯，可以保證Pod調度后創建的云盤順利掛載到對應主機

但是有一個特殊情況，RSSD盤僅能掛載到快杰機型上，如果Pod首次調度到了非快杰機型上，那么后續創建云盤就會失敗，因此如果您選擇了RSSD盤，請確保Pod首次調度到快杰機型上。

9.2 Pod重建后調度流程

首次運行后，如果遇到服務更新，或者節點故障等原因觸發Pod重建，會進行重新調度，以下為調度流程

清理舊Pod，完成UDisk從舊節點上清理卸載工作創建新PodK8S調度器會按照PV中的spec.nodeAffinity字段，校驗節點是否可以調度如果所有節點都不滿足磁盤調度要求，會記錄had volume node affinity conflict類型的EVENT到Pod，并重復上一步流程K8S調度器按照上一步過濾的結果，在可調度的節點范圍內，繼續按照普通Pod調度流程進行調度

10. CSI組件工作原理

CSI是K8S定義的容器存儲接口，可以對接云廠商的多種存儲。 UCloud目前實現了UDisk以及UFile/US3的CSI插件。

CSI組件分為兩大類，分別為Controller以及Daemonset。目前所有csi組件的pod均默認運行在kube-system下面，可以通過執行kubectl get pods -n kube-system -o wide |grep csi 進行查看。如果遇到存儲掛載問題，可以優先查看CSI Controller是否工作正常，以及節點上是否存在對應CSI Daemonset的Pod。

接下來對CSI組件進行簡要介紹。

10.1 CSI Controller

CSI Controller 負責的是全局資源的管理，通過list/watch k8s中的相關資源，執行對應操作。UDisk CSI Controller 會負責磁盤創建和刪除，磁盤到云主機的卸載及掛載操作。US3 CSI Controller 由于無需處理掛載操作，僅僅負責校驗一些StorageClass中的基礎信息。

10.2 CSI Daemonset

CSI Daemonset組件調度到各個節點上，負責單個節點的一些工作。與Controller模式不同，CSI Daemonset通過unix socket地址與kubelet進行通信，接收kubelet請求信息執行對應的操作。 通常CSI unix socket地址為/var/lib/kubelet/csi-plugins/csi-name/csi.sockUDisk/US3 CSI Daemonset 主要負責存儲的Mount以及Umount操作

10.3 其它功能

在基礎的存儲管理以及掛載功能外，CSI還提供了多種其它能力。目前CSI UDisk 則實現了磁盤動態擴容（需要Controller與Daemonset）以及磁盤Metrics信息收集(需要CSI Daemonset)。

11 CSI常見問題排查流程

本節會以UDisk-CSI為例，從創建pvc之后每一步可能出錯的點進行分析，并給出處理建議。另外本節內容僅涉及Pod創建過程中的相關內容。并基于一個假設，即上一個使用該PVC的Pod已經銷毀，并且中間的所有操作及資源已經清理干凈。如果上一個Pod使用的資源沒有清理干凈，也可以依賴本文檔反推確認清理方案。

通過 kubectl get pods -n kube-system -o wide 確認csi的controller及目標節點上Daemonset組件均工作正常確認PV是否創建成功，如果沒有，請查看 11.1 小節PV創建完成后，需要確保Pod成功調度。使用了udisk的Pod在普通調度規則上，會有額外的調度要求，具體可以看第9節如果磁盤掛載失敗，請查看 11.2 小節當確認磁盤已經掛載到目標主機后，需要確認mount成功，如果mount失敗，請查看11.3小節11.1 PV沒有創建成功

如果PV沒有創建成功，需要確保有Pod在使用該PVC。具體原因請查看第9.1節。

如果已有Pod在使用該PVC，則通過kubectl logs csi-udisk-controller-0 -n kube-system csi-udisk 查看controller日志，確認是否存在創建udisk失敗的日志。

通過kubectl get pv -o yaml 記錄下PV對應的udisk名稱，并在控制臺中查看對應的udisk存在。

一般自動創建的pv名字格式是pvc-xxxxxxxxx，這里比較容易混淆。

11.2 磁盤掛載失敗11.2.1 確保volumeattachment資源存在

為了能成功掛盤，首先需要確保volumeattachment資源存在，并且查看node的信息，確認當前是由kubelet還是controller-manager負責掛盤。

kubelet掛盤方式存在缺陷，目前k8s推薦使用controller-manager進行掛盤，具體查看及轉換方式可以對照本文檔6.1小節如果kubelet負責掛盤，并且pod日志中顯示類似volumeattachment資源不存在的情況，則需要按照文檔VolumeAttachment 文件示例中提供的yaml文件，重新補一個同名的 volumeAttachment。如果是controller-manager負責掛盤，則需要確認k8s版本是否為1.17.1-1.17.7或1.18.1-1.18.4，這些版本controller-manager掛盤存在性能問題。controller-manager日志查看方式，登錄到三臺master節點，執行journalctl -fu kube-controller-manager查看，注意三臺master中僅有一臺Master中的controller-manager為leader，即實際工作狀態。kubelet日志查看方式，需要登錄到目標節點，執行journalctl -fu kubelet11.2.2 確保磁盤掛載成功首先需要確認volumeattachment資源狀態為true。如果狀態不為true，可以查看csi-controller是否掛載過程中存在報錯。如果狀態為true，需要在控制臺確認udisk確實掛載到了目標主機，如果確認有問題，可以聯系技術支持。另外，此時需要確認，僅有一個對應的volumeattachment。因為udisk僅允許單點掛載，而us3由于允許多點掛載，并沒有此限制。11.3 磁盤Mount問題首先需要確認磁盤對應的盤符，udisk掛載由于實現原理的限制。在某些特殊情況下，頁面看到的盤符和真實盤符可能不一致，盤符對應信息可以從/sys/block/vdx/serial 文件中查看到。udisk-csi已經實現了該邏輯，不會有錯誤掛盤的出現，但是手動排查問題需要了解此情況。確認好磁盤對應的盤符之后，可以通過mount |grep pv-name 查看掛載路徑。udisk根據csi標準實現了globalmount及pod mount路徑，因此一個udisk正常情況下會看到兩個掛載路徑，一個以globalmount結尾，一個以mount結尾。us3僅實現了pod mount路徑，因此僅能看到一個掛載路徑，且us3也不需要確認盤符。fsGroup導致的磁盤mount緩慢

很多用戶會遇到一個磁盤mount緩慢的問題。此時需要首先確認是否設置了fsGroup，且磁盤中的是否存在大量小文件，如果兩個條件均滿足，則很可能導致掛載緩慢，具體可以查看k8s官方文檔