Kubernetes GA的容器存储接口(CSI)

  Kubernetes 徽标  CSI徽标

作者: Google高级软件工程师Saad Ali

Kubernetes 的实现 集装箱存放接口 (CSI)已在Kubernetes v1.13版本中提升为GA。对CSI的支持为 作为Alpha引入 在Kubernetes v1.9版本中,以及 晋升为Beta 在Kubernetes v1.10版本中。

GA里程碑表明,Kubernetes用户可以依赖该功能及其API,而不必担心将来会出现向后不兼容的更改,从而导致回归。 GA功能受 Kubernetes 弃用政策.

为什么选择CSI?

尽管在CSI之前Kubernetes提供了功能强大的卷插件系统,但要在Kubernetes中添加对新的卷插件的支持却具有挑战性:卷插件是“树中的”,这意味着它们的代码是Kubernetes核心代码的一部分,并随核心Kubernetes二进制文件一起提供。 —希望向Kubernetes添加对其存储系统的支持(甚至修复现有的批量插件中的错误)的供应商被迫与Kubernetes的发布过程保持一致。此外,第三方存储代码在核心Kubernetes二进制文件中引起可靠性和安全性问题,并且该代码对于Kubernetes维护人员来说通常很难(在某些情况下是不可能)进行测试和维护。

CSI被开发为将任意块和文件存储存储系统暴露给诸如Kubernetes之类的容器编排系统(CO)上的容器化工作负载的标准。随着容器存储接口的采用,Kubernetes卷层变得真正可扩展。使用CSI,第三方存储提供商可以编写和部署在Kubernetes中公开新存储系统的插件,而无需接触核心的Kubernetes代码。这为Kubernetes用户提供了更多的存储选项,并使系统更加安全可靠。

什么是新的?

随着向GA的推广,CSI的Kubernetes实现引入了以下更改:

  • Kubernetes 现在与CSI规范兼容 v1.0v0.3 (而不是CSI规范 v0.2 )。
    • CSI规范v0.3.0和v1.0.0之间发生了重大变化,但是Kubernetes v1.13支持两个版本,因此任何一个版本都可以与Kubernetes v1.13一起使用。
    • 请注意,随着CSI 1.0 API的发布,不支持使用0.3和更早版本的CSI API的CSI驱动程序,并且计划在Kubernetes v1.15中删除该支持。
    • CSI规范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 object (introduced in v1.9 in the storage v1alpha1 group, 和 added to the v1beta1 group in v1.10) has been added to the storage v1 group in v1.13.
  • 的 Kubernetes CSIPersistentVolumeSource volume type has been promoted to GA.
  • Kubelet设备插件注册机制在Kubernetes v1.13中,kubelet发现新CSI驱动程序的方法已被提升为GA。

如何部署CSI驱动程序?

对如何在Kubernetes上部署或管理现有CSI驱动程序感兴趣的Kubernetes用户,请查看CSI驱动程序作者提供的文档。

如何使用CSI卷?

Assuming a CSI storage plugin is already deployed on a Kubernetes cluster, users can use CSI volumes through the familiar Kubernetes storage API objects: PersistentVolumeClaims, PersistentVolumes, 和 StorageClasses. Documented 这里 .

尽管CSI的Kubernetes实现是Kubernetes v1.13中的GA功能,但它可能需要以下标志:

  • API服务器二进制文件和kubelet二进制文件:
    • --allow-privileged=true
      • 大多数CSI插件都需要双向挂载传播,只能针对特权Pod启用它。特权Pod仅允许在已将此标志设置为true的群集上使用(在某些环境下,例如GCE,GKE和kubeadm,这是默认设置)。

动态预配

You can enable automatic creation/deletion of volumes for CSI Storage plugins that support dynamic provisioning by creating a StorageClass pointing to the CSI plugin.

的 following StorageClass, for example, enables dynamic creation of “fast-storage” volumes by a CSI volume plugin called “csi-driver.example.com”.

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外部供应商 (v1.0.1+) reserves the parameter keys prefixed with csi.storage.k8s.io/. If the keys do not correspond to a set of known keys the values are simply ignored (and not passed to the CSI driver). 的 older secret parameter keys (csiProvisionerSecretName, csiProvisionerSecretNamespace, etc.) are also supported by CSI外部供应商 v1.0.1 but are deprecated 和 may be removed in future releases of the CSI外部供应商.

