此文档中的信息可能已过时
此文档的更新日期比原文晚，因此其中的信息可能已过时。如果能阅读英文，请查看英文版本以获取最新信息： Node-specific Volume Limits
此页面描述了各个云供应商可挂接至一个节点的最大卷数。
谷歌、亚马逊和微软等云供应商通常对可以挂接到节点的卷数量进行限制。 Kubernetes 需要尊重这些限制。否则，在节点上调度的 Pod 可能会卡住去等待卷的挂接。
Kubernetes 调度器对挂接到一个节点的卷数有默认限制：
| 云服务 | 每节点最大卷数 |
|---|---|
| Amazon Elastic Block Store (EBS) | 39 |
| Google Persistent Disk | 16 |
| Microsoft Azure Disk Storage | 16 |
以下卷类型支持动态卷限制。
对于由树内插件管理的卷，Kubernetes 会自动确定节点类型并确保节点上可挂接的卷数目合规。例如：
对于 M5、C5、R5、T3 和 Z1D 实例类型的 Amazon EBS 磁盘，Kubernetes 仅允许 25 个卷挂接到节点。 对于 Amazon Elastic Compute Cloud (EC2) 上的其他实例类型，Kubernetes 允许 39 个卷挂接至节点。
在 Azure 环境中，根据节点类型，最多 64 个磁盘可以挂接至一个节点。 更多详细信息，请参阅 Azure 虚拟机的数量大小。
如果 CSI 存储驱动（使用 NodeGetInfo）为节点通告卷数上限，则
kube-scheduler
将遵守该限制值。参考
CSI 规范获取更多详细信息。
对于由已迁移到 CSI 驱动的树内插件管理的卷，最大卷数将是 CSI 驱动报告的卷数。
This is a stable feature in
CSI 驱动可以在运行时动态调整可以挂载到 Node 的最大卷数量。 这提高了调度准确性，并减少了由于资源可用性变化导致的 Pod 调度失败。
要使用此特性，你必须在以下组件上启用 MutableCSINodeAllocatableCount
特性门控：
kube-apiserverkubelet当启用时，CSI 驱动可以通过在 CSIDriver 规约中设置
nodeAllocatableUpdatePeriodSeconds 字段来请求定期更新其卷限制。
例如：
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
name: hostpath.csi.k8s.io
spec:
nodeAllocatableUpdatePeriodSeconds: 60
kubelet 将使用 nodeAllocatableUpdatePeriodSeconds
中指定的时间间隔，定期调用相应的 CSI 驱动的 NodeGetInfo
端点来刷新可挂接卷的最大数量。此字段允许的最小值为 10 秒。
如果卷挂载操作失败并返回 ResourceExhausted 错误（gRPC 代码 8），
Kubernetes 会立即触发对此节点可分配卷数量的更新。此外，kubelet
会将受影响的 Pod 标记为 Failed，从而使它们的控制器处理重新创建。
这防止了 Pod 无限期地停留在 ContainerCreating 状态。
如果启用了 VolumeLimitScaling
特性门控，
并且已安装了相应的 CSIDriver 对象，且 spec.preventPodSchedulingIfMissing
设置为 true，则调度器将阻止将 Pod 放置到尚未安装 CSI 驱动程序的节点上。
例如：
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
name: hostpath.csi.k8s.io
spec:
preventPodSchedulingIfMissing: true
此限制仅适用于需要相应 CSI 卷的 Pod。
如果在 cluster-autoscaler 中启用了 --enable-csi-node-aware-scheduling 选项，
则 cluster-autoscaler 可以准确地计算满足需要 CSI 卷的待处理 Pod 所需的节点数。
如果你在 Kubernetes 集群中使用 cluster-autoscaler，
我们不建议通过 PreventPodSchedulingIfMissing 字段阻止 Pod 部署，
除非 cluster-autoscaler 同时启用了 --enable-csi-node-aware-scheduling
命令行选项。此限制的根本原因是，在 VolumeLimitScaling 特性仍处于
Alpha 测试阶段时，阻止 Pod 部署可能会破坏 cluster-autoscaler 运行的调度模拟，
尤其是在 cluster-autoscaler 尚未感知 CSI 卷限制的情况下。
我们预计，一旦 cluster-autoscaler 默认启用 --enable-csi-node-aware-scheduling，
此限制将不复存在。
无论 Kubernetes 中的 VolumeLimitScaling 特性状态如何，
都可以在 cluster-autoscaler 中启用命令行参数
--enable-csi-node-aware-scheduling。
如果你的集群使用 CSI 卷，并且遇到通过 cluster-autoscaler
启动新节点时，节点上 Pod 过多导致资源占用过高的问题，我们建议启用此特性，
因为当前版本的 cluster-autoscaler 无法正确计算满足所有待处理 Pod
所需的节点数量。