摘要：社區(qū)在版本為了解決引入該問(wèn)題。在上一步中，會(huì)有一個(gè)以開(kāi)頭的目錄，之后需要手動(dòng)刪除該目錄。具體限制如下普通云盤(pán)和云盤(pán)掛載要求必須與云主機(jī)處于相同可用區(qū)云盤(pán)掛載要求與云主機(jī)處于相同區(qū)域區(qū)域范圍小于可用區(qū)云盤(pán)僅可以掛

存儲(chǔ)常見(jiàn)問(wèn)題

本篇目錄

1. PV PVC StorageClass 以及 UDisk 的各種關(guān)系？2. VolumeAttachment 的作用3. 如何查看 PVC 對(duì)應(yīng)的 UDisk 實(shí)際掛載情況4. 磁盤(pán)掛載的錯(cuò)誤處理5. UDisk-PVC 使用注意事項(xiàng)6. K8S 1.17 版本升級(jí)到 1.18 過(guò)程中云盤(pán) Detach 問(wèn)題7. Flexv 插件導(dǎo)致 pod 刪除失敗8. 其他常見(jiàn)存儲(chǔ)問(wèn)題匯總9. 掛載Udisk的Pod調(diào)度問(wèn)題10. CSI組件工作原理11 CSI常見(jiàn)問(wèn)題排查流程

1. PV PVC StorageClass 以及 UDisk 的各種關(guān)系？

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

用戶只需要設(shè)置好 StorageClass，在使用 pvc 時(shí)，csi-udisk 插件會(huì)自動(dòng)完成 UDisk 的創(chuàng)建掛載 mount 等一系列的操作，主要流程如下

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

2. VolumeAttachment 的作用

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

VolumeAttachment所表示的，是 K8S 集群中記載的 pv 和某個(gè) Node 的掛載關(guān)系。可以執(zhí)行kubectl get volumeattachment |grep pv-name 進(jìn)行查看這個(gè)掛載關(guān)系和 UDisk 與云主機(jī)的掛載關(guān)系往往是一致的，但是有時(shí)可能會(huì)出現(xiàn)不一致的情況。不一致的情況多見(jiàn)于 UDisk 已經(jīng)從云主機(jī)卸載，但是 VolumeAttachment 記錄中仍然存在，UDisk 是否掛載在云主機(jī)上，可以通過(guò)如何查看 PVC 對(duì)應(yīng)的 UDisk 實(shí)際掛載情況來(lái)查看對(duì)于不一致的情況，可用選擇手動(dòng)刪除對(duì)應(yīng)的 VolumeAttachment 字段，并新建一個(gè)相同的 VolumeAttachment（新建后 ATTACHED 狀態(tài)為 false）如果不能刪除，可以通過(guò)kubectl logs csi-udisk-controller-0 -n kube-system csi-udisk 查看 csi-controller 日志定位原因一般 kubelet 手動(dòng)刪除不掉的情況，可能是對(duì)應(yīng)的節(jié)點(diǎn)已經(jīng)不存在了，此時(shí)直接  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 # 綁定的節(jié)點(diǎn)ip，填寫(xiě)報(bào)錯(cuò)pod所在節(jié)點(diǎn)
  finalizers:
  - external-attacher/udisk-csi-ucloud-cn
  name: csi-1d52d5a7b4c5c172de7cfc17df71c312059cf8a2d7800e05f46e04876a0eb50e # 名稱(chēng)，按照pod報(bào)錯(cuò)名稱(chēng)填寫(xiě)
spec:
  attacher: udisk.csi.ucloud.cn
  nodeName: 10.9.184.108 #綁定的節(jié)點(diǎn)ip，填寫(xiě)報(bào)錯(cuò)pod所在節(jié)點(diǎn)
  source:
    persistentVolumeName: pvc-e51b694f-ffac-4d23-af5e-304a948a155a # 綁定的pv，填寫(xiě)pod使用的pvCopyErrorSuccess