Dynamic provisioning is triggered by the creation of a PersistentVolumeClaim object. 的 following PersistentVolumeClaim, for example, triggers dynamic provisioning using the StorageClass above.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-request-for-storage
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: fast-storage

When volume provisioning is invoked, the parameter type: pd-ssd 和 the secret any referenced secret(s) are passed to the CSI plugin csi-driver.example.com via a CreateVolume call. In response, the external volume plugin provisions a new volume 和 then automatically create a PersistentVolume object to represent the new volume. Kubernetes then binds the new PersistentVolume object to the PersistentVolumeClaim, making it ready to use.

If the fast-storage StorageClass is marked as “default”, there is no need to include the storageClassName in the PersistentVolumeClaim, it will be used by default.

预先配置的卷

You can always expose a pre-existing volume in Kubernetes by manually creating a PersistentVolume object to represent the existing volume. 的 following PersistentVolume, for example, exposes a volume with the name “existingVolumeName” belonging to a CSI storage plugin called “csi-driver.example.com”.

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

固定和安装

You can reference a PersistentVolumeClaim that is bound to a CSI volume in any pod or pod template.

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

When the pod referencing a CSI volume is scheduled, Kubernetes will trigger the appropriate operations against the external CSI plugin (ControllerPublishVolume, NodeStageVolume, NodePublishVolume, etc.) to ensure the specified volume is attached, mounted, 和 ready to use by the containers in the pod.

有关更多详细信息,请参阅CSI实现。 设计文件 文件资料 .

如何编写CSI驱动程序?

kubernetes-csi 该站点详细介绍了如何在Kubernetes上开发,部署和测试CSI驱动程序。通常,CSI驱动程序应与以下Sidecar(辅助)容器一起部署在Kubernetes上:

  • 外部附件
    • Watches Kubernetes VolumeAttachment objects 和 triggers ControllerPublishControllerUnpublish operations against a CSI endpoint.
  • 外部供应商
    • Watches Kubernetes PersistentVolumeClaim objects 和 triggers CreateVolumeDeleteVolume operations against a CSI endpoint.
  • 节点驱动程序注册器
  • 集群驱动程序注册器 (Α)
    • Registers a CSI Driver with the Kubernetes cluster by creating a CSIDriver object which enables the driver to customize how Kubernetes interacts with it.
  • 外部快照者 (Α)
    • Watches Kubernetes VolumeSnapshot CRD objects 和 triggers CreateSnapshotDeleteSnapshot operations against a CSI endpoint.
  • 活力探针

存储供应商可以使用这些组件为其插件构建Kubernetes部署,同时使CSI驱动程序完全不了解Kubernetes。

CSI驱动程序列表

CSI驱动程序由第三方开发和维护。您可以找到CSI驱动程序的非确定列表 这里 .

树内音量插件呢?

有计划将大多数持久性远程树内卷插件迁移到CSI。有关更多详细信息,请参见 设计文件 .

GA的局限性

CSI的GA实现具有以下限制:

  • 临时本地卷必须创建PVC(不支持CSI卷的Pod内联引用)。

下一步是什么?

  • 致力于将仍处于Alpha到Beta的Kubernetes CSI功能进行移动:
    • 原始块体积
    • 拓扑意识(Ku​​bernetes能够理解和影响CSI卷的配置位置(区域,区域等)的能力。
    • 取决于CSI CRD的功能(例如“跳过附加”和“挂载Pod信息”)。
    • 卷快照
  • 努力完成对本地临时卷的支持。
  • 致力于将远程持久树内卷插件迁移到CSI。

如何参与?

Kubernetes Slack频道 wg-csi 和Google小组 kubernetes-sig-storage-wg-csi 连同任何标准 SIG存储通讯渠道 是与SIG存储团队联系的绝佳媒介。

与所有Kubernetes一样,该项目是来自不同背景的许多贡献者共同努力的结果。我们非常感谢新的贡献者,他们在本季度加强了工作,以帮助该项目达到通用计划:

如果您有兴趣参与CSI或Kubernetes Storage System的任何部分的设计和开发,请加入 Kubernetes 存储特别兴趣小组 (SIG)。我们正在迅速发展,并随时欢迎新的贡献者。