容器服務 TKE 儲存外掛與雲硬碟 CBS 最佳實踐應用

引言

隨著自研上雲的深入，越來越多的有狀態服務對於在 TKE 叢集中使用雲上儲存能力的需求也越來越強烈。

目前騰訊雲容器服務 TKE（Tencent Kubernetes Engine已支援在 TKE 叢集中的應用使用多種儲存服務，包括雲硬碟 CBS、檔案儲存 CFS以及物件儲存 COS。TKE 通過兩種儲存外掛（In-Tree 和 CSI）來支援上述能力，使用者可以通過雲控制檯很方便地選擇儲存型別並建立對應的 PV/PVC。但仍然會有一些問題困擾著大家，比如：TKE 叢集中是否支援擴容 CBS 雲盤；如果叢集跨可用區，如何避免叢集中頻繁出現掛載（attach）失敗；TKE 中是否支援快照功能；我的應用應該選擇哪種型別儲存；In-Tree 和 CSI 都支援 CBS，二者有和區別，是否能把之前使用 In-Tree 外掛建立的雲盤轉變為 CSI 外掛管理等。

對於 TKE 儲存的相關問題，這裡會詳細介紹。接下來，我們先概覽下 Kubernetes 持久化儲存的流程

Kubernetes 持久化儲存流程

這裡對 Kubernetes 持久化儲存的流程做個概覽，不深入各個元件。

建立一個使用了持久化儲存的 pod 的流程包含以下步驟：

1. 使用者建立一個引用PVC的 pod（動態建立PV）；
2. Scheduler根據 pod 的配置、節點狀態、PV 配置等其他因素把 pod 排程到一個合適的 node 上；
3. PV Controller watch 到 PVC，呼叫 Volume Plugin 去建立 PV，並繫結 PV 和 PVC。如果是 out-of-tree 儲存外掛（如 CSI），則建立 PV 實際是由 external provisioner 完成，之後 PV Controller 完成 PV 和 PVC 的bound；如果是 in-tree 外掛，但是通過kubernetes-sigs/sig-storage-lib-external-provisioner實現了一個 external provisioner，則與 out-of-tree 外掛相同；如果是 in-tree 外掛，且外掛直接實現了相應的創刪介面，則 PV Controller 直接呼叫 in-tree 外掛的實現完成建立 PV。
4. AD Controller 對比 asw 和 dsw 狀態，發現 Volume 需要被 attach，則呼叫 Volume Plugin 的實現去 attach。in-tree 外掛不需多說，如果是 CSI 外掛，則 AD Controller 會先呼叫 CSI in-tree 程式碼建立 VolumeAttachment 物件，CSI 外掛的一個名為 external-attacher 的 sidecar 會 watch 該物件，watch 到建立則呼叫 CSI driver 的相應方法(ControllerPublishVolume)來 attach。
5. VolumeManager 等到 volume 成功 attach 到節點後，開始呼叫 Volume Plugin 去進行 mount 操作。這個mount 操作分為兩步：第一步是格式化裝置並把 volume mount 到一個 global mount path（/var/lib/kubelet/plugins下），第二步是將 bind mount 剛才的 global mount path到/var/lib/kubelet/pods/${pod_UUID}/volumes下。
6. Kubelet 呼叫容器執行時啟動容器，並且 bind mount 第5步中的 mount path 到容器中。

（Provision -> Attach -> Mount; Unmount -> Detach -> Delete）

TKE 儲存外掛及原理介紹

隨著 Kubernetes 社群發展，TKE 先後支援了 In-Tree 和 CSI 兩種儲存外掛。二者在功能上的主要區別在於 In-Tree 儲存外掛僅支援在 TKE 叢集使用 CBS，而 CSI 支援使用 CBS、CFS、COS。

型別	支援CBS	支援CFS	支援COS	參考
In-Tree	√	×	×
CSI	√	√	√	https://github.com/TencentCloud/kubernetes-csi-tencentcloud

In-Tree 外掛（QcloudCbs）

• kubernetes 早期只支援以 In-Tree 的方式擴充套件儲存外掛，也就是外掛在 Kubernetes 程式碼中實現。