3. 如何查看 PVC 對(duì)應(yīng)的 UDisk 實(shí)際掛載情況

對(duì)應(yīng)關(guān)系表

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

[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. 磁盤(pán)掛載的錯(cuò)誤處理

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

5. UDisk-PVC 使用注意事項(xiàng)

由于 UDisk 不可跨可用區(qū)，因此在建立 StorageClass 時(shí)必須指定 volumeBindingMode: WaitForFirstConsumer由于 UDisk 不可多點(diǎn)掛載，因此必須在 pvc 中指定 accessModes 為 ReadWriteOnce基于 UDisk 不可多點(diǎn)掛載，多個(gè) pod 不可共用同一個(gè) udisk-pvc，上一個(gè) pod 的 udisk-pvc 未處理干凈時(shí)，會(huì)導(dǎo)致后續(xù) pod 無(wú)法創(chuàng)建，此時(shí)可以查看 VolumeAttachment 的狀態(tài)進(jìn)行確認(rèn)

6. K8S 1.17 版本升級(jí)到 1.18 過(guò)程中云盤(pán) Detach 問(wèn)題

我們發(fā)現(xiàn)在 UK8S 集群從 1.17 升級(jí)至 1.18 的過(guò)程中，部分掛載 PVC 的 Pod 會(huì)出現(xiàn) IO 錯(cuò)誤。查相關(guān)日志發(fā)現(xiàn)是因?yàn)閽燧d的盤(pán)被卸載導(dǎo)致 IO 異常。

社區(qū)在 1.18 版本為了解決 Dangling Attachments 引入該問(wèn)題。參見(jiàn) Recover CSI volumes from dangling attachments

K8S 處理掛盤(pán)和卸盤(pán)的實(shí)現(xiàn)中，單個(gè) Node 可以選擇由 kubelet 和 controller-manager 進(jìn)行管理掛盤(pán)和卸盤(pán)，上面的代碼在解決 dangling attachments 問(wèn)題時(shí)引入了一個(gè)新的問(wèn)題，由 kubelet 管理掛盤(pán)的 Node 節(jié)點(diǎn)，在 controller-manager 重啟后，該節(jié)點(diǎn)的磁盤(pán)會(huì)被強(qiáng)制卸載掉。

為了解決該問(wèn)題，需要將由 kubelet 負(fù)責(zé)掛盤(pán)的節(jié)點(diǎn)改為由 controller-manager 負(fù)責(zé)掛盤(pán)。UK8S 添加的節(jié)點(diǎn)已經(jīng)默認(rèn)使用 controller-manager 負(fù)責(zé)掛盤(pán)，后續(xù)添加節(jié)點(diǎn)無(wú)需再手動(dòng)更改

6.1 手動(dòng)修改節(jié)點(diǎn)為controller-manager掛盤(pán)檢查 Kubelet 配置

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

然后執(zhí)行命令 systemctl restart kubelet 重啟 Kubelet。

檢查 Node 狀態(tài)

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

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

如確認(rèn)上述數(shù)據(jù)一致，且 Annotations 中有相應(yīng)記錄，則可以正常進(jìn)行升級(jí)。如有問(wèn)題，請(qǐng)聯(lián)系技術(shù)支持。

7. Flexv 插件導(dǎo)致 pod 刪除失敗

7.1 現(xiàn)象描述

使用flexv插件自動(dòng)創(chuàng)建pv綁定到pod，刪除pod時(shí)，有可能導(dǎo)致pod 處于Terminating狀態(tài)，不能正常刪除。

kubernetes版本: 1.13插件版本：Flexvolume-19.06.17.2 問(wèn)題原因

