CSI学习笔记

从1.8版本开始，Kubernetes Storage SIG开始停止接受in-tree卷插件，并建议所有供应商实现out-of-tree卷插件。CSI是两种out-of-tree的K8S卷扩展机制之一，另外一个是Flexvolume。

Flexvolume的工作方式是，由名为flexvolume的in-tree插件来调用用户提供的卷插件。你需要事先把卷插件拷贝到所有K8S节点上，还要处理好卷插件升级的问题。

CSI出现更晚，也是未来的发展方向。它通过单一的接口描述存储供应商需要实现的逻辑，以保证它们提供的块、文件存储能够在容器工作负载上使用。CSI从设计上不和K8S绑定，期望能在任何容器编排系统中运行。

在K8S的1.13版本，它的CSI实现到达GA，兼容CSI v1.0和v0.3版本。

查看：https://kubernetes-csi.github.io/docs/drivers.html，其中列出了知名的CSI驱动实现。

1. 独立于K8S版本进行演变，包括开发、测试、维护
2. 不会影响K8S核心组件的运行
3. 不会因为和K8S核心组件具有相同的特权，而导致安全隐患
4. 不需要遵循K8S项目本身的开发规范

1. 部署简单，不需要宿主机的root权限
2. attach/mount时常常依赖于第三方工具，例如ceph需要rbd

 

整体架构上，CSI和FlexVolume没有太大区别，只是FlexVolume是通过命令行调用，而CSI则是通过gRPC调用。

上图中：

1. Attach/Detach控制器：负责将卷附到节点，或者执行反向操作。例如将Ceph的RBD卷映射为某个节点上的块设备
2. PV/PVC控制器：负责面向用户的PV/PVC接口
3. Volume Manager：运行在Kubelet中，让卷对于Pod就绪
4. Volume Plugins：插件化机制，对接各种存储解决方案

卷的整个生命周期，会牵涉到6个流程：

1. Provision/Delete：PV控制器会监听API Server中的资源更新，主要监听PV / PVC / SC三类资源。当发现这些资源的CRU操作时，PV控制器会判断是否需要创建、删除、绑定（PV到PVC）、回收卷
2.  Attach/Detach：由AttachDetach控制器、节点上的VolumeManager负责
   1. AttachDetach控制器监听Pod/Node事件，如有必要，调用Volume Plugin执行Attach/Detach操作
   2. VolumeManager也能够触发Attach/Detach操作，但是它监听的是调度到本节点的Pod，判断是否需要调用Volume Plugin执行Attach/Detach操作
3. Mount/Umount：将卷挂载给Pod

最初，只有VolumeManager能够Attach/Detach，但是节点宕掉后，它已经挂载的卷需要在其它节点进行Detach，然后再Attach，这个必须依赖外部才能完成，AttachDetach控制器因而产生。

现在，到底在何处进行Attach/Detach，取决于Volume Plugin，如果实现了Attach相关接口，则在AttachDetach中执行，否则，在Volume Manager上执行。

FlexVolume支持后面4个流程，Provision/Delete需要开发外置的Provisioner来实现。

 

如上图所述，在K8S核心存储之外，CSI引入两组外部组件：

1. K8S团队提供：
   1. Node Driver registrar ：一个Sidecar，向K8S注册CSI驱动
   2. External provisioner ：一个Sidecar，监控PVC，调用匹配的CSI驱动的卷创建、删除接口
   3. External attacher：一个Sidecar，监控VolumeAttachment，调用CSI驱动相应的接口
2. 第三方厂商提供：
   1. CSI Identity：提供插件信息、能力、探测插件状态
   2. CSI Controller：负责创建和管理卷
   3. CSI Node：在节点上完成和卷相关的功能，例如Publish/Unpublish、Stage/Unstage

Kubelet和CSI驱动的交互方式：

1. Kubelet直接通过UDS，向CSI发起NodeStageVolume、NodePublishVolume等调用
2. Kubelet通过插件注册机制来发现CSI驱动及其UDS套接字。这意味着CSI插件必须在任何节点上进行Kubelet插件注册

Master和CSI驱动的交互方式：

