前言

最近在极客时间订阅了kubernetes的专栏,这篇文章是想记录一下自己学习 CSI 插件机制 (container-storage-interface) 的过程,加深一下记忆。

准备工作

老师用的是 csi-digitalocean,还会用到 CSI 的 proto 文件,这是 git 地址container-storage-interface/spec, 在开始本文之前可以先把这两个 repo 下载下来。
csi-digitalocean,这个是主要分析的代码,需要放到 GOPATH 下,就能用 goland 来分析了。

mkdir $GOPATH/src/github.com/digitalocean
cd $GOPATH/src/github.com/digitalocean
git clone https://github.com/digitalocean/csi-digitalocean.git

然后用 goland 打开这个 csi-digitalocean 目录就行了。在用 sublime 或者其他的工具打开 container-storage-interface/spec 就行了,这个git地址我们主要是用根目录下的 csi.proto 和 spec.md 。

背景知识

CSI 插件机制主要是三部分

  • kube-apiserver,kubelet
  • External Components
  • Custom Component

external components 的三部分

  • Driver Registrar
  • External Provisioner
  • External Attacher

custom components 的三部分

  • Identity Service
  • Controller Service
  • Node Service

上面的三部分是需要 CSI plugin 必须要提供的是三个 GRPC 的 endpoint 。详情可见。 下面是后面用到的这个文章里面的文字

A CO interacts with an Plugin through RPCs.
Each SP MUST provide:

  • Node Plugin: A gRPC endpoint serving CSI RPCs that MUST be run on the Node whereupon an SP-provisioned volume will be published.
  • Controller Plugin: A gRPC endpoint serving CSI RPCs that MAY be run anywhere.
  • In some circumstances a single gRPC endpoint MAY serve all CSI RPCs (see Figure 3 in Architecture).

There are three sets of RPCs:

  • Identity Service: Both the Node Plugin and the Controller Plugin MUST implement this sets of RPCs.
  • Controller Service: The Controller Plugin MUST implement this sets of RPCs.
  • Node Service: The Node Plugin MUST implement this sets of RPCs.

其中 Driver Registrar 负责请求 Identity Service 来获取插件信息并且注册到 kubelet 。可以看下 $GOPATH/src/github.com/digitalocean/csi-digitalocean/driver 的内容:

tree $GOPATH/src/github.com/digitalocean/csi-digitalocean/driver
$GOPATH/GoglandProjects/src/github.com/digitalocean/csi-digitalocean/driver
├── controller.go
├── driver.go
├── driver_test.go
├── identity.go
├── mounter.go
└── node.go

具体场景分析

具体的场景 container-storage-interface/spec 这个下面的 spec.md 里面都有,大家可以详细看看。

这里说一下 csi-digitalocean 这个下面 README.md 里面的例子。本文忽略了一些地方只做笔记回顾知识用,具体可以参考源站。

部署CSI插件

执行下面的命令

kubectl apply -f https://raw.githubusercontent.com/digitalocean/csi-digitalocean/master/deploy/kubernetes/releases/csi-digitalocean-v0.3.1.yaml 

大家可以打开这个文件看下,主要是 Node plugin 和 Controller plugin 。

$ egrep 'StatefulSet|DaemonSet|image:' deploy/kubernetes/releases/csi-digitalocean-v0.3.1.yaml 
kind: StatefulSet
          image: quay.io/k8scsi/csi-provisioner:v0.4.1
          image: quay.io/k8scsi/csi-attacher:v0.4.1
          image: digitalocean/do-csi-plugin:v0.3.1
kind: DaemonSet
          image: quay.io/k8scsi/driver-registrar:v0.4.1
          image: digitalocean/do-csi-plugin:v0.3.1

其中 Controller plugin 是以 StatefulSet 部署的。digitalocean/do-csi-plugin:v0.3.1 这个 image 主要是 $GOPATH/src/github.com/digitalocean/csi-digitalocean/driver 这里面代码实现 custom components 需要提供的服务。 Node plugin 是 DaemonSet 主要和 kubelet 交互。

