基于openshift+华为对象存储的CSI开发 -阿里云开发者社区

需求来源

项目上目前使用的是openshift 3.11版本，对应kubernetes 1.11，需要在该平台上使用CSI插件。

GitHub地址：https://github.com/woodliu/csi-s3

环境准备

本次使用openshift 3.11，对应kubernetes 1.11，参考github开源代码ctrox/csi-s3进行开发(强烈建议使用的kubernetes不低于1.13)。
部署中涉及如下sidecar容器：csi-attacher，csi-node-driver-registrar，csi-provisioner，csi-s3。最后一个容器是需要开发的CSI插件，其他sidecar版本需要与kubernetes配套才能使用，参照官方开发文档找到合适的版本，例如符合kubernetes 1.11版本的csi-attacher版本为0.42。除csi-s3之外的镜像都可以从官方镜像库中下载。
CSI spec规定了protobuf格式的存储相关的数据结构，本次应该采用v0.3.0版本。按照官方说法，kubernetes1.13中废弃了CSI spec 0.2和0.3版本。

Kubernetes	CSI Spec Compatibility	Status
v1.9	v0.1.0	Alpha
v1.10	v0.2.0	Beta
v1.11	v0.3.0	Beta
v1.13	v0.3.0, v1.0.0	GA

下载华为OBS对象存储Go语言SDK。
docker 17.05+(使用multi-stage生成镜像)

代码修改

主要是使用华为OBS的SDK操作替换代码中对bucket的操作等。涉及修改的代码文件为pkg/s3/controllerserver.go，nodeserver.go，s3-client.go

镜像下载

docker pull quay.io/k8scsi/csi-attacher:v0.4.2
docker pull quay.io/k8scsi/driver-registrar:v0.4.2
docker pull quay.io/k8scsi/csi-provisioner:v0.4.2

镜像生成

在/csi-s3目录中执行如下命令可以在/csi-s3/_output/目录中生成可执行文件s3driver

make build

在/csi-s3目录下执行如下命令生成镜像

make container

修改部署文件

修改storageclass
ctrox/csi-s3目录中的deploy/kubernetes/storageclass.yaml内容如下，mounter使用s3fs，由于仅使用s3fsMounterType类型，因此无需指定StorageClass.mounter字段

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: csi-s3
provisioner: ch.ctrox.csi.s3-driver
parameters:
# specify which mounter to use
# can be set to rclone, s3fs, goofys or s3backer
csiProvisionerSecretName: csi-s3-secret
csiProvisionerSecretNamespace: kube-system
csiControllerPublishSecretName: csi-s3-secret
csiControllerPublishSecretNamespace: kube-system
csiNodeStageSecretName: csi-s3-secret
csiNodeStageSecretNamespace: kube-system
csiNodePublishSecretName: csi-s3-secret
csiNodePublishSecretNamespace: kube-system

其中parameters字段的内容在1.0.1版本进行了修改，因此小于1.0版本的prvisioner采用左边的声明。

Deprecated	Replacement
csiProvisionerSecretName	csi.storage.k8s.io/provisioner-secret-name
csiProvisionerSecretNamespace	csi.storage.k8s.io/provisioner-secret-namespace
csiControllerPublishSecretName	csi.storage.k8s.io/controller-publish-secret-name
csiControllerPublishSecretNamespace	csi.storage.k8s.io/controller-publish-secret-namespace
csiNodeStageSecretName	csi.storage.k8s.io/node-stage-secret-name
csiNodeStageSecretNamespace	csi.storage.k8s.io/node-stage-secret-namespace
csiNodePublishSecretName	csi.storage.k8s.io/node-publish-secret-name
csiNodePublishSecretNamespace	csi.storage.k8s.io/node-publish-secret-namespace
fstype	csi.storage.k8s.io/fstype

修改secret.yaml，特别注意endpoint字段不能省略http或https