kubelet重啟后找不到volume對(duì)應(yīng)的Flexvolume插件。kubelet在重啟之后如果發(fā)現(xiàn)了orphan pod（正常的pod不會(huì)導(dǎo)致這個(gè)問(wèn)題），就會(huì)通過(guò)pod記錄volume的路徑來(lái)推斷出使用的插件，但是flexv會(huì)在插件前面加入flexvolume-字段，導(dǎo)致kubelet推斷出的名字和flexv提供的名字匹配不上。kubelet日志中會(huì)報(bào)no volume plugin matched 的錯(cuò)誤，進(jìn)而導(dǎo)致pod卡在Terminating的狀態(tài)。

具體可以查看下面issue

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

手動(dòng)umount掉當(dāng)前pod使用的路徑，并進(jìn)行清理操作。

謹(jǐn)慎操作，本操作是代替kubelet手動(dòng)進(jìn)行資源清理，請(qǐng)閱讀結(jié)束下面所有步驟再進(jìn)行操作.

找到不能正常umount的pv。登錄到node節(jié)點(diǎn)上查看mount記錄。

mount | grep pv-nameCopyErrorSuccess

記錄上一步匹配到的所有路徑path,手動(dòng)umount掉pv在當(dāng)前節(jié)點(diǎn)下的路徑。

umount pathCopyErrorSuccess

在上一步umount中，會(huì)有一個(gè)以/var/lib/kubelet/pods開(kāi)頭的目錄，umount之后需要手動(dòng)刪除該目錄。

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

8. 其他常見(jiàn)存儲(chǔ)問(wèn)題匯總

8.1 一個(gè)PVC可以掛載到多個(gè) pod 嗎？

UDisk不支持多點(diǎn)讀寫(xiě)，如需要多點(diǎn)讀寫(xiě)請(qǐng)使用UFS。

8.2 Pod刪除后，如何復(fù)用原先的云盤(pán)？

可以使用靜態(tài)創(chuàng)建PV的方法進(jìn)行原有云盤(pán)綁定的方法進(jìn)行復(fù)用原有云盤(pán)，詳見(jiàn)在UK8S中使用已有UDISK

9. 掛載Udisk的Pod調(diào)度問(wèn)題

相較于普通Pod，使用Udisk的Pod調(diào)度涉及到了UDisk自身掛載規(guī)則的限制，更為復(fù)雜。具體限制如下

普通云盤(pán)和SSD云盤(pán)掛載要求必須與云主機(jī)處于相同可用區(qū)RSSD云盤(pán)掛載要求與云主機(jī)處于相同RDMA區(qū)域（RDMA區(qū)域范圍小于可用區(qū)）RSSD云盤(pán)僅可以掛載到快杰云主機(jī)

?? RSSD UDisk調(diào)度要求同一個(gè)RDMA區(qū)域的快杰型云主機(jī)，RDMA區(qū)域范圍小于可用區(qū)，而主機(jī)目前不支持指定RDMA區(qū)域創(chuàng)建機(jī)器。因此使用RSSD UDisk，在Pod漂移的情況下，有可能出現(xiàn)Pod無(wú)法調(diào)度的問(wèn)題。請(qǐng)您使用前務(wù)必確認(rèn)可以接受該風(fēng)險(xiǎn)。

UDisk掛載限制在實(shí)際UK8S的使用中主要體現(xiàn)到以下兩個(gè)方面

自動(dòng)創(chuàng)建PV的過(guò)程中，如何判定創(chuàng)建哪個(gè)可用區(qū)/RDMA區(qū)域的云盤(pán)當(dāng)Pod需要重新調(diào)度時(shí)，如何保證新調(diào)度的節(jié)點(diǎn)滿足云盤(pán)掛載的要求

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

9.1 創(chuàng)建PVC時(shí)自動(dòng)創(chuàng)建UDisk

從上面的文檔中可以了解到，當(dāng)PVC創(chuàng)建完成時(shí)，CSI會(huì)自動(dòng)創(chuàng)建PV以及UDisk，并完成綁定工作。但是創(chuàng)建哪個(gè)可用區(qū)的UDisk呢，如果隨意選擇，則會(huì)導(dǎo)致后續(xù)Pod調(diào)度完成后無(wú)法掛載云盤(pán)。

