本页介绍了对于各种云提供商，可以挂载到节点上的最大卷数量。
像 Google、Amazon 和 Microsoft 这样的云提供商通常对可以挂载到节点上的卷数量有限制。Kubernetes 必须遵守这些限制，这一点非常重要。否则，调度到节点上的 Pod 可能会卡在等待卷挂载的过程中。
Kubernetes 调度器对可以挂载到节点上的卷数量有默认限制
| 云服务 | 每个节点的最大卷数 |
|---|---|
| Amazon Elastic Block Store (EBS) | 39 |
| Google Persistent Disk | 16 |
| Microsoft Azure Disk Storage | 16 |
Kubernetes v1.17 [稳定]动态卷限制支持以下卷类型。
对于由内嵌卷插件管理的卷，Kubernetes 会自动确定节点类型并强制执行该节点适用的最大卷数量。例如：
在 Google Compute Engine 上，根据节点类型，最多可以挂载 127 个卷到节点上，具体取决于节点类型。
对于 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 驱动程序报告的数量。
Kubernetes v1.36 [稳定] (默认启用)CSI 驱动程序可以在运行时动态调整可挂载到节点上的最大卷数量。这提高了调度准确性，并减少了由于资源可用性变化导致的 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 状态。
Kubernetes v1.35 [Alpha] (默认禁用)如果启用了 VolumeLimitScaling 特性门控，并且安装了相应的 CSI 驱动程序（对应的 CSIDriver 对象中设置了 spec.preventPodSchedulingIfMissing 为 true），则调度器将阻止 Pod 放置到尚未安装 CSI 驱动程序的节点上。例如：
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
name: hostpath.csi.k8s.io
spec:
preventPodSchedulingIfMissing: true
此限制仅适用于需要相应 CSI 卷的 Pod。
如果集群自动扩缩器中启用了 --enable-csi-node-aware-scheduling 选项，则集群自动扩缩器可以准确计算满足需要 CSI 卷的待处理 Pod 所需的节点数量。
如果您在 Kubernetes 集群中使用集群自动扩缩器，除非集群自动扩缩器也启用了 --enable-csi-node-aware-scheduling 命令行选项，否则我们不建议通过 PreventPodSchedulingIfMissing 字段阻止 Pod 放置。在 VolumeLimitScaling 特性处于 alpha 阶段时，此限制的根本原因是：如果集群自动扩缩器尚未意识到 CSI 卷限制，阻止 Pod 放置可能会破坏集群自动扩缩器运行的调度模拟。我们预计一旦 --enable-csi-node-aware-scheduling 在集群自动扩缩器中默认启用，这一限制就会消失。
无论 Kubernetes 中的 VolumeLimitScaling 特性状态如何，都可以启用集群自动扩缩器中的命令行选项 --enable-csi-node-aware-scheduling。如果您的集群正在使用 CSI 卷，并且在通过集群自动扩缩器启动新节点时遇到 Pod 过多挤占节点的问题，我们建议启用它，因为当前版本的集群自动扩缩器无法计算满足所有待处理 Pod 所需的正确节点数量。