• In-Tree 外掛名為cloud.tencent.com/qcloud-cbs，所以也可稱為 QcloudCbs，在 TKE 叢集中有個預設的名為cbs的 StorageClass。

  NAME            PROVISIONER                    AGEcbs (default)   cloud.tencent.com/qcloud-cbs   48m
  

特性

In-Tree 外掛只實現了使用 CBS 的能力，其主要特性有：

• 靜態資料卷：即使用者手動建立 volme、PV 物件、PVC 物件
• 動態資料卷：根據 StorageClass 配置來由外掛控制建立和刪除 volume 和 PV
• 拓撲感知：CBS 不支援跨可用區掛載，在多可用區叢集中，會先排程 pod，然後去排程後的 node 的 zone 建立 volume。
• 排程器感知節點 maxAttachLimit：騰訊雲單個 CVM 上預設最多掛載 20塊 CBS 盤，排程器感知該限制，排程時過濾到要超過 maxAttachLimit 的節點。可以全域性修改 maxAttachLimit，但需要 IaaS 層先支援。

騰訊雲端儲存	靜態資料卷	動態資料卷	拓撲感知	排程器感知節點 maxAttachLimit
騰訊雲硬碟（CBS）	支援兩種使用方式： 直接通過 volume 使用 通過PV/PVC使用（推薦）	支援	支援。pod 排程後，在同一個可用區建立 volume。避免 CBS 跨可用區無法使用。	支援。雲伺服器(cvm)可以掛載的雲硬碟(cbs)是有上限的。排程器排程 pod 時過濾掉超過最大可掛載 CBS 數量的節點。

原理簡介

下面簡單瞭解下 In-Tree 外掛 QcloudCbs 的架構圖，瞭解各相關元件分別完成何種工作。

上圖是包含 TKE In-Tree 儲存外掛的 Kubernetes 儲存架構圖。圖中綠色部分，皆屬於 In-Tree 外掛 QcloudCbs 的實現範疇。
由上述的 Kubernetes持久化儲存流程 可知要動態使用一個 cbs pv，主要有三個過程：provision、attach、mount，而這三個過程是由不同元件負責的：

• cbs-provisioner 負責 volume 的 provision/delete。為了與 Kubernetes 程式碼解耦，cbs-provisioner 是基於kubernetes-sigs/sig-storage-lib-external-provisioner實現的一個 external provisioner，來 provision 和 delete volume。PV Controller 在這種模式下雖然不去 provision/delete volume，但是還是會參與處理（比如 PV 和 PVC 的繫結）。
• AD Controller 負責 volume 的 attach/detach。Tencent Cloud Provider 中封裝雲 API，In-Tree 外掛呼叫 Cloud Provider 實現了 attach/detach 的具體邏輯，並提供給 AD Controller 呼叫。
• kubelet 的 Volume Manager 負責 volume 的 mount/unmount。In-Tree 外掛中實現 MountDevice、SetUp 等介面，Volume Manager 呼叫其完成準備 volume 的最後一步。
• 另外，Scheduler 中也有 volume 相關的邏輯，我們新增了一個 predicate 策略：MaxQcloudCbsVolumeCount，該策略主要實現排程器感知節點 maxAttachLimit特性。而 Scheduler 原生的一個 predicate 策略：NoVolumeZoneConflictPred，是用來把 pod 排程到已有 PV 所在 zone 的節點，這可以避免雲盤跨可用區掛載的問題；對於新建 PV 的話，避免雲盤跨可用區掛載問題則由拓撲感知特性完成。

CSI 外掛

CSI 是 Kubernetes 社群擴充套件卷的標準和推薦方式。TKE 的 CSI 外掛包含 CBS、CFS、COS 三個 driver，本節重點介紹 CBS CSI driver，並與 QcloudCbs 進行對比。3個 driver 的靜態 pv 和動態 pv 的支援情況如下表所示：

騰訊雲端儲存	靜態資料卷	動態資料卷
雲硬碟（CBS)	支援	支援
檔案儲存（CFS）	支援	支援
物件儲存（COS）	支援	不支援

CBS CSI 特性及與 QcloudCbs 對比