為此K8S提供了WaitForFirstConsumer機(jī)制。當(dāng)StorageClass中指定了volumeBindingMode: WaitForFirstConsumer參數(shù)時(shí)，CSI不會(huì)立刻創(chuàng)建PV及云盤(pán)，以下為WaitForFirstConsumer模式下的工作流程。

手動(dòng)創(chuàng)建PVC創(chuàng)建Pod，并且在Pod綁定上一步中定義的PVC等待Pod進(jìn)行調(diào)度，此時(shí)k8s會(huì)在PVC的Annotations中增加一個(gè)字段volume.kubernetes.io/selected-node,用以記錄Pod預(yù)計(jì)調(diào)度到的Node。注意此時(shí)查看Pod狀態(tài)仍然為Pending。CSI查詢Node云主機(jī)的可用區(qū)，創(chuàng)建相同可用區(qū)的云盤(pán)，并創(chuàng)建相應(yīng)PV進(jìn)行綁定CSI更新PV中的spec.csi.volumeHandle字段，記錄創(chuàng)建的云盤(pán)IDCSI更新PV中的spec.nodeAffinity字段，記錄云盤(pán)所在的可用區(qū)等信息

按照以上邏輯，可以保證Pod調(diào)度后創(chuàng)建的云盤(pán)順利掛載到對(duì)應(yīng)主機(jī)

但是有一個(gè)特殊情況，RSSD盤(pán)僅能掛載到快杰機(jī)型上，如果Pod首次調(diào)度到了非快杰機(jī)型上，那么后續(xù)創(chuàng)建云盤(pán)就會(huì)失敗，因此如果您選擇了RSSD盤(pán)，請(qǐng)確保Pod首次調(diào)度到快杰機(jī)型上。

9.2 Pod重建后調(diào)度流程

首次運(yùn)行后，如果遇到服務(wù)更新，或者節(jié)點(diǎn)故障等原因觸發(fā)Pod重建，會(huì)進(jìn)行重新調(diào)度，以下為調(diào)度流程

清理舊Pod，完成UDisk從舊節(jié)點(diǎn)上清理卸載工作創(chuàng)建新PodK8S調(diào)度器會(huì)按照PV中的spec.nodeAffinity字段，校驗(yàn)節(jié)點(diǎn)是否可以調(diào)度如果所有節(jié)點(diǎn)都不滿足磁盤(pán)調(diào)度要求，會(huì)記錄had volume node affinity conflict類(lèi)型的EVENT到Pod，并重復(fù)上一步流程K8S調(diào)度器按照上一步過(guò)濾的結(jié)果，在可調(diào)度的節(jié)點(diǎn)范圍內(nèi)，繼續(xù)按照普通Pod調(diào)度流程進(jìn)行調(diào)度

10. CSI組件工作原理

CSI是K8S定義的容器存儲(chǔ)接口，可以對(duì)接云廠商的多種存儲(chǔ)。 UCloud目前實(shí)現(xiàn)了UDisk以及UFile/US3的CSI插件。

CSI組件分為兩大類(lèi)，分別為Controller以及Daemonset。目前所有csi組件的pod均默認(rèn)運(yùn)行在kube-system下面，可以通過(guò)執(zhí)行kubectl get pods -n kube-system -o wide |grep csi 進(jìn)行查看。如果遇到存儲(chǔ)掛載問(wèn)題，可以優(yōu)先查看CSI Controller是否工作正常，以及節(jié)點(diǎn)上是否存在對(duì)應(yīng)CSI Daemonset的Pod。

接下來(lái)對(duì)CSI組件進(jìn)行簡(jiǎn)要介紹。

10.1 CSI Controller

CSI Controller 負(fù)責(zé)的是全局資源的管理，通過(guò)list/watch k8s中的相關(guān)資源，執(zhí)行對(duì)應(yīng)操作。UDisk CSI Controller 會(huì)負(fù)責(zé)磁盤(pán)創(chuàng)建和刪除，磁盤(pán)到云主機(jī)的卸載及掛載操作。US3 CSI Controller 由于無(wú)需處理掛載操作，僅僅負(fù)責(zé)校驗(yàn)一些StorageClass中的基礎(chǔ)信息。

