Kubernetes Storage : 淺談如何實(shí)現(xiàn)一個(gè) CSI 插件

作者：CloudNative101 2023-12-18 08:23:12

CSI 是 Kubernetes 存儲(chǔ)體系中的核心組件，為存儲(chǔ)供應(yīng)商提供了靈活且可擴(kuò)展的集成方式，也為 Kubernetes 用戶提供了高效穩(wěn)定的存儲(chǔ)解決方案。

現(xiàn)在，我將繼續(xù)和大家聊一聊關(guān)于 K8s 存儲(chǔ)的一個(gè)重要組成部分：Container Storage Interface (CSI)。在接下來的內(nèi)容中，我們將會(huì)了解到 CSI 的工作原理、核心概念以及如何將其集成到你的容器化環(huán)境中。

為什么需要 CSI ？它解決了什么問題？

在學(xué)習(xí) CSI 之前，了解其產(chǎn)生的背景以及它能夠解決的問題我覺得是很有必要的。

為什么需要 CSI

雖然 Kubernetes 平臺(tái)它本身支持了非常多的存儲(chǔ)插件，但是畢竟也是有限的，永遠(yuǎn)無法滿足用戶日益增長(zhǎng)的需求，比方說有客戶要求我們的 Paas 平臺(tái)必須接國(guó)產(chǎn)的存儲(chǔ)怎么辦？

面臨的問題，如何做集成？

Kubernetes 本身提供了一個(gè)強(qiáng)大的 Volume 插件系統(tǒng)，最直接的方式就是向這個(gè) Volume Plugin 增加新的插件。

但是，想必大家也知道 Kubernetes 太復(fù)雜了，它有一定的學(xué)習(xí)曲線，這樣做一來成本比較高，再者直接集成第三方代碼，可能會(huì)對(duì) Kubernetes 平臺(tái)系統(tǒng)的可靠性和安全性產(chǎn)生隱患。

另外，這種方法它也不方便測(cè)試和維護(hù)，比方說第三方存儲(chǔ)服務(wù)如果有變更，我們就需要提交變更代碼到 Kubernetes，等待 Code Review。換句話說，我們必須要等到 Kubernetes 發(fā)布才能將存儲(chǔ)服務(wù)的變動(dòng)上線，這就意味著存儲(chǔ)的集成與 Kubernetes 的發(fā)布周期捆綁在一起了。

所以直接和 Kubernetes 做集成是非常不方便的。

讓我們重新回過來看下，上面反復(fù)提到過的 In-Tree 和 Out-Of-Tree 這兩個(gè)概念，我相信從字面意思上大家都已經(jīng)理解了，再結(jié)合下面這張表格，大家心里是否都已經(jīng)有了答案？

圖片

解決了什么痛點(diǎn)？

CSI 將三方存儲(chǔ)代碼與 K8s 代碼解耦，不同的存儲(chǔ)插件只要實(shí)現(xiàn)這些統(tǒng)一的接口，就能對(duì)接 K8s，用戶無需接觸核心的 K8s 代碼。

最重要的是，CSI 規(guī)范現(xiàn)在是業(yè)界容器編排統(tǒng)一的存儲(chǔ)接入標(biāo)準(zhǔn)。

圖片

Container Orchestrators(CO)

那么，什么是 CSI？

以下是 ChatGPT 給出的回答：

CSI（Container Storage Interface）是一個(gè)規(guī)范化的接口，用于容器編排引擎與存儲(chǔ)供應(yīng)商之間的通信。它允許存儲(chǔ)供應(yīng)商編寫標(biāo)準(zhǔn)的插件，以便容器編排引擎可以與其集成，從而實(shí)現(xiàn)更加靈活和可擴(kuò)展的存儲(chǔ)解決方案。

CSI 驅(qū)動(dòng)器由三個(gè)主要組件組成，每個(gè)組件都扮演著特定的角色：

Node Service: 運(yùn)行在每個(gè) Kubernetes 節(jié)點(diǎn)上，負(fù)責(zé)在節(jié)點(diǎn)上掛載和卸載存儲(chǔ)卷，并處理節(jié)點(diǎn)級(jí)別的存儲(chǔ)操作。
Controller Service: 運(yùn)行在 Kubernetes 控制平面中，負(fù)責(zé)管理存儲(chǔ)卷的生命周期，包括創(chuàng)建、刪除和擴(kuò)容等操作。
Identity Service: 它是 CSI 驅(qū)動(dòng)器的第三個(gè)組件，它在 CSI 驅(qū)動(dòng)器注冊(cè)時(shí)提供標(biāo)識(shí)信息，并向 Kubernetes 集群公開驅(qū)動(dòng)器的支持能力。它負(fù)責(zé)告知 Kubernetes 驅(qū)動(dòng)器的存在，提供驅(qū)動(dòng)器的基本信息和功能支持。

