存储容量
存储容量是有限的，并且可能因 Pod 运行的节点而异：网络附加存储可能无法被所有节点访问，或者存储一开始就本地于某个节点。
Kubernetes v1.24 [stable]本页面描述了 Kubernetes 如何跟踪存储容量以及调度器如何使用这些信息将Pod 调度到具有足够存储容量的节点上，以满足剩余缺失卷的需求。如果没有存储容量跟踪，调度器可能会选择一个没有足够容量来供应卷的节点，这将需要多次调度重试。
准备工作
Kubernetes v1.34 包含对存储容量跟踪的集群级 API 支持。要使用此功能，你还必须使用支持容量跟踪的 CSI 驱动。请查阅你使用的 CSI 驱动的文档，以了解此支持是否可用，以及如果可用，如何使用它。如果你未运行 Kubernetes v1.34，请查阅该版本 Kubernetes 的文档。
API
此功能有两个 API 扩展
- CSIStorageCapacity 对象：这些对象由 CSI 驱动在驱动安装的命名空间中生成。每个对象包含一个存储类的容量信息，并定义哪些节点可以访问该存储。
CSIDriverSpec.StorageCapacity字段：当设置为true时，Kubernetes 调度器将考虑使用 CSI 驱动的卷的存储容量。
调度
如果以下条件成立，Kubernetes 调度器将使用存储容量信息
- Pod 使用尚未创建的卷，
- 该卷使用引用 CSI 驱动并使用
WaitForFirstConsumer卷绑定模式的StorageClass，并且 - 驱动的
CSIDriver对象将StorageCapacity设置为 true。
在这种情况下，调度器只考虑为 Pod 提供的具有足够可用存储的节点。此检查非常简单，只将卷的大小与包含该节点的拓扑的 CSIStorageCapacity 对象中列出的容量进行比较。
对于采用 Immediate 卷绑定模式的卷，存储驱动器独立于将使用该卷的 Pod 决定在何处创建卷。然后，调度器在卷创建后将 Pod 调度到卷可用的节点上。
对于CSI 临时卷，调度始终不考虑存储容量。这是基于以下假设：这种卷类型仅由节点本地的特殊 CSI 驱动使用，并且不需要那里的大量资源。
重新调度
当为具有 WaitForFirstConsumer 卷的 Pod 选择了节点时，该决定仍然是暂定的。下一步是请求 CSI 存储驱动器创建卷，并提示该卷应在选定的节点上可用。
由于 Kubernetes 可能会根据过时的容量信息选择节点，因此卷可能无法实际创建。然后，节点选择将被重置，Kubernetes 调度器将再次尝试为 Pod 查找节点。
限制
存储容量跟踪增加了调度在第一次尝试时成功的机会，但不能保证这一点，因为调度器必须根据可能过时的信息做出决定。通常，与没有存储容量信息时的调度失败相同的重试机制会处理调度失败。
一种可能导致调度永久失败的情况是 Pod 使用多个卷：一个卷可能已经在拓扑片段中创建，而该片段没有足够的容量用于另一个卷。需要人工干预才能从中恢复，例如通过增加容量或删除已创建的卷。
下一步
- 有关设计的更多信息，请参阅Pod 调度存储容量限制 KEP。