云計(jì)算

作者 | 孫志恒（惠志） 阿里巴巴開發(fā)工程師

導(dǎo)讀：眾所周知，K8s 的持久化存儲(chǔ)（Persistent Storage）保證了應(yīng)用數(shù)據(jù)獨(dú)立于應(yīng)用生命周期而存在，但其內(nèi)部實(shí)現(xiàn)卻少有人提及。K8s 內(nèi)部的存儲(chǔ)流程到底是怎樣的？PV、PVC、StorageClass、Kubelet、CSI 插件等之間的調(diào)用關(guān)系又如何，這些謎底將在本文中一一揭曉。

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供石樓網(wǎng)站建設(shè)、石樓做網(wǎng)站、石樓網(wǎng)站設(shè)計(jì)、石樓網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、石樓企業(yè)網(wǎng)站模板建站服務(wù)，十多年石樓做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

K8s 持久化存儲(chǔ)基礎(chǔ)

在進(jìn)行 K8s 存儲(chǔ)流程講解之前，先回顧一下 K8s 中持久化存儲(chǔ)的基礎(chǔ)概念。

1. 名詞解釋

in-tree：代碼邏輯在 K8s 官方倉庫中；

out-of-tree：代碼邏輯在 K8s 官方倉庫之外，實(shí)現(xiàn)與 K8s 代碼的解耦；

PV：PersistentVolume，集群級(jí)別的資源，由 集群管理員 or External Provisioner 創(chuàng)建。PV 的生命周期獨(dú)立于使用 PV 的 Pod，PV 的 .Spec 中保存了存儲(chǔ)設(shè)備的詳細(xì)信息；

PVC：PersistentVolumeClaim，命名空間（namespace）級(jí)別的資源，由 用戶 or StatefulSet 控制器（根據(jù)VolumeClaimTemplate） 創(chuàng)建。PVC 類似于 Pod，Pod 消耗 Node 資源，PVC 消耗 PV 資源。Pod 可以請(qǐng)求特定級(jí)別的資源（CPU 和內(nèi)存），而 PVC 可以請(qǐng)求特定存儲(chǔ)卷的大小及訪問模式（Access Mode）；

StorageClass：StorageClass 是集群級(jí)別的資源，由集群管理員創(chuàng)建。SC 為管理員提供了一種動(dòng)態(tài)提供存儲(chǔ)卷的“類”模板，SC 中的 .Spec 中詳細(xì)定義了存儲(chǔ)卷 PV 的不同服務(wù)質(zhì)量級(jí)別、備份策略等等；

CSI：Container Storage Interface，目的是定義行業(yè)標(biāo)準(zhǔn)的“容器存儲(chǔ)接口”，使存儲(chǔ)供應(yīng)商（SP）基于 CSI 標(biāo)準(zhǔn)開發(fā)的插件可以在不同容器編排（CO）系統(tǒng)中工作，CO 系統(tǒng)包括 Kubernetes、Mesos、Swarm 等。

2. 組件介紹

PV Controller：負(fù)責(zé) PV/PVC 綁定及周期管理，根據(jù)需求進(jìn)行數(shù)據(jù)卷的 Provision/Delete 操作；

AD Controller：負(fù)責(zé)數(shù)據(jù)卷的 Attach/Detach 操作，將設(shè)備掛接到目標(biāo)節(jié)點(diǎn)；

Kubelet：Kubelet 是在每個(gè) Node 節(jié)點(diǎn)上運(yùn)行的主要 “節(jié)點(diǎn)代理”，功能是 Pod 生命周期管理、容器健康檢查、容器監(jiān)控等；

Volume Manager：Kubelet 中的組件，負(fù)責(zé)管理數(shù)據(jù)卷的 Mount/Umount 操作（也負(fù)責(zé)數(shù)據(jù)卷的 Attach/Detach 操作，需配置 kubelet 相關(guān)參數(shù)開啟該特性）、卷設(shè)備的格式化等等；

Volume Plugins：存儲(chǔ)插件，由存儲(chǔ)供應(yīng)商開發(fā)，目的在于擴(kuò)展各種存儲(chǔ)類型的卷管理能力，實(shí)現(xiàn)第三方存儲(chǔ)的各種操作能力，即是 上面藍(lán)色操作的實(shí)現(xiàn)。Volume Plugins 有 in-tree 和 out-of-tree 兩種；