1. K8S控制平面不直接和CSI驱动交互
2. K8S控制平面组件仅仅通过K8S API进行相互交互
3. CSI驱动必须监控相关K8S API资源，并触发对应的CSI操作，例如卷创建、Attach、快照生成…

细节参考：https://github.com/container-storage-interface/spec/blob/master/spec.md

术语	说明
Volume	通过CSI来让CO管理的容器能够使用的存储单元
Block Volume	在容器里呈现为块设备的卷
Mounted Volume	利用某种文件系统挂载到容器的，表现为目录的卷
CO	容器编排系统，使用CSI的RPC接口和CSI插件交互
SP	存储提供商，即CSI插件的实现的提供者
RPC	远程过程调用
Node	用户工作负载在其上运行的节点，在CSI插件的视角，以节点ID唯一标识
Plugin	CSI插件，本质上是实现了CSI服务的gRPC端点
Plugin Supervisor	管理CSI插件的进程，可以是CO
Workload	可以被CO调度的原子工作单元，可能是一个容器，或容器组

CSI规范的主要关注点是CO和Plugin之间的协议。CO应该同时支持中心化部署、headless部署的Plugin。几种可能的部署架构：

1. 插件运行在所有节点上，在CO的Master上运行中心化的控制器，所有节点上运行Node Plugin：
   
   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

   CO "Master" Host +-------------------------------------------+ |                                           | |  +------------+           +------------+  | |  |     CO     |   gRPC    | Controller |  | |  |            +----------->   Plugin   |  | |  +------------+           +------------+  | |                                           | +-------------------------------------------+                               CO "Node" Host(s) +-------------------------------------------+ |                                           | |  +------------+           +------------+  | |  |     CO     |   gRPC    |    Node    |  | |  |            +----------->   Plugin   |  | |  +------------+           +------------+  | |                                           | +-------------------------------------------+

2. Headless部署，在所有CO节点上运行Plugin，Controller Plugin、Node Plugin分开部署：
   
   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

   CO "Node" Host(s) +-------------------------------------------+ |                                           | |  +------------+           +------------+  | |  |     CO     |   gRPC    | Controller |  | |  |            +--+-------->   Plugin   |  | |  +------------+  |        +------------+  | |                  |                        | |                  |                        | |                  |        +------------+  | |                  |        |    Node    |  | |                  +-------->   Plugin   |  | |                           +------------+  | |                                           | +-------------------------------------------+

3. Headless部署，在所有CO节点上运行Plugin，Controller Plugin、Node Plugin合并部署：
   
   1 2 3 4 5 6 7 8 9 10

   CO "Node" Host(s) +-------------------------------------------+ |                                           | |  +------------+           +------------+  | |  |     CO     |   gRPC    | Controller |  | |  |            +----------->    Node    |  | |  +------------+           |   Plugin   |  | |                           +------------+  | |                                           | +-------------------------------------------+

4. Headless部署，在所有CO节点上运行Plugin，只运行Node Plugin。GetPluginCapabilities调用不会报告CONTROLLER_SERVICE特性：
   
   1 2 3 4 5 6 7 8 9

   CO "Node" Host(s) +-------------------------------------------+ |                                           | |  +------------+           +------------+  | |  |     CO     |   gRPC    |    Node    |  | |  |            +----------->   Plugin   |  | |  +------------+           +------------+  | |                                           | +-------------------------------------------+

状态说明：

状态	说明
CREATED	卷已经创建，包括在底层存储中的对应物
NODE_READY	卷已经被Attach到某个节点上
PUBLISHED	卷已经挂载给容器
VOL_READY	卷已经在节点上可用（deviceMount，在节点上进行了卷的全局性挂载），但是没有（bind）挂载给容器

一个动态提供的卷，从创建到销毁的状态流转：

如果Node Plugin支持STAGE_UNSTAGE_VOLUME特性，则创建到销毁的状态流转：

预分配的卷，控制器将其发布到节点（ControllerPublishVolume），然后发布给容器（NodePublishVolume）的状态流转： 

通过capabilities API可以禁用掉某些生命周期状态。和这种卷的交互仅剩下NodePublishVolume/NodeUnpublishVolume：

