这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。
Kubernetes 1.24: StatefulSet 的最大不可用副本数
作者： Mayank Kumar (Salesforce)
译者： Xiaoyang Zhang（Huawei）
Kubernetes StatefulSet，
自 1.5 版本中引入并在 1.9 版本中变得稳定以来，已被广泛用于运行有状态应用。它提供固定的 Pod 身份标识、
每个 Pod 的持久存储以及 Pod 的有序部署、扩缩容和滚动更新功能。你可以将 StatefulSet
视为运行复杂有状态应用程序的原子构建块。随着 Kubernetes 的使用增多，需要 StatefulSet 的场景也越来越多。
当 StatefulSet 的 Pod 管理策略为 OrderedReady 时，其中许多场景需要比当前所支持的一次一个 Pod
的更新更快的滚动更新。
这里有些例子：
- 我使用 StatefulSet 来编排一个基于缓存的多实例应用程序，其中缓存的规格很大。 缓存冷启动，需要相当长的时间才能启动容器。所需要的初始启动任务有很多。在应用程序完全更新之前， 此 StatefulSet 上的 RollingUpdate 将花费大量时间。如果 StatefulSet 支持一次更新多个 Pod， 那么更新速度会快得多。
- 我的有状态应用程序由 leader 和 follower 或者一个 writer 和多个 reader 组成。 我有多个 reader 或 follower，并且我的应用程序可以容忍多个 Pod 同时出现故障。 我想一次更新这个应用程序的多个 Pod，特别是当我的应用程序实例数量很多时，这样我就能快速推出新的更新。 注意，我的应用程序仍然需要每个 Pod 具有唯一标识。
为了支持这样的场景，Kubernetes 1.24 提供了一个新的 alpha 特性。在使用新特性之前，必须启用
MaxUnavailableStatefulSet 特性标志。一旦启用，就可以指定一个名为 maxUnavailable 的新字段，
这是 StatefulSet spec 的一部分。例如：
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
namespace: default
spec:
podManagementPolicy: OrderedReady # 你必须设为 OrderedReady
replicas: 5
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
# 镜像自发布以来已更改（以前使用的仓库为 "k8s.gcr.io"）
- image: registry.k8s.io/nginx-slim:0.8
imagePullPolicy: IfNotPresent
name: nginx
updateStrategy:
rollingUpdate:
maxUnavailable: 2 # 这是 alpha 特性的字段，默认值是 1
partition: 0
type: RollingUpdate
如果你启用了新特性，但没有在 StatefulSet 中指定 maxUnavailable 的值，Kubernetes
会默认设置 maxUnavailable: 1。这与你不启用新特性时看到的行为是一致的。
我将基于该示例清单做场景演练，以演示此特性是如何工作的。我将部署一个有 5 个副本的 StatefulSet，
maxUnavailable 设置为 2 并将 partition 设置为 0。
我可以通过将镜像更改为 registry.k8s.io/nginx-slim:0.9 来触发滚动更新。一旦开始滚动更新，
就可以看到一次更新 2 个 Pod，因为 maxUnavailable 的当前值是 2。
下面的输出显示了一个时间段内的结果，但并不是完整过程。maxUnavailable 可以是绝对数值（例如 2）或所需 Pod
的百分比（例如 10%），绝对数是通过百分比计算结果进行四舍五入到最接近的整数得出的。
kubectl get pods --watch
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 85s
web-1 1/1 Running 0 2m6s
web-2 1/1 Running 0 106s
web-3 1/1 Running 0 2m47s
web-4 1/1 Running 0 2m27s
web-4 1/1 Terminating 0 5m43s ----> start terminating 4
web-3 1/1 Terminating 0 6m3s ----> start terminating 3
web-3 0/1 Terminating 0 6m7s
web-3 0/1 Pending 0 0s
web-3 0/1 Pending 0 0s
web-4 0/1 Terminating 0 5m48s
web-4 0/1 Terminating 0 5m48s
web-3 0/1 ContainerCreating 0 2s
web-3 1/1 Running 0 2s
web-4 0/1 Pending 0 0s
web-4 0/1 Pending 0 0s
web-4 0/1 ContainerCreating 0 0s
web-4 1/1 Running 0 1s
web-2 1/1 Terminating 0 5m46s ----> start terminating 2 (only after both 4 and 3 are running)
web-1 1/1 Terminating 0 6m6s ----> start terminating 1
web-2 0/1 Terminating 0 5m47s
web-1 0/1 Terminating 0 6m7s
web-1 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-1 0/1 ContainerCreating 0 1s
web-1 1/1 Running 0 2s
web-2 0/1 Pending 0 0s
web-2 0/1 Pending 0 0s
web-2 0/1 ContainerCreating 0 0s
web-2 1/1 Running 0 1s
web-0 1/1 Terminating 0 6m6s ----> start terminating 0 (only after 2 and 1 are running)
web-0 0/1 Terminating 0 6m7s
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 1s
注意，滚动更新一开始，4 和 3（两个最高序号的 Pod）同时开始进入 Terminating 状态。
Pod 4 和 3 会按照自身节奏进行更新。一旦 Pod 4 和 3 更新完毕后，Pod 2 和 1 会同时进入
Terminating 状态。当 Pod 2 和 1 都准备完毕处于 Running 状态时，Pod 0 开始进入 Terminating 状态
在 Kubernetes 中，StatefulSet 更新 Pod 时遵循严格的顺序。在此示例中，更新从副本 4 开始，
然后是副本 3，然后是副本 2，以此类推，一次更新一个 Pod。当一次只更新一个 Pod 时，
副本 3 不可能在副本 4 之前准备好进入 Running 状态。当 maxUnavailable 值
大于 1 时（在示例场景中我设置 maxUnavailable 值为 2），副本 3 可能在副本 4 之前准备好并运行，
这是没问题的。如果你是开发人员并且设置 maxUnavailable 值大于 1，你应该知道可能出现这种情况，
并且如果有这种情况的话，你必须确保你的应用程序能够处理发生的此类顺序问题。当你设置 maxUnavailable
值大于 1 时，更新 Pod 的批次之间会保证顺序。该保证意味着在批次 0（副本 4 和 3）中的 Pod
准备好之前，更新批次 2（副本 2 和 1）中的 Pod 无法开始更新。
尽管 Kubernetes 将这些称为副本，但你的有状态应用程序可能不这样理解，StatefulSet 的每个 Pod 可能持有与其他 Pod 完全不同的数据。重要的是，StatefulSet 的更新是分批进行的， 你现在让批次大小大于 1（作为 alpha 特性）。
还要注意，上面的行为采用的 Pod 管理策略是 podManagementPolicy: OrderedReady。
如果你的 StatefulSet 的 Pod 管理策略是 podManagementPolicy: Parallel，
那么不仅是 maxUnavailable 数量的副本同时被终止，还会导致 maxUnavailable 数量的副本同时在
ContainerCreating 阶段。这就是所谓的突发（Bursting）。
因此，现在你可能有很多关于以下方面的问题：
- 当设置
podManagementPolicy:Parallel时，会产生什么行为？ - 将
partition设置为非0值时会发生什么？
自己试试看可能会更好。这是一个 alpha 特性，Kubernetes 贡献者正在寻找有关此特性的反馈。 这是否有助于你实现有状态的场景？你是否发现了一个 bug，或者你认为实现的行为不直观易懂， 或者它可能会破坏应用程序或让他们感到吃惊？请登记一个 issue 告知我们。