深入了解kubernetes存储细节以及流程解析

这是Kubernetes存储系列的第二篇文章。上一篇花了一些篇幅解释了Kubernetes中的一些存储概念,最终带出了关键的一点-----动态供应。在编排系统中,存储资源也应该像Pod一样,可以动态规划的,这种方式又称之为动态供应(dynamic provision)。为了实现这个目标,k8s社区提出了好几种方案,今天在此进行探索一番。

动态供应的不同时期不同方案

有以下方法实现卷插件:

In-tree Volume Plugin Out-of-tree Provisioner Out-of-tree CSI Driver 最初地,Kubernetes内部代码中实现了一些存储插件,用于支持一些主流网络存储,叫作In-tree Volume Plugin。

第二种 Out-of-tree Provisioner:如果官方的插件不能满足要求,存储供应商可以根据需要去定制或者优化存储插件并集成到Kubernetes系统。

第三种是容器存储接口CSI (Container Storage Interface),是Kubernetes对外开放的存储接口,实现这个接口即可集成到Kubernetes系统中。CSI特性在刚过去的12月正式GA,同时社区也宣布未来将不再对In tree/Out of tree继续开发,并将已有功能全部迁移到CSI上,所以对于存储供应商和使用者来说,第三种CSI是更推荐的解决方案。

In-tree Volume Plugin

这是最初的一种方案,Kubernetes最初处理存储的方式比较粗暴,就是需要什么存储需求就直接添加一个卷插件,比如说最开始的,只是提供简单的hostpath存储卷(宿主机上的某个共享目录),那就添加一个hostpath volume plugin并添加相应的实现代码。然后开始用户有其他需求,比如这次就想要使用ceph的块接口,需要支持rbd接口的动态插件,就又开发了rbd plugin。这个口子一开,肯定还有更多的存储插件加到kubernetes 源码中,到后面就包括Google自家的gcePersistentDisk,AWS的云存储,以及其他很多厂商的提供存储服务的代码开始逐步怼到kubernetes源码中。确实就是这么粗暴的,截止如今,还是有很多这种代码嵌入到Kubernetes的源码中,我认为这是非常可怕的事情😨。 这种把存储服务集成到kubernetes系统的中插件又称为In-tree Volume Plugin,他们是k8s系统的一部分,会随着kuberntes版本发布而更新,维护等都和Kubernetes紧密联系

比如下面例子: volume_plugins 可以看到这里有一大堆不同类型的volume plugin,需要新增加一个存储供应商就往这里怼点代码,简直就是大力出奇迹。 以ceph和cinder为例,他们会根据自己的存储特性,后端结果等有着不同的实现。但是并没有统一的接口。此时可以说是面向对象开发而不是面向接口。 ceph_fs vs cinder

这种实现虽然不够优雅,但是至少某种程度上解决了Kubernetes编排系统中持久化存储的难点。 很多的存储从而变得可以动态供应。比如说我只需要创建一个rbd的storagecalss以及一个pvc,此时借助这些内置的存储插件,就可以让系统自动创建想要的rbd类型的PV,并且和这个PVC进行绑定。再也不用人工创建以及回收等繁复的操作了。(但是并不所有的volume plugin都实现的动态供应比如原生的nfs就不能动态创建)。

Out-of-tree Provisioner

显然上面这种方式有很多的值得吐槽的地方,比如是和Kubernetes核心代码紧密的联系在一起,要是存储商的后端接口有变动或者其他原因需要更新volume plugin的时候还得等到kubernetes下一次版本发布。这些intree volume plugin甚至有可能会影响到Kubernetes本身,这是个问题💩。 这个时候就逐步衍生了另外一种方案,如果官方的插件不能满足要求,存储供应商可以根据需要去定制或者优化存储插件并集成到Kubernetes系统,这种外置的插件并不需要和以前一样成为内嵌在Kubernetes的核心代码中,这些插件称之为external provisioner

What is an 'external provisioner'? An external provisioner is a dynamic PV provisioner whose code lives out-of-tree/external to Kubernetes. Unlike in-tree dynamic provisioners that run as part of the Kubernetes controller manager, external ones can be deployed & updated independently.

它们可以独立部署(比如以deployment的形式运作在集群中),这是因为kubernetes作出了适配,可在需要使用到它们功能的时候ubernetes可以根据名字找到这些外置的插件,并要求这些external provisioner来实现供应PV的操作。

举个例子: 前面我提到过,kubernetes原生不知道nfs动态供应功能,但是现在我们可以创建一个专用的external provisoner来实现nfs 的动态供应。 先创建一个PVC,并在PVC中指定使用storageclassA来动态创建PV,

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim
  annotations:
    volume.beta.kubernetes.io/storage-class: "nfssc"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Mi

