本文描述了两个特性,即用于 StatefulSet 的 minReadySeconds
以及用于 DaemonSet 的 maxSurge
, 很高兴宣布这两个特性在 Kubernetes 1.25 进入稳定阶段。
当 .spec.updateStrategy
字段设置为 RollingUpdate
时, 你可以设置 minReadySeconds
, 通过让每个 Pod 等待一段预期时间来减缓 StatefulSet 的滚动上线。
这两个特性也可用于 Deployment 和其他工作负载。此功能的提级有助于将这一功能在所有工作负载上对齐。
minReadySeconds
确保 StatefulSet 工作负载在给定的秒数内处于 Ready
, 然后才会将该 Pod 报告为 Available
。处于 Ready
和 Available
状况的这种说法对工作负载相当重要。例如 Prometheus 这些工作负载有多个 Alertmanager 实例, 只有 Alertmanager 的状态转换完成后才应该被视为 Available
。minReadySeconds
还有助于云驱动确定何时使用负载均衡器。因为 Pod 应在给定的秒数内处于 Ready
,所以这就提供了一段缓冲时间, 防止新 Pod 还没起来之前就杀死了旧 Pod。
CNI、CSI 这类 Kubernetes 系统级别的组件通常以 DaemonSet 方式运行。如果这些 DaemonSet 在升级期间瞬间挂掉, 对应的组件可能会影响工作负载的可用性。此特性允许 DaemonSet Pod 临时增加数量,以此确保 DaemonSet 的停机时间为零。
请注意在 DaemonSet 中不允许同时使用 hostPort
和 maxSurge
, 因为 DaemonSet Pod 被捆绑到了一个节点,所以两个活跃的 Pod 无法共享同一节点上的相同端口。
DaemonSet 控制器根据 .spec.strategy.rollingUpdate.maxSurge
中给出的值创建额外 Pod (超出 DaemonSet 规约所设定的预期数量)。这些 Pod 将运行在旧 DaemonSet Pod 运行所在的同一节点上,直到这个旧 Pod 被杀死为止。
MaxUnavailable
为 0 时此值不能为 0
。执行以下命令为任意 StatefulSet 指定一个 minReadySeconds
值, 通过检验 AvailableReplicas
字段查看这些 Pod 是否可用:
kubectl get statefulset/<StatefulSet 名称> -o yaml
请注意 minReadySeconds
的默认值为 0。
为 .spec.updateStrategy.rollingUpdate.maxSurge
指定一个值并将 .spec.updateStrategy.rollingUpdate.maxUnavailable
设置为 0
。
然后观察下一次滚动上线是不是更快,同时运行的 Pod 数量是不是更多。
kubectl rollout restart daemonset <name_of_the_daemonset>
kubectl get pods -w
作者:Ravi Gudimetla (Apple)、Filip Křepinský (Red Hat)、Maciej Szulik (Red Hat) 出处:https://u.kubeinfo.cn/VHe47Q
- END -