• CBS CSI 比 QcloudCbs 多幾個特性：volume 線上擴容，volume 快照和恢復。

儲存外掛	靜態資料卷	動態資料卷	拓撲感知	排程器感知節點maxAttachLimit	卷線上擴容	卷快照&恢復
CBS CSI	√	√	√	√	√	√
QcloudCbs（In-Tree）	√	√	√	√	×	×

原理簡介

CSI 原理簡介

CSI 原理參考上圖。要實現一個 CSI driver，一般需要實現以下 3 個 gRPC services（CSI Controller Service 可選）：

• CSI Identity Services：提供 driver 資訊（drivername，版本等）

• CSI Controller Services

  （可選）：controller 負責創刪卷、attach/detach、擴容、快照等。涉及的方法如下：

  • CreateVolume/DeleteVolume
  • Controller[Publish|Unpublish]Volume (對應attach/detach)
  • CreateSnapshot/DeleteSnapshot/ListSnapshots
  • ControllerExpandVolume

• CSI Node Services

  ：負責向節點註冊 driver，mount/unmount。涉及的方法如下：

  • NodeStageVolume/NodeUnstageVolume（(un)mount device）
  • NodePublishVolume/NodeUpPublishVolume（(un)mount volume）

在我們實現之外，kuberntes Team 還提供了多個外部元件，用於溝通 k8s 原生元件（apiserver、controller manager、kubelet）與自己實現的 CSI driver。

• external-provisioner：watch PersistentVolumeClaim（PVC）物件，呼叫 driver 的CreateVolume/DeleteVolume
• external-attacher：watch VolumeAttachment物件，呼叫 driver 的Controller[Publish|Unpublish]Volume
• external-resizer: watch PersistentVolumeClaim物件，呼叫 driver 的ControllerExpandVolume
• external-snapshotter和snapshot-controller：snapshot-controller watch VolumeSnapshot和VolumeSnapshotContent CRD 物件，external-snapshotter watch VolumeSnapshotContent物件。呼叫 driver 的CreateSnapshot/DeleteSnapshot/ListSnapshots
• *node-driver-registrar*：使用NodeGetInfo獲取 driver 資訊，然後使用 kubelet 外掛序號產生器制註冊 driver。

CBS CSI 部署圖

CBS CSI 使用社群推薦部署方式，包含兩個 workload：

• 一個 DaemonSet，也就是每個 Node 會有一個，我們可以簡單稱為NodePlugin，由 CBS CSI Driver 和 node-driver-registrar 兩個容器組成。負責向節點註冊 driver，並提供 mount 的能力。
• 一個 StatefulSet/Deployment，我們可以簡稱為Controller。由 driver 和多個 sidecar（external-provisioner、external-attacher、external-resizer、external-snapshotter、snapshot-controller）一起構成，提供創刪卷、attach/detach、擴容、快照等能力

CBS CSI 外掛的 mount 是 driver 容器執行的，它是如何 mount 到 Node 上的？

• 答案是：掛載傳播（Mount propagation）。掛載傳播允許容器內的 mount 在容器外可見。參見https://stupefied-goodall-e282f7.netlify.app/contributors/design-proposals/node/propagation/
• CBS CSI 的 global mount 階段（NodeStageVolume）要把裝置 mount 到/var/lib/kubelet/plugins的子目錄下；之後 bind mount 階段（NodePublishVolume）的 target path 是/var/lib/kubelet/pods。所以我們為這兩個目錄都設定了掛載傳播（模式為Bidirectional）
  

使用推薦

• TKE 叢集版本為 1.14+(包含 1.14)，推薦使用 CSI 外掛
• 需要在TKE叢集中使用 CFS 和 COS 能力，使用 CSI 外掛
• 需要在TKE叢集中對 CBS 盤線上擴容和使用快照功能，使用 CSI 外掛
• 已經使用了 QcloudCbs（In-Tree 外掛）的，可以繼續使用。（後續會通過 Volume Migration 統一到 CBS CSI）

最佳實踐

provisioner:

• cbs csi —— "com.tencent.cloud.csi.cbs"
• cbs intree —— "cloud.tencent.com/qcloud-cbs"

