当创建pvc后，kubernetes组件如何协作

本文分享自华为云社区《当创建一个pvc后，kubernetes会发生什么？》，作者：可以交个朋友。
一、背景

外部存储接入 Kubernetes 的方式主要有两种：In-Tree 和 Out-of-Tree：

• In-Tree 是指存储驱动的源码都在 Kubernetes 代码库中，与 Kubernetes 一起发布、迭代、管理，这种方式灵活性较差，且门槛较高。
  
• Out-of-Tree 是指存储插件由第三方编写、发布、管理，作为一种扩展与 Kubernetes 配合使用。Out-of-Tree 主要有 FlexVolume 和 CSI 两种实现方式，其中，FlexVolume 因为其命令式的特点，不易维护和管理，从 Kubernetes v1.23 版本开始已被弃用。因此 CSI 已经成为 Kubernetes 存储扩展（ Out-of-Tree ）的唯一方式。
  

外部存储最终的效果是将存储（磁盘、obs、nas盘等）挂载到容器中被业务使用，所以一般包括存在两个过程：

• attach 是将存储介质在指定虚拟机上绑盘，部分存储介质才需要attach操作，比如容器中使用块存储，大致流程是1）需要先调用openstack接口，将某块evs绑到某个虚拟机上，成为虚拟机设备；2）在将存储设备挂载到容器目录上
  
• mount 将某个存储挂载到对应文件系统上，是操作系统层面的行为，所有的存储介质挂载到容器中都需要mount阶段，比如容器中使用nas或者obs，本质上就是执行nfs命令将网络存储挂载到容器目录上
  

二、CSI 架构解读

kubernetes CSI存储插件的关键组件与推荐的容器化部署架构

三、动态创建 Volume 执行过程

以块类型存储为例，从声明pvc到pod挂载卷成功时序图：

1、涉及组件解读

• PV Controller：负责处理集群中的pvc/pv对象，对pvc/pv对象进行状态转换，并根据需求进行数据卷的 Provision/Delete 操作（注：Static pv不会触发provisioner、Dynamic pv才会触发provisioner）
  
• AD Controller：负责VolumeAttachement的生命周期管理，并通过external-attacher将设备挂载到目标节点或从目标节点卸载。VolumeAttachement是控制块存储设备的 Attach/Detach 操作的逻辑对象。（注：可通过kubelet配置文件开关控制节点是否由AD Controller管理）。
  

• kubelet主要包含与存储相关的两个插件：:1）Volume Manager：管理存储卷的 Mount/Unmount 操作、卷设备的格式化等操作（注：如果当前节点并没有交给AD Controller管理，那么就是volumeManager负责管理VolumeAttachement的生命周期）；2）Volume Plugin：K8S平台为存储提供商提供存储接入的插件接口，其中包含in-tree的多种存储插件和out-tree的两种存储插件。通过该插件机制进而为容器应用提供各种类型的存储。社区推荐的是CSI架构的扩展插件
  

2、涉及资源解读

PV：PersistentVolume，集群级别的资源，由集群管理员 or External Provisioner创建。PV 的生命周期独立于使用 PV 的 Pod，PV 的 .Spec 中保存了存储设备的详细信息。

1. kind: PersistentVolume
2. apiVersion: v1
3. metadata:
4.   name: pv-test
5.   labels:
6.     failure-domain.beta.kubernetes.io/region: cn-north-4
7.     failure-domain.beta.kubernetes.io/zone: cn-north-4a
8.   annotations:
9.     pv.kubernetes.io/provisioned-by: xxxx-provisioner #存储提供者
10. spec:
11.   capacity:
12.     storage: 10Gi
13.   csi:
14.     driver: disk.csi.everest.io
15.     volumeHandle: 698a99d8-xxx-xxxx-xxxx-ab80b1ecbf #使用的存储设备信息
16. volumeAttributes:
17.       everest.io/disk-mode: SCSI
18.       everest.io/disk-volume-type: ESSD
19.       storage.kubernetes.io/csiProvisionerIdentity: xxxx-provisioner
20.   accessModes:
21.     - ReadWriteOnce
22.   # 引用对象, 该pv由哪个pvc创建
23.   claimRef:
24.     kind: PersistentVolumeClaim
25.     namespace: test
26.     name: pvc-test
27.     uid: xxxx-xxxx-xxxx-22bf9101f0ce
28.     apiVersion: v1
29.   persistentVolumeReclaimPolicy: Delete
30.   storageClassName: csi-disk
31.   volumeMode: Filesystem
32.   nodeAffinity:
33.     required:
34.       nodeSelectorTerms:
35.         - matchExpressions:
36.             - key: failure-domain.beta.kubernetes.io/zone
37.               operator: In
38.               values:
39.                 - cn-north-4a
40. status:
41.   phase: Bound
42.   # available : 表示当前的pv没有被绑定
43.   # bound:      已经被pvc挂载
44.   # released:   pvc没有在使用pv, 需要管理员手工释放pv
45.   # failed：    资源回收失败