CO和Plugin之间的接口，使用gRPC为载体。每个SP都需要提供：

1. Node Plugin：对于任何SP提供的卷，想要Publish到的节点，都要运行此插件
2. Controller Plugin：可以运行在任何地方，实现创建卷、创建快照等功能。可选

某些部署架构下，一个gRPC端点（可能由一个二进制文件提供）可以提供上述两组服务。

通常情况下，由CO保证，针对同一个卷，在任何时刻，不会有大于1个的in-flight调用。

但是，如果CO崩溃，它会丢失状态信息，导致可能重复发送请求。Plugin应当尽可能优雅的处理这种场景，有可能应当返回ABORTED提示CO。

字符串最大128字节。map<string,string>最大4KiB。

规范中所有RPC接口都允许超时、在超时后可以重试。等待时间、超时重试间隔，由CO自行决定。

Plugin实现必须注意满足幂等要求。

取消一个调用的唯一方式，是执行一个反向操作，例如发起ControllerUnpublishVolume可以取消ControllerPublishVolume。

Plugin必须返回标准的gRPC状态码。状态code必须包含规范错误码。CO需要处理所有有效的错误码。

错误情形和对应gRPC代码如下：

例外条件	gRPC代码	描述
缺少必须字段	3 INVALID_ARGUMENT	提示请求中缺失必须字段，更多信息查看status.message字段
无效或不支持的字段	3 INVALID_ARGUMENT	一个或多个字段不被插件支持，或者用法不对
访问被拒绝	7 PERMISSION_DENIED	插件能够识别请求者的身份，但是此身份没有访问资格
对于目标卷存在未决的操作	10 ABORTED	提示当前存在一个针对卷的、尚未完成的操作。通常CO会保证在同一时刻不会存在大于1个的、针对同一个卷的in-fight请求
RPC接口没实现	12 UNIMPLEMENTED	插件没有实现接口，或者在当前配置下被禁用
身份验证失败	16 UNAUTHENTICATED	RPC请求没有携带有效的secret

你可以通过标准的K8S API来使用CSI卷，包括PersistentVolumeClaim、PersistentVolume、StorageClass。

你可能需要开启Kubelet的标记 --allow-privileged=true，因为大部分CSI插件需要双向挂载传播，者有特权Pod才能做到这一点。

使用StorageClass，示例：

然后在你的PVC中引用此StorageClass：

细节参考：https://kubernetes-csi.github.io/docs/developing.html

K8S开发团队推荐了一套开发、部署、测试CSI驱动的途径，目标是减少样板代码、简化总体开发流程。该机制依赖于以下组件：

1. Kubernetes CSI Sidecar Containers
2. Kubernetes CSI Objects
3. CSI 驱动测试工具

要基于推荐途径，实现一个CSI驱动，开发者需要：

1. 创建一个容器化的应用程序，实现Identity、Node接口，可选的，实现Controller接口
2. 基于csi-sanity进行单元测试
3. 定义K8S编排配置，部署CSI驱动容器 + 适当的（K8S官方维护的）Sidecar容器
4. 部署到K8S，进行端到端测试

开发CSI驱动的第一步是编写CSI规范中要求的gRPC服务。你至少需要实现：

1. Identity：让调用者（K8S组件、CSI Sidecar容器）能识别驱动，知晓它具有哪些可选特性
2. Node：必须实现NodePublishVolume、NodeUnpublishVolume、NodeGetCapabilities。这些方法能够将卷在节点的特定路径可用

CSI驱动不需要实现CSI规范的全集，你需要为驱动指定capabilities，声明它支持哪些CSI特性。

CSI的capabilities用于描述驱动支持的额外特性（对应CSI规范中的方法）：

