更多 k8s CSI 的分析,可以查看这篇博客kubernetes ceph-csi分析,以 ceph-csi 为例,做了详细的源码分析。
其他关联博客:kubernetes/k8s CRI分析-容器运行时接口分析
kubernetes/k8s CNI分析-容器网络接口分析
kubernetes的设计初衷是支持可插拔架构,从而利于扩展kubernetes
的功能。在此架构思想下,kubernetes
提供了3个特定功能的接口,分别是容器网络接口CNI
、容器运行时接口CRI
和容器存储接口CSI
。kubernetes
通过调用这几个接口,来完成相应的功能。
下面我们来对容器存储接口CSI
来做一下介绍与分析。
在本文中,会对CSI
是什么、为什么要有CSI
、CSI
系统架构做一下介绍,然后对CSI
所涉及的k8s
对象与组件进行了简单的介绍,以及k8s
对CSI
存储进行相关操作的流程分析,存储相关操作包括了存储创建、存储扩容、存储挂载、解除存储挂载以及存储删除操作。
CSI是Container Storage Interface
(容器存储接口)的简写。
CSI的目的是定义行业标准“容器存储接口”,使存储供应商(SP)能够开发一个符合CSI标准的插件并使其可以在多个容器编排(CO)系统中工作。CO包括Cloud Foundry
, Kubernetes
, Mesos
等。
kubernetes将通过CSI
接口来跟第三方存储厂商进行通信,来操作存储,从而提供容器存储服务。
其实在没有CSI
之前kubernetes
就已经提供了强大的存储卷插件系统,但是这些插件系统实现是kubernetes
代码的一部分,需要随kubernetes
组件二进制文件一起发布,这样就会存在一些问题。
(1)如果第三方存储厂商发现有问题需要修复或者优化,即使修复后也不能单独发布,需要与kubernetes
一起发布,对于k8s
本身而言,不仅要考虑自身的正常迭代发版,还需要考虑到第三方存储厂商的迭代发版,这里就存在双方互相依赖、制约的问题,不利于双方快速迭代;
(2)另外第三方厂商的代码跟kubernetes
代码耦合在一起,还会引起安全性、可靠性问题,还增加了kubernetes
代码的复杂度以及后期的维护成本等等。
基于以上问题,kubernetes
将存储体系抽象出了外部存储组件接口即CSI
,kubernetes
通过grpc
接口与第三方存储厂商的存储卷插件系统进行通信。
这样一来,对于第三方存储厂商来说,既可以单独发布和部署自己的存储插件,进行正常迭代,而又无需接触kubernetes
核心代码,降低了开发的复杂度。同时,对于kubernetes
来说,这样不仅降低了自身的维护成本,还能为用户提供更多的存储选项。
这是一张k8s csi的系统架构图,图中所画的组件以及k8s对象,接下来会一一进行分析。
CSI相关组件一般采用容器化部署,减少环境依赖。
持久存储卷,集群级别资源,代表了存储卷资源,记录了该存储卷资源的相关信息。
(1)retain:保留策略,当删除pvc的时候,保留pv与外部存储资源。
(2)delete:删除策略,当与pv绑定的pvc被删除的时候,会从k8s集群中删除pv对象,并执行外部存储资源的删除操作。
(3)resycle(已废弃)
available --> bound --> released
持久存储卷声明,namespace级别资源,代表了用户对于存储卷的使用需求声明。
示例:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test
namespace: test
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Gi
storageClassName: csi-cephfs-sc
volumeMode: Filesystem
pending --> bound
定义了创建pv的模板信息,集群级别资源,用于动态创建pv。
示例:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: csi-rbd-sc
parameters:
clusterID: ceph01
imageFeatures: layering
imageFormat: "2"
mounter: rbd
pool: kubernetes
provisioner: rbd.csi.ceph.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
VolumeAttachment 记录了pv的相关挂载信息,如挂载到哪个node节点,由哪个volume plugin来挂载等。
AD Controller 创建一个 VolumeAttachment,而 External-attacher 则通过观察该 VolumeAttachment,根据其状态属性来进行存储的挂载和卸载操作。
示例:
apiVersion: storage.k8s.io/v1
kind: VolumeAttachment
metadata:
name: csi-123456
spec:
attacher: cephfs.csi.ceph.com
nodeName: 192.168.1.10
source:
persistentVolumeName: pvc-123456
status:
attached: true
CSINode 记录了csi plugin的相关信息(如nodeId、driverName、拓扑信息等)。
当Node Driver Registrar向kubelet注册一个csi plugin后,会创建(或更新)一个CSINode对象,记录csi plugin的相关信息。
示例:
apiVersion: storage.k8s.io/v1
kind: CSINode
metadata:
name: 192.168.1.10
spec:
drivers:
- name: cephfs.csi.ceph.com
nodeID: 192.168.1.10
topologyKeys: null
- name: rbd.csi.ceph.com
nodeID: 192.168.1.10
topologyKeys: null
下面来介绍下涉及的组件与作用。
扩展各种存储类型的卷的管理能力,实现第三方存储的各种操作能力与k8s存储系统的结合。调用第三方存储的接口或命令,从而提供数据卷的创建/删除、attach/detach、mount/umount的具体操作实现,可以认为是第三方存储的代理人。前面分析组件中的对于数据卷的创建/删除、attach/detach、mount/umount操作,全是调用volume plugin来完成。
根据源码所在位置,volume plugin分为in-tree与out-of-tree。
在k8s源码内部实现,和k8s一起发布、管理,更新迭代慢、灵活性差。
代码独立于k8s,由存储厂商实现,有csi、flexvolume两种实现。
csi plugin分为ControllerServer与NodeServer,各负责不同的存储操作。
external plugin包括了external-provisioner、external-attacher、external-resizer、external-snapshotter等,external plugin辅助csi plugin组件,共同完成了存储相关操作。external plugin负责watch pvc、volumeAttachment等对象,然后调用volume plugin来完成存储的相关操作。如external-provisioner watch pvc对象,然后调用csi plugin来创建存储,最后创建pv对象;external-attacher watch volumeAttachment对象,然后调用csi plugin来做attach/dettach操作;external-resizer watch pvc对象,然后调用csi plugin来做存储的扩容操作等。
Node-Driver-Registrar组件负责实现csi plugin(NodeServer)的注册,让kubelet感知csi plugin的存在。
csi plugin controllerServer与external plugin作为容器,使用deployment部署,多副本可实现高可用;而csi plugin NodeServer与Node-Driver-Registrar作为容器,使用daemonset部署,即每个node节点都有。
负责pv、pvc的绑定与生命周期管理(如创建/删除底层存储,创建/删除pv对象,pv与pvc对象的状态变更)。
(1)in-tree:创建/删除底层存储、创建/删除pv对象的操作,由PV controller调用volume plugin(in-tree)来完成。
(2)out-tree CSI:创建/删除底层存储、创建/删除pv对象的操作由external-provisioner与csi plugin共同来完成。
AD Cotroller全称Attachment/Detachment 控制器,主要负责创建、删除VolumeAttachment对象,并调用volume plugin来做存储设备的Attach/Detach操作(将数据卷挂载到特定node节点上/从特定node节点上解除挂载),以及更新node.Status.VolumesAttached等。
不同的volume plugin的Attach/Detach操作逻辑有所不同,对于csi plugin(out-tree volume plugin)来说,AD controller的Attach/Detach操作只是修改VolumeAttachment对象的状态,而不会真正的将数据卷挂载到节点/从节点上解除挂载,真正的节点存储挂载/解除挂载操作由kubelet中volume manager调用csi plugin来完成。
主要是管理卷的Attach/Detach(与AD controller作用相同,通过kubelet启动参数控制哪个组件来做该操作)、mount/umount等操作。
对于csi来说,volume manager的Attach/Detach操作只创建/删除VolumeAttachment对象,而不会真正的将数据卷挂载到节点/从节点上解除挂载;csi-attacer组件也不会做挂载/解除挂载操作,只是更新VolumeAttachment对象,真正的节点存储挂载/解除挂载操作由kubelet中volume manager调用调用csi plugin来完成。
先来看下kubernetes通过in-tree volume plugin来创建与挂载volume的流程
(1)用户创建pvc
;
(2)PV controller
watch到pvc
的创建,寻找合适的pv
与之绑定。
(3)(4)当找不到合适的pv
时,将调用volume plugin
来创建volume,并创建pv
对象,之后该pv
对象与pvc
对象绑定。
(5)用户创建挂载pvc
的pod
;
(6)kube-scheduler
watch到pod
的创建,为其寻找合适的node调度。
(7)(8)pod
调度完成后,AD controller
/volume manager
watch到pod
声明的volume没有进行attach
操作,将调用volume plugin
来做attach
操作。
(9)volume plugin
进行attach
操作,将volume挂载到pod
所在node节点,成为如/dev/vdb
的设备。
(10)(11)attach
操作完成后,volume manager
watch到pod
声明的volume没有进行mount
操作,将调用volume plugin
来做mount
操作。
(12)volume plugin
进行mount
操作,将node节点上的第(9)步得到的/dev/vdb
设备挂载到指定目录。
再来看下kubernetes通过out-of-tree volume plugin来创建与挂载volume的流程,以csi-plugin为例。
(1)用户创建pvc
;
(2)PV controller
watch到pvc
的创建,寻找合适的pv
与之绑定。当寻找不到合适的pv
时,将更新pvc
对象,添加annotation
:volume.beta.kubernetes.io/storage-provisioner
,让external-provisioner
组件开始开始创建存储与pv
对象的操作。
(3)external-provisioner
组件watch到pvc
的创建/更新事件,判断annotation
:volume.beta.kubernetes.io/storage-provisioner
的值,即判断是否是自己来负责做创建操作,是则调用csi-plugin ControllerServer
来创建存储,并创建pv
对象(这里的pv
对象使用了提前绑定特性,将pvc
信息填入了pv
对象的spec.claimRef
属性)。
(4)PV controller
将上一步创建的pv
与pvc
绑定。
(5)用户创建挂载pvc
的pod
;
(6)kube-scheduler
watch到pod
的创建,为其寻找合适的node
调度。
(7)(8)pod
调度完成后,AD controller
/volume manager
watch到pod
声明的volume没有进行attach
操作,将调用csi-attacher
来做attach
操作(实际上只是创建volumeAttachement
对象)。
(9)external-attacher
组件watch到volumeAttachment
对象的新建,调用csi-plugin
进行attach
操作(如果volume plugin
是ceph-csi
,external-attacher
组件watch到volumeAttachment
对象的新建后,只是修改该对象的状态属性,不会做attach
操作,真正的attach
操作由kubelet
中的volume manager
调用volume plugin``````ceph-csi
来完成)。
(10)csi-plugin ControllerServer
进行attach
操作,将volume挂载到pod
所在node
节点,成为如/dev/vdb
的设备。
(11)(12)attach
操作完成后,volume manager
watch到pod
声明的volume没有进行mount
操作,将调用csi-mounter
来做mount
操作。
(13)csi-mounter
调用csi-plugin NodeServer
进行mount
操作,将node节点上的第(10)步得到的/dev/vdb
设备挂载到指定目录。
下面来看下kubernetes
通过ceph-csi volume plugin
来创建/删除、挂载/解除挂载ceph存储的流程。
(1)用户创建pvc
对象;
(2)pv controller
监听pvc
对象,寻找现存的合适的pv
对象,与pvc
对象绑定。当找不到现存合适的pv
对象时,将更新pvc
对象,添加annotation
:volume.beta.kubernetes.io/storage-provisioner
,让external-provisioner
组件开始开始创建存储与pv
对象的操作;当找到时,将pvc
与pv
绑定,结束操作。
(3)external-provisioner
组件监听到pvc
的新增事件,判断pvc
的annotation
:volume.beta.kubernetes.io/storage-provisioner
的值,即判断是否是自己来负责做创建操作,是则调用ceph-csi
组件进行存储的创建;
(4)ceph-csi
组件调用ceph创建底层存储;
(5)底层存储创建完成后,external-provisioner
根据存储信息,拼接pv
对象,创建pv
对象(这里的pv
对象使用了提前绑定特性,将pvc
信息填入了pv
对象的spec.claimRef
属性);
(6)pv controller
监听pvc
对象,将第(5)步创建的pv
对象,与pvc
对象绑定。
(1)修改pvc
对象,修改申请存储大小(pvc.spec.resources.requests.storage
);
(2)修改成功后,external-resizer
监听到该pvc
的update
事件,发现pvc.Spec.Resources.Requests.storgage
比pvc.Status.Capacity.storgage
大,于是调ceph-csi
组件进行 controller端扩容;
(3)ceph-csi
组件调用ceph存储,进行底层存储扩容;
(4)底层存储扩容完成后,external-resizer
组件更新pv
对象的.Spec.Capacity.storgage
的值为扩容后的存储大小;
(5)kubelet
的volume manager
在reconcile()
调谐过程中发现pv.Spec.Capacity.storage
大于pvc.Status.Capacity.storage
,于是调ceph-csi
组件进行 node端扩容;
(6)ceph-csi
组件对node上存储对应的文件系统扩容;
(7)扩容完成后,kubelet
更新pvc.Status.Capacity.storage
的值为扩容后的存储大小。
kubelet启动参数--enable-controller-attach-detach
,该启动参数设置为 true
表示启用 Attach/Detach controller
进行Attach/Detach
操作,同时禁用 kubelet
执行 Attach/Detach
操作(默认值为 true
)。实际上Attach/Detach
操作就是创建/删除VolumeAttachment
对象。
(1)kubelet
启动参数--enable-controller-attach-detach=true
,Attach/Detach controller
进行Attach/Detach
操作。
(2)kubelet
启动参数--enable-controller-attach-detach=false
,kubelet
端volume manager
进行Attach/Detach
操作。
(1)用户创建一个挂载了pvc
的pod
;
(2)AD controller
或volume manager
中的reconcile()
发现有volume
未执行attach
操作,于是进行attach
操作,即创建VolumeAttachment
对象;
(3)external-attacher
组件list/watch``````VolumeAttachement
对象,更新VolumeAttachment.status.attached=true
;
(4)AD controller
更新node
对象的.Status.VolumesAttached
属性值,将该volume
记为attached
;
(5)kubelet
中的volume manager
获取node.Status.VolumesAttached
属性值,发现volume
已被标记为attached
;
(6)于是volume manager
中的reconcile()
调用ceph-csi
组件的NodeStageVolume
与NodePublishVolume
完成存储的挂载。
(1)kubelet
启动参数--enable-controller-attach-detach=true
,Attach/Detach controller
进行Attach/Detach
操作。
(2)kubelet
启动参数--enable-controller-attach-detach=false
,kubelet
端volume manager
进行Attach/Detach
操作。
(1)用户删除声明了pvc
的pod
;
(2)AD controller
或volume manager
中的reconcile()
发现有volume
未执行dettach
操作,于是进行dettach
操作,即删除VolumeAttachment
对象;
(3)AD controller
或volume manager
等待VolumeAttachment
对象删除成功;
(4)AD controller
更新node
对象的.Status.VolumesAttached
属性值,将标记为attached
的该volume
从属性值中去除;
(5)kubelet
中的volume manager
获取node.Status.VolumesAttached
属性值,找不到相关的volume
信息;
(6)于是volume manager
中的reconcile()
调用ceph-csi
组件的NodeUnpublishVolume
与NodeUnstageVolume
完成存储的解除挂载操作。
(1)用户删除pvc
对象;
(2)pv controller
发现与pv
绑定的pvc
对象被删除,于是更新pv
的状态为released
;
(3)external-provisioner
watch到pv
更新事件,并检查pv
的状态是否为released
,以及回收策略是否为delete
;
(4)确认了pv
对象的状态以及回收策略之后,接下来external-provisioner
组件会调用ceph-csi
的DeleteVolume
来删除存储;
(5)ceph-csi
组件的DeleteVolume
方法,调用ceph集群命令,删除底层存储;
(6)删除底层存储后,external-provisioner
组件删除pv
对象。
CSI即Container Storage Interface
(容器存储接口)。
为了解决第三方存储厂商的存储卷插件代码集成到kubernetes代码中所带来的各种问题,kubernetes
将存储体系抽象出了外部存储组件接口即CSI
,kubernetes
通过grpc
接口与第三方存储厂商的存储卷插件系统进行通信,来操作存储,从而提供容器存储服务。
这样一来,对于第三方存储厂商来说,既可以单独发布和部署自己的存储插件,进行正常迭代,而又无需接触kubernetes
核心代码,降低了开发的复杂度。同时,对于kubernetes
来说,这样不仅降低了自身的维护成本,还能为用户提供更多的存储选项。
更多 k8s CSI 的分析,可以查看这篇博客kubernetes ceph-csi分析,以 ceph-csi 为例,做了详细的源码分析。
其他关联博客:kubernetes/k8s CRI分析-容器运行时接口分析