External Provioner：External Provioner 是一種 sidecar 容器，作用是調(diào)用 Volume Plugins 中的 CreateVolume 和 DeleteVolume 函數(shù)來執(zhí)行 Provision/Delete 操作。因?yàn)?K8s 的 PV 控制器無法直接調(diào)用 Volume Plugins 的相關(guān)函數(shù)，故由 External Provioner 通過 gRPC 來調(diào)用；

External Attacher：External Attacher 是一種 sidecar 容器，作用是調(diào)用 Volume Plugins 中的 ControllerPublishVolume 和 ControllerUnpublishVolume 函數(shù)來執(zhí)行 Attach/Detach 操作。因?yàn)?K8s 的 AD 控制器無法直接調(diào)用 Volume Plugins 的相關(guān)函數(shù)，故由 External Attacher 通過 gRPC 來調(diào)用。

3. 持久卷使用

Kubernetes 為了使應(yīng)用程序及其開發(fā)人員能夠正常請(qǐng)求存儲(chǔ)資源， 避免處理存儲(chǔ)設(shè)施細(xì)節(jié)，引入了 PV 和 PVC。創(chuàng)建 PV 有兩種方式：

一種是集群管理員通過手動(dòng)方式 靜態(tài)創(chuàng)建應(yīng)用所需要的 PV；

另一種是用戶手動(dòng)創(chuàng)建 PVC 并由 Provisioner 組件 動(dòng)態(tài)創(chuàng)建對(duì)應(yīng)的 PV。

下面我們以 NFS 共享存儲(chǔ)為例來看二者區(qū)別。

靜態(tài)創(chuàng)建存儲(chǔ)卷

靜態(tài)創(chuàng)建存儲(chǔ)卷流程如下圖所示：

第一步：集群管理員創(chuàng)建 NFS PV，NFS 屬于 K8s 原生支持的 in-tree 存儲(chǔ)類型。yaml 文件如下：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 192.168.4.1
    path: /nfs_storage

第二步：用戶創(chuàng)建 PVC，yaml 文件如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

通過 kubectl get pv 命令可看到 PV 和 PVC 已綁定：

[root@huizhi ~]# kubectl get pvc
NAME      STATUS   VOLUME               CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-pvc   Bound    nfs-pv-no-affinity   10Gi       RWO                           4s

第三步：用戶創(chuàng)建應(yīng)用，并使用第二步創(chuàng)建的 PVC。

apiVersion: v1
kind: Pod
metadata:
  name: test-nfs
spec:
  containers:
  - image: nginx:alpine
    imagePullPolicy: IfNotPresent
    name: nginx
    volumeMounts:
    - mountPath: /data
      name: nfs-volume
  volumes:
  - name: nfs-volume
    persistentVolumeClaim:
      claimName: nfs-pvc

此時(shí) NFS 的遠(yuǎn)端存儲(chǔ)就掛載了到 Pod 中 nginx 容器的 /data 目錄下。

動(dòng)態(tài)創(chuàng)建存儲(chǔ)卷

動(dòng)態(tài)創(chuàng)建存儲(chǔ)卷，要求集群中部署有 nfs-client-provisioner 以及對(duì)應(yīng)的 storageclass。

動(dòng)態(tài)創(chuàng)建存儲(chǔ)卷相比靜態(tài)創(chuàng)建存儲(chǔ)卷，少了集群管理員的干預(yù)，流程如下圖所示：

集群管理員只需要保證環(huán)境中有 NFS 相關(guān)的 storageclass 即可：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: nfs-sc
provisioner: example.com/nfs
mountOptions:
  - vers=4.1

第一步：用戶創(chuàng)建 PVC，此處 PVC 的 storageClassName 指定為上面 NFS 的 storageclass 名稱：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nfs
  annotations:
    volume.beta.kubernetes.io/storage-class: example-nfs
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Mi
  storageClassName: nfs-sc

第二步：集群中的 nfs-client-provisioner 會(huì)動(dòng)態(tài)創(chuàng)建相應(yīng) PV。此時(shí)可看到環(huán)境中 PV 已創(chuàng)建，并與 PVC 已綁定。