复制代码

• PVC：PersistentVolumeClaim，命名空间（namespace）级别的资源，由用户 or StatefulSet 控制器（根据VolumeClaimTemplate）创建。PVC 类似于 Pod，Pod 消耗 Node 资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存），而 PVC 可以请求特定存储卷的大小及访问模式（Access Mode）。
  

1. kind: PersistentVolumeClaim
2. apiVersion: v1
3. metadata:
4.   name: pvc-evs-test
5.   namespace: test
6.   uid: xxxx-xxxx-xxxx-22bf9101f0ce
7.   labels:
8.     failure-domain.beta.kubernetes.io/region: cn-north-4
9.     failure-domain.beta.kubernetes.io/zone: cn-north-4a
10.   annotations:
11.     volume.kubernetes.io/selected-node: xxx.xxx.xxx.186
12.     everest.io/disk-volume-type: ESSD
13.     volume.kubernetes.io/storage-provisioner: xxxx-provisioner
14. spec:
15.   # ReadWriteOnce:被单个节点mount为读写rw模式
16.   # ReadOnlyMany  被多个节点mount为只读ro模式
17.   # ReadWriteMany 被多个节点mount为读写rw模式
18.   accessModes:
19.     - ReadWriteOnce
20.   resources:
21.     requests:
22.       storage: 10Gi
23.   volumeName: pv-test #绑定的pv name
24.   # 使用的sc类型
25.   storageClassName: csi-disk
26.   # 存储模式,包含Filesystem(文件系统)和Block（块设备）
27.   volumeMode: Filesystem
28. status:
29.   # Pending：pvc刚创建还未与pv绑定
30.   # Bound： pvc与pv完成绑定
31.   # Lost：对应的pv被删除
32.   phase: Bound
33.   accessModes:
34.     - ReadWriteOnce

复制代码

• SC：StorageClass 是集群级别的资源，由集群管理员创建。SC 为管理员提供了一种动态提供存储卷的“类”模板，SC 中的 .Spec 中详细定义了存储卷 PV 的不同服务质量级别、备份策略等等。
  

1. apiVersion: storage.k8s.io/v1
2. kind: StorageClass
3. metadata:
4.   name: csi-disk
5. parameters:
6.   csi.storage.k8s.io/csi-driver-name: disk.csi.everest.io
7.   csi.storage.k8s.io/fstype: ext4
8.   everest.io/disk-volume-type: SATA
9.   everest.io/passthrough: "true"
10. provisioner: xxxx-provisioner
11. # 回收策略, pvc和pv解绑,删除了pvc, pv里面的数据是否还保留
12. # Retain: 保留数据, 需要手工删除
13. # delete: pv删除
14. reclaimPolicy: Delete
15. # Immediate: pv创建好之后立马将pvc和pv进行绑定
16. # WaitForFirstConsumer: 延迟绑定，直到使用pvc的pod被调度到节点上
17. volumeBindingMode: Immediate
18. allowVolumeExpansion: true #是否允许扩容

复制代码

3、涉及 CSI API 对象

CSINode

• 判断外部 CSI 插件是否注册成功。在 Node Driver Registrar 组件向 Kubelet 注册完毕后，Kubelet 会创建该资源，故不需要显式创建 CSINode 资源
  
• 将 Kubernetes 中 Node 资源名称与三方存储系统中节点名称（nodeID）一一对应。此处 Kubelet 会调用外部 CSI 插件 NodeServer 的 GetNodeInfo 函数获取 nodeID。
  
• 显示卷拓扑信息。CSINode 中 topologyKeys 用来表示存储节点的拓扑信息，卷拓扑信息会使得 Scheduler 在 Pod 调度时选择合适的存储节点。
  

