如何接入 K8s 持久化存盤？K8s CSI 實作機制淺析

作者

王成，騰訊云研發工程師，Kubernetes contributor，從事資料庫產品容器化、資源管控等作業，關注 Kubernetes、Go、云原生領域，

概述

進入 K8s 的世界，會發現有很多方便擴展的 Interface，包括 CSI, CNI, CRI 等，將這些介面抽象出來，是為了更好的提供開放、擴展、規范等能力，

K8s 持久化存盤經歷了從 in-tree Volume 到 CSI Plugin(out-of-tree) 的遷移，一方面是為了將 K8s 核心主干代碼與 Volume 相關代碼解耦，便于更好的維護；另一方面則是為了方便各大云廠商實作統一的介面，提供個性化的云存盤能力，以期達到云存盤生態圈的開放共贏，

本文將從持久卷 PV 的 創建(Create)、附著(Attach)、分離(Detach)、掛載(Mount)、卸載(Unmount)、洗掉(Delete) 等核心生命周期，對 CSI 實作機制進行了決議，

相關術語

本文及后續相關文章都基于 K8s v1.22

流程概覽

PV 創建核心流程：

• apiserver 創建 Pod，根據 PodSpec.Volumes 創建 Volume；
• PVController 監聽到 PV informer，添加相關 Annotation(如 pv.kubernetes.io/provisioned-by)，調諧實作 PVC/PV 的系結(Bound)；
• 判斷 StorageClass.volumeBindingMode：WaitForFirstConsumer 則等待 Pod 調度到 Node 成功后再進行 PV 創建，Immediate 則立即呼叫 PV 創建邏輯，無需等待 Pod 調度；
• external-provisioner 監聽到 PV informer, 呼叫 RPC-CreateVolume 創建 Volume；
• AttachDetachController 將已經系結(Bound) 成功的 PVC/PV，經過 InTreeToCSITranslator 轉換器，由 CSIPlugin 內部邏輯實作 VolumeAttachment 資源型別的創建；
• external-attacher 監聽到 VolumeAttachment informer，呼叫 RPC-ControllerPublishVolume 實作 AttachVolume；
• kubelet reconcile 持續調諧：通過判斷 controllerAttachDetachEnabled || PluginIsAttachable 及當前 Volume 狀態進行 AttachVolume/MountVolume，最終實作將 Volume 掛載到 Pod 指定目錄中，供 Container 使用；

從 CSI 說起

