在 Azure Kubernetes 服务 (AKS) 中使用 Azure 磁盘容器存储接口 (CSI) 驱动程序
Azure 磁盘容器存储接口 (CSI) 驱动程序是符合 CSI 规范的驱动程序,供 Azure Kubernetes 服务 (AKS) 用来管理 Azure 磁盘的生命周期。
CSI 是有关对 Kubernetes 上的容器化工作负载公开任意块和文件存储系统的一个标准。 现在,AKS 可以采用 CSI 来编写、部署和迭代插件,以在 Kubernetes 中公开新的或改进现有的存储系统。 在 AKS 中使用 CSI 驱动程序可以避免改动核心 Kubernetes 代码并等待完成代码发布周期。
要创建支持 CSI 驱动程序的 AKS 群集,请参阅在 AKS 上启用 CSI 驱动程序。 本文介绍了如何使用 Azure 磁盘 CSI 驱动程序版本 1。
注意
Azure 磁盘 CSI 驱动程序 v2(预览版)提高了可伸缩性并降低了 Pod 故障转移延迟。 它使用共享磁盘在多个群集节点上预配附件副本,并与 Pod 调度程序集成以确保在 Pod 故障转移时选择具有附件副本的节点。 Azure 磁盘 CSI 驱动程序 v2(预览版)还提供了微调性能的功能。 如果有兴趣体验预览版,请提交请求:https://aka.ms/DiskCSIv2Preview。 此预览版的提供不含服务级别协议,我们会不时在该预览版中进行中断性变更。 不建议将预览版用于生产工作负载。 有关详细信息,请参阅适用于 Azure 预览版的补充使用条款。
注意
“树中驱动程序”是指包含在核心 Kubernetes 代码中的当前存储驱动程序,而不是新的 CSI 驱动程序(插件)。
Azure 磁盘 CSI 驱动程序功能
除了树中的驱动程序功能外,Azure 磁盘 CSI 驱动程序还支持以下功能:
并发磁盘附加和拆离期间的性能改进
树中驱动程序以串行方式附加或拆离磁盘,而 CSI 驱动程序以批量方式附加或拆离磁盘。 当多个磁盘附加到一个节点时,就会出现显著改进。
注意
根据所使用的 VM SKU,Azure 磁盘 CSI 驱动程序可能具有每节点的卷限制。 例如,对于一些功能强大的 VM(例如,16 个核心),此限制为每个节点 64 个卷。 若要确定每个 VM SKU 的限制,请查看提供的每个 VM SKU 的“最大数据磁盘数”列。 有关提供的 VM SKU 及其相应的详细容量限制的列表,请参阅常规用途虚拟机大小。
使用含 Azure 磁盘的 CSI 永久性卷
永久性卷 (PV) 表示已经过预配的可用于 Kubernetes Pod 的存储块。 PV 可供一个或多个 Pod 使用,并可动态或静态预配。 本文介绍了如何动态创建含 Azure 磁盘的 PV,以供 AKS 群集中的单个 Pod 使用。 有关静态预配,请参阅使用 Azure 磁盘创建静态卷。
有关 Kubernetes 卷的详细信息,请参阅 AKS 中应用程序的存储选项。
使用内置存储类动态创建 Azure 磁盘 PV
存储类用于定义使用永久性卷动态创建存储单位的方式。 有关 Kubernetes 存储类的详细信息,请参阅 Kubernetes 存储类。
在 AKS 上使用 Azure 磁盘 CSI 驱动程序时,还有两个使用 Azure 磁盘 CSI 存储驱动程序的内置 StorageClasses
。 其他这些 CSI 存储类是使用群集连同树中默认的存储类一起创建的。
managed-csi
:使用 Azure Standard SSD 本地冗余存储 (LRS) 创建托管磁盘。managed-csi-premium
:使用 Azure 高级 LRS 创建托管磁盘。
这两个存储类中的回收策略可确保在删除相应 PV 时删除基础 Azure 磁盘。 存储类还会将 PV 配置为可扩展。 只需使用新大小编辑永久性卷声明 (PVC) 即可。
若要使用这些存储类,请创建一个引用并使用这些类的 PVC 和相应 Pod。 PVC 用于基于存储类自动预配存储。 PVC 可以使用一个预先创建的存储类或用户定义的存储类,创建所需 SKU 和大小的 Azure 托管磁盘。 创建 Pod 定义时,将指定 PVC 来请求所需的存储。
通过运行 kubectl apply 命令创建示例 Pod 和相应的 PVC:
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/pvc-azuredisk-csi.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/nginx-pod-azuredisk.yaml
该命令的输出类似于以下示例:
persistentvolumeclaim/pvc-azuredisk created
pod/nginx-azuredisk created
Pod 处于运行状态后,运行以下命令创建名为 test.txt
的新文件。
kubectl exec nginx-azuredisk -- touch /mnt/azuredisk/test.txt
要验证磁盘是否已正确装载,请运行以下命令并验证输出是否出现 test.txt
文件:
kubectl exec nginx-azuredisk -- ls /mnt/azuredisk
lost+found
outfile
test.txt
创建自定义存储类
默认存储类适用于最常见的场景。 在某些情况下,你可能想要使用自己的参数来自定义自己的存储类。 例如,你可能需要更改 volumeBindingMode
类。
你可以使用 volumeBindingMode: Immediate
类,此类可保证创建 PVC 后立即生效。 在节点池受拓扑限制的情况下,例如在使用可用性区域时,绑定或预配 PV 时便不会考虑 Pod 的计划要求。
为处理这种情况,可以使用 volumeBindingMode: WaitForFirstConsumer
,它会延迟 PV 绑定和预配,直至创建使用该 PVC 的 Pod。 这样,PV 将与 Pod 的计划约束指定的可用性区域(或其他拓扑)一致并预配到其中。 默认存储类使用 volumeBindingMode: WaitForFirstConsumer
类。
创建名为 sc-azuredisk-csi-waitforfirstconsumer.yaml
的文件,然后粘贴以下清单。 此存储类与 managed-csi
存储类相同,但它使用不同的 volumeBindingMode
类。
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: azuredisk-csi-waitforfirstconsumer
provisioner: disk.csi.azure.com
parameters:
skuname: StandardSSD_LRS
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
通过运行 kubectl apply 命令创建存储类并指定 sc-azuredisk-csi-waitforfirstconsumer.yaml
文件:
kubectl apply -f sc-azuredisk-csi-waitforfirstconsumer.yaml
该命令的输出类似于以下示例:
storageclass.storage.k8s.io/azuredisk-csi-waitforfirstconsumer created
卷快照
Azure 磁盘 CSI 驱动程序支持创建永久性卷的快照。 通过此功能,此驱动程序可以创建完整快照或增量快照,具体取决于 incremental
参数中设置的值(默认情况下为 true)。
下表提供所有参数的详细信息。
名称 | 含义 | 可用值 | 必需 | 默认值 |
---|---|---|---|---|
resourceGroup | 用于存储快照截图的资源组 | 现有资源组 | 否 | 如果未指定,快照将存储在源 Azure 磁盘所在的资源组中 |
增量 | 拍摄完整快照或增量快照 | true ,false |
否 | true |
标记 | Azure 磁盘标记 | 标记格式:“key1=val1,key2=val2” | 否 | "" |
userAgent | 用于客户使用情况归因的用户代理 | 否 | 生成的用户代理格式为 driverName/driverVersion compiler/version (OS-ARCH) |
|
subscriptionID | 指定将在其中创建 Azure 磁盘的 Azure 订阅 ID | Azure 订阅 ID | 否 | 如果不为空,则必须提供 resourceGroup ,必须将 incremental 设置为 false |
创建卷快照
注意
在继续之前,请确保应用程序不会将数据写入源磁盘。
为演示此功能,我们使用 kubectl apply 命令创建卷快照类:
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/storageclass-azuredisk-snapshot.yaml
该命令的输出类似于以下示例:
volumesnapshotclass.snapshot.storage.k8s.io/csi-azuredisk-vsc created
现在基于我们在本教程开头动态创建的 PVC pvc-azuredisk
创建卷快照。
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/azuredisk-volume-snapshot.yaml
该命令的输出类似于以下示例:
volumesnapshot.snapshot.storage.k8s.io/azuredisk-volume-snapshot created
若要验证是否正确创建了快照,请运行以下命令:
kubectl describe volumesnapshot azuredisk-volume-snapshot
该命令的输出类似于以下示例:
Name: azuredisk-volume-snapshot
Namespace: default
Labels: <none>
Annotations: API Version: snapshot.storage.k8s.io/v1
Kind: VolumeSnapshot
Metadata:
Creation Timestamp: 2020-08-27T05:27:58Z
Finalizers:
snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
Generation: 1
Resource Version: 714582
Self Link: /apis/snapshot.storage.k8s.io/v1/namespaces/default/volumesnapshots/azuredisk-volume-snapshot
UID: dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Spec:
Source:
Persistent Volume Claim Name: pvc-azuredisk
Volume Snapshot Class Name: csi-azuredisk-vsc
Status:
Bound Volume Snapshot Content Name: snapcontent-dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Creation Time: 2020-08-31T05:27:59Z
Ready To Use: true
Restore Size: 10Gi
Events: <none>
基于卷快照创建新的 PVC
可以基于卷快照创建新的 PVC。 使用在上一步中创建的快照,并创建新的 PVC 和要使用它的新 Pod。
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/pvc-azuredisk-snapshot-restored.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/nginx-pod-restored-snapshot.yaml
该命令的输出类似于以下示例:
persistentvolumeclaim/pvc-azuredisk-snapshot-restored created
pod/nginx-restored created
最后,让我们通过运行以下命令检查内容来确保它与之前创建的 PVC 相同:
kubectl exec nginx-restored -- ls /mnt/azuredisk
该命令的输出类似于以下示例:
lost+found
outfile
test.txt
与预期一样,我们仍然可以看到以前创建的 test.txt
文件。
克隆卷
克隆卷表示现有 Kubernetes 卷的副本。 有关在 Kubernetes 中克隆卷的详细信息,请参阅有关卷克隆的概念文档。
Azure 磁盘的 CSI 驱动程序支持卷克隆。 为了进行演示,我们创建之前创建的 azuredisk-pvc
的克隆卷和要使用它的新 Pod。
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/pvc-azuredisk-cloning.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/nginx-pod-restored-cloning.yaml
该命令的输出类似于以下示例:
persistentvolumeclaim/pvc-azuredisk-cloning created
pod/nginx-restored-cloning created
可以通过运行以下命令并确认 test.txt
文件已创建来验证克隆卷的内容:
kubectl exec nginx-restored-cloning -- ls /mnt/azuredisk
该命令的输出类似于以下示例:
lost+found
outfile
test.txt
在不停机的情况下,调整永久性卷的大小
可为 PVC 请求较大的卷。 编辑 PVC 对象,并指定较大的大小。 此项更改会触发为 PV 提供支持的基础卷的扩展。
注意
永远不会创建新的 PV 来满足声明, 而是会调整现有卷的大小。
在 AKS 中,内置的 managed-csi
存储类已经能够支持扩展,因此请使用先前通过此存储类创建的 PVC。 此 PVC 请求了 10 Gi 永久性卷。 通过运行以下命令进行确认:
kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk
该命令的输出类似于以下示例:
Filesystem Size Used Avail Use% Mounted on
/dev/sdc 9.8G 42M 9.8G 1% /mnt/azuredisk
运行以下命令,增加 spec.resources.requests.storage
字段,从而扩展 PVC:
kubectl patch pvc pvc-azuredisk --type merge --patch '{"spec": {"resources": {"requests": {"storage": "15Gi"}}}}'
注意
目前不支持收缩永久性卷。 尝试修补大小小于当前大小的现有 PVC 会导致以下错误消息:The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.
该命令的输出类似于以下示例:
persistentvolumeclaim/pvc-azuredisk patched
运行以下命令以确认卷大小已增加:
kubectl get pv
该命令的输出类似于以下示例:
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-391ea1a6-0191-4022-b915-c8dc4216174a 15Gi RWO Delete Bound default/pvc-azuredisk managed-csi 2d2h
(...)
几分钟后,运行以下命令以确认 PVC 的大小:
kubectl get pvc pvc-azuredisk
该命令的输出类似于以下示例:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-azuredisk Bound pvc-391ea1a6-0191-4022-b915-c8dc4216174a 15Gi RWO managed-csi 2d2h
执行以下命令确认 Pod 内部磁盘的大小:
kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk
该命令的输出类似于以下示例:
Filesystem Size Used Avail Use% Mounted on
/dev/sdc 15G 46M 15G 1% /mnt/azuredisk
按需突发
通过按需磁盘突发模式,磁盘可以在其需求超出其当前容量时突发。 只要磁盘出现突发时,此模型就会产生额外的费用。 按需突发仅适用于大于 512 GiB 的高级 SSD。 有关高级 SSD 预配的 IOPS 和每个磁盘的吞吐量的详细信息,请参阅高级 SSD 大小。 或者,基于额度的突发:仅在磁盘的额度桶中积满突发额度时,磁盘才会突发。 磁盘突发时,基于额度的突发不会产生额外的费用。 基于额度的突发仅适用于高级 SSD 512 GiB 以及更小的磁盘和标准 SSD 1024 GiB 以及更小的磁盘。 有关按需突发的详细信息,请参阅按需突发。
重要
默认 managed-csi-premium
存储类已禁用按需突发,并使用基于额度的突发。 基于默认 managed-csi-premium
存储类的永久性卷声明动态创建的任何高级 SSD 也禁用按需突发。
若要创建启用了按需突发的高级 SSD 永久性卷,可以创建新存储类,并将 enableBursting 参数设置为 true
,如以下 YAML 模板所示。 有关启用按需突发的详细信息,请参阅按需突发。 有关生成自己的已启用按需突发的存储类的详细信息,请参阅创建可突发托管 CSI 高级存储类。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: burstable-managed-csi-premium
provisioner: disk.csi.azure.com
parameters:
skuname: Premium_LRS
enableBursting: "true"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
Windows 容器
Azure 磁盘 CSI 驱动程序支持 Windows 节点和容器。 如果要使用 Windows 容器,请遵循 Windows 容器快速入门教程添加 Windows 节点池。
具有 Windows 节点池后,现在可以使用内置的存储类,如 managed-csi
。 可以通过运行以下 kubectl apply 命令部署基于 Windows 的 StatefulSet 示例,该示例将时间戳保存到文件 data.txt
中:
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/windows/statefulset.yaml
该命令的输出类似于以下示例:
statefulset.apps/busybox-azuredisk created
要验证卷的内容,请运行以下命令:
kubectl exec -it busybox-azuredisk-0 -- cat c:\\mnt\\azuredisk\\data.txt # on Linux/MacOS Bash
kubectl exec -it busybox-azuredisk-0 -- cat c:\mnt\azuredisk\data.txt # on Windows Powershell/CMD
该命令的输出类似于以下示例:
2020-08-27 08:13:41Z
2020-08-27 08:13:42Z
2020-08-27 08:13:44Z
(...)
后续步骤
- 要了解如何将 CSI 驱动程序用于 Azure 文件,请参阅结合使用 Azure 文件与 CSI 驱动程序。
- 若要了解如何将 CSI 驱动程序用于 Azure Blob 存储,请参阅将 Azure Blob 存储与 CSI 驱动程序配合使用。
- 有关存储最佳做法的详细信息,请参阅有关 Azure Kubernetes 服务中存储和备份的最佳做法。
- 有关基于磁盘的存储解决方案的详细信息,请参阅 AKS 中基于磁盘的解决方案。