CSI 的設(shè)計(jì)思想是將存儲(chǔ)管理和容器編排系統(tǒng)解耦，使得新的存儲(chǔ)系統(tǒng)可以通過實(shí)現(xiàn)一組標(biāo)準(zhǔn)化的接口來與 Kubernetes 進(jìn)行集成，而無需修改 Kubernetes 的核心代碼。

CSI 驅(qū)動(dòng)器的出現(xiàn)為 Kubernetes 用戶帶來了更多的存儲(chǔ)選擇，同時(shí)也為存儲(chǔ)供應(yīng)商和開發(fā)者提供了更方便的接入點(diǎn)，使得集群的存儲(chǔ)管理更加靈活和可擴(kuò)展。

圖片

Storage in Cloud Native Environment

CSI 適配工作是由容器編排系統(tǒng)（CO）和存儲(chǔ)提供商（SP）共同完成的，CO 通過 gRPC 與 CSI 插件進(jìn)行通信。相信大家也都觀察到了，CSI 在這里充當(dāng)了連接的紐帶，上層連接容器編排系統(tǒng)，下層操作三方存儲(chǔ)服務(wù)。

CSI 的工作原理，它是如何工作的？

Typical CSI driver architecture

下面是 CSI 的一個(gè)典型架構(gòu)，雖然 CSI 對(duì)于存儲(chǔ)提供商來說只需實(shí)現(xiàn)三個(gè)模塊即可，但是整個(gè)編排流程可以說是相當(dāng)復(fù)雜的。

圖片

Kubernetes cluster with CSI

CSI 的整個(gè)運(yùn)轉(zhuǎn)流程會(huì)涉及到兩方面的組件：

?? 由 Kubernetes 官方維護(hù)的一組標(biāo)準(zhǔn) external 組件，他們主要負(fù)責(zé)監(jiān)聽 K8s 里的資源對(duì)象，從而向 CSI Driver 發(fā)起 gRPC 調(diào)用，詳見：Kubernetes CSI Sidecar Containers[1]。它們是與 CSI 驅(qū)動(dòng)器一起部署在同一個(gè) Pod 中，用于輔助 CSI Driver 完成一些額外的任務(wù)和功能。?? 各存儲(chǔ)廠商開發(fā)的組件（需要實(shí)現(xiàn) Identity Service，Controller Service，Node Service）

我們來看下左邊的 CSI Driver Controller 部分，它是通過多個(gè) Sidecar 組件配合第三方實(shí)現(xiàn)的插件(Controller Service)來完成的。

正如上面提到的，它負(fù)責(zé)管理存儲(chǔ)卷的生命周期，包括創(chuàng)建、刪除和擴(kuò)容等操作。換句話說，我們的存儲(chǔ)廠商能夠提供什么樣的能力，部署 Controller 的時(shí)候，就需要提供與之對(duì)應(yīng)的 Sidecar 容器一起部署。

好比說我的 CSI Driver 只提供了 Dynamic provisioning 的能力，其他能力的接口我都沒實(shí)現(xiàn)，在控制器部署的時(shí)候，我只需要將 external-provisioner 和我的 Controller Service 部署在一個(gè) Pod 即可，組件的選擇完全取決于三方的實(shí)現(xiàn)。

Kubernetes CSI Sidecar Containers

#1. external-provisioner

external-provisioner 是一個(gè) Sidecar 容器，用于在 Kubernetes 中動(dòng)態(tài)地創(chuàng)建和刪除外部存儲(chǔ)卷。

當(dāng)一個(gè)新的 PVC (PersistentVolumeClaim) 被創(chuàng)建時(shí)，external-provisioner 會(huì)向外部存儲(chǔ)系統(tǒng)發(fā)起請(qǐng)求，以創(chuàng)建相應(yīng)的存儲(chǔ)卷，并將其與 PVC 關(guān)聯(lián)，從而滿足 Pod 對(duì)持久化存儲(chǔ)的需求。

