存储容量
存储容量有限,并且可能会因运行 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。