Kubernetes 1.24 中的存储容量跟踪达到 GA

作者： Patrick Ohly（英特尔）

Kubernetes v1.24 版本将存储容量 跟踪作为一项普遍可用的功能。

我们解决的问题

正如在上一篇关于此功能的博客文章中更详细地解释的那样，存储容量跟踪允许 CSI 驱动程序发布有关剩余容量的信息。然后，当 Pod 具有仍需要配置的卷时，kube-scheduler 使用该信息为 Pod 选择合适的节点。

如果没有这些信息，Pod 可能会在没有被调度到合适的节点的情况下被卡住，因为 kube-scheduler 必须盲目地选择并且总是最终选择一个无法为其配置卷的节点，因为由 CSI 驱动程序管理的底层存储系统确实如此没有足够的容量。

因为 CSI 驱动程序发布的存储容量信息在以后可能不再是最新的时候被使用，所以仍然可能会发生最终选择的节点无法正常工作。卷配置通过通知调度程序它需要使用不同的节点重试来从中恢复。

为升级到 GA 而再次进行的负载测试 证实，集群中的所有存储都可以由具有存储容量跟踪功能的 Pod 使用，而没有它的 Pod 会卡住。

我们尚未解决的问题

从失败的卷配置尝试中恢复有一个已知的限制：如果 Pod 使用两个卷并且只能配置其中一个，那么所有未来的调度决策都会受到已经配置的卷的限制。如果该卷是节点的本地卷，并且无法在那里配置其他卷，则 Pod 会卡住。此问题早于存储容量跟踪，虽然附加信息使其不太可能发生，但在所有情况下都无法避免，当然每个 Pod 仅使用一个卷除外。

在KEP 草案中提出了解决此问题的想法：已配置但尚未使用的卷不能包含任何有价值的数据，因此可以在其他地方释放和再次配置。SIG Storage 正在寻找愿意继续从事此工作的感兴趣的开发人员。

同样没有解决的是集群自动缩放器对具有卷的 Pod 的支持。对于具有存储容量跟踪功能的 CSI 驱动程序，开发了一个原型并在PR中进行了讨论。它旨在与任意 CSI 驱动程序一起使用，但这种灵活性使其难以配置并减慢了扩展操作：因为自动扩展程序无法模拟卷配置，它一次只能将集群扩展一个节点，这被视为不足的。

因此，PR 没有被合并，需要一种不同的方法，在自动缩放器和 CSI 驱动程序之间实现更紧密的耦合。为此，需要更好地了解哪些本地存储 CSI 驱动程序与集群自动缩放结合使用。如果这会导致新的 KEP，那么用户将不得不在实践中尝试实现，然后才能迁移到 beta 或 GA。因此，如果您对此主题感兴趣，请联系 SIG Storage。

致谢

非常感谢为此功能做出贡献或提供反馈的社区成员，包括SIG Scheduling、 SIG Autoscaling，当然还有SIG Storage！

转自 https://kubernetes.io/blog/2022/05/06/storage-capacity-ga/