如果使用external provisioner此时可以看到这个storageclassA的定义是这样的:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfssc
provisioner: xsky.nfs/v1 # or choose another name, must match deployment's env PROVISIONER_NAME'
parameters:
  archiveOnDelete: "false"

⚠️注意这里:我使用了一个自定义的provisoner叫xsky.nfs/v1,这当然不是Kuberntes自带的插件。这是我们额外部署的external provisions。

这个external provisoner是这样定义的(其实就是一个特殊的deployment)源码请看后面说明:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: xsky.nfs/v1
            - name: NFS_SERVER
              value: 10.252.90.104
            - name: NFS_PATH
              value: /sdsfs/filesys/

具体的使用external provisioner来实现nfs动态供应的详细例子可以戳这里

尽管这样还是有个问题。毕竟这只是个provisioner,顾名思义,它是负责供应PV的(创建和删除PV)。面对日益复杂的Kubernetes上的持久化存储需求,这就有点抓襟见肘,比如快照,动态扩容等高级功能就等还是没办法解决🤷‍♂️

CSI容器存储接口

Kubernetes和CNCF决定把容器存储进行抽象,通过标准接口的形式把存储部分移到容器编排系统外部去。CSI的设计目的是定义一个行业标准,该标准将使存储供应商能够自己实现,维护和部署他们的存储插件。这些存储插件会以Sidecar Container形式运行在Kubernetes上并为容器平台提供稳定的存储服务。

CSI: 是容器存储接口,是针对存储抽象出的一类接口,由存储厂商实现具体的接口操作。https://github.com/container-storage-interface/spec/blob/master/csi.proto

可以看到这里的protobuf的定义,其实就是一类RPC服务以及基本的类型,简单来说就是通过重新定义和统一了存储接口,任意的存储厂商只要遵循这套接口,实现想要的操作并能对Kubernetes系统提供gRPC调用,那就可以集成到Kubernetes系统中。具体接口怎么实现那就是存储厂商的事情了,反正他们已经给定了一个protobuf的定义了。

既然是csi是容器存储接口,能否用其他语言来实现?当然是可以,csi是一套抽象接口,使用protobuf协议定义,protobuf是类型json或者xml一样的序列化数据结果,由于它可跨平台,因此可以生成不同语言的库,比如Java,Go,C++,C#,Python等等,只要针对其中定义的接口实现,最后在Kubernetes编排系统里部署起来作为gRPC的服务端即可。

最后一种容器存储接口CSI (Container Storage Interface),是Kubernetes对外开放的存储接口,实现这个接口即可集成到Kubernetes系统中。CSI特性在18年的12月正式GA,同时社区也宣布未来将不再对In tree/Out of tree继续开发,并将已有功能全部迁移到CSI上,所以对于存储供应商和使用者来说,第三种CSI是更推荐的解决方案。

细节解析

尽管说到这个份上了,实际可能还是不是很清晰🤯🤯🤯,理论归理论,文字总是枯燥的

还是用图片来解释把:

In tree volume plugin 解析图:

in_tree

⚠️注意: 尽管这个示意图把中间的volume plugin抽离出来,只是为了阐述他们的作为连接k8s编排(包括master和kubelt直接)和后端存储的一个桥梁身份。实际上volume plugin是属于controller manager组件下的。

如图所示,In-tree Volume Plugin是Kubernetes自带的,属于Kubernetes的一部分,由Kubernetes一起发布和维护,所有存储插件代码都集成在Kubernetes中。第三方存储供应商难以集成。 1) 首先在Kubernetes启动的时候,master侧会有三个核心组件,kubectl-sheduler,etcd和controller-masnter

scheduler负责资源对象的调度,比如把一个pod调度到某个节点nodeA

etcd会负责把集群内的资源对象持久化,比如把pod,pvc,node,service等存到etcd

controller-manager包含非常多模块,比如pod manager,volume manager等等,是集群的大脑🧠。他们负责监控集群内的组件,并判断是否需要操作。

比如创建一个PVC资源后,pv controller就会检测到,并在适合的适合调用某个volume plugin来创建PV。

in tree volume plugin属于volume manager下的,因此他们会被加载进来,然后在需要的时候会被调用。

2)k8s集群内的负载节点Node会在启动的适合启动关键进程kubelet。

kubelet会在node商执行一些初始化以及收拾烂摊子的工作,比如某个pod被调度进来它就要开始检查Pod依赖的卷是否准备好,如果没有就要负责挂载操作

然后才能吧pod容器启动。

这里先不细说每个组件的源码,后面会再分析。只需要知道每个组件负责什么,整个数据流搞清楚就够了。

Out-of-tree Provisioner 解析图:

前面有讲到,其实Out-of-tree Provisioner 是基于In tree Volume plugin来实现的。

