存储容量
存储容量是有限的,并且可能因 Pod 运行所在的节点而异:网络附加存储可能并非所有节点都可访问,或者存储一开始就位于本地节点。
Kubernetes v1.24 [stable]
本页介绍了 Kubernetes 如何跟踪存储容量,以及调度器如何使用该信息将 Pod 调度到有足够存储容量来满足剩余缺失卷的节点上。 如果没有存储容量跟踪,调度器可能会选择没有足够容量来配置卷的节点,并且需要多次调度重试。
开始之前
Kubernetes v1.32 包含对存储容量跟踪的集群级 API 支持。 要使用此功能,你还必须使用支持容量跟踪的 CSI 驱动程序。 请查阅你使用的 CSI 驱动程序的文档,以了解此支持是否可用,如果可用,如何使用。 如果你没有运行 Kubernetes v1.32,请查看该版本的 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。