cbs csi 的安裝請參見 cbs csi 文件，我們也已經在騰訊雲控制檯支援擴充套件元件安裝。

本節最佳實踐均以 cbs csi 外掛為例，相應版本要求也是針對 cbs csi 外掛。

1、如果叢集節點跨 zone，如何避免 cbs 雲盤跨可用區掛載？

cbs 雲盤不支援跨可用區掛載到節點，所以在跨可用區的叢集中推薦通過拓撲感知特性來避免跨可用區掛載的問題。

1.1 使用前注意

• TKE叢集版本 >= 1.14
• 確保 csi 外掛為最新版本

1.2 如何使用

使用方式很簡單，在 storageclass 中設定 volumeBindingMode為WaitForFirstConsumer，然後使用該 storageClass 即可。intree 和 csi 外掛均支援。

kind: StorageClass
metadata:
  name: cbs-topo
parameters:
  type: cbs
provisioner: com.tencent.cloud.csi.cbs
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

1.3 原理

拓撲感知排程需要多個 k8s 元件配合完成，包括 scheduler、pv controller、external-provisioner。流程為：

1. pv controller watch 到 PVC 物件，發現 storageclass 的 volumeBindingMode 為WaitForFirstConsumer，即不會馬上處理該pvc的建立事件，等待 scheduler 處理；
2. scheduler 排程完 pod 後，會將 nodeName 以 annotation 的方式打到 PVC 物件上: volume.kubernetes.io/selected-node: 10.0.0.72
3. pv controller 獲取到 PVC 物件的更新事件後，處理這個 annotation(volume.kubernetes.io/selected-node)，根據 nodeName 獲取 Node 物件，傳入到 provisioner 中。
4. provisioner 根據傳過來的 Node 物件的 label 獲取可用區（failure-domain.beta.kubernetes.io/zone），之後在對應 zone 建立 pv，從而達到和 pod 相同可用區的效果，避免雲盤和 node 在不同可用區而無法掛載。

2、如何線上擴容雲盤？

TKE 支援線上擴容 PV，對應的雲盤及檔案系統，即不需要重啟 pod 即可完成擴容。但，為了確保檔案系統的穩定性，還是推薦先讓雲盤檔案系統處於未 mount 情況下。為此，我們將提供兩種擴容方式：

1. 不重啟 pod 的情況下線上擴容
   • 這種情況下被擴容的雲盤的檔案系統被 mount 在節點上，如果 I/O 的話，有可能會出現檔案系統擴容錯誤
2. 重啟 pod 的情況下線上擴容
   • 這種情況下被擴容的雲盤的檔案系統被 unmount了。可以避免上面的問題，推薦這種方式。

2.1 使用前注意

• TKE叢集版本 >= 1.16，詳見 cbs csi 文件
• 僅 cbs csi 外掛支援擴容，確保 csi 外掛為最新版本
• 可以在擴容前使用快照來備份資料，避免擴容失敗導致資料丟失。參見下方 3.2.1 使用快照備份雲硬碟

2.2 如何使用

2.2.1 建立允許擴容的 StorageClass

在 storageclass 中設定allowVolumeExpansion為true：

allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cbs-csi-expand
parameters:
  diskType: CLOUD_PREMIUM
provisioner: com.tencent.cloud.csi.cbs
reclaimPolicy: Delete
volumeBindingMode: Immediate

2.2.2 不重啟 pod 的情況下線上擴容

1、確認擴容前 pv 和檔案系統狀態，大小均為 20G

$ kubectl exec ivantestweb-0 df /usr/share/nginx/html
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/vdd        20511312 45036  20449892   1% /usr/share/nginx/html
$ kubectl get pv pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                        STORAGECLASS   REASON   AGE
pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c   20Gi       RWO            Delete           Bound    default/www1-ivantestweb-0   cbs-csi                 20h

2、執行以下命令修改 PVC 物件中的容量，擴容至 30G

$ kubectl patch pvc www1-ivantestweb-0 -p '{"spec":{"resources":{"requests":{"storage":"30Gi"}}}}'

執行後稍等片刻，可以發現 pv 和檔案系統已經擴容至 30G：