1. apiVersion: storage.k8s.io/v1
2. kind: CSINode
3. metadata:
4.   annotations:
5.     everest.io/node.localvolume.capacity: "null"
6.   name: xxx.xxx.xxx.186
7.   ownerReferences:
8.   - apiVersion: v1
9.     kind: Node
10.     name: xxx.xxx.xxx.186
11.     uid: 091cc415-b8bb-4173-8312-5f6318d4383f
12.   uid: fea2c180-99b8-4195-a966-3953b8bab16a
13. spec:
14.   # 节点上有哪些driver
15.   drivers:
16.   - allocatable:
17.       count: 58
18.     name: disk.csi.everest.io
19.     nodeID: 7d279bf8-c70f-4179-842e-5e501d591d17
20.     topologyKeys:
21.     - failure-domain.beta.kubernetes.io/zone
22.   - name: proxy.csi.everest.io
23.     nodeID: 7d279bf8-c70f-4179-842e-5e501d591d17
24.     topologyKeys: null
25.   - name: sfsturbo.csi.everest.io
26.     nodeID: 7d279bf8-c70f-4179-842e-5e501d591d17
27.     topologyKeys: null
28.   - name: nas.csi.everest.io
29.     nodeID: 7d279bf8-c70f-4179-842e-5e501d591d17
30.     topologyKeys: null
31.     ...
32. apiVersion: storage.k8s.io/v1
33. kind: CSINode
34. metadata:
35.   annotations:
36.     everest.io/node.localvolume.capacity: "null"
37.   name: xxx.xxx.xxx.186
38.   ownerReferences:
39.   - apiVersion: v1
40.     kind: Node
41.     name: xxx.xxx.xxx.186
42.     uid: 091cc415-b8bb-4173-8312-5f6318d4383f
43.   uid: fea2c180-99b8-4195-a966-3953b8bab16a
44. spec:
45.   # 节点上有哪些driver
46.   drivers:
47.   - allocatable:
48.       count: 58
49.     name: disk.csi.everest.io
50.     nodeID: 7d279bf8-c70f-4179-842e-5e501d591d17
51.     topologyKeys:
52.     - failure-domain.beta.kubernetes.io/zone
53.   - name: proxy.csi.everest.io
54.     nodeID: 7d279bf8-c70f-4179-842e-5e501d591d17
55.     topologyKeys: null
56.   - name: sfsturbo.csi.everest.io
57.     nodeID: 7d279bf8-c70f-4179-842e-5e501d591d17
58.     topologyKeys: null
59.   - name: nas.csi.everest.io
60.     nodeID: 7d279bf8-c70f-4179-842e-5e501d591d17
61.     topologyKeys: null
62.     ...

复制代码

CSIDriver

• 简化外部 CSI 插件的发现。由集群管理员创建，通过 kubectl get csidriver 即可得知环境上有哪些 CSI 插件。
  
• 自定义Kubernetes 行为，如一些外部 CSI 插件不需要执行卷挂接（VolumeAttach）操作，则可以设置 .spec.attachRequired 为 false。
  

1. apiVersion: storage.k8s.io/v1
2. kind: CSIDriver
3. metadata:
4.   name: disk.csi.everest.io
5.   uid: 5d33a29b-4bf1-4ab8-815f-e97b207b991e
6. spec:
7.   # 是否需要attache和mount，只有evs需要attach
8.   attachRequired: true
9.   podInfoOnMount: true
10.   requiresRepublish: false
11.   storageCapacity: false
12.   volumeLifecycleModes:
13.   - Persistent   #volume生命周期，持久模式

复制代码

VolumeAttachment
AD Controller 创建一个 VolumeAttachment，而 External-attacher 则通过观察该 VolumeAttachment，根据其状态属性来进行存储的挂载和卸载操作。

1. apiVersion: storage.k8s.io/v1
2. kind: VolumeAttachment
3. metadata:
4.   annotations:
5.     csi.alpha.kubernetes.io/node-id: xxxx-xxxx-xxxx-5e501d591d17
6.   finalizers:
7.   - everest-csi-attacher/disk-csi-everest-io
8.   name: csi-d10b9f7e4dde469fa2b7f3461fcfef7862260883196647d6b7ae7bb17bc0e226
9.   uid: 665b740f-a544-4f3e-9953-00b8d186c548
10. spec:
11.   attacher: disk.csi.everest.io
12.   nodeName:xxx.xxx.xxx.186
13.   source:
14.     persistentVolumeName: pv-test
15. status:
16.   # 标记是否attached到节点上，attache后才能mount
17.   attached: true
18.   attachmentMetadata: #attach的设备信息
19.     bus: scsi
20.     device: /dev/sdg

复制代码

四、存储拓展-延迟绑定

kubernetes里面有两个绑定：

• kube-schedule将pod和node绑定
  
• Pvc controller将pvc和pv绑定。正常情况下，kube-schedule绑定pod和node时候，如果pod有pvc,会等待pvc和pv绑定完成后根据pv所在的az选择node过滤一部分不满足节点，然后再完成绑定pod和node。延迟绑定场景，kube-schedule 先不等待PVC和PV绑定，先预调度node，然后把预调度结果写到PVC注解中，pvc控制接获取到预调度az信息后，再完成pv创建和pv绑定。所以，延迟绑定时延迟了pvc和pv绑定阶段。
  

stroageclass延迟绑定作用字段：VolumeBindingMode

• Immediate ：表示一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态制备（不参与调度）。 对于由于拓扑限制而非集群所有节点可达的存储后端，PersistentVolume 会在不知道 Pod 调度要求的情况下绑定或者制备。
  
• WaitForFirstConsumer ：该模式将延迟 PersistentVolume 的绑定和制备，直到使用该 PersistentVolumeClaim 的 Pod 被创建。 PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或制备。 这些包括但不限于资源需求、 节点筛选器、 Pod 亲和性和互斥性、 以及污点和容忍度。
  

 
点击关注，第一时间了解华为云新鲜技术~
 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！