前言
最近在极客时间订阅了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 。详情可见。 下面是后面用到的这个文章里面的文字
其中 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 的流程就结束了。
总结
本文的主要目的就是把各种资料和连接放到这里，然后把整个流程大致梳理一遍。虽然抄了很多东西，但是自己还是把代码都下载了，仔细梳理了一遍，加上一些自己的东西，感觉还是很有意义的。