$ kubectl exec ivantestweb-0 df /usr/share/nginx/html
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/vdd        30832548 44992  30771172   1% /usr/share/nginx/html
$ kubectl get pv pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                        STORAGECLASS   REASON   AGE
pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c   30Gi       RWO            Delete           Bound    default/www1-ivantestweb-0   cbs-csi                 20h

2.2.3 重啟 pod 的情況下線上擴容

1、確認擴容前 pv 和檔案系統狀態，大小均為 30G

$ kubectl exec ivantestweb-0 df /usr/share/nginx/html
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/vdd        30832548 44992  30771172   1% /usr/share/nginx/html
$ kubectl get pv pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c 
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                        STORAGECLASS   REASON   AGE
pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c   30Gi       RWO            Delete           Bound    default/www1-ivantestweb-0   cbs-csi                 20h

2、使用下面命令給 PV 物件打標籤，打一個非法 zone，旨在下一步重啟 pod 後 pod 無法排程到某個節點上

$ kubectl label pv pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c failure-domain.beta.kubernetes.io/zone=nozone

3、重啟 pod。重啟後由於 pod 對應的 pv 的標籤表明的是非法 zone，pod 會處於 Pending 狀態

$ kubectl delete pod ivantestweb-0

$ kubectl get pod ivantestweb-0
NAME            READY   STATUS    RESTARTS   AGE
ivantestweb-0   0/1     Pending   0          25s

$ kubectl describe pod ivantestweb-0
Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning  FailedScheduling  40s (x3 over 2m3s)  default-scheduler  0/1 nodes are available: 1 node(s) had no available volume zone.

4、修改 PVC 物件中的容量，擴容至 40G

kubectl patch pvc www1-ivantestweb-0 -p '{"spec":{"resources":{"requests":{"storage":"40Gi"}}}}'

5、去掉 PV 物件之前打的標籤，這樣 pod 就能排程成功了。

$ kubectl label pv pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c failure-domain.beta.kubernetes.io/zone-persistentvolume/pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c labeled

稍等片刻，pod running，對應的 pv 和檔案系統也擴容成功，從 30G 擴容到 40G 了

$ kubectl get pod ivantestweb-0
NAME            READY   STATUS    RESTARTS   AGE
ivantestweb-0   1/1     Running   0          17m

$ kubectl get pv pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                        STORAGECLASS   REASON   AGE
pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c   40Gi       RWO            Delete           Bound    default/www1-ivantestweb-0   cbs-csi                 20h

$ kubectl get pvc www1-ivantestweb-0
NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
www1-ivantestweb-0   Bound    pvc-e193201e-6f6d-48cf-b96d-ccc09225cf9c   40Gi       RWO            cbs-csi        20h

$ kubectl exec ivantestweb-0 df /usr/share/nginx/html
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/vdd        41153760 49032  41088344   1% /usr/share/nginx/html

3、如何建立快照和使用快照來恢復卷？

3.1 使用前注意

• TKE叢集版本 >= 1.18，詳見 cbs csi 文件
• 僅 cbs csi 外掛支援快照，確保 csi 外掛映象為最新版本

3.2 如何使用

3.2.1 使用快照備份雲硬碟

1、使用下面 yaml，建立VolumeSnapshotClass物件

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotClass
metadata:
  name: cbs-snapclass
driver: com.tencent.cloud.csi.cbs
deletionPolicy: Delete

建立後顯示：

$ kubectl get volumesnapshotclass
NAME            DRIVER                      DELETIONPOLICY   AGE
cbs-snapclass   com.tencent.cloud.csi.cbs   Delete           17m

2、使用下面 yaml，建立

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
  name: new-snapshot-demo
spec:
  volumeSnapshotClassName: cbs-snapclass
  source:
    persistentVolumeClaimName: csi-pvc

建立後稍等片刻，volumesnapshot 和 volumesnapshotcontent 物件都建立成功，READYTOUSE為 true：