10.2 CSI Daemonset

CSI Daemonset組件調(diào)度到各個(gè)節(jié)點(diǎn)上，負(fù)責(zé)單個(gè)節(jié)點(diǎn)的一些工作。與Controller模式不同，CSI Daemonset通過(guò)unix socket地址與kubelet進(jìn)行通信，接收kubelet請(qǐng)求信息執(zhí)行對(duì)應(yīng)的操作。 通常CSI unix socket地址為/var/lib/kubelet/csi-plugins/csi-name/csi.sockUDisk/US3 CSI Daemonset 主要負(fù)責(zé)存儲(chǔ)的Mount以及Umount操作

10.3 其它功能

在基礎(chǔ)的存儲(chǔ)管理以及掛載功能外，CSI還提供了多種其它能力。目前CSI UDisk 則實(shí)現(xiàn)了磁盤(pán)動(dòng)態(tài)擴(kuò)容（需要Controller與Daemonset）以及磁盤(pán)Metrics信息收集(需要CSI Daemonset)。

11 CSI常見(jiàn)問(wèn)題排查流程

本節(jié)會(huì)以UDisk-CSI為例，從創(chuàng)建pvc之后每一步可能出錯(cuò)的點(diǎn)進(jìn)行分析，并給出處理建議。另外本節(jié)內(nèi)容僅涉及Pod創(chuàng)建過(guò)程中的相關(guān)內(nèi)容。并基于一個(gè)假設(shè)，即上一個(gè)使用該P(yáng)VC的Pod已經(jīng)銷(xiāo)毀，并且中間的所有操作及資源已經(jīng)清理干凈。如果上一個(gè)Pod使用的資源沒(méi)有清理干凈，也可以依賴本文檔反推確認(rèn)清理方案。

通過(guò) kubectl get pods -n kube-system -o wide 確認(rèn)csi的controller及目標(biāo)節(jié)點(diǎn)上Daemonset組件均工作正常確認(rèn)PV是否創(chuàng)建成功，如果沒(méi)有，請(qǐng)查看 11.1 小節(jié)PV創(chuàng)建完成后，需要確保Pod成功調(diào)度。使用了udisk的Pod在普通調(diào)度規(guī)則上，會(huì)有額外的調(diào)度要求，具體可以看第9節(jié)如果磁盤(pán)掛載失敗，請(qǐng)查看 11.2 小節(jié)當(dāng)確認(rèn)磁盤(pán)已經(jīng)掛載到目標(biāo)主機(jī)后，需要確認(rèn)mount成功，如果mount失敗，請(qǐng)查看11.3小節(jié)11.1 PV沒(méi)有創(chuàng)建成功

如果PV沒(méi)有創(chuàng)建成功，需要確保有Pod在使用該P(yáng)VC。具體原因請(qǐng)查看第9.1節(jié)。

如果已有Pod在使用該P(yáng)VC，則通過(guò)kubectl logs csi-udisk-controller-0 -n kube-system csi-udisk 查看controller日志，確認(rèn)是否存在創(chuàng)建udisk失敗的日志。

通過(guò)kubectl get pv -o yaml 記錄下PV對(duì)應(yīng)的udisk名稱(chēng)，并在控制臺(tái)中查看對(duì)應(yīng)的udisk存在。

一般自動(dòng)創(chuàng)建的pv名字格式是pvc-xxxxxxxxx，這里比較容易混淆。

11.2 磁盤(pán)掛載失敗11.2.1 確保volumeattachment資源存在

為了能成功掛盤(pán)，首先需要確保volumeattachment資源存在，并且查看node的信息，確認(rèn)當(dāng)前是由kubelet還是controller-manager負(fù)責(zé)掛盤(pán)。

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

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