这篇文章已超过一年。较旧的文章可能包含过时内容。请检查页面信息自发布以来是否已不再准确。
用于 StatefulSets 的最短就绪秒数
本文介绍了 StatefulSet
工作负载的可用性概念,以及 Kubernetes 1.22 中一个新增的 Alpha 特性,该特性为 StatefulSet
添加了 minReadySeconds
配置。
这解决了什么问题?
在 Kubernetes 1.22 发布之前,一旦 StatefulSet
的 Pod
进入 Ready
状态,就被认为是 Available
并可以接收流量。对于某些 StatefulSet
工作负载来说,情况可能并非如此。例如,像 Prometheus 这样的工作负载,包含 Alertmanager 的多个实例,只有当 Alertmanager 的状态转移完成时,它才应该被视为 Available
,而不是当 Pod
处于 Ready
状态时。由于 minReadySeconds
增加了缓冲时间,状态转移可能会在 Pod
变为 Available
之前完成。虽然这并不是一种万无一失的方法来判断状态转移是否完成,但它为最终用户提供了一种方式,表达他们希望在 Pod
被视为 Available
并准备好服务请求之前等待一段时间的意图。
另一个 minReadySeconds
有帮助的场景是与云提供商一起使用 LoadBalancer
Services
时。由于 minReadySeconds
在 Pod
进入 Ready
状态后增加了延迟,它提供了缓冲时间,以防止在新的 Pod 出现之前轮换终止 Pod。想象一下,负载均衡器在非正常路径下需要 10-15 秒才能传播更新。如果你有两个副本,你会在第一个副本启动后才终止第二个副本,但实际上,第一个副本因为还没有准备好服务请求而无法被负载均衡器看到。
因此,总的来说,StatefulSet
中的 Availability
概念非常有用,此特性有助于解决上述问题。这是一个已存在于 Deployments
和 DaemonSets
中的特性,现在 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-apiserver
和kube-controller-manager
上使用命令行参数--feature-gates=StatefulSetMinReadySeconds=true
开启功能门
成功启动 kube-apiserver
和 kube-controller-manager
后,你将在 status 中看到 AvailableReplicas
,并在 spec 中看到 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 邮件列表联系:kubernetes-sig-apps@googlegroups.com