external-provisioner 實(shí)際上會(huì)執(zhí)行檢查，以驗(yàn)證 PVC 中是否存在注解 volume.kubernetes.io/storage-provisioner，并且該注解的值是否與 CSI 驅(qū)動(dòng)程序的名稱相匹配。整個(gè)流程貫穿了 PV Controller 這個(gè)組件。

圖片

provision

這里涉及到的兩個(gè)操作分別對(duì)應(yīng)著 Controller Service 中的 CreateVolume 和 DeleteVolume 兩個(gè)接口的實(shí)現(xiàn)，它們的調(diào)用者正是 External Provisoner。

這一流程的核心是，external-provisioner 充當(dāng)了中間人，通過 Kubernetes 的 PVC 和 StorageClass 機(jī)制，將 Pod 的持久存儲(chǔ)需求傳遞給外部存儲(chǔ)系統(tǒng)。這使得存儲(chǔ)卷的創(chuàng)建和管理能夠無縫集成到 Kubernetes 集群中，為應(yīng)用提供了持久性的存儲(chǔ)解決方案。

思考

假設(shè)每個(gè) PVC 背后對(duì)應(yīng)的 Volume 都需要獨(dú)立加密，并且加密密鑰也各不相同，PVC 的 Spec 中已經(jīng)沒有額外的參數(shù)來提供這些信息了，那么我們?nèi)绾螌⑦@些加密密鑰傳遞給 CSI 接口呢？

這里有必要提一下 CSI Operation Secrets 這個(gè)概念，它允許針對(duì)每種不同的 CSI 操作定制不同的 Secret，并且通過 StorageClass 與之配合使用。

讓我們來看下面這個(gè) StorageClass 的定義作為例子：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: xfs2-sc-4-per-volume
provisioner: xfs2.csi.basebit.ai
parameters:
  csi.storage.k8s.io/provisioner-secret-name: ${pvc.name}
  csi.storage.k8s.io/provisioner-secret-namespace: ${pvc.namespace}

需要關(guān)注的是 parameters 字段中的 csi.storage.k8s.io/provisioner-secret-name 字段的值，它使用了變量 ${pvc.name}。怎么理解呢？

具體而言，當(dāng)我們使用 ${pvc.name} 作為 csi.storage.k8s.io/provisioner-secret-name 參數(shù)的值時(shí)，每次創(chuàng)建 PVC 后，都可以為它創(chuàng)建一個(gè)對(duì)應(yīng)的 Provisioner Secret，并將該 PVC 的名稱作為 Provisioner Secret 的名稱。

這樣，每個(gè) PVC 都會(huì)擁有一個(gè)唯一的 Provisioner Secret，用于身份驗(yàn)證和認(rèn)證。Secret 的具體定義取決于每個(gè) CSI 驅(qū)動(dòng)器的實(shí)現(xiàn)。在針對(duì)創(chuàng)建存儲(chǔ)卷的場(chǎng)景中，CreateVolumeRequest 可以獲取到 Secret 的詳細(xì)信息。

這種參數(shù)化技術(shù)是 Kubernetes 中允許的一種靈活方式，可用于在運(yùn)行時(shí)動(dòng)態(tài)生成配置文件

provision、delete、expand、attach 和 detach 等操作通常也需要 CSI 驅(qū)動(dòng)程序在存儲(chǔ)后端使用憑證，后面就不再多做贅述了。
如需了解更多高級(jí)用法，請(qǐng)參考文檔：StorageClass Secrets[2]

#2. external-attacher

external-attacher 是一個(gè) Sidecar 容器，其作用是在 Kubernetes 節(jié)點(diǎn)上動(dòng)態(tài)地進(jìn)行外部存儲(chǔ)卷的掛載（Attach）和卸載（Detach）操作。

它是通過監(jiān)聽 Kubernetes API Server 中的 VolumeAttachment 對(duì)象，來觸發(fā) Controller Service 中的 ControllerPublishVolume 和 ControllerUnpublishVolume 兩個(gè)接口調(diào)用。

然而，并不是所有情況下都需要使用 attach/detach 操作，尤其是在一些分布式文件系統(tǒng)的 CSI 驅(qū)動(dòng)程序中，這樣的操作可能并不適用。因此，可以說 attach/detach 是一項(xiàng)可選的特性。

