Skip to content

Commit 638a62e

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #34090 from zhangxyjlu/maxunavailable-for-statefulset
[zh]Add 2022-05-27-maxunavailable-for-statefulset.md chinese version
2 parents 0cd764e + f6fdad4 commit 638a62e

File tree

1 file changed

+239
-0
lines changed

1 file changed

+239
-0
lines changed

‎content/zh/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md

Lines changed: 239 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,239 @@
1+
---
2+
layout: blog
3+
title: 'Kubernetes 1.24: StatefulSet 的最大不可用副本数'
4+
date: 2022-05-27
5+
slug: maxunavailable-for-statefulset
6+
---
7+
<!--
8+
layout: blog
9+
title: 'Kubernetes 1.24: Maximum Unavailable Replicas for StatefulSet'
10+
date: 2022-05-27
11+
slug: maxunavailable-for-statefulset
12+
13+
**Author:** Mayank Kumar (Salesforce)
14+
-->
15+
**作者：** Mayank Kumar (Salesforce)
16+
17+
<!--
18+
Kubernetes [StatefulSets](/docs/concepts/workloads/controllers/statefulset/), since their introduction in
19+
1.5 and becoming stable in 1.9, have been widely used to run stateful applications. They provide stable pod identity, persistent
20+
per pod storage and ordered graceful deployment, scaling and rolling updates. You can think of StatefulSet as the atomic building
21+
block for running complex stateful applications. As the use of Kubernetes has grown, so has the number of scenarios requiring
22+
StatefulSets. Many of these scenarios, require faster rolling updates than the currently supported one-pod-at-a-time updates, in the
23+
case where you're using the `OrderedReady` Pod management policy for a StatefulSet.
24+
-->
25+
Kubernetes [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)，
26+
自 1.5 版本中引入并在 1.9 版本中变得稳定以来，已被广泛用于运行有状态应用。它提供固定的 Pod 身份标识、
27+
每个 Pod 的持久存储以及 Pod 的有序部署、扩缩容和滚动更新功能。你可以将 StatefulSet
28+
视为运行复杂有状态应用程序的原子构建块。随着 Kubernetes 的使用增多，需要 StatefulSet 的场景也越来越多。
29+
当 StatefulSet 的 Pod 管理策略为 `OrderedReady` 时，其中许多场景需要比当前所支持的一次一个 Pod
30+
的更新更快的滚动更新。
31+
32+
<!--
33+
Here are some examples:
34+
35+
- I am using a StatefulSet to orchestrate a multi-instance, cache based application where the size of the cache is large. The cache
36+
starts cold and requires some siginificant amount of time before the container can start. There could be more initial startup tasks
37+
that are required. A RollingUpdate on this StatefulSet would take a lot of time before the application is fully updated. If the
38+
StatefulSet supported updating more than one pod at a time, it would result in a much faster update.
39+
-->
40+
这里有些例子：
41+
42+
- 我使用 StatefulSet 来编排一个基于缓存的多实例应用程序，其中缓存的规格很大。
43+
缓存冷启动，需要相当长的时间才能启动容器。所需要的初始启动任务有很多。在应用程序完全更新之前，
44+
此 StatefulSet 上的 RollingUpdate 将花费大量时间。如果 StatefulSet 支持一次更新多个 Pod，
45+
那么更新速度会快得多。
46+
47+
<!--
48+
- My stateful application is composed of leaders and followers or one writer and multiple readers. I have multiple readers or
49+
followers and my application can tolerate multiple pods going down at the same time. I want to update this application more than
50+
one pod at a time so that i get the new updates rolled out quickly, especially if the number of instances of my application are
51+
large. Note that my application still requires unique identity per pod.
52+
-->
53+
- 我的有状态应用程序由 leader 和 follower 或者一个 writer 和多个 reader 组成。
54+
我有多个 reader 或 follower，并且我的应用程序可以容忍多个 Pod 同时出现故障。
55+
我想一次更新这个应用程序的多个 Pod，特别是当我的应用程序实例数量很多时，这样我就能快速推出新的更新。
56+
注意，我的应用程序仍然需要每个 Pod 具有唯一标识。
57+
58+
<!--
59+
In order to support such scenarios, Kubernetes 1.24 includes a new alpha feature to help. Before you can use the new feature you must
60+
enable the `MaxUnavailableStatefulSet` feature flag. Once you enable that, you can specify a new field called `maxUnavailable`, part
61+
of the `spec` for a StatefulSet. For example:
62+
-->
63+
为了支持这样的场景，Kubernetes 1.24 提供了一个新的 alpha 特性。在使用新特性之前，必须启用
64+
`MaxUnavailableStatefulSet` 特性标志。一旦启用，就可以指定一个名为 `maxUnavailable` 的新字段，
65+
这是 StatefulSet `spec` 的一部分。例如：
66+
67+
```
68+
apiVersion: apps/v1
69+
kind: StatefulSet
70+
metadata:
71+
name: web
72+
namespace: default
73+
spec:
74+
podManagementPolicy: OrderedReady # 你必须设为 OrderedReady
75+
replicas: 5
76+
selector:
77+
matchLabels:
78+
app: nginx
79+
template:
80+
metadata:
81+
labels:
82+
app: nginx
83+
spec:
84+
containers:
85+
- image: k8s.gcr.io/nginx-slim:0.8
86+
imagePullPolicy: IfNotPresent
87+
name: nginx
88+
updateStrategy:
89+
rollingUpdate:
90+
maxUnavailable: 2 # 这是 alpha 特性的字段，默认值是 1
91+
partition: 0
92+
type: RollingUpdate
93+
```
94+
95+
<!--
96+
If you enable the new feature and you don't specify a value for `maxUnavailable` in a StatefulSet, Kubernetes applies a default
97+
`maxUnavailable: 1`. This matches the behavior you would see if you don't enable the new feature.
98+
-->
99+
如果你启用了新特性，但没有在 StatefulSet 中指定 `maxUnavailable` 的值，Kubernetes
100+
会默认设置 `maxUnavailable: 1`。这与你不启用新特性时看到的行为是一致的。
101+
102+
<!--
103+
I'll run through a scenario based on that example manifest to demonstrate how this feature works. I will deploy a StatefulSet that
104+
has 5 replicas, with `maxUnavailable` set to 2 and `partition` set to 0.
105+
-->
106+
我将基于该示例清单做场景演练，以演示此特性是如何工作的。我将部署一个有 5 个副本的 StatefulSet，
107+
`maxUnavailable` 设置为 2 并将 `partition` 设置为 0。
108+
109+
<!--
110+
I can trigger a rolling update by changing the image to `k8s.gcr.io/nginx-slim:0.9`. Once I initiate the rolling update, I can
111+
watch the pods update 2 at a time as the current value of maxUnavailable is 2. The below output shows a span of time and is not
112+
complete. The maxUnavailable can be an absolute number (for example, 2) or a percentage of desired Pods (for example, 10%). The
113+
absolute number is calculated from percentage by rounding down.
114+
-->
115+
我可以通过将镜像更改为 `k8s.gcr.io/nginx-slim:0.9` 来触发滚动更新。一旦开始滚动更新，
116+
就可以看到一次更新 2 个 Pod，因为 `maxUnavailable` 的当前值是 2。
117+
下面的输出显示了一个时间段内的结果，但并不是完整过程。`maxUnavailable` 可以是绝对数值（例如 2）或所需 Pod
118+
的百分比（例如 10%），绝对数是通过百分比计算结果进行四舍五入得出的。
119+
120+
```
121+
kubectl get pods --watch
122+
```
123+
124+
```
125+
NAME READY STATUS RESTARTS AGE
126+
web-0 1/1 Running 0 85s
127+
web-1 1/1 Running 0 2m6s
128+
web-2 1/1 Running 0 106s
129+
web-3 1/1 Running 0 2m47s
130+
web-4 1/1 Running 0 2m27s
131+
web-4 1/1 Terminating 0 5m43s ----> start terminating 4
132+
web-3 1/1 Terminating 0 6m3s ----> start terminating 3
133+
web-3 0/1 Terminating 0 6m7s
134+
web-3 0/1 Pending 0 0s
135+
web-3 0/1 Pending 0 0s
136+
web-4 0/1 Terminating 0 5m48s
137+
web-4 0/1 Terminating 0 5m48s
138+
web-3 0/1 ContainerCreating 0 2s
139+
web-3 1/1 Running 0 2s
140+
web-4 0/1 Pending 0 0s
141+
web-4 0/1 Pending 0 0s
142+
web-4 0/1 ContainerCreating 0 0s
143+
web-4 1/1 Running 0 1s
144+
web-2 1/1 Terminating 0 5m46s ----> start terminating 2 (only after both 4 and 3 are running)
145+
web-1 1/1 Terminating 0 6m6s ----> start terminating 1
146+
web-2 0/1 Terminating 0 5m47s
147+
web-1 0/1 Terminating 0 6m7s
148+
web-1 0/1 Pending 0 0s
149+
web-1 0/1 Pending 0 0s
150+
web-1 0/1 ContainerCreating 0 1s
151+
web-1 1/1 Running 0 2s
152+
web-2 0/1 Pending 0 0s
153+
web-2 0/1 Pending 0 0s
154+
web-2 0/1 ContainerCreating 0 0s
155+
web-2 1/1 Running 0 1s
156+
web-0 1/1 Terminating 0 6m6s ----> start terminating 0 (only after 2 and 1 are running)
157+
web-0 0/1 Terminating 0 6m7s
158+
web-0 0/1 Pending 0 0s
159+
web-0 0/1 Pending 0 0s
160+
web-0 0/1 ContainerCreating 0 0s
161+
web-0 1/1 Running 0 1s
162+
```
163+
<!--
164+
Note that as soon as the rolling update starts, both 4 and 3 (the two highest ordinal pods) start terminating at the same time. Pods
165+
with ordinal 4 and 3 may become ready at their own pace. As soon as both pods 4 and 3 are ready, pods 2 and 1 start terminating at the
166+
same time. When pods 2 and 1 are both running and ready, pod 0 starts terminating.
167+
-->
168+
注意，滚动更新一开始，4 和 3（两个最高序号的 Pod）同时开始进入 `Terminating` 状态。
169+
Pod 4 和 3 会按照自身节奏进行更新。一旦 Pod 4 和 3 更新完毕后，Pod 2 和 1 会同时进入
170+
`Terminating` 状态。当 Pod 2 和 1 都准备完毕处于 `Running` 状态时，Pod 0 开始进入 `Terminating` 状态
171+
172+
<!--
173+
In Kubernetes, updates to StatefulSets follow a strict ordering when updating Pods. In this example, the update starts at replica 4, then
174+
replica 3, then replica 2, and so on, one pod at a time. When going one pod at a time, its not possible for 3 to be running and ready
175+
before 4. When `maxUnavailable` is more than 1 (in the example scenario I set `maxUnavailable` to 2), it is possible that replica 3 becomes
176+
ready and running before replica 4 is ready&mdash;and that is ok. If you're a developer and you set `maxUnavailable` to more than 1, you should
177+
know that this outcome is possible and you must ensure that your application is able to handle such ordering issues that occur
178+
if any. When you set `maxUnavailable` greater than 1, the ordering is guaranteed in between each batch of pods being updated. That guarantee
179+
means that pods in update batch 2 (replicas 2 and 1) cannot start updating until the pods from batch 0 (replicas 4 and 3) are ready.
180+
-->
181+
在 Kubernetes 中，StatefulSet 更新 Pod 时遵循严格的顺序。在此示例中，更新从副本 4 开始，
182+
然后是副本 3，然后是副本 2，以此类推，一次更新一个 Pod。当一次只更新一个 Pod 时，
183+
副本 3 不可能在副本 4 之前准备好进入 `Running` 状态。当 `maxUnavailable` 值
184+
大于 1 时（在示例场景中我设置 `maxUnavailable` 值为 2），副本 3 可能在副本 4 之前准备好并运行，
185+
这是没问题的。如果你是开发人员并且设置 `maxUnavailable` 值大于 1，你应该知道可能出现这种情况，
186+
并且如果有这种情况的话，你必须确保你的应用程序能够处理发生的此类顺序问题。当你设置 `maxUnavailable`
187+
值大于 1 时，更新 Pod 的批次之间会保证顺序。该保证意味着在批次 0（副本 4 和 3）中的 Pod
188+
准备好之前，更新批次 2（副本 2 和 1）中的 Pod 无法开始更新。
189+
190+
<!--
191+
Although Kubernetes refers to these as _replicas_, your stateful application may have a different view and each pod of the StatefulSet may
192+
be holding completely different data than other pods. The important thing here is that updates to StatefulSets happen in batches, and you can
193+
now have a batch size larger than 1 (as an alpha feature).
194+
-->
195+
尽管 Kubernetes 将这些称为**副本**，但你的有状态应用程序可能不这样理解，StatefulSet 的每个
196+
Pod 可能持有与其他 Pod 完全不同的数据。重要的是，StatefulSet 的更新是分批进行的，
197+
你现在让批次大小大于 1（作为 alpha 特性）。
198+
199+
<!--
200+
Also note, that the above behavior is with `podManagementPolicy: OrderedReady`. If you defined a StatefulSet as `podManagementPolicy: Parallel`,
201+
not only `maxUnavailable` number of replicas are terminated at the same time; `maxUnavailable` number of replicas start in `ContainerCreating`
202+
phase at the same time as well. This is called bursting.
203+
-->
204+
还要注意，上面的行为采用的 Pod 管理策略是 `podManagementPolicy: OrderedReady`。
205+
如果你的 StatefulSet 的 Pod 管理策略是 `podManagementPolicy: Parallel`，
206+
那么不仅是 `maxUnavailable` 数量的副本同时被终止，还会导致 `maxUnavailable` 数量的副本同时在
207+
`ContainerCreating` 阶段。这就是所谓的突发（Bursting）。
208+
209+
<!--
210+
So, now you may have a lot of questions about:-
211+
- What is the behavior when you set `podManagementPolicy: Parallel`?
212+
- What is the behavior when `partition` to a value other than `0`?
213+
-->
214+
因此，现在你可能有很多关于以下方面的问题：
215+
- 当设置 `podManagementPolicy:Parallel` 时，会产生什么行为？
216+
- 将 `partition` 设置为非 `0` 值时会发生什么？
217+
218+
<!--
219+
It might be better to try and see it for yourself. This is an alpha feature, and the Kubernetes contributors are looking for feedback on this feature. Did
220+
this help you achieve your stateful scenarios Did you find a bug or do you think the behavior as implemented is not intuitive or can
221+
break applications or catch them by surprise? Please [open an issue](https://github.com/kubernetes/kubernetes/issues) to let us know.
222+
-->
223+
自己试试看可能会更好。这是一个 alpha 特性，Kubernetes 贡献者正在寻找有关此特性的反馈。
224+
这是否有助于你实现有状态的场景？你是否发现了一个 bug，或者你认为实现的行为不直观易懂，
225+
或者它可能会破坏应用程序或让他们感到吃惊？请[登记一个 issue](https://github.com/kubernetes/kubernetes/issues)
226+
告知我们。
227+
228+
<!--
229+
## Further reading and next steps {#next-steps}
230+
- [Maximum unavailable Pods](/docs/concepts/workloads/controllers/statefulset/#maximum-unavailable-pods)
231+
- [KEP for MaxUnavailable for StatefulSet](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/961-maxunavailable-for-statefulset)
232+
- [Implementation](https://github.com/kubernetes/kubernetes/pull/82162/files)
233+
- [Enhancement Tracking Issue](https://github.com/kubernetes/enhancements/issues/961)
234+
-->
235+
## 进一步阅读和后续步骤 {#next-steps}
236+
- [最多不可用 Pod 数](/zh/docs/concepts/workloads/controllers/statefulset/#maximum-unavailable-pods)
237+
- [KEP for MaxUnavailable for StatefulSet](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/961-maxunavailable-for-statefulset)
238+
- [代码实现](https://github.com/kubernetes/kubernetes/pull/82162/files)
239+
- [增强跟踪 Issue](https://github.com/kubernetes/enhancements/issues/961)

0 commit comments

Comments
 (0)