Kubernetes的容器存储接口（CSI）GA了

摘要：作者，高级软件工程师实施的容器存储接口已在版本中升级为。功能受弃用政策保护。随着容器存储接口的采用，卷层变得真正可扩展。年中国论坛提案征集现已开放论坛让用户开发人员从业人员汇聚一堂，面对面进行交流合作。

作者：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之前，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。

对如何在Kubernetes上部署，或管理现有CSI驱动程序感兴趣的Kubernetes用户，应该查看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

你可以在任何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实施设计文档和文档。

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。有关详细信息，请参阅设计文档。

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赞助方案出炉啦