Kubernetes 1.24：存储容量跟踪现已正式可用

Kubernetes v1.24 版本将存储容量跟踪功能作为通用功能正式发布。

我们已解决的问题

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

如果没有这些信息，Pod 可能会因为 kube-scheduler 必须盲目选择并总是选择一个无法供应卷的节点（因为 CSI 驱动程序管理的基础存储系统没有足够的剩余容量）而无法调度到合适的节点上，从而陷入停滞。

由于 CSI 驱动程序发布的存储容量信息在后续使用时可能不是最新的，因此仍可能发生选择了最终不适用的节点的情况。卷供应会通过通知调度器需要尝试使用不同的节点来从这种情况中恢复。

为正式发布而进行的负载测试再次证实，在启用存储容量跟踪的情况下，集群中的所有存储都可以被 Pod 消耗，而没有该功能时 Pod 会卡住。

我们 尚未 解决的问题

从失败的卷供应尝试中恢复有一个已知限制：如果 Pod 使用两个卷，而只有一个卷能够供应，那么所有未来的调度决策都会受到已供应卷的限制。如果该卷是节点本地的，并且另一个卷无法在该节点上供应，则 Pod 将会卡住。这个问题早于存储容量跟踪，虽然附加信息使其发生可能性降低，但并非在所有情况下都能避免，除非每个 Pod 只使用一个卷。

为了解决这个问题，在一份 KEP 草案中提出了一个想法：已供应但尚未使用的卷不包含任何有价值的数据，因此可以释放并在其他地方重新供应。SIG Storage 正在寻找对此感兴趣并愿意继续开发此功能的开发人员。

此外，Cluster Autoscaler 对带卷的 Pod 的支持也尚未解决。对于具有存储容量跟踪功能的 CSI 驱动程序，已在一个 PR 中开发并讨论了一个原型。它旨在与任意 CSI 驱动程序配合使用，但这种灵活性使得配置困难并减慢了扩容操作：由于 autoscaler 无法模拟卷供应，它每次只能扩展一个节点，这被认为是不够的。

因此，该 PR 未被合并，需要采用一种不同的方法，即 autoscaler 和 CSI 驱动程序之间更紧密的耦合。为此，需要更好地了解哪些本地存储 CSI 驱动程序与集群自动扩容结合使用。如果这将导致一个新的 KEP，那么用户将必须在实践中尝试实施，然后才能将其推广到 beta 或 GA。因此，如果您对此主题感兴趣，请联系 SIG Storage。

致谢

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

• ←上一篇
• 下一篇→