存储容量
存储容量有限，并且可能因 Pod 运行所在的节点而异：网络附加存储可能无法被所有节点访问，或者存储一开始就仅限于某个节点使用。
Kubernetes v1.24 [stable]本页介绍 Kubernetes 如何跟踪存储容量，以及调度器如何利用这些信息来将 Pod 调度到能够访问足够存储容量以应对剩余待创建卷的节点上。如果没有存储容量跟踪，调度器可能会选择一个没有足够容量来配置卷的节点，这时就需要多次调度重试。
准备工作
Kubernetes v1.33 包含了用于存储容量跟踪的集群级别 API 支持。要使用此功能，你还必须使用支持容量跟踪的 CSI 驱动。请查阅你所使用的 CSI 驱动的文档，了解是否提供此支持以及如何使用它。如果你运行的不是 Kubernetes v1.33，请查阅对应 Kubernetes 版本的文档。
API
此功能有两个 API 扩展
- CSIStorageCapacity 对象：这些对象由 CSI 驱动在其安装的命名空间中创建。每个对象包含一个 StorageClass 的容量信息，并定义了哪些节点可以访问该存储。
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。