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

StatefulSet 的 Minimum Ready Seconds

作者：Ravi Gudimetla (红帽), Maciej Szulik (红帽) |

这篇博客介绍了 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 并准备好服务请求之前等待一段时间。

另一个 minReadySeconds 有帮助的场景是与云提供商一起使用 LoadBalancer Services 时。由于 minReadySeconds 在 Pod 准备就绪后增加了延迟，它提供了缓冲时间，以防止在新 Pod 出现之前杀死轮换中的 Pod。想象一下负载均衡器在非正常情况下需要 10-15 秒才能传播。如果你有两个副本，那么你只会在第一个副本启动后才杀死第二个副本，但实际上，第一个副本无法被看到，因为它尚未准备好服务请求。

因此，总的来说，StatefulSet 中的 可用性 概念非常有用，此功能有助于解决上述问题。这是 Deployments 和 DaemonSets 已有的功能，现在 StatefulSet 也拥有此功能，以提供用户一致的工作负载体验。

它是如何工作的？

StatefulSet 控制器会同时监视 StatefulSet 和与之关联的 Pod。当与此功能关联的功能门启用时，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，并在 spec 中看到 minReadySeconds（默认值为 0）。

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

我如何了解更多信息？

我如何参与？

请通过 Slack 上的 #sig-apps 频道与我们联系（如果需要邀请，请访问 https://slack.k8s.io/），或通过 SIG Apps 邮件列表联系：kubernetes-sig-apps@googlegroups.com