特性	说明
CONTROLLER_SERVICE	PluginCapability，整个Controller组件都是可选的，此特性提示CSI驱动支持Controller中的一个或多个方法
VOLUME_ACCESSIBILITY_CONSTRAINTS	PluginCapability，提示该CSI插件生成的卷，不一定在任何节点上，都可以完全相同的访问。驱动可以返回额外的拓扑相关的信息给K8S，K8S可以利用这些信息： 更加智能的调度工作负载 影响卷在何处创建
VolumeExpansion	PluginCapability，提示CSI插件支持resize创建好的卷
CREATE_DELETE_VOLUME	ControllerServiceCapability，提示CSI插件支持动态的创建（Provision）和删除（Delete）卷
PUBLISH_UNPUBLISH_VOLUME	ControllerServiceCapability，提示CSI插件支持ControllerPublishVolume、ControllerUnpublishVolume操作，这两个方法对应K8S卷的Attach/Detach操作 举例来说，这些操作可能将RBD卷映射为某个节点上的块设备
CREATE_DELETE_SNAPSHOT	ControllerServiceCapability。提示CSI插件支持创建快照，并且支持基于快照创建新的卷
CLONE_VOLUME	ControllerServiceCapability。提示CSI插件支持克隆卷
STAGE_UNSTAGE_VOLUME	NodeServiceCapability。提示CSI驱动实现了NodeStageVolume、NodeUnstageVolume操作，这两个方法对应K8S卷设备的mount/umount操作 举例来说，这些操作可能将卷在节点上进行全局性的挂载

K8S API中包含两个CSI相关的对象。

该对象有两方面的价值：

1. 简化CSI驱动的发现：你可以在安装CSI驱动时附带一个CSIDriver对象，这样K8S就可以轻易的发现此驱动（通过kubectl get csidriver）
2. 定制K8S的行为：K8S具有一套和CSI驱动交互的默认规则，例如默认它会调用Attach/Detach操作。使用CSIDriver对象可以定制这一行为

对象示例：

列出所有CSI Driver：

CSI驱动产生的、节点相关的信息，存放在此对象中（而非Node对象）。价值：

1. 映射K8S节点名称到CSI节点名称：CSI的GetNodeInfo调用返回的name，是存储系统引用节点使用的名字。在后续的ControllerPublishVolume调用中K8S使用该名字引用节点
2. 为kubelet提供和kube-controller-manager、kube-scheduler交互的机制，不管CSI插件是否可用（注册到节点）
3. 卷拓扑：CSI的GetNodeInfo调用会返回一系列标签（键值对），来识别节点的拓扑信息。K8S使用这些信息进行拓扑感知的卷创建。这些键值对存放在Node对象中，Kubelet会把键存放在CSINode中，供后续引用

对象示例：

将你的CSI驱动二进制程序，和不同的Sidecar一起编排，然后部署在node/controller模式下，实现不同的角色。

这些Sidecar由K8S官方维护，将通用的、样板逻辑抽取出来，降低开发CSI驱动的负担。

监控K8S API中的VolumeAttachment对象并进行处理（调用CSI驱动对应方法），VolumeAttachment对象表示一个将卷Attach/Detach到某个节点的期望。

监控PersistentVolumeClaim，调用CSI驱动的CreateVolume以创建新的卷。此Sidecar还负责删除卷、从快照创建卷、复制现有的卷。

一个新的PersistentVolumeClaim对象会触发卷的创建流程，如果PVC关联了SC，那么SC的provisioner字段指明谁负责实际的创建工作。

如果CSI驱动的Identity.GetPluginInfo返回的name，和上述provisioner匹配，则该CSI驱动负责创建，这一逻辑已经由external-provisioner实现好。

当卷创建好了，该Sidecar会创建一个PersistentVolume对象，代表新创建的卷。

当PVC删除后，它绑定的PersistentVolume的回收策略如果是delete，则该Sidecar会调用CSI驱动的DeleteVolume，清理掉卷。该Sidecar也会同时删除掉PersistentVolume对象。

在卷创建好后，还可以自动从数据源填充数据进去，参考VolumeContentSource。

external-provisioner支持Snapshot数据源。external-provisioner会通过SnapshotContent对象获取快照的信息，在CreateVolume调用中提供数据源字段，CSI驱动应该识别此字段，并且调用底层存储的接口，基于快照创建卷：

类似的， 将数据源类型设置为PersistentVolumeClaim，可以克隆现有的PVC对应的卷：

在创建新卷时，external-provisioner会设置CreateVolumeRequest的 map<string, string> parameters字段，将它正在处理PVC的SC的parameters键值对存放到该parameters字段中。以 csi.storage.k8s.io/前缀的键是保留的，以此前缀开头的键值对，不作为opaque参数传递（也就是说会引发external-provisioner的特殊行为）：

