作者
王成，騰訊云研發工程師，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 實作機制進行了決議，
相關術語
| Term | Definition |
|---|---|
| CSI | Container Storage Interface. |
| CNI | Container Network Interface. |
| CRI | Container Runtime Interface. |
| PV | Persistent Volume. |
| PVC | Persistent Volume Claim. |
| StorageClass | Defined by provisioner(i.e. Storage Provider), to assemble Volume parameters as a resource object. |
| Volume | A unit of storage that will be made available inside of a CO-managed container, via the CSI. |
| Block Volume | A volume that will appear as a block device inside the container. |
| Mounted Volume | A volume that will be mounted using the specified file system and appear as a directory inside the container. |
| CO | Container Orchestration system, communicates with Plugins using CSI service RPCs. |
| SP | Storage Provider, the vendor of a CSI plugin implementation. |
| RPC | Remote Procedure Call. |
| Node | A host where the user workload will be running, uniquely identifiable from the perspective of a Plugin by a node ID. |
| Plugin | Aka “plugin implementation”, a gRPC endpoint that implements the CSI Services. |
| Plugin Supervisor | Process that governs the lifecycle of a Plugin, MAY be the CO. |
| Workload | The atomic unit of "work" scheduled by a CO. This MAY be a container or a collection of containers. |
本文及后續相關文章都基于 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；kubeletreconcile 持續調諧：通過判斷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
相關資料
- CSI 規范
- Kubernetes 原始碼
- kubernetes-csi 原始碼
- kubernetes-sig-storage 原始碼
- K8s CSI 概念
- K8s CSI 介紹
關于我們
更多關于云原生的案例和知識，可關注同名【騰訊云原生】公眾號~
福利：
①公眾號后臺回復【手冊】，可獲得《騰訊云原生路線圖手冊》&《騰訊云原生最佳實踐》~
②公眾號后臺回復【系列】，可獲得《15個系列100+篇超實用云原生原創干貨合集》，包含Kubernetes 降本增效、K8s 性能優化實踐、最佳實踐等系列，
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/337534.html
標籤：其他