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