Kubernetes 1.24：存储容量跟踪功能现已正式发布

Kubernetes v1.24 版本带来了存储容量跟踪功能，并将其作为正式可用 (GA) 特性。

我们已解决的问题

如之前关于此功能的博客文章中更详细地解释的那样，存储容量跟踪允许 CSI 驱动程序发布有关剩余容量的信息。然后 kube-scheduler 使用该信息，在 Pod 包含需要供应的卷时，为其选择合适的节点。

如果没有这些信息，Pod 可能会卡住，永远无法调度到合适的节点上，因为 kube-scheduler 必须盲目选择，最终总是选择一个卷无法供应的节点，原因在于 CSI 驱动程序管理的底层存储系统没有足够的剩余容量。

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

针对晋升到 GA 再次进行的负载测试证实，使用存储容量跟踪时，集群中的所有存储都可以被 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的成员们！

• ←上一页
• 下一页→