本文发表时间已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

StatefulSet 的最小就绪秒数

作者：Ravi Gudimetla (Red Hat), Maciej Szulik (Red Hat) | 2021 年 8 月 27 日，星期五

此博客描述了 StatefulSet 工作负载的可用性概念，以及 Kubernetes 1.22 中新增的 alpha 功能，该功能为 StatefulSet 添加了 minReadySeconds 配置。

这解决了什么问题？

在 Kubernetes 1.22 版本之前，一旦 StatefulSet 的 Pod 处于 Ready 状态，就被认为可以接收流量。对于某些 StatefulSet 工作负载来说，情况可能并非如此。例如，像 Prometheus 这样具有多个 Alertmanager 实例的工作负载，只有在 Alertmanager 的状态传输完成时才应被认为是 Available，而不是在 Pod 处于 Ready 状态时。由于 minReadySeconds 添加了缓冲区，状态传输可能会在 Pod 变为 Available 之前完成。虽然这并非确定状态传输是否完成的万无一失的方法，但它为最终用户提供了一种表达其意图的方式，即在 Pod 被认为是 Available 且准备好服务请求之前等待一段时间。

在云提供商中使用带有 LoadBalancer 的 Services 时，minReadySeconds 也有帮助。由于 minReadySeconds 在 Pod 处于 Ready 状态后增加了延迟，因此它提供了缓冲时间，以防止在新的 Pod 出现之前轮换杀死 Pod。想象一下，一个负载均衡器在异常路径下需要 10-15 秒才能传播。如果您有 2 个副本，那么只有在第一个副本启动后才会杀死第二个副本，但实际上，第一个副本是不可见的，因为它尚未准备好服务请求。

因此，总的来说，StatefulSets 中的 Availability 概念非常有用，此功能有助于解决上述问题。这是一个已经存在于 Deployments 和 DaemonSets 中的功能，现在我们也在 StatefulSets 中提供了该功能，以给用户带来一致的工作负载体验。

它是如何工作的？

statefulSet 控制器会监视 StatefulSets 以及与其关联的 Pods。当与此功能关联的功能门启用时，statefulSet 控制器会识别与 StatefulSet 关联的特定 Pod 处于 Running 状态的时间长度。

如果此值大于或等于最终用户在 .spec.minReadySeconds 字段中指定的时间，则 statefulSet 控制器会更新 StatefulSet 的状态子资源中名为 availableReplicas 的字段，以包含此 Pod。StatefulSet 状态中的 status.availableReplicas 是一个整数字段，用于跟踪 Available 的 Pod 的数量。

我如何使用它？

您需要准备以下事项才能试用此功能

下载并安装大于 v1.22.0 版本的 kubectl
在 kube-apiserver 和 kube-controller-manager 上使用命令行标志 --feature-gates=StatefulSetMinReadySeconds=true 打开功能门

成功启动 kube-apiserver 和 kube-controller-manager 后，您将在状态中看到 AvailableReplicas，并在规范中看到 minReadySeconds（默认值为 0）。

为任何 StatefulSet 指定 minReadySeconds 的值，您可以使用以下命令通过检查 AvailableReplicas 字段来检查 Pods 是否可用： kubectl get statefulset/<statefulset 的名称> -o yaml

如何了解更多？

阅读 KEP：StatefulSets 的 minReadySeconds
阅读文档：StatefulSet 的最低就绪秒数
查看 StatefulSet 的 API 定义

如何参与？

请在 Slack 上的 #sig-apps 频道中联系我们（如果您需要邀请，请访问 https://slack.k8s.io/），或者在 SIG Apps 邮件列表中联系我们： [email protected]

←上一个

下一个→