#3. external-resizer

external-resizer 是一個(gè) Sidecar 容器，用于調(diào)整外部存儲(chǔ)卷的大小。

當(dāng) PVC 的存儲(chǔ)需求發(fā)生變化時(shí)，external-resizer 可以根據(jù)需求調(diào)整外部存儲(chǔ)卷的大小，確保存儲(chǔ)資源得到最優(yōu)的利用。

它會(huì)調(diào)用 Controller Service 中的 ControllerExpandVolume 接口。

#4. external-snapshotter

external-snapshotter 是一個(gè) Sidecar 容器，用于實(shí)現(xiàn)外部存儲(chǔ)卷的快照功能。

它是通過監(jiān)聽 Kubernetes Snapshot CRD 對(duì)象，來觸發(fā) Controller Service 中的 CreateSnapshot 和 DeleteSnapshot 兩個(gè)接口調(diào)用。

它負(fù)責(zé)在外部存儲(chǔ)系統(tǒng)上創(chuàng)建、刪除和管理快照，以便于實(shí)現(xiàn)數(shù)據(jù)備份、恢復(fù)和復(fù)制等功能。

思考

這玩意兒有什么用呢？VolumeSnapshot 允許在 Kubernetes 集群中創(chuàng)建卷的快照，這些快照可以用于數(shù)據(jù)備份和應(yīng)用程序恢復(fù)。當(dāng)應(yīng)用程序出現(xiàn)故障或數(shù)據(jù)損壞時(shí)，我們可以使用先前創(chuàng)建的快照來還原應(yīng)用程序的狀態(tài)。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: redis-data-my-redis-master-0
spec:
  dataSource:
    name: my-server-snapshot-0
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

#5. liveness-probe

liveness-probe 是一個(gè) Sidecar 容器，用于監(jiān)控 CSI 驅(qū)動(dòng)程序的運(yùn)行狀況，并通過 Liveness Probe 機(jī)制向 Kubernetes 報(bào)告。

如果驅(qū)動(dòng)器出現(xiàn)故障或停止響應(yīng)，Kubernetes 將重啟相關(guān)的 Pod(Controller Service/Node Service) 以確保服務(wù)的可用性。

有關(guān)具體的用法和配置示例，可以參考這里[3]的說明文檔。

思考

實(shí)際上 livenessProbe 是通過 CSI 驅(qū)動(dòng)程序在容器上設(shè)置的。liveness-probe sidecar 容器的主要作用是提供了 /healthz 這個(gè) HTTP 端點(diǎn)。它背后 checkProbe 最終向 CSI 驅(qū)動(dòng)程序的 Identity Service 中的 Probe 接口發(fā)起調(diào)用，用來檢測(cè)插件是否處于健康狀態(tài)。

這種架構(gòu)使得插件的健康狀態(tài)檢查與應(yīng)用程序分離，通過 CSI 驅(qū)動(dòng)程序的 Probe 接口進(jìn)行通信。

事實(shí)上 Kubernetes 從 v1.23 開始具有內(nèi)置 gRPC 健康探測(cè)，已經(jīng)不需要這么麻煩了。

#6. node-driver-registrar

node-driver-registrar 是一個(gè)作為 Sidecar 容器運(yùn)行的組件，其主要職責(zé)是通過直接調(diào)用 CSI 驅(qū)動(dòng)程序的 Node Service 中的 NodeGetInfo 接口，獲取驅(qū)動(dòng)程序的信息。

然后，它會(huì)利用 kubelet 的插件注冊(cè)機(jī)制，將這些驅(qū)動(dòng)程序的信息注冊(cè)到相應(yīng)節(jié)點(diǎn)的 kubelet 中。

小結(jié)

我們需要記住這張能力關(guān)系組合表，它對(duì)部署 CSI 驅(qū)動(dòng)程序和排查問題非常的有用。

圖片

如何實(shí)現(xiàn)一個(gè) CSI 插件？

要實(shí)現(xiàn)一個(gè) CSI 驅(qū)動(dòng)程序，確實(shí)只需要完成一系列接口的實(shí)現(xiàn)即可，但僅僅完成這些接口的實(shí)現(xiàn)還不足以構(gòu)建一個(gè)穩(wěn)健、可用的 CSI 驅(qū)動(dòng)程序，構(gòu)建一個(gè)穩(wěn)健的驅(qū)動(dòng)程序還需要考慮方方面面。