csi.storage.k8s.io/provisioner-secret-name
csi.storage.k8s.io/provisioner-secret-namespace
csi.storage.k8s.io/controller-publish-secret-name
csi.storage.k8s.io/controller-publish-secret-namespace
csi.storage.k8s.io/node-stage-secret-name
csi.storage.k8s.io/node-stage-secret-namespace
csi.storage.k8s.io/node-publish-secret-name
csi.storage.k8s.io/node-publish-secret-namespace
csi.storage.k8s.io/fstype

示例SC：

监控PersistentVolumeClaim的变更，如果容量变大，则触发CSI驱动的ControllerExpandVolume操作，增加底层卷大尺寸。

在1.17中卷快照功能到达Beta，原先的CSI external-snapshotter sidecar controller分裂为两个组件：

1. snapshot-controller
2. CSI external-snapshotter sidecar

snapshot-controller会监控VolumeSnapshot、VolumeSnapshotContent对象。它会创建VolumeSnapshotContent对象，此对象会触发sidecar进行快照相关操作。

snapshot-controller需要独立于CSI驱动部署，你需要安装CRD和控制器本身：

external-snapshotter仅监控VolumeSnapshotContent，并调用CSI驱动的CreateSnapshot、DeleteSnapshot、ListSnapshots方法。

此sidecar探测CSI驱动的健康状况，并通过Liveness Probe机制上报给K8S，这样K8S可以探测到CSI驱动的故障，并尝试重启解决。

通过调用NodeGetInfo获取CSI驱动的信息，然后基于kubelet的插件注册机制，来注册到本地的kubelet。

已经在1.16废弃。

此Sidecar的目的是，自动注册包含CSI驱动信息的CSIDriver对象到K8S。由于已经废弃，CSI驱动提供商需要在安装清单中添加一个CSIDriver对象。

如果CSI驱动需要Secret信息（例如账号密码），而且此信息是驱动级别的（而非卷级别），应该使用K8S标准的密钥分发机制（卷挂载），直接注入到CSI驱动的Pod。 

如果需要针对单个CSI操作、单个卷、单个存储池提供Secret，则可以通过CreateVolumeRequest、ControllerPublishVolumeRequest等操作的参数传递Secret。集群管理员需要创建相应的Secret对象，并在StorageClass、SnapshotClass对象中提供具有特定名字的parameters。

external-provisioner能够自动处理：

CreateVolumeRequest
DeleteVolumeRequest
ControllerPublishVolumeRequest
ControllerUnpublishVolumeRequest
ControllerExpandVolumeRequest
NodeStageVolumeRequest
NodePublishVolumeRequest

这些操作需要的Secret信息，它能够识别StorageClass.parameters中的以下名字：

csi.storage.k8s.io/provisioner-secret-name
csi.storage.k8s.io/provisioner-secret-namespace
csi.storage.k8s.io/controller-publish-secret-name
csi.storage.k8s.io/controller-publish-secret-namespace
csi.storage.k8s.io/node-stage-secret-name
csi.storage.k8s.io/node-stage-secret-namespace
csi.storage.k8s.io/node-publish-secret-name
csi.storage.k8s.io/node-publish-secret-namespace

csi.storage.k8s.io/controller-expand-secret-name
csi.storage.k8s.io/controller-expand-secret-namespace

示例一，Provision需要的通用Secret：

示例二，Per-volume Secret：

某些存储系统，会暴露不是对任何K8S节点“等同可访问”的卷，也就是说，某些卷可能仅仅允许部分节点访问。集群中的节点可能被分段到rack、zone、region之类的组中，并且限定某些卷仅能够某些分组使用。

要启用该特性，需要设置external-provisioner的 --feature-gates=Topology=true参数。

为了让K8S这样的CO能够与上面的存储系统协作，CSI规范支持：

1. 允许CSI驱动“不透明的”（opaquely）指定特定节点所在位置，例如节点A位于zone 1
2. 允许K8S（的用户或组件）影响卷在何处创建，例如在zone 1或zone 2中创建卷
3. 允许CSI驱动“不透明的”指定卷在何处，例如volume 1在zone 1或zone2的所有节点可用