[root@huizhi ~]# kubectl get pv
NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM         REASON    AGE
pvc-dce84888-7a9d-11e6-b1ee-5254001e0c1b   10Mi        RWX           Delete          Bound       default/nfs             4s

第三步：用戶創(chuàng)建應(yīng)用，并使用第二步創(chuàng)建的 PVC，同靜態(tài)創(chuàng)建存儲(chǔ)卷的第三步。

K8s 持久化存儲(chǔ)流程 1. 流程概覽

此處借鑒 @郡寶 在 云原生存儲(chǔ)課程中的流程圖

流程如下：

用戶創(chuàng)建了一個(gè)包含 PVC 的 Pod，該 PVC 要求使用動(dòng)態(tài)存儲(chǔ)卷；

Scheduler 根據(jù) Pod 配置、節(jié)點(diǎn)狀態(tài)、PV 配置等信息，把 Pod 調(diào)度到一個(gè)合適的 Worker 節(jié)點(diǎn)上；

PV 控制器 watch 到該 Pod 使用的 PVC 處于 Pending 狀態(tài)，于是調(diào)用 Volume Plugin（in-tree）創(chuàng)建存儲(chǔ)卷，并創(chuàng)建 PV 對(duì)象（out-of-tree 由 External Provisioner 來處理）；

AD 控制器發(fā)現(xiàn) Pod 和 PVC 處于待掛接狀態(tài)，于是調(diào)用 Volume Plugin 掛接存儲(chǔ)設(shè)備到目標(biāo) Worker 節(jié)點(diǎn)上

在 Worker 節(jié)點(diǎn)上， Kubelet 中的 Volume Manager 等待存儲(chǔ)設(shè)備掛接完成，并通過 Volume Plugin 將設(shè)備掛載到 全局目錄： /var/lib/kubelet/pods/[pod uid]/volumes/kubernetes.io~iscsi/[PV
name]（以 iscsi 為例）；

Kubelet 通過 Docker 啟動(dòng) Pod 的 Containers，用 bind mount 方式將已掛載到本地全局目錄的卷映射到 容器中。

更詳細(xì)的流程如下：

2. 流程詳解

不同 K8s 版本，持久化存儲(chǔ)流程略有區(qū)別。本文基于 Kubernetes 1.14.8 版本。

從上述流程圖中可看到，存儲(chǔ)卷從創(chuàng)建到提供應(yīng)用使用共分為三個(gè)階段： Provision/Delete、Attach/Detach、Mount/Unmount。

provisioning volumes

PV 控制器中有兩個(gè) Worker：

ClaimWorker：處理 PVC 的 add / update / delete 相關(guān)事件以及 PVC 的狀態(tài)遷移； VolumeWorker：負(fù)責(zé) PV 的狀態(tài)遷移。

PV 狀態(tài)遷移（UpdatePVStatus）：

PV 初始狀態(tài)為 Available，當(dāng) PV 與 PVC 綁定后，狀態(tài)變?yōu)?Bound； 與 PV 綁定的 PVC 刪除后，狀態(tài)變?yōu)?Released； 當(dāng) PV 回收策略為 Recycled 或手動(dòng)刪除 PV 的 .Spec.ClaimRef 后，PV 狀態(tài)變?yōu)?Available； 當(dāng) PV 回收策略未知或 Recycle 失敗或存儲(chǔ)卷刪除失敗，PV 狀態(tài)變?yōu)?Failed； 手動(dòng)刪除 PV 的 .Spec.ClaimRef，PV 狀態(tài)變?yōu)?Available。

PVC 狀態(tài)遷移（UpdatePVCStatus）：

當(dāng)集群中不存在滿足 PVC 條件的 PV 時(shí)，PVC 狀態(tài)為 Pending。在 PV 與 PVC 綁定后，PVC 狀態(tài)由 Pending 變?yōu)?Bound； 與 PVC 綁定的 PV 在環(huán)境中被刪除，PVC 狀態(tài)變?yōu)?Lost； 再次與一個(gè) 同名 PV 綁定后，PVC 狀態(tài)變?yōu)?Bound。

Provisioning 流程如下（此處模擬用戶創(chuàng)建一個(gè)新 PVC）：