apiVersion: v1
kind: Secret
metadata:
name: csi-s3-secret
stringData:
accessKeyID: ${AK}
secretAccessKey: ${SK}
# For AWS set it to "https://s3.<region>.amazonaws.com"
endpoint: http://obs.${mycloud}.com
# If not on S3, set it to ""
region: <S3_REGION>

修改csi-s3.yaml，将容器卷挂载地址修改为/var/lib/origin/openshift.local.volumes/pods/
修改各个配置文件中的镜像仓库和版本

部署CSI插件

部署组件

cd deploy/kubernetes
kubectl create -f provisioner.yaml
kubectl create -f attacher.yaml
kubectl create -f csi-s3.yaml

部署storageclass

kubectl create -f storageclass.yaml

测试，创建一个pvc

kubectl create -f pvc.yaml

查看该pvc是否已经绑定

# oc get pvc
NAME         STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
csi-s3-pvc   Bound     pvc-ea844fa4-6f64-11ea-8eab-fa163e07eb1d   5Gi        RWO            csi-s3         30m

创建一个pod，查看该pod是否运行成功，并在该pod挂载的目录/var/lib/www/html下创建文件，看对象存储那端是否有新的文件生成。

oc create -f pod.yaml

CSI原理

核心原理

CSI的核心原理比较简单，见下图。基本原理就是启动一个CSI容器(自己写的插件)，将Node主机上的/var/lib/origin/openshift.local.volumes/pods/目录(该目录包含所有Pod的卷挂载点)挂载到CSI容器内部的/var/lib/origin/openshift.local.volumes/pods/目录下。然后调用s3fs命令将对象存储挂载到/var/lib/origin/openshift.local.volumes/pods/${POD_ID}/volumes/kubernetes.io~csi/${PV_NAME}/mount目录下，而/var/lib/origin/openshift.local.volumes/pods/${POD_ID}/volumes/kubernetes.io~csi/${PV_NAME}/mount就是对应容器挂载PVC对应的node节点上的挂载点。对象存储的BUCKET_NAME与PV_NAME相同。

总之整个过程涉及三次挂载：将应用容器在Node节点上的目录挂载到CSI容器中；将后端存储挂载到CSI容器中；将应用容器在Node节点上的目录挂载到应用容器中。

s3fs ${BUCKET_NAME}:/csi-fs /var/lib/origin/openshift.local.volumes/pods/${POD_ID}/volumes/kubernetes.io~csi/${PV_NAME}/mount -o use_path_request_style -o url=http://obs.${mycloud}.com  -o allow_other -o mp_umask=000

生命周期：

CSI插件的运作流程需要符合卷的生命周期特性，官方给出的生命周期如下：

CreateVolume +------------+ DeleteVolume
+------------->|  CREATED   +--------------+
|              +---+----^---+              |
|       Controller |    | Controller       v
+++         Publish |    | Unpublish       +++
|X|          Volume |    | Volume          | |
+-+             +---v----+---+             +-+
| NODE_READY |
+---+----^---+
               Node |    | Node
            Publish |    | Unpublish
             Volume |    | Volume
+---v----+---+
| PUBLISHED  |
+------------+
Figure 5: The lifecycle of a dynamically provisioned volume, from
creation to destruction.

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  |
+------------+
Figure 6: The lifecycle of a dynamically provisioned volume, from
creation to destruction, when the Node Plugin advertises the
STAGE_UNSTAGE_VOLUME capability.

Controller                  Controller
       Publish                  Unpublish
        Volume  +------------+  Volume
 +------------->+ NODE_READY +--------------+
 |              +---+----^---+              |
 |             Node |    | Node             v
+++         Publish |    | Unpublish       +++
|X| <-+      Volume |    | Volume          | |
+++   |         +---v----+---+             +-+
 |    |         | PUBLISHED  |
 |    |         +------------+
 +----+
   Validate
   Volume
   Capabilities