K8S能够使用CSI拓扑进行智能调度。external-provisioner也能够使用CSI拓扑来确定Provision决策。

要在你的CSI驱动中实现拓扑特性，需要：

1. PluginCapability需要支持VOLUME_ACCESSIBILITY_CONTRAINTS
2. 驱动必须在NodeGetInfoResponse中设置好accessible_topology，这个信息会被K8S用来产生CSINode对象、为Node对象添加拓扑相关标签。
3. 在CreateVolume时，拓扑信息会通过CreateVolumeRequest.accessibility_requirements传入，你的CSI驱动需要正确处理

在StorageClass对象中，volumeBindingMode可以取值：

1. Immediate，则external-provisioner会传入集群中所有可用的拓扑信息
2. WaitForFirstConsumer，则external-provisioner会等待调度器选择一个节点，该节点的拓扑信息会被设置为CreateVolumeRequest.accessibility_requirements.preferred的第一个元素。所有其它拓扑信息仍然包含在requisite、preferred字段中，以支持那些跨越多个拓扑的存储系统

（原始）块卷就是在容器中呈现为块设备的卷，而挂载卷（Mounted volume）则以特定类型的文件系统，挂载为容器中的一个目录。

CSI没有提供一个针对原始块卷的capability，CO会传递一个块卷创建请求给CSI驱动，如果你的驱动不支持创建快卷，则可以返回gRCP错误码InvalidArgument。

可以通过卷创建请求的VolumeCapabilities字段字段识别，K8S要你创建的是块卷还是挂载卷。该字段是一个数组，你创建的卷必须满足数组中所有元素指明的特性。如果一个VolumeCapability.AccessType == VolumeCapability_Block，则意味着请求的是块卷。

某些卷驱动，例如NFS，没有Attach（对应ControllerPublishVolume）的概念，但是K8S总是会执行Attach/Detach操作，即使CSI驱动没有实现相应的接口。

如果不经任何处理，调用必然会出错。一个变通方案是使用external-attacher，它能够直接向K8S响应以noop。这个方案的缺点是多了不必要的一层，而且还需要部署sidecar。

更好的方式是，使用CSIDriver对象，声明K8S应当和CSI驱动进行交互的方式：

此对象应该包含在你的CSI安装包的清单文件中。

CSI避免在规范中添加K8S特有的信息，以保持中立。

但是某些情况下，CSI驱动需要知道关于工作负载的信息（是哪个Pod需要使用卷），要获得这些信息，需要配置CSIDriver对象： 

NodePublishVolumeRequest.volume_context中增加的字段包括：

csi.storage.k8s.io/pod.name: {pod.Name}
csi.storage.k8s.io/pod.namespace: {pod.Namespace}
csi.storage.k8s.io/pod.uid: {pod.UID}
csi.storage.k8s.io/serviceAccount.name: {pod.Spec.ServiceAccountName}

要支持在创建之后，改变卷的大小，你的驱动需要：

1. 实现VolumeExpansion这一插件特性（capability）
2. 实现控制器特性EXPAND_VOLUME，或者节点特性EXPAND_VOLUME，或者都实现

根据你的实现方式不同，卷扩容可能通过一次控制平面CSI RPC调用完成，也可能通过一次Node CSI RPC调用完成，也可以同时调用，分两步完成。

取决于插件特性VolumeExpansion，调用ControllerExpandVolume可以针对ONLINE或OFFLINE的卷执行：

1. ONLINE，卷当前已经被publish（attach），或者在节点上可用
2. OFFLINE，卷当前没有被publish，在节点上不可用

而NodeExpandVolume，则总是要求卷处于ONLINE状态。对于块存储，NodeExpandVolume典型情况下用来扩展它在节点上的文件系统的大小。

external-resizer这个sidecar由K8S提供，它负责监控PVC的变更，必要的话向CSI驱动发起ControllerExpandVolume调用。

在1.14 - 1.15中，卷扩展是Alpha特性，需要通过特性开关启用： --feature-gates=ExpandCSIVolumes=true

