Kubernetes实施的容器存储接口(CSI)已在Kubernetes v1.13版本中升级为GA。CSI的支持在Kubernetes v1.9版本中作为alpha引入,并在Kubernetes v1.10版本中升级为beta。
GA里程碑表明Kubernetes用户可能依赖于该功能及其API,而不必担心将来回归(regression)导致的向后不兼容的更改。GA功能受Kubernetes弃用(deprecation)政策保护。
https://github.com/container-storage-interface/spec/blob/master/spec.md
https://kubernetes.io/docs/reference/using-api/deprecation-policy/
为何选择CSI?
虽然在CSI之前,Kubernetes提供了一个功能强大的卷插件系统,但是在Kubernetes添加对新卷插件的支持是一项挑战:卷插件是“树内”(“in-tree”),这意味着他们的代码是核心Kubernetes代码的一部分,并随核心Kubernetes一起提供二进制文件。希望向Kubernetes添加对其存储系统的支持(或修复现有卷插件中的错误)的供应商被迫与Kubernetes发布流程保持一致。此外,第三方存储代码导致核心Kubernetes二进制文件中的可靠性和安全性问题,代码通常很难(在某些情况下不可能)让Kubernetes维护者进行测试和维护。
CSI是作为将任意块和文件存储存储系统暴露于容器编排系统(CO)上,如Kubernetes,的容器化工作负载的标准而开发的。随着容器存储接口的采用,Kubernetes卷层变得真正可扩展。使用CSI,第三方存储供应商可以编写和部署插件,在Kubernetes中暴露新的存储系统,而无需触及核心Kubernetes代码。这为Kubernetes用户提供了更多存储选项,使系统更加安全可靠。
新的改变?
随着升级到GA,Kubernetes对CSI的实施引入了以下变化:
https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-registration
如何部署CSI驱动程序?
对如何在Kubernetes上部署,或管理现有CSI驱动程序感兴趣的Kubernetes用户,应该查看CSI驱动程序作者提供的文档。
如何使用CSI卷?
假设CSI存储插件已部署在Kubernetes集群上,用户可以通过熟悉的Kubernetes存储API对象使用CSI卷:PersistentVolumeClaims,PersistentVolumes和StorageClasses。文档在这里。
https://kubernetes.io/docs/concepts/storage/volumes/#csi
虽然Kubernetes实施CSI是Kubernetes v1.13中的GA功能,但它可能需要以下标志:
动态配置
你可以通过创建指向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外部配置商的未来版本中删除。
https://github.com/kubernetes-csi/external-provisioner
动态配置由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实施设计文档和文档。
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md
https://kubernetes.io/docs/concepts/storage/volumes/#csi
如何编写CSI驱动程序?
kubernetes-csi网站详细介绍了如何在Kubernetes上开发、部署和测试CSI驱动程序。一般而言,CSI驱动程序应与Kubernetes一起部署以下侧车/辅助(sidercar/helper)容器:
https://kubernetes-csi.github.io/
存储供应商可以使用这些组件为其插件构建Kubernetes部署,而他们的CSI驱动程序完全不需知道Kubernetes。
CSI驱动程序列表
CSI驱动程序由第三方开发和维护。你可以在此处找到CSI驱动程序的列表。
https://kubernetes-csi.github.io/docs/Drivers.html
树内(in-tree)卷插件怎么样?
有计划将大多数持久的远程树内卷插件迁移到CSI。有关详细信息,请参阅设计文档。
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/csi-migration.md
GA的限制
CSI的GA实施具有以下限制:
下一步?
怎样参与?
Slack频道wg-csi和谷歌讨论区kubernetes-sig-storage-wg-csi,以及任何标准的SIG存储通信渠道都是接触SIG存储团队的绝佳媒介。
https://kubernetes.slack.com/messages/C8EJ01Z46/details/
https://groups.google.com/forum/#!forum/kubernetes-sig-storage-wg-csi
https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact
像Kubernetes一样,这个项目是许多来自不同背景的贡献者共同努力的结果。我们非常感谢本季度主动帮助项目达成GA的新贡献者:
如果你有兴趣参与CSI或Kubernetes存储系统的任何部分的设计和开发,请加入Kubernetes存储特别兴趣小组(SIG)。我们正在快速成长,一直欢迎新的贡献者。
https://github.com/kubernetes/community/tree/master/sig-storage