存储容量

存储容量有限，可能因 Pod 运行的节点而异：网络连接存储可能无法被所有节点访问，或者存储一开始就是节点本地存储。

此页面描述了 Kubernetes 如何跟踪存储容量以及调度器如何使用该信息将 调度 Pod 到拥有足够存储容量以容纳剩余缺失卷的节点。如果没有存储容量跟踪，调度器可能会选择一个没有足够容量来配置卷的节点，需要进行多次调度重试。

在开始之前

Kubernetes v1.31 包含用于存储容量跟踪的集群级 API 支持。要使用此功能，您还必须使用支持容量跟踪的 CSI 驱动程序。请参阅您使用的 CSI 驱动程序的文档，了解其是否支持此功能，以及如何使用它。如果您没有运行 Kubernetes v1.31，请查看该版本 Kubernetes 的文档。

API

此功能有两个 API 扩展

• CSIStorageCapacity 对象：这些对象由 CSI 驱动程序在驱动程序安装的命名空间中生成。每个对象包含一个存储类的容量信息，并定义哪些节点可以访问该存储。
• CSIDriverSpec.StorageCapacity 字段：设置为 true 时，Kubernetes 调度器将考虑使用 CSI 驱动程序的卷的存储容量。

调度

如果满足以下条件，则 Kubernetes 调度器将使用存储容量信息

• 一个 Pod 使用一个尚未创建的卷，
• 该卷使用一个 StorageClass，该存储类引用了一个 CSI 驱动程序并使用 WaitForFirstConsumer 卷绑定模式，并且
• 驱动程序的 CSIDriver 对象的 StorageCapacity 设置为 true。

在这种情况下，调度器只考虑 Pod 可以使用且拥有足够可用存储空间的节点。此检查非常简单，仅将卷的大小与包含节点的拓扑结构中的 CSIStorageCapacity 对象中列出的容量进行比较。

对于使用 Immediate 卷绑定模式的卷，存储驱动程序将独立于使用该卷的 Pod 决定在何处创建该卷。然后，调度器在卷创建后将 Pod 调度到卷可用的节点。

对于 CSI 短暂卷，调度始终不考虑存储容量。这是基于这样的假设：此卷类型仅供节点本地的特殊 CSI 驱动程序使用，不需要节点上的大量资源。

重新调度

当为使用 WaitForFirstConsumer 卷的 Pod 选择一个节点时，该决定仍然是暂时的。下一步是 CSI 存储驱动程序被要求创建一个卷，并提示该卷应该在选定的节点上可用。

由于 Kubernetes 可能会根据过时的容量信息选择一个节点，因此该卷实际上可能无法创建。然后重置节点选择，Kubernetes 调度器会再次尝试为 Pod 找到一个节点。

局限性

存储容量跟踪增加了调度首次成功的可能性，但不能保证这一点，因为调度器必须根据可能过时的信息做出决定。通常，与没有存储容量信息的调度相同的重试机制用于处理调度失败。

一种情况是调度可能永久失败，即 Pod 使用多个卷时：一个卷可能已经在一个拓扑段中创建，然后该拓扑段没有足够的容量来创建另一个卷。需要手动干预才能从这种情况中恢复，例如增加容量或删除已经创建的卷。

下一步

• 有关设计的更多信息，请参阅 Pod 调度的存储容量约束 KEP。