创建 pvc 和创建使用该 pvc 的 pod。

主要是下面这个流程,分为三阶段就是 Provision Attach Mount。

   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.

使用 kubectl apply 下面的 yaml .

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: do-block-storage

这个时候 External Provisioner 监听到了 PVC 对象的创建,然后 External Provisioner 就会调用 CSI Controller 的 CreateVolume 方法创建 PV , 创建完 PV 之后 kube-apiserver 中的 VolumeController 的 PersistentVolumeController reconcile loop 就会 watch 到这对 PV 和 PVC 的大小和 storageclass 是一样的。然后就把 PV 和 PVC 进行绑定然后就是上图中的 CREATED 。 这个阶段就是 Provision。

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM             STORAGECLASS       REASON    AGE
pvc-0879b207-9558-11e8-b6b4-5218f75c62b9   5Gi        RWO            Delete           Bound     default/csi-pvc   do-block-storage             3m

之后创建 Pod

kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeMounts:
      - mountPath: "/data"
        name: my-do-volume
      command: [ "sleep", "1000000" ]
  volumes:
    - name: my-do-volume
      persistentVolumeClaim:
        claimName: csi-pvc 

这时这个 Pod 会被调度到一个机器 A 上,然后 VolumeController 的 AttachDetachController reconcile loop 就会 watch 到这个 PVC 需要 Attach 到 A 上,之后这个 AttachDetachController 就会创建一个 VolumeAttach 对象。 这时 quay.io/k8scsi/csi-attacher 这个容易就会 watch 到这个变化,通过 GRPC 调用 CSI 里面的 Controller Service 的 ControllerPublishVolume 方法把 PV 调度到这个机器上 进入流程图中的 NODE_READY 。到现在为止是 Attach 阶段。

之后就是 Mount 阶段了。 Mount 阶段如上述流程图是分为 NodeStageVolume 和 NodePublishVolume 两个阶段,这两个阶段都在 driver/node.go 里面。 NodeStageVolume :

func (d *Driver) NodeStageVolume(ctx context.Context, req *csi.NodeStageVolumeRequest) (*csi.NodeStageVolumeResponse, error) 

	_, ok := req.VolumeAttributes[annNoFormatVolume]
	if !ok {
		formatted, err := d.mounter.IsFormatted(source)
		if err != nil {
			return nil, err
		}

		if !formatted {
			ll.Info("formatting the volume for staging")
			if err := d.mounter.Format(source, fsType); err != nil {
				return nil, status.Error(codes.Internal, err.Error())
			}
		} else {
			ll.Info("source device is already formatted")
		}

	} else {
		ll.Info("skipping formatting the source device")
	}
	if !mounted {
		if err := d.mounter.Mount(source, target, fsType, options...); err != nil {
			return nil, status.Error(codes.Internal, err.Error())
		}
	} else {
		ll.Info("source device is already mounted to the target path")
	}

主要是就是 Format 和 Mount ,其他的代码我都省略了,详情可以看源码。这里面的挂载是一个临时的挂载点 target := req.StagingTargetPath ,然后 NodePublishVolume

func (d *Driver) NodePublishVolume(ctx context.Context, req *csi.NodePublishVolumeRequest) 

	// Perform a bind mount to the full path to allow duplicate mounts of the same PD.
	options = append(options, "bind")

	if !mounted {
		ll.Info("mounting the volume")
		if err := d.mounter.Mount(source, target, fsType, options...); err != nil {
			return nil, status.Error(codes.Internal, err.Error())
		}
	} else {
		ll.Info("volume is already mounted")
	}

主要就是通过 bind 再把这个 StagingTargetPath mount 到 TargetPath。到此一个 dynamically provisioned volume 的流程就结束了。

总结

本文的主要目的就是把各种资料和连接放到这里,然后把整个流程大致梳理一遍。虽然抄了很多东西,但是自己还是把代码都下载了,仔细梳理了一遍,加上一些自己的东西,感觉还是很有意义的。