这篇文章已超过一年。较旧的文章可能包含过时内容。请检查页面信息自发布以来是否已不再准确。

用于 StatefulSets 的最短就绪秒数

本文介绍了 StatefulSet 工作负载的可用性概念,以及 Kubernetes 1.22 中一个新增的 Alpha 特性,该特性为 StatefulSet 添加了 minReadySeconds 配置。

这解决了什么问题?

在 Kubernetes 1.22 发布之前,一旦 StatefulSetPod 进入 Ready 状态,就被认为是 Available 并可以接收流量。对于某些 StatefulSet 工作负载来说,情况可能并非如此。例如,像 Prometheus 这样的工作负载,包含 Alertmanager 的多个实例,只有当 Alertmanager 的状态转移完成时,它才应该被视为 Available,而不是当 Pod 处于 Ready 状态时。由于 minReadySeconds 增加了缓冲时间,状态转移可能会在 Pod 变为 Available 之前完成。虽然这并不是一种万无一失的方法来判断状态转移是否完成,但它为最终用户提供了一种方式,表达他们希望在 Pod 被视为 Available 并准备好服务请求之前等待一段时间的意图。

另一个 minReadySeconds 有帮助的场景是与云提供商一起使用 LoadBalancer Services 时。由于 minReadySecondsPod 进入 Ready 状态后增加了延迟,它提供了缓冲时间,以防止在新的 Pod 出现之前轮换终止 Pod。想象一下,负载均衡器在非正常路径下需要 10-15 秒才能传播更新。如果你有两个副本,你会在第一个副本启动后才终止第二个副本,但实际上,第一个副本因为还没有准备好服务请求而无法被负载均衡器看到。

因此,总的来说,StatefulSet 中的 Availability 概念非常有用,此特性有助于解决上述问题。这是一个已存在于 DeploymentsDaemonSets 中的特性,现在 StatefulSet 也支持了它,以给用户提供一致的工作负载体验。

它是如何工作的?

StatefulSet 控制器会监听 StatefulSets 及其相关的 Pods。当与此特性相关的功能门被启用时,StatefulSet 控制器会识别与 StatefulSet 关联的某个 Pod 处于 Running 状态的时长。

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

如何使用?

要尝试此特性,你需要准备以下事项

  • 下载并安装 v1.22.0 或更高版本的 kubectl
  • kube-apiserverkube-controller-manager 上使用命令行参数 --feature-gates=StatefulSetMinReadySeconds=true 开启功能门

成功启动 kube-apiserverkube-controller-manager 后,你将在 status 中看到 AvailableReplicas,并在 spec 中看到 minReadySeconds(默认值为 0)。

为任意 StatefulSet 指定 minReadySeconds 的值,然后通过检查 AvailableReplicas 字段来判断 Pods 是否可用,使用命令:kubectl get statefulset/<StatefulSet名称> -o yaml

如何了解更多?

如何参与贡献?

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