Figure 7: The lifecycle of a pre-provisioned volume that requires
controller to publish to a node (`ControllerPublishVolume`) prior to
publishing on the node (`NodePublishVolume`).

+-+  +-+
       |X|  | |
       +++  +^+
        |    |
   Node |    | Node
Publish |    | Unpublish
 Volume |    | Volume
    +---v----+---+
    | PUBLISHED  |
    +------------+
Figure 8: Plugins MAY forego other lifecycle steps by contraindicating
them via the capabilities API. Interactions with the volumes of such
plugins is reduced to `NodePublishVolume` and `NodeUnpublishVolume`
calls.

可以看到，并不需要实现controller(见下)中的所有功能，只需按照需要实现即可。

组件介绍

官方架构如下，主要分为两部分：DeamonSet Pod和Statefulset/Deployment Pod ,前者负责各个Node节点上的卷的挂载；后者负责操作后端存储并与API Server交互。

官方提供了两个很好的文档：Container Storage Interface (CSI)和CSI Volume Plugins in Kubernetes Design Doc。前者给出了开发涉及的接口，后者给出了内部原理。

CSI需要实现3个RPC服务

Identity Service: 允许容器编排系统像插件获取capabilities, health(probe), 和其他元数据
Controller Service: 见下文Controller接口的介绍
Node Service：见下文Node接口的介绍：

在CSI执行前需要调用如下接口注册对应的组件，各个组件需要实现对应的接口(见下文)：

func (s *Server) RegisterService(sd *ServiceDesc, ss interface{})
func (s *Server) RegisterService(sd *ServiceDesc, ss interface{})
func (s *Server) RegisterService(sd *ServiceDesc, ss interface{})

service Identity {
  rpc GetPluginInfo(GetPluginInfoRequest)
    returns (GetPluginInfoResponse) {}
  rpc GetPluginCapabilities(GetPluginCapabilitiesRequest)
    returns (GetPluginCapabilitiesResponse) {}
  rpc Probe (ProbeRequest)
    returns (ProbeResponse) {}
}
service Controller {
  rpc CreateVolume (CreateVolumeRequest)
    returns (CreateVolumeResponse) {}
  rpc DeleteVolume (DeleteVolumeRequest)
    returns (DeleteVolumeResponse) {}
  rpc ControllerPublishVolume (ControllerPublishVolumeRequest)
    returns (ControllerPublishVolumeResponse) {}
  rpc ControllerUnpublishVolume (ControllerUnpublishVolumeRequest)
    returns (ControllerUnpublishVolumeResponse) {}
  rpc ValidateVolumeCapabilities (ValidateVolumeCapabilitiesRequest)
    returns (ValidateVolumeCapabilitiesResponse) {}
  rpc ListVolumes (ListVolumesRequest)
    returns (ListVolumesResponse) {}
  rpc GetCapacity (GetCapacityRequest)
    returns (GetCapacityResponse) {}
  rpc ControllerGetCapabilities (ControllerGetCapabilitiesRequest)
    returns (ControllerGetCapabilitiesResponse) {}
  rpc CreateSnapshot (CreateSnapshotRequest)
    returns (CreateSnapshotResponse) {}
  rpc DeleteSnapshot (DeleteSnapshotRequest)
    returns (DeleteSnapshotResponse) {}
  rpc ListSnapshots (ListSnapshotsRequest)
    returns (ListSnapshotsResponse) {}
  rpc ControllerExpandVolume (ControllerExpandVolumeRequest)
    returns (ControllerExpandVolumeResponse) {}
}
service Node {
  rpc NodeStageVolume (NodeStageVolumeRequest)
    returns (NodeStageVolumeResponse) {}
  rpc NodeUnstageVolume (NodeUnstageVolumeRequest)
    returns (NodeUnstageVolumeResponse) {}
  rpc NodePublishVolume (NodePublishVolumeRequest)
    returns (NodePublishVolumeResponse) {}
  rpc NodeUnpublishVolume (NodeUnpublishVolumeRequest)
    returns (NodeUnpublishVolumeResponse) {}
  rpc NodeGetVolumeStats (NodeGetVolumeStatsRequest)
    returns (NodeGetVolumeStatsResponse) {}
  rpc NodeExpandVolume(NodeExpandVolumeRequest)
    returns (NodeExpandVolumeResponse) {}
  rpc NodeGetCapabilities (NodeGetCapabilitiesRequest)
    returns (NodeGetCapabilitiesResponse) {}
  rpc NodeGetInfo (NodeGetInfoRequest)
    returns (NodeGetInfoResponse) {}
}