靜態(tài)存儲(chǔ)卷流程（FindBestMatch）： PV 控制器首先在環(huán)境中篩選一個(gè)狀態(tài)為 Available 的 PV 與新 PVC匹配。

DelayBinding：PV 控制器判斷該 PVC 是否需要 延遲綁定：1. 查看 PVC 的 annotation 中是否包含volume.kubernetes.io/selected-node，若存在則表示該 PVC 已經(jīng)被調(diào)度器指定好了節(jié)點(diǎn)（屬于 ProvisionVolume），故不需要延遲綁定；2. 若 PVC 的 annotation 中不存在 volume.kubernetes.io/selected-node，同時(shí)沒有 StorageClass，默認(rèn)表示不需要延遲綁定；若有 StorageClass，查看其 VolumeBindingMode 字段，若為 WaitForFirstConsumer 則需要延遲綁定，若為 Immediate 則不需要延遲綁定；

FindBestMatchPVForClaim：PV 控制器嘗試找一個(gè)滿足 PVC 要求的環(huán)境中現(xiàn)有的 PV。PV 控制器會(huì)將 所有的 PV 進(jìn)行一次篩選，并會(huì)從滿足條件的 PV 中選擇一個(gè)匹配的PV。篩選規(guī)則：1. VolumeMode 是否匹配；2. PV 是否已綁定到 PVC 上；3. PV 的 .Status.Phase 是否為 Available；4. LabelSelector 檢查，PV 與 PVC 的 label 要保持一致；5. PV 與 PVC 的 StorageClass 是否一致；6. 每次迭代更新最小滿足 PVC requested size 的 PV，并作為最終結(jié)果返回；

Bind：PV 控制器對(duì)選中的 PV、PVC 進(jìn)行綁定：1. 更新 PV 的 .Spec.ClaimRef 信息為當(dāng)前 PVC；2. 更新 PV 的 .Status.Phase 為 Bound；3. 新增 PV 的 annotation ： pv.kubernetes.io/bound-by-controller: “yes”；4. 更新 PVC 的 .Spec.VolumeName 為 PV 名稱；5. 更新 PVC 的 .Status.Phase 為 Bound；6. 新增 PVC 的 annotation：pv.kubernetes.io/bound-by-controller: “yes” 和 pv.kubernetes.io/bind-completed: “yes”；

動(dòng)態(tài)存儲(chǔ)卷流程（ProvisionVolume）：若環(huán)境中沒有合適的 PV，則進(jìn)入動(dòng)態(tài) Provisioning 場景：

Before Provisioning：1. PV 控制器首先判斷 PVC 使用的 StorageClass 是 in-tree 還是 out-of-tree：通過查看 StorageClass 的 Provisioner 字段是否包含 “kubernetes.io/“ 前綴來判斷；2. PV 控制器更新 PVC 的 annotation：claim.Annotations[“volume.beta.kubernetes.io/storage-provisioner”] = storageClass.Provisioner；

in-tree Provisioning（internal provisioning）：1. in-tree 的 Provioner 會(huì)實(shí)現(xiàn) ProvisionableVolumePlugin 接口的 NewProvisioner 方法，用來返回一個(gè)新的 Provisioner；2. PV 控制器調(diào)用 Provisioner 的 Provision 函數(shù)，該函數(shù)會(huì)返回一個(gè) PV 對(duì)象；3. PV 控制器創(chuàng)建上一步返回的 PV 對(duì)象，將其與 PVC 綁定，Spec.ClaimRef 設(shè)置為 PVC，.Status.Phase 設(shè)置為 Bound，.Spec.StorageClassName 設(shè)置為與 PVC 相同的 StorageClassName；同時(shí)新增 annotation：”pv.kubernetes.io/bound-by-controller”=”yes” 和 “pv.kubernetes.io/provisioned-by”=plugin.GetPluginName()；