在1.14 - 1.15中，在线卷扩展需要通过特性开关启用： --feature-gates=ExpandInUsePersistentVolumes=true

创建PVC时，你可以指定PersistentVolumeClaim.DataSource字段，该字段对应CreateVolumeRequest.VolumeContentSource，VolumeContentSource提示CSI驱动，使用指定数据源来填充新创建的卷。

第一种用法是卷克隆，另一种是卷快照。

此特性1.16到达Beta。

传统的由CSI驱动提供的卷，仅仅和PV/PVC联用，是持久化的卷。

Pod内联卷（inline volume）用于支持临时存储用例。你可以在Pod Spec中直接指定CSI卷。在运行期间，内联卷遵循临时存储的生命周期（和Pod同步），CSI驱动在Pod创建、销毁期间，完成卷的管理操作。

配置示例：

要支持内联卷，CSI驱动的逻辑需要变动。当K8S遇到声明了内联卷的Pod，它采用不同的处理方式。主要的一点是，驱动仅仅会：

1. 在卷挂载期间，接收到NodePublish调用
2. 在Pod删除、卷卸载时，接收到NodeUnpublish调用

CSIDriver对象的volumeLifecycleModes，必须包含Ephemeral。

1.15的特性开关 --feature-gates=CSIInlineVolume=true必须打开。

使用来自csi-test项目的sanity包，可以进行单元测试。

该包提供了一系列基础测试用例，任何CSI驱动都应该通过。例如，对于NodePublishVolume，如果没有提供卷，则应当失败。

你可以通过两种模式使用该包：

1. 使用Go测试框架，将sanity包导入为依赖
2. 使用命令行方式，针对你的驱动二进制文件进行测试

该库提供了一种简单的方式，验证CSI驱动遵循了规范。正如上文所述，对于Go语言开发的驱动，你可以将它引入为依赖。对于其它语言开发的驱动，则需要调用 csi-sanity命令对驱动的二进制文件进行测试。

sanity基于Ginkgo这一BDD测试框架，你可以在自己的TestXxx函数中调用sanity.Test：

另外一种用法，将自己的测试用例嵌入到Ginkgo测试套件中：

目前，CSI社区提供了端到端测试用例集，你可以将其导入自己的CSI驱动项目并执行。

未来CSI社区将会创建一套CSI一致性套件（CSI Conformance Suite），用于认证某个CSI驱动符合CSI Spec。

作为前提条件，你需要kubectl和1.13版本以上的K8S集群。

运行端到端测试的两种方式：

1. 使用Kubernetes E2E Tests，通过参数提供DriverDefinition YAML文件。某些情况下，你无法使用这种测试途径，例如NFS的CSI插件，目前不支持动态Provisioning，因此必须跳过此步骤，你需要编写自己的testdriver
2. 导入in-tree用例，使用go test执行

本节主要讨论第2种测试方式。

你可以使用K8S in-tree的存储E2E测试（1.14+）来测试自己的CSI驱动，参考NFS CSI plugin了解具体做法：测试文件位于test目录，主测试文件位于cmd目录。

你的驱动需要依赖1.14+版本的K8S，因为从1.14开始，才支持可拔插的E2E测试。

你还需要为CSI驱动实现testdriver，以说明如何创建测试用例。对于任何testdriver，以下函数是必须的：