下看主要看一下controller中涉及的主要功能：

CreateVolume/DeleteVolume：由provisioner调用，负责后端存储上卷的创建/删除，如对象存储上bucket的创建/删除。provisioner会监控用户创建/删除的PVC，进而操作PVC指定的storageclass。
ControllerPublishVolumeResponse/ControllerUnpublishVolume：由attacher调用，负责将远端卷挂载到node节点上。本次实现中，远端卷直接使用s3fs挂载到了csi容器中，因此没有实现该接口，即没有指定ControllerServiceCapability_RPC_PUBLISH_UNPUBLISH_VOLUME。*注：虽然没有实现该接口，但attacher容器必须要部署。
NodeStageVolume/NodeUnstageVolume：由registrar调用，用于处理setup/teardown(初始化设置/清理环境)卷。
NodePublishVolume/NodeUnpublishVolume：由registrar调用，用于将卷挂载/卸载到应用容器中。registrar用到了两个UNIX域套接字：

Registration socket：

创建reg.sock文件，用于将驱动注册到kubelet
通过kubelet插件库路径(通常是/var/lib/kubelet/plugins_registry/<drivername.example.com>-reg.sock暴露服务

CSI driver socket：

创建sock文件，kubelet用该socket与CSI驱动交互
通过kubelet插件库路径(通常是/var/lib/kubelet/plugins/<drivername.example.com>/csi.sock)暴露服务。

NOTE

本方式其实是将对象存储转化为文件系统的方式，理论上应该是存在性能损失的
更多内容可以参见这篇文章

FAQ

pvc创建不成功。这个一般是对后端存储的操作不正确导致的，需要检查controllerserver.go中的代码
pv和pvc绑定成功，但容器挂载不成功：transport endpoint is not connected，可以在对应节点的daemonset pod中csi容器中执行如下命令调试，一般是s3fs命令格式不对导致的。

echo ${AK}:${SK} > ${passwd_file}
s3fs ${bucket_name} ${target_mount_path} -o url=http://obs.${mycloud}.com -o passwd_file=${passwd} -o dbglevel=info -f -o curldbg

pv和pvc绑定成功，且容器挂载成功，但对容器挂载目录的变更无法同步到后端存储。需要检查对应node节点上的csi容器中的挂载点是否正确。一般是spec.template.spec.containers.csi-s3.volumeMounts.pods-mount-dir和spec.template.spec.volumes.pods-mount-dir值不一致导致的

基于openshift+华为对象存储的CSI开发

需求来源

环境准备

代码修改

镜像下载

镜像生成

修改部署文件

部署CSI插件

CSI原理

核心原理

生命周期：

组件介绍

NOTE

FAQ

参考：

热门文章

最新文章

探索云世界

热门

云计算

大数据

云原生

人工智能

数据库

开发与运维

活动广场

任务中心

训练营

直播

乘风者计划

下载

镜像站

技术资料

基于openshift+华为对象存储的CSI开发

需求来源

环境准备

代码修改

镜像下载

镜像生成

修改部署文件

部署CSI插件

CSI原理

核心原理

生命周期：

组件介绍

NOTE

FAQ

参考：

热门文章

最新文章