$ kubectl get volumesnapshot
NAME                READYTOUSE   SOURCEPVC            SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS   SNAPSHOTCONTENT                                    CREATIONTIME   AGE
new-snapshot-demo   true         www1-ivantestweb-0                           10Gi          cbs-snapclass   snapcontent-ea11a797-d438-4410-ae21-41d9147fe610   22m            22m
$ kubectl get volumesnapshotcontent
NAME                                               READYTOUSE   RESTORESIZE   DELETIONPOLICY   DRIVER                      VOLUMESNAPSHOTCLASS   VOLUMESNAPSHOT      AGE
snapcontent-ea11a797-d438-4410-ae21-41d9147fe610   true         10737418240   Delete           com.tencent.cloud.csi.cbs   cbs-snapclass         new-snapshot-demo   22m

具體快照 id 在 volumesnapshotcontent 物件中，status.snapshotHandle(snap-e406fc9m)，可以根據這個快照 id 在騰訊雲控制檯確認快照是否存在

$ kubectl get volumesnapshotcontent snapcontent-ea11a797-d438-4410-ae21-41d9147fe610 -oyaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotContent
metadata:
  creationTimestamp: "2020-11-04T08:58:39Z"
  finalizers:
  - snapshot.storage.kubernetes.io/volumesnapshotcontent-bound-protection
  name: snapcontent-ea11a797-d438-4410-ae21-41d9147fe610
  resourceVersion: "471437790"
  selfLink: /apis/snapshot.storage.k8s.io/v1beta1/volumesnapshotcontents/snapcontent-ea11a797-d438-4410-ae21-41d9147fe610
  uid: 70d0390b-79b8-4276-aa79-a32e3bdef3d6
spec:
  deletionPolicy: Delete
  driver: com.tencent.cloud.csi.cbs
  source:
    volumeHandle: disk-7z32tin5
  volumeSnapshotClassName: cbs-snapclass
  volumeSnapshotRef:
    apiVersion: snapshot.storage.k8s.io/v1beta1
    kind: VolumeSnapshot
    name: new-snapshot-demo
    namespace: default
    resourceVersion: "471418661"
    uid: ea11a797-d438-4410-ae21-41d9147fe610
status:
  creationTime: 1604480319000000000
  readyToUse: true
  restoreSize: 10737418240
  snapshotHandle: snap-e406fc9m

3.2.2 從快照恢復卷（雲硬碟）

1、我們在 3.2.1 中建立的VolumeSnapshot的物件名為new-snapshot-demo，使用下面 yaml 來從快照恢復一個卷

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restore-test
spec:
  storageClassName: cbs-csi
  dataSource:
    name: new-snapshot-demo
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

發現 restore 的 pvc 已經建立出來，diskid 也在 pv 中（disk-gahz1kw1）

$ kubectl get pvc restore-test
NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
restore-test   Bound    pvc-80b98084-29a3-4a38-a96c-2f284042cf4f   10Gi       RWO            cbs-csi        97s
$ kubectl get pv pvc-80b98084-29a3-4a38-a96c-2f284042cf4f -oyaml
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: com.tencent.cloud.csi.cbs
  creationTimestamp: "2020-11-04T12:08:25Z"
  finalizers:
  - kubernetes.io/pv-protection
  name: pvc-80b98084-29a3-4a38-a96c-2f284042cf4f
  resourceVersion: "474676883"
  selfLink: /api/v1/persistentvolumes/pvc-80b98084-29a3-4a38-a96c-2f284042cf4f
  uid: 5321df93-5f21-4895-bafc-71538d50293a
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 10Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: restore-test
    namespace: default
    resourceVersion: "474675088"
    uid: 80b98084-29a3-4a38-a96c-2f284042cf4f
  csi:
    driver: com.tencent.cloud.csi.cbs
    fsType: ext4
    volumeAttributes:
      diskType: CLOUD_PREMIUM
      storage.kubernetes.io/csiProvisionerIdentity: 1604478835151-8081-com.tencent.cloud.csi.cbs
    volumeHandle: disk-gahz1kw1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.com.tencent.cloud.csi.cbs/zone
          operator: In
          values:
          - ap-beijing-2
  persistentVolumeReclaimPolicy: Delete
  storageClassName: cbs-csi
  volumeMode: Filesystem
status:
  phase: Bound

參考

• Kubernetes CSI in Action: Explained with Features and Use Cases
• CSI Volume Plugins in Kubernetes Design Doc

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！