只是让Kubernetes作适配,兼容外置的插件,有很多组件的使用和控制都还是共用的。

详细数据流如下:

external_provisioner

⚠️:

a. 上图volume plugin组件被分离处理,实际上代码还是在controller manager里面,只是因为它处理的PV既可以在master也可以在kubelet侧,因此单独拿出来

b. 尽管使用了external provisioner,实际volume plugin也还参与工作,比如把创建卷请求路由到指定的external provisioner上

分析:

1) 当这里用 kubectl create xxx的时候会在集群创建一些资源(pv,pvc,pod...)。

2) k8s各方组件会对资源进行监控和调度,比如scheduler检测到Pod资源创建了,就开始把Pod分配到某个Node上

3) Pod被分配到Node上还不能马上启动,因为它所依赖的PV卷还没准备好,此时还要等待Kubelet准备好环境

kubelet上的volume manager需要等待PV的创建,直到PV可用了,它才可以把PV存储挂载到宿主机上,再从宿主机映射到容器内

另一条路上(controller manager),准确点说应该是PV controller,它也在监听集群中刚创建的PVC,并发现这个新的PVC还没绑定,

于是就决定先创建一个PV。

4) Controller会查找pvc.yam里指定的StoageClass对象(如果没有指定的话则使用默认的SC),此时确定了需要使用的Provisioner。

一个外置的external-provisoner就会被调用,负责创建PV,这个external-provisoner会和相应的后端存储(比如nfs server端)通过某种方式通信(比如RPC或者RESTful接口)

并在后端创建了一种存储资源,成功后就给k8s这边吐出一个相应的PV。此时完成provision动作。

5) Kubelet检测到这个PV已经准备完毕处于可用状态则开始把PV挂载在宿主机NodeA上, 即attach。

6) 当远端存储已经在宿主机上完成挂载和初始化(可能会有格式化), Kubelet 会将宿主机上的mountpoint 映射到容器内指定位置,比如使用docker的-v参数

7) Kubelet 启动Pod,并开始使用这个PV

CSI(Container storage interface)

直接上解析图:

csi

⚠️注意:

上图中实际上绿色和橙色两部分都会在Kubernetes中运行,最终形态都是Pod。

采用容器存储接口方案,总览图是这样的。

大体上分为4部分:

1) master侧,这里其实还是和之前一样,有controller manager在检测组件并路由请求,如果是CSI类型的PV,它就不用找in tree volume plugin,或者external provision了

但是它还是会进行状态判断,已经更新状态等操作

2)此时还需要额外创建3个辅助容器(gRPC客户端):

他们其实也是从以前的kubernetes代码里抽离处理的,只是这里是专门地用来处理CSI 卷的处理,分别是

Driver-registrar: 使用 Kubelet注册 CSI 驱动程序的 sidecar 容器,并将 NodeId (通过 GetNodeID 调用检索到 CSI endpoint)添加到 Kubernetes Node API 对象的 annotation 里面。

External-provisioner: 监听 Kubernetes PersistentVolumeClaim 对象的 sidecar 容器,并触发对 CSI 端点的 CreateVolume 和DeleteVolume 操作;

External-attacher: 可监听 Kubernetes VolumeAttachment 对象并触发 ControllerPublish 和 ControllerUnPublish 操作的 sidecar 容器,负责attache/detache卷到node节点上;

3) 右侧橘黄色表示存储厂商实现的存储插件驱动,分别有三个服务(gRPC服务端):

他们是实现了csi标志(proto文件里定义的接口)的gRPC服务端

CSI identify: 标志插件服务,并维持插件健康状态;

CSI Controller: 创建/删除,attaching/detaching,快照,扩容等;

CSI Node: attach/mount、umount/detach;

4)真正的后端存储(厂商,AWS, Google, Tencent ...) CSI driver真正操作的后端存储平台,比如csi driver通过腾讯的接口调用创建块存储卷,如果成功则对k8s侧返回一个PV对象

删除操作同理。

动态供应方式总结

通过对比Kubernetes的In-tree Volume Plugin,以及Out-of-tree Provisioner和CSI三种方式,在对接比较常见的存储时,可以使用不需要改动的In-tree方案,因为开箱即用,但是缺点也非常明显,只支持有限的存储类型,可拓展性较差甚至有版本限制,另外官方宣布以后新特性将不再添加到其中。相比之下,使用Out-of-tree Provisioner或者CSI则可以实现和Kubernetes的核心组件解耦,并能支持更多的存储类型和高级特性,因而也是推荐使用的一种供应方式。由于后者对编排系统而言是非侵入式插件部署,因而更受存储供应商的青睐。目前CSI方案是kubernetes社区最为推荐的方式。因此后面还会专门针对CSI进行讲解。