out-of-tree Provisioning（external provisioning）：1. External Provisioner 檢查 PVC 中的 claim.Spec.VolumeName 是否為空，不為空則直接跳過該 PVC；2. External Provisioner 檢查 PVC 中的 claim.Annotations[“volume.beta.kubernetes.io/storage-provisioner”] 是否等于自己的 Provisioner Name（External Provisioner 在啟動(dòng)時(shí)會(huì)傳入—provisioner 參數(shù)來確定自己的 Provisioner Name）；3. 若 PVC 的 VolumeMode=Block，檢查 External Provisioner 是否支持塊設(shè)備；4. External Provisioner 調(diào)用 Provision 函數(shù)：通過 gRPC 調(diào)用 CSI 存儲(chǔ)插件的 CreateVolume 接口；5. External Provisioner 創(chuàng)建一個(gè) PV 來代表該 volume，同時(shí)將該 PV 與之前的 PVC 做綁定。

deleting volumes

Deleting 流程為 Provisioning 的反操作：

用戶刪除 PVC，刪除 PV 控制器改變 PV.Status.Phase 為 Released。

當(dāng) PV.Status.Phase == Released 時(shí)，PV 控制器首先檢查 Spec.PersistentVolumeReclaimPolicy 的值，為 Retain 時(shí)直接跳過，為 Delete 時(shí)：

in-tree Deleting：1. in-tree 的 Provioner 會(huì)實(shí)現(xiàn) DeletableVolumePlugin 接口的 NewDeleter 方法，用來返回一個(gè)新的 Deleter；2. 控制器調(diào)用 Deleter 的 Delete 函數(shù)，刪除對(duì)應(yīng) volume；3. 在 volume 刪除后，PV 控制器會(huì)刪除 PV 對(duì)象；

out-of-tree Deleting：1. External Provisioner 調(diào)用 Delete 函數(shù)，通過 gRPC 調(diào)用 CSI 插件的 DeleteVolume 接口；2. 在 volume 刪除后，External Provisioner 會(huì)刪除 PV 對(duì)象

Attaching Volumes

Kubelet 組件和 AD 控制器都可以做 attach/detach 操作，若 Kubelet 的啟動(dòng)參數(shù)中指定了—enable-controller-attach-detach，則由 Kubelet 來做；否則默認(rèn)由 AD 控制起來做。下面以 AD 控制器為例來講解 attach/detach 操作。

AD 控制器中有兩個(gè)核心變量：

DesiredStateOfWorld（DSW）：集群中預(yù)期的數(shù)據(jù)卷掛接狀態(tài)，包含了 nodes->volumes->pods 的信息； ActualStateOfWorld（ASW）：集群中實(shí)際的數(shù)據(jù)卷掛接狀態(tài)，包含了 volumes->nodes 的信息。

Attaching 流程如下：

AD 控制器根據(jù)集群中的資源信息，初始化 DSW 和 ASW。

AD 控制器內(nèi)部有三個(gè)組件周期性更新 DSW 和 ASW：

Reconciler。通過一個(gè) GoRoutine 周期性運(yùn)行， 確保 volume 掛接/摘除完畢。此期間不斷更新 ASW：

in-tree attaching：1. in-tree 的 Attacher 會(huì)實(shí)現(xiàn) AttachableVolumePlugin 接口的 NewAttacher 方法，用來返回一個(gè)新的 Attacher；2. AD 控制器調(diào)用 Attacher 的 Attach 函數(shù)進(jìn)行設(shè)備掛接；3. 更新 ASW。

out-of-tree attaching：1. 調(diào)用 in-tree 的 CSIAttacher 創(chuàng)建一個(gè) VolumeAttachement（VA）對(duì)象，該對(duì)象包含了 Attacher 信息、節(jié)點(diǎn)名稱、待掛接 PV 信息；2. External Attacher 會(huì) watch 集群中的 VolumeAttachement 資源，發(fā)現(xiàn)有需要掛接的數(shù)據(jù)卷時(shí)，調(diào)用 Attach 函數(shù)，通過 gRPC 調(diào)用 CSI 插件的 ControllerPublishVolume 接口。

DesiredStateOfWorldPopulator。通過一個(gè) GoRoutine 周期性運(yùn)行，主要功能是 更新 DSW：

findAndRemoveDeletedPods - 遍歷所有 DSW 中的 Pods，若其已從集群中刪除則從 DSW 中移除；
findAndAddActivePods - 遍歷所有 PodLister 中的 Pods，若 DSW 中不存在該 Pod 則添加至 DSW。 PVC Worker。watch PVC 的 add/update 事件，處理 PVC 相關(guān)的 Pod，并實(shí)時(shí)更新 DSW。 Detaching Volumes