CSI(Container Storage Interface) 是由來自 Kubernetes、Mesos、Docker 等社區 member 聯合制定的一個行業標準介面規范(https://github.com/container-storage-interface/spec)，旨在將任意存盤系統暴露給容器化應用程式，

CSI 規范定義了存盤提供商實作 CSI 兼容的 Volume Plugin 的最小操作集和部署建議，CSI 規范的主要焦點是宣告 Volume Plugin 必須實作的介面，

先看一下 Volume 的生命周期：

   CreateVolume +------------+ DeleteVolume
 +------------->|  CREATED   +--------------+
 |              +---+----^---+              |
 |       Controller |    | Controller       v
+++         Publish |    | Unpublish       +++
|X|          Volume |    | Volume          | |
+-+             +---v----+---+             +-+
                | NODE_READY |
                +---+----^---+
               Node |    | Node
              Stage |    | Unstage
             Volume |    | Volume
                +---v----+---+
                |  VOL_READY |
                +---+----^---+
               Node |    | Node
            Publish |    | Unpublish
             Volume |    | Volume
                +---v----+---+
                | PUBLISHED  |
                +------------+

The lifecycle of a dynamically provisioned volume, from
creation to destruction, when the Node Plugin advertises the
STAGE_UNSTAGE_VOLUME capability.

從 Volume 生命周期可以看到，一塊持久卷要達到 Pod 可使用狀態，需要經歷以下階段：

CreateVolume -> ControllerPublishVolume -> NodeStageVolume -> NodePublishVolume

而當洗掉 Volume 的時候，會經過如下反向階段：

NodeUnpublishVolume -> NodeUnstageVolume -> ControllerUnpublishVolume -> DeleteVolume

上面流程的每個步驟，其實就對應了 CSI 提供的標準介面，云存盤廠商只需要按標準介面實作自己的云存盤插件，即可與 K8s 底層編排系統無縫銜接起來，提供多樣化的云存盤、備份、快照(snapshot)等能力，

多組件協同

為實作具有高擴展性、out-of-tree 的持久卷管理能力，在 K8s CSI 實作中，相關協同的組件有：

組件介紹

• kube-controller-manager：K8s 資源控制器，主要通過 PVController, AttachDetach 實作持久卷的系結(Bound)/解綁(Unbound)、附著(Attach)/分離(Detach)；
• CSI-plugin：K8s 獨立拆分出來，實作 CSI 標準規范介面的邏輯控制與呼叫，是整個 CSI 控制邏輯的核心樞紐；
• node-driver-registrar：是一個由官方 K8s sig 小組維護的輔助容器(sidecar)，它使用 kubelet 插件注冊機制向 kubelet 注冊插件，需要請求 CSI 插件的 Identity 服務來獲取插件資訊；
• external-provisioner：是一個由官方 K8s sig 小組維護的輔助容器(sidecar)，主要功能是實作持久卷的創建(Create)、洗掉(Delete)；
• external-attacher：是一個由官方 K8s sig 小組維護的輔助容器(sidecar)，主要功能是實作持久卷的附著(Attach)、分離(Detach)；
• external-snapshotter：是一個由官方 K8s sig 小組維護的輔助容器(sidecar)，主要功能是實作持久卷的快照(VolumeSnapshot)、備份恢復等能力；
• external-resizer：是一個由官方 K8s sig 小組維護的輔助容器(sidecar)，主要功能是實作持久卷的彈性擴縮容，需要云廠商插件提供相應的能力；
• kubelet：K8s 中運行在每個 Node 上的控制樞紐，主要功能是調諧節點上 Pod 與 Volume 的附著、掛載、監控探測上報等；
• cloud-storage-provider：由各大云存盤廠商基于 CSI 標準介面實作的插件，包括 Identity 身份服務、Controller 控制器服務、Node 節點服務；

組件通信

由于 CSI plugin 的代碼在 K8s 中被認為是不可信的，因此 CSI Controller Server 和 External CSI SideCar、CSI Node Server 和 Kubelet 通過 Unix Socket 來通信，與云存盤廠商提供的 Storage Service 通過 gRPC(HTTP/2) 通信：

RPC 呼叫

從 CSI 標準規范可以看到，云存盤廠商想要無縫接入 K8s 容器編排系統，需要按規范實作相關介面，相關介面主要為：

• Identity 身份服務：Node Plugin 和 Controller Plugin 都必須實作這些 RPC 集，協調 K8s 與 CSI 的版本資訊，負責對外暴露這個插件的資訊，
• Controller 控制器服務：Controller Plugin 必須實作這些 RPC 集，創建以及管理 Volume，對應 K8s 中 attach/detach volume 操作，
• Node 節點服務：Node Plugin 必須實作這些 RPC 集，將 Volume 存盤卷掛載到指定目錄中，對應 K8s 中的 mount/unmount volume 操作，

相關 RPC 介面功能如下：

創建/洗掉 PV

K8s 中持久卷 PV 的創建(Create)與洗掉(Delete)，由 external-provisioner 組件實作，相關工程代碼在：【https://github.com/kubernetes-csi/external-provisioner】

首先，通過標準的 cmd 方式獲取命令列引數，執行 newController -> Run() 邏輯，相關代碼如下：

// external-provisioner/cmd/csi-provisioner/csi-provisioner.go
main() {
...
	// 初始化控制器，實作 Volume 創建/洗掉介面
	csiProvisioner := ctrl.NewCSIProvisioner(
		clientset,
		*operationTimeout,
		identity,
		*volumeNamePrefix,
		*volumeNameUUIDLength,
		grpcClient,
		snapClient,
		provisionerName,
		pluginCapabilities,
		controllerCapabilities,
		...
	)
	...
	// 真正的 ProvisionController，包裝了上面的 CSIProvisioner
	provisionController = controller.NewProvisionController(
		clientset,
		provisionerName,
		csiProvisioner,
		provisionerOptions...,
	)
	...
	run := func(ctx context.Context) {
		...
        // Run 運行起來
		provisionController.Run(ctx)
	}
}

接著，呼叫 PV 創建/洗掉流程：

PV 創建：runClaimWorker -> syncClaimHandler -> syncClaim -> provisionClaimOperation -> Provision -> CreateVolume
PV 洗掉：runVolumeWorker -> syncVolumeHandler -> syncVolume -> deleteVolumeOperation -> Delete -> DeleteVolume

由 sigs.k8s.io/sig-storage-lib-external-provisioner 抽象了相關介面：

// 通過 vendor 方式引入 sigs.k8s.io/sig-storage-lib-external-provisioner
// external-provisioner/vendor/sigs.k8s.io/sig-storage-lib-external-provisioner/v7/controller/volume.go
type Provisioner interface {
	// 呼叫 PRC CreateVolume 介面實作 PV 創建
	Provision(context.Context, ProvisionOptions) (*v1.PersistentVolume, ProvisioningState, error)
	// 呼叫 PRC DeleteVolume 介面實作 PV 洗掉
	Delete(context.Context, *v1.PersistentVolume) error
}

Controller 調諧

K8s 中與 PV 相關的控制器有 PVController、AttachDetachController，

PVController

PVController 通過在 PVC 添加相關 Annotation(如 pv.kubernetes.io/provisioned-by)，由 external-provisioner 組件負責完成對應 PV 的創建/洗掉，然后 PVController 監測到 PV 創建成功的狀態，完成與 PVC 的系結(Bound)，調諧(reconcile)任務完成，然后交給 AttachDetachController 控制器進行下一步邏輯處理，

值得一提的是，PVController 內部通過使用 local cache，高效實作了 PVC 與 PV 的狀態更新與系結事件處理，相當于在 K8s informer 機制之外，又自己維護了一個 local store 進行 Add/Update/Delete 事件處理，

首先，通過標準的 newController -> Run() 邏輯：

// kubernetes/pkg/controller/volume/persistentvolume/pv_controller_base.go
func NewController(p ControllerParameters) (*PersistentVolumeController, error) {
	...
	// 初始化 PVController
	controller := &PersistentVolumeController{
		volumes:                       newPersistentVolumeOrderedIndex(),
		claims:                        cache.NewStore(cache.DeletionHandlingMetaNamespaceKeyFunc),
		kubeClient:                    p.KubeClient,
		eventRecorder:                 eventRecorder,
		runningOperations:             goroutinemap.NewGoRoutineMap(true /* exponentialBackOffOnError */),
		cloud:                         p.Cloud,
		enableDynamicProvisioning:     p.EnableDynamicProvisioning,
		clusterName:                   p.ClusterName,
		createProvisionedPVRetryCount: createProvisionedPVRetryCount,
		createProvisionedPVInterval:   createProvisionedPVInterval,
		claimQueue:                    workqueue.NewNamed("claims"),
		volumeQueue:                   workqueue.NewNamed("volumes"),
		resyncPeriod:                  p.SyncPeriod,
		operationTimestamps:           metrics.NewOperationStartTimeCache(),
	}
	...
	// PV 增刪改事件監聽
	p.VolumeInformer.Informer().AddEventHandler(
		cache.ResourceEventHandlerFuncs{
			AddFunc:    func(obj interface{}) { controller.enqueueWork(controller.volumeQueue, obj) },
			UpdateFunc: func(oldObj, newObj interface{}) { controller.enqueueWork(controller.volumeQueue, newObj) },
			DeleteFunc: func(obj interface{}) { controller.enqueueWork(controller.volumeQueue, obj) },
		},
	)
	...
	// PVC 增刪改事件監聽
	p.ClaimInformer.Informer().AddEventHandler(
		cache.ResourceEventHandlerFuncs{
			AddFunc:    func(obj interface{}) { controller.enqueueWork(controller.claimQueue, obj) },
			UpdateFunc: func(oldObj, newObj interface{}) { controller.enqueueWork(controller.claimQueue, newObj) },
			DeleteFunc: func(obj interface{}) { controller.enqueueWork(controller.claimQueue, obj) },
		},
	)
	...
	return controller, nil
}

接著，呼叫 PVC/PV 系結/解綁邏輯：

PVC/PV 系結：claimWorker -> updateClaim -> syncClaim -> syncBoundClaim -> bind
PVC/PV 解綁：volumeWorker -> updateVolume -> syncVolume -> unbindVolume

AttachDetachController

AttachDetachController 將已經系結(Bound) 成功的 PVC/PV，內部經過 InTreeToCSITranslator 轉換器，實作由 in-tree 方式管理的 Volume 向 out-of-tree 方式管理的 CSI 插件模式轉換，

接著，由 CSIPlugin 內部邏輯實作 VolumeAttachment 資源型別的創建/洗掉，調諧(reconcile) 任務完成，然后交給 external-attacher 組件進行下一步邏輯處理，

相關核心代碼在 reconciler.Run() 中實作如下：

// kubernetes/pkg/controller/volume/attachdetach/reconciler/reconciler.go
func (rc *reconciler) reconcile() {

	// 先進行 DetachVolume，確保因 Pod 重新調度到其他節點的 Volume 提前分離(Detach)
	for _, attachedVolume := range rc.actualStateOfWorld.GetAttachedVolumes() {
		// 如果不在期望狀態的 Volume，則呼叫 DetachVolume 洗掉 VolumeAttachment 資源物件
		if !rc.desiredStateOfWorld.VolumeExists(
			attachedVolume.VolumeName, attachedVolume.NodeName) {
			...
			err = rc.attacherDetacher.DetachVolume(attachedVolume.AttachedVolume, verifySafeToDetach, rc.actualStateOfWorld)
			...
		}
	}
	// 呼叫 AttachVolume 創建 VolumeAttachment 資源物件
	rc.attachDesiredVolumes()
	...
}

附著/分離 Volume

K8s 中持久卷 PV 的附著(Attach)與分離(Detach)，由 external-attacher 組件實作，相關工程代碼在：【https://github.com/kubernetes-csi/external-attacher】

external-attacher 組件觀察到由上一步 AttachDetachController 創建的 VolumeAttachment 物件，如果其 .spec.Attacher 中的 Driver name 指定的是自己同一 Pod 內的 CSI Plugin，則呼叫 CSI Plugin 的ControllerPublish 介面進行 Volume Attach，

首先，通過標準的 cmd 方式獲取命令列引數，執行 newController -> Run() 邏輯，相關代碼如下：

// external-attacher/cmd/csi-attacher/main.go
func main() {
    ...
    ctrl := controller.NewCSIAttachController(
		clientset,
		csiAttacher,
		handler,
		factory.Storage().V1().VolumeAttachments(),
		factory.Core().V1().PersistentVolumes(),
		workqueue.NewItemExponentialFailureRateLimiter(*retryIntervalStart, *retryIntervalMax),
		workqueue.NewItemExponentialFailureRateLimiter(*retryIntervalStart, *retryIntervalMax),
		supportsListVolumesPublishedNodes,
		*reconcileSync,
	)

	run := func(ctx context.Context) {
		stopCh := ctx.Done()
		factory.Start(stopCh)
		ctrl.Run(int(*workerThreads), stopCh)
	}
    ...
}

接著，呼叫 Volume 附著/分離邏輯：

Volume 附著(Attach)：syncVA -> SyncNewOrUpdatedVolumeAttachment -> syncAttach -> csiAttach -> Attach -> ControllerPublishVolume
Volume 分離(Detach)：syncVA -> SyncNewOrUpdatedVolumeAttachment -> syncDetach -> csiDetach -> Detach -> ControllerUnpublishVolume

kubelet 掛載/卸載 Volume

K8s 中持久卷 PV 的掛載(Mount)與卸載(Unmount)，由 kubelet 組件實作，

kubelet 通過 VolumeManager 啟動 reconcile loop，當觀察到有新的使用 PersistentVolumeSource 為CSI 的 PV 的 Pod 調度到本節點上，于是呼叫 reconcile 函式進行 Attach/Detach/Mount/Unmount 相關邏輯處理，

// kubernetes/pkg/kubelet/volumemanager/reconciler/reconciler.go
func (rc *reconciler) reconcile() {
	// 先進行 UnmountVolume，確保因 Pod 洗掉被重新 Attach 到其他 Pod 的 Volume 提前卸載(Unmount)
	rc.unmountVolumes()

	// 接著通過判斷 controllerAttachDetachEnabled || PluginIsAttachable 及當前 Volume 狀態
	// 進行 AttachVolume / MountVolume / ExpandInUseVolume
	rc.mountAttachVolumes()

	// 卸載(Unmount) 或分離(Detach) 不再需要(Pod 洗掉)的 Volume
	rc.unmountDetachDevices()
}

相關呼叫邏輯如下：

Volume 掛載(Mount)：reconcile -> mountAttachVolumes -> MountVolume -> SetUp -> SetUpAt -> NodePublishVolume
Volume 卸載(Unmount)：reconcile -> unmountVolumes -> UnmountVolume -> TearDown -> TearDownAt -> NodeUnpublishVolume

小結

本文通過分析 K8s 中持久卷 PV 的 創建(Create)、附著(Attach)、分離(Detach)、掛載(Mount)、卸載(Unmount)、洗掉(Delete) 等核心生命周期流程，對 CSI 實作機制進行了決議，通過原始碼、圖文方式說明了相關流程邏輯，以期更好的理解 K8s CSI 運行流程，

可以看到，K8s 以 CSI Plugin(out-of-tree) 插件方式開放存盤能力，一方面是為了將 K8s 核心主干代碼與 Volume 相關代碼解耦，便于更好的維護；另一方面在遵從 CSI 規范介面下，便于各大云廠商根據業務需求實作相關的介面，提供個性化的云存盤能力，以期達到云存盤生態圈的開放共贏，

PS: 更多內容請關注 k8s-club

相關資料

1. CSI 規范
2. Kubernetes 原始碼
3. kubernetes-csi 原始碼
4. kubernetes-sig-storage 原始碼
5. K8s CSI 概念
6. K8s CSI 介紹

關于我們

更多關于云原生的案例和知識，可關注同名【騰訊云原生】公眾號~

福利：

   ①公眾號后臺回復【手冊】，可獲得《騰訊云原生路線圖手冊》&《騰訊云原生最佳實踐》~

   ②公眾號后臺回復【系列】，可獲得《15個系列100+篇超實用云原生原創干貨合集》，包含Kubernetes 降本增效、K8s 性能優化實踐、最佳實踐等系列，

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

標籤：其他

上一篇：一文回顧阿里云彈性計算云棲大會精彩看點

下一篇：Pod持久化