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？

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