Detaching 流程如下：

當(dāng) Pod 被刪除，AD 控制器會(huì) watch 到該事件。首先 AD 控制器檢查 Pod 所在的 Node 資源是否包含”volumes.kubernetes.io/keep-terminated-pod-volumes”標(biāo)簽，若包含則不做操作；不包含則從 DSW 中去掉該 volume；

AD 控制器通過 Reconciler 使 ActualStateOfWorld 狀態(tài)向 DesiredStateOfWorld 狀態(tài)靠近，當(dāng)發(fā)現(xiàn) ASW 中有 DSW 中不存在的 volume 時(shí)，會(huì)做 Detach 操作：

in-tree detaching：1. AD 控制器會(huì)實(shí)現(xiàn) AttachableVolumePlugin 接口的 NewDetacher 方法，用來返回一個(gè)新的 Detacher；2. 控制器調(diào)用 Detacher 的 Detach 函數(shù)，detach 對(duì)應(yīng) volume；3. AD 控制器更新 ASW。

out-of-tree detaching：1. AD 控制器調(diào)用 in-tree 的 CSIAttacher 刪除相關(guān) VolumeAttachement 對(duì)象；2. External Attacher 會(huì) watch 集群中的 VolumeAttachement（VA）資源，發(fā)現(xiàn)有需要摘除的數(shù)據(jù)卷時(shí)，調(diào)用 Detach 函數(shù)，通過 gRPC 調(diào)用 CSI 插件的 ControllerUnpublishVolume 接口；3. AD 控制器更新 ASW。

Volume Manager 中同樣也有兩個(gè)核心變量：

DesiredStateOfWorld（DSW）：集群中預(yù)期的數(shù)據(jù)卷掛載狀態(tài)，包含了 volumes->pods 的信息； ActualStateOfWorld（ASW）：集群中實(shí)際的數(shù)據(jù)卷掛載狀態(tài)，包含了 volumes->pods 的信息。

Mounting/UnMounting 流程如下：

全局目錄（global mount path）存在的目的：塊設(shè)備在 Linux 上只能掛載一次，而在 K8s 場景中，一個(gè) PV 可能被掛載到同一個(gè) Node 上的多個(gè) Pod 實(shí)例中。若塊設(shè)備格式化后先掛載至 Node 上的一個(gè)臨時(shí)全局目錄，然后再使用 Linux 中的 bind mount 技術(shù)把這個(gè)全局目錄掛載進(jìn) Pod 中對(duì)應(yīng)的目錄上，就可以滿足要求。上述流程圖中，全局目錄即 /var/lib/kubelet/pods/[pod uid]/volumes/kubernetes.io~iscsi/[PV
name]

VolumeManager 根據(jù)集群中的資源信息，初始化 DSW 和 ASW。

VolumeManager 內(nèi)部有兩個(gè)組件周期性更新 DSW 和 ASW：

DesiredStateOfWorldPopulator：通過一個(gè) GoRoutine 周期性運(yùn)行，主要功能是 更新 DSW； Reconciler：通過一個(gè) GoRoutine 周期性運(yùn)行， 確保 volume 掛載/卸載完畢。此期間不斷更新 ASW：

unmountVolumes：確保 Pod 刪除后 volumes 被 unmount。遍歷一遍所有 ASW 中的 Pod，若其不在 DSW 中（表示 Pod 被刪除），此處以 VolumeMode=FileSystem 舉例，則執(zhí)行如下操作：

Remove all bind-mounts：調(diào)用 Unmounter 的 TearDown 接口（若為 out-of-tree 則調(diào)用 CSI 插件的 NodeUnpublishVolume 接口）； Unmount volume：調(diào)用 DeviceUnmounter 的 UnmountDevice 函數(shù)（若為 out-of-tree 則調(diào)用 CSI 插件的 NodeUnstageVolume 接口）； 更新 ASW。

mountAttachVolumes：確保 Pod 要使用的 volumes 掛載成功。遍歷一遍所有 DSW 中的 Pod，若其不在 ASW 中（表示目錄待掛載映射到 Pod 上），此處以 VolumeMode=FileSystem 舉例，執(zhí)行如下操作：

