建站
咨詢
售后
建站咨詢
新聞中心
現(xiàn)在，我將繼續(xù)和大家聊一聊關(guān)于 K8s 存儲(chǔ)的一個(gè)重要組成部分：Container Storage Interface (CSI)。在接下來的內(nèi)容中，我們將會(huì)了解到 CSI 的工作原理、核心概念以及如何將其集成到你的容器化環(huán)境中。
創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比祁連網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式祁連網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋祁連地區(qū)。費(fèi)用合理售后完善，10余年實(shí)體公司更值得信賴。
為什么需要 CSI ？它解決了什么問題？
在學(xué)習(xí) CSI 之前，了解其產(chǎn)生的背景以及它能夠解決的問題我覺得是很有必要的。
為什么需要 CSI
雖然 Kubernetes 平臺(tái)它本身支持了非常多的存儲(chǔ)插件，但是畢竟也是有限的，永遠(yuǎn)無法滿足用戶日益增長的需求，比方說有客戶要求我們的 Paas 平臺(tái)必須接國產(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)生隱患。
另外，這種方法它也不方便測試和維護(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ǔ)卷的場景中，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)用，用來檢測插件是否處于健康狀態(tài)。
這種架構(gòu)使得插件的健康狀態(tài)檢查與應(yīng)用程序分離，通過 CSI 驅(qū)動(dòng)程序的 Probe 接口進(jìn)行通信。
事實(shí)上 Kubernetes 從 v1.23 開始具有內(nèi)置 gRPC 健康探測，已經(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:
- EphemeralEphemeral 模式表示存儲(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é)
CSI 是 Kubernetes 存儲(chǔ)體系中的核心組件，為存儲(chǔ)供應(yīng)商提供了靈活且可擴(kuò)展的集成方式，也為 Kubernetes 用戶提供了高效穩(wěn)定的存儲(chǔ)解決方案。
通過標(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)。
參考資料
[1]Kubernetes CSI Sidecar Containers: https://kubernetes-csi.github.io/docs/sidecar-containers.html
[2]StorageClass Secrets: https://kubernetes-csi.github.io/docs/secrets-and-credentials-storage-class.html
[3]這里: https://github.com/kubernetes-csi/livenessprobe/blob/master/deployment/kubernetes/livenessprobe-sidecar.yaml
[4]Secrets Store CSI Driver: https://github.com/kubernetes-sigs/secrets-store-csi-driver
[5]Cert-Manager CSI Driver: https://github.com/cert-manager/csi-driver
[6]cert-manager: https://cert-manager.io/
[7]Container Storage Interface (CSI) Specification : https://github.com/container-storage-interface/spec/blob/master/spec.md
[8]CSI Documentation: https://kubernetes-csi.github.io/docs/
[9]CloudNativeCon EU 2018 CSI Jie Yu: https://schd.ws/hosted_files/kccnceu18/fb/CloudNativeCon%20EU%202018%20CSI%20Jie%20Yu.pdf
分享文章：KubernetesStorage:淺談如何實(shí)現(xiàn)一個(gè)CSI插件
文章路徑：http://fisionsoft.com.cn/article/djcohje.html
