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

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

我们已解决的问题

正如在之前关于此功能的博客文章中更详细地解释的那样，存储容量跟踪允许 CSI 驱动程序发布关于剩余容量的信息。然后，当 Pod 具有仍需要配置的卷时，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！

• ←上一篇
下一篇→