等待 volume 掛接到節(jié)點(diǎn)上（由 External Attacher or Kubelet 本身掛接）； 掛載 volume 到全局目錄：調(diào)用 DeviceMounter 的 MountDevice 函數(shù)（若為 out-of-tree 則調(diào)用 CSI 插件的 NodeStageVolume 接口）； 更新 ASW：該 volume 已掛載到全局目錄； bind-mount volume 到 Pod 上：調(diào)用 Mounter 的 SetUp 接口（若為 out-of-tree 則調(diào)用 CSI 插件的 NodePublishVolume 接口）； 更新 ASW。

unmountDetachDevices：確保需要 unmount 的 volumes 被 unmount。遍歷一遍所有 ASW 中的 UnmountedVolumes，若其不在 DSW 中（表示 volume 已無需使用），執(zhí)行如下操作：

Unmount volume：調(diào)用 DeviceUnmounter 的 UnmountDevice 函數(shù)（若為 out-of-tree 則調(diào)用 CSI 插件的NodeUnstageVolume接口）； 更新 ASW。 總結(jié)

本文先對(duì) K8s 持久化存儲(chǔ)基礎(chǔ)概念及使用方法進(jìn)行了介紹，并對(duì) K8s 內(nèi)部存儲(chǔ)流程進(jìn)行了深度解析。在 K8s 上，使用任何一種存儲(chǔ)都離不開上面的流程（有些場景不會(huì)用到 attach/detach），環(huán)境上的存儲(chǔ)問題也一定是其中某個(gè)環(huán)節(jié)出現(xiàn)了故障。

容器存儲(chǔ)的坑比較多，專有云環(huán)境下尤其如此。不過挑戰(zhàn)越多，機(jī)遇也越多！目前國內(nèi)專有云市場在存儲(chǔ)領(lǐng)域也是群雄逐鹿，我們敏捷 PaaS 容器團(tuán)隊(duì)歡迎大俠的加入，一起共創(chuàng)未來！

參考鏈接 Kubernetes 社區(qū)源碼 【云原生公開課】Kubernetes 存儲(chǔ)架構(gòu)及插件使用（郡寶） 【云原生公開課】應(yīng)用存儲(chǔ)和持久化數(shù)據(jù)卷 - 核心知識(shí)（至天） 【kubernetes-design-proposals】volume-provisioning 【kubernetes-design-proposals】CSI Volume Plugins in Kubernetes Design Doc 云原生應(yīng)用團(tuán)隊(duì)招人啦！

阿里云原生應(yīng)用平臺(tái)團(tuán)隊(duì)目前求賢若渴，如果你滿足：

對(duì)容器和基礎(chǔ)設(shè)施相關(guān)領(lǐng)域的云原生技術(shù)充滿熱情，在相關(guān)領(lǐng)域如 Kubernetes、Serverless 平臺(tái)、容器網(wǎng)絡(luò)與存儲(chǔ)、運(yùn)維平臺(tái)等云原生基礎(chǔ)設(shè)施其中某一方向有豐富的積累和突出成果（如產(chǎn)品落地，創(chuàng)新技術(shù)實(shí)現(xiàn)，開源貢獻(xiàn)，領(lǐng)先的學(xué)術(shù)成果）；

優(yōu)秀的表達(dá)能力，溝通能力和團(tuán)隊(duì)協(xié)作能力；對(duì)技術(shù)和業(yè)務(wù)有前瞻性思考；具備較強(qiáng)的 ownership，以結(jié)果為導(dǎo)向，善于決策；

至少熟悉 Java、Golang 中的一項(xiàng)編程語言；

本科及以上學(xué)歷、3 年以上工作經(jīng)驗(yàn)。

簡歷可投遞至郵箱：huizhi.szh @alibaba-inc.com，如有疑問歡迎加微信咨詢：TheBeatles1994。

云原生網(wǎng)絡(luò)研討會(huì)邀您參加

點(diǎn)擊立即預(yù)約直播

“ 阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的公眾號(hào)?！?/p>

文章名稱：一文讀懂K8s持久化存儲(chǔ)流程
URL標(biāo)題：http://jinyejixie.com/article28/cphgjp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站制作、網(wǎng)站策劃、企業(yè)網(wǎng)站制作、網(wǎng)站內(nèi)鏈、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)