共计 5930 个字符，预计需要花费 15 分钟才能阅读完成。
作者：Saad Ali，Google 高级软件工程师
Kubernetes 实施的容器存储接口（CSI）已在 Kubernetes v1.13 版本中升级为 GA。CSI 的支持在 Kubernetes v1.9 版本中作为 alpha 引入，并在 Kubernetes v1.10 版本中升级为 beta。
GA 里程碑表明 Kubernetes 用户可能依赖于该功能及其 API，而不必担心将来回归（regression）导致的向后不兼容的更改。GA 功能受 Kubernetes 弃用（deprecation）政策保护。
为何选择 CSI？
虽然在 CSI 之前，Kubernetes 提供了一个功能强大的卷插件系统，但是在 Kubernetes 添加对新卷插件的支持是一项挑战：卷插件是“树内”（“in-tree”），这意味着他们的代码是核心 Kubernetes 代码的一部分，并随核心 Kubernetes 一起提供二进制文件。希望向 Kubernetes 添加对其存储系统的支持（或修复现有卷插件中的错误）的供应商被迫与 Kubernetes 发布流程保持一致。此外，第三方存储代码导致核心 Kubernetes 二进制文件中的可靠性和安全性问题，代码通常很难（在某些情况下不可能）让 Kubernetes 维护者进行测试和维护。
CSI 是作为将任意块和文件存储存储系统暴露于容器编排系统（CO）上，如 Kubernetes，的容器化工作负载的标准而开发的。随着容器存储接口的采用，Kubernetes 卷层变得真正可扩展。使用 CSI，第三方存储供应商可以编写和部署插件，在 Kubernetes 中暴露新的存储系统，而无需触及核心 Kubernetes 代码。这为 Kubernetes 用户提供了更多存储选项，使系统更加安全可靠。
新的改变？
随着升级到 GA，Kubernetes 对 CSI 的实施引入了以下变化：
Kubernetes 现在与 CSI spec v1.0 和 v0.3 兼容（而不是 CSI spec v0.2）。
CSI spec v0.3 和 v1.0 之间存在重大变化，但 Kubernetes v1.13 支持这两个版本，因此任何一个版本都适用于 Kubernetes v1.13。
请注意，随着 CSI 1.0 API 的发布，使用 0.3 或更老版本 CSI API 的 CSI 驱动程序被弃用（deprecated），并计划在 Kubernetes v1.15 中删除。
CSI spec v0.2 和 v0.3 之间没有重大变化，因此 v0.2 驱动程序也应该与 Kubernetes v1.10.0+ 一起使用。
CSI 规范 v0.1 和 v0.2 之间存在重大变化，因此在使用 Kubernetes v1.10.0+ 之前，必须将实现非常旧的 CSI 0.1 驱动程序更新为至少 0.2 兼容。
Kubernetes VolumeAttachment 对象（在 v1.9 storage v1alpha1 group 引入，并在 v1.10 中添加到 v1beta1 group）在 v1.13 已添加到的 storage v1 group。
Kubernetes CSIPersistentVolumeSource 卷类型已升级为 GA。
Kubelet 设备插件注册机制，即 kubelet 发现新 CSI 驱动程序的方式，已在 Kubernetes v1.13 中提升为 GA。
如何部署 CSI 驱动程序？
对如何在 Kubernetes 上部署，或管理现有 CSI 驱动程序感兴趣的 Kubernetes 用户，应该查看 CSI 驱动程序作者提供的文档。
如何使用 CSI 卷？
假设 CSI 存储插件已部署在 Kubernetes 集群上，用户可以通过熟悉的 Kubernetes 存储 API 对象使用 CSI 卷：PersistentVolumeClaims，PersistentVolumes 和 StorageClasses。文档在这里。
虽然 Kubernetes 实施 CSI 是 Kubernetes v1.13 中的 GA 功能，但它可能需要以下标志：
API 服务器二进制文件和 kubelet 二进制文件：
–allow-privileged=true
大多数 CSI 插件都需要双向安装传播（bidirectional mount propagation），只能在特权 (privileged)pod 启用。只有在此标志设置为 true 的群集上才允许使用特权 pod，这是某些环境（如 GCE，GKE 和 kubeadm）的默认设置。
动态配置
你可以通过创建指向 CSI 插件的 StorageClass，为支持动态配置（dynamic provisioning）的 CSI Storage 插件启用卷的自动创建 / 删除（creation/deletion）。
例如，以下 StorageClass 通过名为“csi-driver.example.com”的 CSI 卷插件，动态创建“fast-storage”卷。
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: fast-storage
provisioner: csi-driver.example.com
parameters:
type: pd-ssd
csi.storage.k8s.io/provisioner-secret-name: mysecret
csi.storage.k8s.io/provisioner-secret-namespace: mynamespace
GA 的新功能，CSI 的 external-provisioner 外部配置商（v1.0.1+）保留以 csi.storage.k8s.io/ 为前缀的参数键。如果密钥（key）不对应于一组已知密钥，则简单地忽略这些值（并且不将其传递给 CSI 驱动程序）。CSI 外部配置商 v1.0.1 也支持旧的秘密参数密钥（csiProvisionerSecretName，csiProvisionerSecretNamespace 等），但被弃用（deprecated），可能会在 CSI 外部配置商的未来版本中删除。
动态配置由 PersistentVolumeClaim 对象的创建触发。例如，以下 PersistentVolumeClaim 使用上面的 StorageClass 触发动态配置。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-request-for-storage
spec:
accessModes:
– ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: fast-storage
调用卷配置时，参数类型：pd-ssd 和秘密通过 CreateVolume 调用，递给 CSI 插件 csi-driver.example.com。作为响应，外部卷插件提供新卷，然后自动创建 PersistentVolume 对象以表示新卷。然后，Kubernetes 将新的 PersistentVolume 对象绑定到 PersistentVolumeClaim，使其可以使用。
如果快速存储（fast-storage）StorageClass 标记为“default”，则不需要在 PersistentVolumeClaim 中包含 storageClassName，默认情况下将使用它。
预先配置的卷
你可以通过手动创建 PersistentVolume 对象来表示现有卷，从而在 Kubernetes 中暴露预先存在的卷。例如，以下 PersistentVolume 暴露名为“existingVolumeName”的卷，该卷属于名为“csi-driver.example.com”的 CSI 存储插件。
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-manually-created-pv
spec:
capacity:
storage: 5Gi
accessModes:
– ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
csi:
driver: csi-driver.example.com
volumeHandle: existingVolumeName
readOnly: false
fsType: ext4
volumeAttributes:
foo: bar
controllerPublishSecretRef:
name: mysecret1
namespace: mynamespace
nodeStageSecretRef:
name: mysecret2
namespace: mynamespace
nodePublishSecretRef
name: mysecret3
namespace: mynamespace
连接（Attaching）和安装（Mounting）
你可以在任何 pod 或 pod 模板中引用绑定到 CSI 卷的 PersistentVolumeClaim。
kind: Pod
apiVersion: v1
metadata:
name: my-pod
spec:
containers:
– name: my-frontend
image: nginx
volumeMounts:
– mountPath: “/var/www/html”
name: my-csi-volume
volumes:
– name: my-csi-volume
persistentVolumeClaim:
claimName: my-request-for-storage
当引用 CSI 卷的 pod 被调度时，Kubernetes 将针对外部 CSI 插件（ControllerPublishVolume、NodeStageVolume、NodePublishVolume 等）触发相应的操作，以确保指定的卷被连接（attached）和安装（mounted），并准备好给 pod 里的容器使用。
有关详细信息，请参阅 CSI 实施设计文档和文档。
如何编写 CSI 驱动程序？
kubernetes-csi 网站详细介绍了如何在 Kubernetes 上开发、部署和测试 CSI 驱动程序。一般而言，CSI 驱动程序应与 Kubernetes 一起部署以下侧车 / 辅助（sidercar/helper）容器：
external-attacher
观察 Kubernetes VolumeAttachment 对象，并触发针对 CSI 端点的 ControllerPublish 和 ControllerUnpublish 操作。
external-provisioner
观察 Kubernetes PersistentVolumeClaim 对象，并触发针对 CSI 端点的 CreateVolume 和 DeleteVolume 操作。
node-driver-registrar
通过 Kubelet 设备插件机制，使用 kubelet 注册 CSI 驱动程序。
cluster-driver-registrar (Alpha)
通过创建 CSIDriver 对象，向 Kubernetes 集群注册 CSI 驱动程序，该对象使驱动程序能够自定义 Kubernetes 与其交互的方式。
external-snapshotter (Alpha)
观察 Kubernetes VolumeSnapshot CRD 对象，并触发针对 CSI 端点的 CreateSnapshot 和 DeleteSnapshot 操作。
livenessprobe
可以包含在 CSI 插件 pod 中，以启用 Kubernetes Liveness Probe 机制。
存储供应商可以使用这些组件为其插件构建 Kubernetes 部署，而他们的 CSI 驱动程序完全不需知道 Kubernetes。
CSI 驱动程序列表
CSI 驱动程序由第三方开发和维护。你可以在此处找到 CSI 驱动程序的列表。
树内（in-tree）卷插件怎么样？
有计划将大多数持久的远程树内卷插件迁移到 CSI。有关详细信息，请参阅设计文档。
GA 的限制
CSI 的 GA 实施具有以下限制：
短暂（Ephemeral）的本地卷必须创建 PVC（不支持 pod 内联引用 CSI 卷）。
下一步？
致力于移动 Kubernetes CSI 的 alpha 功能到 beta：
Raw block volumes
拓扑感知。Kubernetes 理解和影响 CSI 卷的配置位置（zone 可用区，region 地域等）的能力。
取决于 CSI CRD 的功能（例如“跳过附加”和“挂载时的 Pod 信息”）。
卷快照
努力完成对本地短暂卷的支持。
将远程持久性树内卷插件迁移到 CSI。
怎样参与？
Slack 频道 wg-csi 和谷歌讨论区 kubernetes-sig-storage-wg-csi，以及任何标准的 SIG 存储通信渠道都是接触 SIG 存储团队的绝佳媒介。
像 Kubernetes 一样，这个项目是许多来自不同背景的贡献者共同努力的结果。我们非常感谢本季度主动帮助项目达成 GA 的新贡献者：
Saad Ali (saad-ali)
Michelle Au (msau42)
Serguei Bezverkhi (sbezverk)
Masaki Kimura (mkimuram)
Patrick Ohly (pohly)
Luis Pabón (lpabon)
Jan Šafránek (jsafrane)
Vladimir Vivien (vladimirvivien)
Cheng Xing (verult)
Xing Yang (xing-yang)
David Zhu (davidz627)
如果你有兴趣参与 CSI 或 Kubernetes 存储系统的任何部分的设计和开发，请加入 Kubernetes 存储特别兴趣小组（SIG）。我们正在快速成长，一直欢迎新的贡献者。
2019 年 KubeCon + CloudNativeCon 中国论坛提案征集（CFP）现已开放
KubeCon + CloudNativeCon 论坛让用户、开发人员、从业人员汇聚一堂，面对面进行交流合作。与会人员有 Kubernetes、Prometheus 及其他云原生计算基金会 (CNCF) 主办项目的领导，和我们一同探讨云原生生态系统发展方向。
2019 年中国开源峰会提案征集（CFP）现已开放
在中国开源峰会上，与会者将共同合作及共享信息，了解最新和最有趣的开源技术，包括 Linux、容器、云技术、网络、微服务等；并获得如何在开源社区中导向和引领的信息。
大会日期：
提案征集截止日期：太平洋标准时间 2 月 15 日，星期五，晚上 11:59
提案征集通知日期：2019 年 4 月 1 日
会议日程通告日期：2019 年 4 月 3 日
幻灯片提交截止日期：6 月 17 日，星期一
会议活动举办日期：2019 年 6 月 24 至 26 日
2019 年 KubeCon + CloudNativeCon + Open Source Summit China 赞助方案出炉啦