CSI Plugin components

下面是每一個(gè) CSI 驅(qū)動(dòng)程序要實(shí)現(xiàn)的接口清單。

其中 Identity Service 負(fù)責(zé)提供 CSI 驅(qū)動(dòng)程序的身份信息，Controller Service 負(fù)責(zé) Volume 的管理，Node Service 負(fù)責(zé)將 Volume 掛載到 Pod 中。

圖片

正如前面提到的，一個(gè) CSI 驅(qū)動(dòng)程序能提供什么樣的能力，取決于各自存儲(chǔ)廠商的實(shí)現(xiàn)，三個(gè)組件都有對(duì)外暴露能力的接口，比如

Identity Service 中的 GetPluginCapabilities 方法，表示該 CSI 驅(qū)動(dòng)程序主要提供了哪些功能。
Controller Service 中的 ControllerGetCapabilities 方法，實(shí)際上告訴 K8s，CSI 驅(qū)動(dòng)程序具備哪些能力。這些能力可以包括卷的創(chuàng)建、刪除、擴(kuò)容、快照等操作。
Node Service 中的 NodeGetCapabilities 方法，提供 Node plugin 的能力列表。

CSI lifecycle

在通常情況下，每個(gè) Volume 都會(huì)經(jīng)歷完整的生命周期過程。

圖片

從創(chuàng)建 PersistentVolumeClaim（PVC）開始，接著被 Pod 所使用，這個(gè)過程包括三個(gè)主要階段：Provision -> Attach -> Mount。

隨后，從 Pod 開始被刪除，直到 PVC 被刪除，整個(gè)過程又經(jīng)歷了另外三個(gè)關(guān)鍵階段: Unmount -> Detach -> Delete。

然而，存在一種特殊的存儲(chǔ)卷，它就是 Ephemeral Inline Volumes，它可以通過改變 CSIDriver 的規(guī)范中的 volumeLifecycleModes 參數(shù)來改變其生命周期。

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: xfs2.csi.basebit.ai
spec:
  ...
  volumeLifecycleModes:
  - Ephemeral

Ephemeral 模式表示存儲(chǔ)卷是臨時(shí)的，會(huì)隨著 Pod 的生命周期結(jié)束而被釋放。對(duì)于這種類型的存儲(chǔ)卷，Kubelet 在向 CSI 驅(qū)動(dòng)請(qǐng)求卷時(shí)，只會(huì)調(diào)用 NodePublishVolume，省略了其他階段（例如 CreateVolume、NodeStageVolume）的調(diào)用。而在 Pod 結(jié)束需要釋放存儲(chǔ)卷時(shí)，只會(huì)調(diào)用 NodeUnpublishVolume。

具體的 Pod 規(guī)范如下所示：

kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeMounts:
      - mountPath: "/data"
        name: my-csi-inline-vol
      command: ["sleep","1000000"]
  volumes:
    - name: my-csi-inline-vol
      csi:
        driver: xfs2.csi.basebit.ai
        volumeAttributes:
          foo: bar

這里的 volumeAttributes 用于指定驅(qū)動(dòng)程序需要準(zhǔn)備的卷的屬性。這些屬性在每個(gè)驅(qū)動(dòng)程序中都是特定的，沒有標(biāo)準(zhǔn)化的實(shí)現(xiàn)方法。

Ephemeral 使用案例

Secrets Store CSI Driver[4]允許用戶將 Secret 作為內(nèi)聯(lián)卷從外部掛載到一個(gè) Pod 中。當(dāng)密鑰存儲(chǔ)在外部管理服務(wù)或 Vault 實(shí)例中時(shí)，這可能很有用。
Cert-Manager CSI Driver[5] 與 cert-manager[6] 協(xié)同工作，無縫地請(qǐng)求和掛載證書密鑰對(duì)到一個(gè) Pod 中。這使得證書可以在應(yīng)用 Pod 中自動(dòng)更新。

通過這個(gè)特性，再一次說明了我們并不要求所有的接口都需要實(shí)現(xiàn)，取決于插件實(shí)現(xiàn)方提供什么樣的能力，我們?cè)偃?shí)現(xiàn)相應(yīng)的邏輯即可。

CSI idempotent