1. GetDriverInfo() *testsuites.DriverInfo：返回DriverInfo，测试基于此方法寻找部署的CSI驱动，并且依据驱动的capability决定执行哪些用例。NFS驱动返回的信息如下：
   
   Go

   1 2 3 4 5 6 7 8 9 10 11

   testsuites.DriverInfo{             Name:        "csi-nfsplugin",             MaxFileSize: testpatterns.FileSizeLarge,             SupportedFsType: sets.NewString(                 "", // Default fsType             ),             Capabilities: map[testsuites.Capability]bool{                 testsuites.CapPersistence: true,                 testsuites.CapExec:        true,             }, }

    Hostpath驱动返回的信息如下：

   Go

   1 2 3 4 5 6 7 8 9 10 11

   testsuites.DriverInfo{             Name:        "csi-hostpath",             FeatureTag:  "",             MaxFileSize: testpatterns.FileSizeMedium,             SupportedFsType: sets.NewString(                 "", // Default fsType             ),             Capabilities: map[testsuites.Capability]bool{                 testsuites.CapPersistence: true,             }, }

2. SkipUnsupportedTest(pattern testpatterns.TestPattern)：提供你声明的、不支持的用例
3. PrepareTest(f *framework.Framework) (*testsuites.PerTestConfig, func())：在此编写代码，setup你的CSI插件，在执行每个用例之前该方法会被调用

此外，取决于CSI驱动的特点， 你可能还需要实现testdriver的其它接口。例如对于NFS驱动，需要实现PreprovisionedVolumeTestDriver、PreprovisionedPVTestDriver，这样才能启动pre-provisioned测试

为CSI驱动实现了testdriver之后，你需要创建一个csi-volumes.go文件，在其中，利用testdriver来执行in-tree存储测试套件。

所有可用的in-tree存储测试套件参考：https://github.com/kubernetes/kubernetes/tree/master/test/e2e/storage/testsuites。 

最后，在主测试文件中导入test包，初始化测试套件，运行测试：

尽管主测试文件会产生一个二进制文件，你也可以用go test来执行E2E测试：

典型情况下，一个CSI驱动部署为K8S的两组组件：Controller组件、Per-node组件。

可以部署在任何节点上，部署为Deployment或StatefulSet。该组件必须包含实现了CSI Controller服务的CSI驱动，附带1或多个sidecar。 Sidecar负责监控K8S对象，然后通过UDS（通过emptyDir在容器之间共享）调用CSI驱动的gRPC服务，Sidecar将CSI驱动公共逻辑提取出去，让你不必写样板代码。

你可以部署多个副本，实现HA，但是最好使用Leader选举机制，确保同一时刻只有一个活动的控制器。

通过DaemonSet部署到所有节点。该组件必须包含实现了CSI Node服务的CSI驱动，附带node-driver-registrar这个sidecar。

运行在节点上的Kubelet负责调用Node组件，进行mount/umount，并让卷对Pod可见。Kubelet同样通过UDS调用CSI驱动，UDS文件描述符位于hostPath卷中，在宿主机位置为 /var/lib/kubelet/<plugin name>/csi.sock

Node组件需要直接访问宿主机，这样才能保证块设备/文件系统挂载能够被Kubelet看见。因此，Node组件的挂载点必须设置为双向传播（Bidirectional）的，允许Kubelet能够看到Node组件容器创建的新挂载：

为了启用K8S的挂载转播特性，底层运行时可能需要进行配置。对于Docker，你需要修改Systemd单元： 

并重启Docker服务。 

该项目的地址：https://github.com/kubernetes-csi/csi-driver-nfs，实现了CSI规范的最小子集。

该服务需要在宿主机上执行挂载操作，因此驱动通过下面的调用为它提供了一个Mounter：

Node服务实现了CSI Spec的Node接口：

代码比较简单：

不管是三大服务的哪个，都需要持有nfsDriver的引用：

Identity服务实现了CSI Spec的Identity接口：

代码如下：

Controller服务实现了CSI Spec的Controller接口：

代码就不贴了，都是简单的返回Unimplemented错误。 

在nfsDriver的Run方法中，将上述三个服务组装为一个gRPC服务：

gRPC服务由下面的接口表示：

它的实现是一个结构，引用一个grpc.Server：

启动gRPC服务的逻辑：

前文介绍过，端到端测试可以作为二进制文件运行：

按照约定，在名为test/csi-volumes.go的文件中定义测试用例：

test/nfs-testdriver.go中则定义了NFS CSI Driver的TestDriver，我们先看一下该接口：

此外，NFS的测试驱动还实现了：

以支持pre-provisioned测试。 

下面看一下NFS的TestDriver的实现：

这里有一个华为CSI的例子，我们看看它是如何编排的。

Attacher属于Controller组件，因此部署为Deployment：

权限相关：

StorageClass：

这个不知道为什么要做成StatefulSet：

权限相关：

该组件需要运行在所有节点，因此是DaemonSet：

权限相关：