本文描述了两个特性，即用于 StatefulSet 的 minReadySeconds 以及用于 DaemonSet 的 maxSurge， 很高兴宣布这两个特性在 Kubernetes 1.25 进入稳定阶段。
当 .spec.updateStrategy 字段设置为 RollingUpdate 时， 你可以设置 minReadySeconds， 通过让每个 Pod 等待一段预期时间来减缓 StatefulSet 的滚动上线。
当 .spec.updateStrategy 字段设置为 RollingUpdate 时， maxSurge 允许 DaemonSet 工作负载在滚动上线期间在一个节点上运行同一 Pod 的多个实例。这对于消费者而言有助于将 DaemonSet 的停机时间降到最低。
这两个特性也可用于 Deployment 和其他工作负载。此功能的提级有助于将这一功能在所有工作负载上对齐。
这两个特性能解决什么问题？
针对 StatefulSet 的 minReadySeconds
minReadySeconds 确保 StatefulSet 工作负载在给定的秒数内处于 Ready， 然后才会将该 Pod 报告为 Available。处于 Ready 和 Available 状况的这种说法对工作负载相当重要。例如 Prometheus 这些工作负载有多个 Alertmanager 实例， 只有 Alertmanager 的状态转换完成后才应该被视为 Available。minReadySeconds 还有助于云驱动确定何时使用负载均衡器。因为 Pod 应在给定的秒数内处于 Ready，所以这就提供了一段缓冲时间， 防止新 Pod 还没起来之前就杀死了旧 Pod。
针对 DaemonSet 的 maxSurge
CNI、CSI 这类 Kubernetes 系统级别的组件通常以 DaemonSet 方式运行。如果这些 DaemonSet 在升级期间瞬间挂掉， 对应的组件可能会影响工作负载的可用性。此特性允许 DaemonSet Pod 临时增加数量，以此确保 DaemonSet 的停机时间为零。
请注意在 DaemonSet 中不允许同时使用 hostPort 和 maxSurge， 因为 DaemonSet Pod 被捆绑到了一个节点，所以两个活跃的 Pod 无法共享同一节点上的相同端口。
工作原理
针对 StatefulSet 的 minReadySeconds
StatefulSet 控制器监视 StatefulSet Pod 并统计特定的 Pod 已处于 Running 状态多长时间了， 如果这个值大于或等于 StatefulSet 的 .spec.minReadySeconds 字段中指定的时间， StatefulSet 控制器将更新 StatefulSet 的状态中的 AvailableReplicas 字段。
针对 DaemonSet 的 maxSurge
DaemonSet 控制器根据 .spec.strategy.rollingUpdate.maxSurge 中给出的值创建额外 Pod （超出 DaemonSet 规约所设定的预期数量）。这些 Pod 将运行在旧 DaemonSet Pod 运行所在的同一节点上，直到这个旧 Pod 被杀死为止。
- 默认值为 0。
- 当
MaxUnavailable为 0 时此值不能为0。 - 此值可以指定为一个绝对的 Pod 个数或预期 Pod 总数的百分比（向上取整）。
如何使用它？
针对 StatefulSet 的 minReadySeconds
执行以下命令为任意 StatefulSet 指定一个 minReadySeconds 值， 通过检验 AvailableReplicas 字段查看这些 Pod 是否可用：
kubectl get statefulset/<StatefulSet 名称> -o yaml
请注意 minReadySeconds 的默认值为 0。
针对 DaemonSet 的 maxSurge
为 .spec.updateStrategy.rollingUpdate.maxSurge 指定一个值并将 .spec.updateStrategy.rollingUpdate.maxUnavailable 设置为 0。
然后观察下一次滚动上线是不是更快，同时运行的 Pod 数量是不是更多。
代码语言：javascript复制kubectl rollout restart daemonset <name_of_the_daemonset>
kubectl get pods -w
学习更多
阅读下面链接