我們應(yīng)該確保所有的 CSI 操作都是冪等的，這意味著同一操作被多次調(diào)用時(shí)，結(jié)果始終保持一致，不會(huì)因?yàn)槎啻握{(diào)用而導(dǎo)致狀態(tài)變化或產(chǎn)生額外的副作用。這種冪等性是保證系統(tǒng)穩(wěn)定性和一致性的關(guān)鍵因素。

舉個(gè)例子，假設(shè)我們做一個(gè) DeleteVolume 的操作，如果底層的 Volume 已經(jīng)不存在了，依然不能報(bào)錯(cuò)。無論是第一次執(zhí)行 DeleteVolume 還是多次重試，操作的最終結(jié)果都應(yīng)該是相同的。

這里不得不提一下 CSI Sanity Test，它可用于驗(yàn)證 CSI 驅(qū)動(dòng)程序的基本功能和穩(wěn)定性。它會(huì)模擬不同的錯(cuò)誤和異常情況，例如創(chuàng)建已存在的卷、卸載不存在的卷等，以驗(yàn)證驅(qū)動(dòng)程序?qū)@些情況的處理是否正確。

它能夠驗(yàn)證 CSI 驅(qū)動(dòng)程序是否符合 Kubernetes CSI 規(guī)范并且可以正確運(yùn)行，對(duì)開發(fā) CSI 驅(qū)動(dòng)程序非常的有幫助。比如說可以幫助開發(fā)人員快速定位和修復(fù)常見問題，減少在生產(chǎn)環(huán)境中出現(xiàn)意外問題的可能性。

官方文檔中詳細(xì)闡述了規(guī)范（Container Storage Interface，CSI）的內(nèi)容，同時(shí)還提供了與開發(fā)相關(guān)的注意事項(xiàng)。這些注意事項(xiàng)涵蓋了規(guī)范中的一些關(guān)鍵要點(diǎn)，以及在開發(fā)過程中可能會(huì)遇到的挑戰(zhàn)和解決方案。我們可以在 Container Storage Interface (CSI) Specification [7] 找到這些詳細(xì)信息。

如何部署 CSI?

標(biāo)準(zhǔn)的 CSI 驅(qū)動(dòng)程序部署架構(gòu)如下圖所示，其中包括一個(gè)由 DaemonSet 運(yùn)行的 CSI Node 組件，以及一個(gè)運(yùn)行在 StatefulSet 內(nèi)的 CSI Controller 組件。

?? 這兩個(gè)容器通過本地 Socket (Unix Domain Socket, UDS)進(jìn)行通信，并使用 gRPC 協(xié)議。CSI 插件直接與同一宿主機(jī)上的 K8s 組件進(jìn)行交互，通過本機(jī)進(jìn)程之間的 Unix 域套接字通信，相較于 TCP 套接字，具備更高的通信效率和性能。

圖片

在部署 CSI Node 時(shí)，需要將宿主機(jī)上的 kubelet 目錄(/var/lib/kubelet)掛載到驅(qū)動(dòng)程序的容器內(nèi)，且需將 Mount Propagation 設(shè)置為 Bidirectional。這樣，驅(qū)動(dòng)程序容器內(nèi)的后續(xù) Mount/Umount 操作能夠傳播到宿主機(jī)上。

請(qǐng)注意，這只是一個(gè)高層次的架構(gòu)概述，具體的實(shí)施細(xì)節(jié)可能會(huì)因不同的 CSI 插件和環(huán)境而有所變化。

CSI 在集群部署成功后，可以用以下兩個(gè)命令來做下檢查：

#1. 查看集群內(nèi)安裝的 CSI Driver

? kubectl get csidrivers

#2. 列出哪些節(jié)點(diǎn)具有 CSI

? kubectl get csinodes

總結(jié)

通過標(biāo)準(zhǔn)化容器編排器與存儲(chǔ)供應(yīng)商之間的接口，CSI 構(gòu)建了一種統(tǒng)一的范式，確保所有與 CSI 兼容的存儲(chǔ)系統(tǒng)都遵循相同的實(shí)現(xiàn)規(guī)范。事實(shí)上，通過編寫一個(gè) CSI 驅(qū)動(dòng)程序，我們不僅為 Kubernetes 存儲(chǔ)架構(gòu)增添了新的維度，還深化了對(duì)存儲(chǔ)資源管理的理解。

下一期，我將繼續(xù)與大家分享在實(shí)際工作中使用 CSI Driver 遇到的問題和挑戰(zhàn)。