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

存儲常見問題

本篇目錄

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

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

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

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

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

2. VolumeAttachment 的作用

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

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

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

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

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

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

5. UDisk-PVC 使用注意事項

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

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

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

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

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

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

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

檢查節(jié)點的 /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)行升級。如有問題，請聯(lián)系技術(shù)支持。

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

7.1 現(xiàn)象描述

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

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

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

具體可以查看下面issue

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

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

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

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

mount | grep pv-nameCopyErrorSuccess

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

umount pathCopyErrorSuccess

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.1 創(chuàng)建PVC時自動創(chuàng)建UDisk

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

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

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

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

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

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

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

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

10. CSI組件工作原理

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

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

接下來對CSI組件進(jìn)行簡要介紹。

10.1 CSI Controller

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

10.2 CSI Daemonset

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

10.3 其它功能

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

11 CSI常見問題排查流程

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

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

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

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

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

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

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

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

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

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