Skip to content

Commit 30c9213

Browse files
committed
[zh] Sync basic-stateful-set.md
1 parent cb2f55e commit 30c9213

File tree

1 file changed

+127
-64
lines changed

1 file changed

+127
-64
lines changed

content/zh-cn/docs/tutorials/stateful-application/basic-stateful-set.md

Lines changed: 127 additions & 64 deletions
Original file line numberDiff line numberDiff line change
@@ -894,21 +894,21 @@ Pod 时,挂载到 StatefulSet 的 Pod 的 PersistentVolume 卷不会被删除
894894
## 更新 StatefulSet {#updating-statefulsets}
895895

896896
<!--
897-
In Kubernetes 1.7 and later, the StatefulSet controller supports automated updates. The
897+
The StatefulSet controller supports automated updates. The
898898
strategy used is determined by the `spec.updateStrategy` field of the
899-
StatefulSet API Object. This feature can be used to upgrade the container
899+
StatefulSet API object. This feature can be used to upgrade the container
900900
images, resource requests and/or limits, labels, and annotations of the Pods in a
901-
StatefulSet. There are two valid update strategies, `RollingUpdate` and
902-
`OnDelete`.
901+
StatefulSet.
903902
-->
904-
从 Kubernetes 1.7 版本开始,StatefulSet 控制器支持自动更新。
903+
StatefulSet 控制器支持自动更新。
905904
更新策略由 StatefulSet API 对象的 `spec.updateStrategy` 字段决定。这个特性能够用来更新一个
906-
StatefulSet 中 Pod 的的容器镜像、资源请求和限制、标签和注解。
905+
StatefulSet 中 Pod 的容器镜像、资源请求和限制、标签和注解。
907906

908907
<!--
909-
`RollingUpdate` update strategy is the default for StatefulSets.
908+
There are two valid update strategies, `RollingUpdate` (the default) and
909+
`OnDelete`.
910910
-->
911-
`RollingUpdate` 更新策略是 StatefulSet 默认策略
911+
有两个有效的更新策略:`RollingUpdate`(默认)和 `OnDelete`
912912

913913
<!--
914914
### RollingUpdate {#rolling-update}
@@ -923,16 +923,16 @@ reverse ordinal order, while respecting the StatefulSet guarantees.
923923
Pod,采用与序号索引相反的顺序并遵循 StatefulSet 的保证。
924924

925925
<!--
926-
Patch the `web` StatefulSet to apply the `RollingUpdate` update strategy:
926+
You can split updates to a StatefulSet that uses the `RollingUpdate` strategy
927+
into _partitions_, by specifying `.spec.updateStrategy.rollingUpdate.partition`.
928+
You'll practice that later in this tutorial.
929+
930+
First, try a simple rolling update.
927931
-->
928-
`web` StatefulSet 应用 Patch 操作来应用 `RollingUpdate` 更新策略:
932+
你可以通过指定 `.spec.updateStrategy.rollingUpdate.partition` 将使用 `RollingUpdate`
933+
策略的 StatefulSet 的更新拆分为多个**分区** 。你将在本教程中稍后练习此操作。
929934

930-
```shell
931-
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'
932-
```
933-
```
934-
statefulset.apps/web patched
935-
```
935+
首先,尝试一个简单的滚动更新。
936936

937937
<!--
938938
In one terminal window, patch the `web` StatefulSet to change the container
@@ -1010,12 +1010,12 @@ StatefulSet controller terminates each Pod, and waits for it to transition to Ru
10101010
Ready prior to updating the next Pod. Note that, even though the StatefulSet
10111011
controller will not proceed to update the next Pod until its ordinal successor
10121012
is Running and Ready, it will restore any Pod that fails during the update to
1013-
its current version.
1013+
that Pod's existing version.
10141014
-->
10151015
StatefulSet 里的 Pod 采用和序号相反的顺序更新。在更新下一个 Pod 前,StatefulSet
10161016
控制器终止每个 Pod 并等待它们变成 Running 和 Ready。
10171017
请注意,虽然在顺序后继者变成 Running 和 Ready 之前 StatefulSet 控制器不会更新下一个
1018-
Pod,但它仍然会重建任何在更新过程中发生故障的 Pod,使用的是它们当前的版本
1018+
Pod,但它仍然会重建任何在更新过程中发生故障的 Pod,使用的是它们现有的版本
10191019

10201020
<!--
10211021
Pods that have already received the update will be restored to the updated version,
@@ -1060,31 +1060,55 @@ StatefulSet 的滚动更新状态。
10601060
#### 分段更新 {#staging-an-update}
10611061

10621062
<!--
1063-
You can stage an update to a StatefulSet by using the `partition` parameter of
1064-
the `RollingUpdate` update strategy. A staged update will keep all of the Pods
1065-
in the StatefulSet at the current version while allowing mutations to the
1066-
StatefulSet's `.spec.template`.
1063+
You can split updates to a StatefulSet that uses the `RollingUpdate` strategy
1064+
into _partitions_, by specifying `.spec.updateStrategy.rollingUpdate.partition`.
1065+
-->
1066+
你可以通过指定 `.spec.updateStrategy.rollingUpdate.partition` 将使用 `RollingUpdate` 策略的
1067+
StatefulSet 的更新拆分为多个**分区**
1068+
1069+
<!--
1070+
For more context, you can read [Partitioned rolling updates](/docs/concepts/workloads/controllers/statefulset/#partitions)
1071+
in the StatefulSet concept page.
10671072
-->
1068-
你可以使用 `RollingUpdate` 更新策略的 `partition` 参数来分段更新一个 StatefulSet。
1069-
分段的更新将会使 StatefulSet 中的其余所有 Pod 保持当前版本的同时允许改变
1070-
StatefulSet 的 `.spec.template`
1073+
有关更多上下文,你可以阅读 StatefulSet
1074+
概念页面中的[分区滚动更新](/zh-cn/docs/concepts/workloads/controllers/statefulset/#partitions)
10711075

10721076
<!--
1073-
Patch the `web` StatefulSet to add a partition to the `updateStrategy` field:
1077+
You can stage an update to a StatefulSet by using the `partition` field within
1078+
`.spec.updateStrategy.rollingUpdate`.
1079+
For this update, you will keep the existing Pods in the StatefulSet
1080+
unchanged whilst you change the pod template for the StatefulSet.
1081+
Then you - or, outside of a tutorial, some external automation - can
1082+
trigger that prepared update.
10741083
-->
1075-
`web` StatefulSet 执行 Patch 操作为 `updateStrategy` 字段添加一个分区:
1084+
你可以使用 `.spec.updateStrategy.rollingUpdate` 中的 `partition` 字段对 StatefulSet 执行更新的分段操作。
1085+
对于此更新,你将保持 StatefulSet 中现有 Pod 不变,同时更改 StatefulSet 的 Pod 模板。
1086+
然后,你(或通过教程之外的一些外部自动化工具)可以触发准备好的更新。
10761087

1088+
<!--
1089+
First, patch the `web` StatefulSet to add a partition to the `updateStrategy` field:
1090+
-->
1091+
`web` StatefulSet 执行 Patch 操作,为 `updateStrategy` 字段添加一个分区:
1092+
1093+
<!--
1094+
# The value of "partition" determines which ordinals a change applies to
1095+
# Make sure to use a number bigger than the last ordinal for the
1096+
# StatefulSet
1097+
-->
10771098
```shell
1099+
# "partition" 的值决定更改适用于哪些序号
1100+
# 确保使用比 StatefulSet 的最后一个序号更大的数字
10781101
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'
10791102
```
10801103
```
10811104
statefulset.apps/web patched
10821105
```
10831106

10841107
<!--
1085-
Patch the StatefulSet again to change the container's image:
1108+
Patch the StatefulSet again to change the container image that this
1109+
StatefulSet uses:
10861110
-->
1087-
再次 Patch StatefulSet 来改变容器镜像
1111+
再次 Patch StatefulSet 来改变此 StatefulSet 使用的容器镜像
10881112

10891113
```shell
10901114
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.7"}]'
@@ -1106,9 +1130,9 @@ pod "web-2" deleted
11061130
```
11071131

11081132
<!--
1109-
Wait for the Pod to be Running and Ready.
1133+
Wait for the replacement `web-2` Pod to be Running and Ready:
11101134
-->
1111-
等待 Pod 变成 Running 和 Ready。
1135+
等待替代的 Pod 变成 Running 和 Ready。
11121136

11131137
<!--
11141138
# End the watch when you see that web-2 is healthy
@@ -1139,11 +1163,11 @@ registry.k8s.io/nginx-slim:0.8
11391163

11401164
<!--
11411165
Notice that, even though the update strategy is `RollingUpdate` the StatefulSet
1142-
restored the Pod with its original container. This is because the
1166+
restored the Pod with the original container image. This is because the
11431167
ordinal of the Pod is less than the `partition` specified by the
11441168
`updateStrategy`.
11451169
-->
1146-
请注意,虽然更新策略是 `RollingUpdate`,StatefulSet 还是会使用原始的容器恢复 Pod。
1170+
请注意,虽然更新策略是 `RollingUpdate`,StatefulSet 还是会使用原始的容器镜像恢复 Pod。
11471171
这是因为 Pod 的序号比 `updateStrategy` 指定的 `partition` 更小。
11481172

11491173
<!--
@@ -1152,11 +1176,16 @@ ordinal of the Pod is less than the `partition` specified by the
11521176
#### 金丝雀发布 {#rolling-out-a-canary}
11531177

11541178
<!--
1155-
You can roll out a canary to test a modification by decrementing the `partition`
1179+
You're now going to try a [canary rollout](https://glossary.cncf.io/canary-deployment/)
1180+
of that staged change.
1181+
-->
1182+
现在,你将尝试对分段的变更进行[金丝雀发布](https://glossary.cncf.io/canary-deployment/)
1183+
1184+
<!--
1185+
You can roll out a canary (to test the modified template) by decrementing the `partition`
11561186
you specified [above](#staging-an-update).
11571187
-->
1158-
你可以通过减少[上文](#staging-an-update)指定的
1159-
`partition` 来进行金丝雀发布,以此来测试你的程序的改动。
1188+
你可以通过减少[上文](#staging-an-update)指定的 `partition` 来进行金丝雀发布,以测试修改后的模板。
11601189

11611190
<!--
11621191
Patch the StatefulSet to decrement the partition:
@@ -1168,17 +1197,21 @@ Patch the StatefulSet to decrement the partition:
11681197
# the StatefulSet
11691198
-->
11701199
```shell
1171-
# “partition” 的值应与 StatefulSet 现有的最高序数相匹配
1200+
# “partition” 的值应与 StatefulSet 现有的最高序号相匹配
11721201
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'
11731202
```
11741203
```
11751204
statefulset.apps/web patched
11761205
```
11771206

11781207
<!--
1179-
Wait for `web-2` to be Running and Ready.
1208+
The control plane triggers replacement for `web-2` (implemented by
1209+
a graceful **delete** followed by creating a new Pod once the deletion
1210+
is complete).
1211+
Wait for the new `web-2` Pod to be Running and Ready.
11801212
-->
1181-
等待 `web-2` 变成 Running 和 Ready。
1213+
控制平面会触发 `web-2` 的替换(先优雅地 **删除** 现有 Pod,然后在删除完成后创建一个新的 Pod)。
1214+
等待新的 `web-2` Pod 变成 Running 和 Ready。
11821215

11831216
<!--
11841217
# This should already be running
@@ -1205,7 +1238,6 @@ kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image
12051238
```
12061239
```
12071240
registry.k8s.io/nginx-slim:0.7
1208-
12091241
```
12101242

12111243
<!--
@@ -1374,27 +1406,51 @@ continue the update process.
13741406
### OnDelete 策略 {#on-delete}
13751407

13761408
<!--
1377-
The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior,
1378-
When you select this update strategy, the StatefulSet controller will not
1379-
automatically update Pods when a modification is made to the StatefulSet's
1380-
`.spec.template` field. This strategy can be selected by setting the
1409+
You select this update strategy for a StatefulSet by setting the
13811410
`.spec.template.updateStrategy.type` to `OnDelete`.
1411+
1412+
Patch the `web` StatefulSet to use the `OnDelete` update strategy:
1413+
-->
1414+
通过将 `.spec.template.updateStrategy.type` 设置为 `OnDelete`,你可以为 StatefulSet 选择此更新策略。
1415+
1416+
`web` StatefulSet 执行 patch 操作,以使用 `OnDelete` 更新策略:
1417+
1418+
```shell
1419+
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"OnDelete"}}}'
1420+
```
1421+
```
1422+
statefulset.apps/web patched
1423+
```
1424+
1425+
<!--
1426+
When you select this update strategy, the StatefulSet controller does not
1427+
automatically update Pods when a modification is made to the StatefulSet's
1428+
`.spec.template` field. You need to manage the rollout yourself - either
1429+
manually, or using separate automation.
13821430
-->
1383-
`OnDelete` 更新策略实现了传统(1.7 之前)行为,它也是默认的更新策略。
13841431
当你选择这个更新策略并修改 StatefulSet 的 `.spec.template` 字段时,StatefulSet 控制器将不会自动更新 Pod。
1432+
你需要自己手动管理发布,或使用单独的自动化工具来管理发布。
13851433

13861434
<!--
13871435
## Deleting StatefulSets
13881436
-->
13891437
## 删除 StatefulSet {#deleting-statefulsets}
13901438

13911439
<!--
1392-
StatefulSet supports both Non-Cascading and Cascading deletion. In a
1393-
Non-Cascading Delete, the StatefulSet's Pods are not deleted when the StatefulSet is deleted. In a Cascading Delete, both the StatefulSet and its Pods are
1394-
deleted.
1440+
StatefulSet supports both _non-cascading_ and _cascading_ deletion. In a
1441+
non-cascading **delete**, the StatefulSet's Pods are not deleted when the
1442+
StatefulSet is deleted. In a cascading **delete**, both the StatefulSet and
1443+
its Pods are deleted.
13951444
-->
1396-
StatefulSet 同时支持级联和非级联删除。使用非级联方式删除 StatefulSet 时,StatefulSet
1397-
的 Pod 不会被删除。使用级联删除时,StatefulSet 和它的 Pod 都会被删除。
1445+
StatefulSet 同时支持**非级联****级联**删除。使用非级联方式**删除** StatefulSet 时,StatefulSet
1446+
的 Pod 不会被删除。使用级联**删除**时,StatefulSet 和它的 Pod 都会被删除。
1447+
1448+
<!--
1449+
Read [Use Cascading Deletion in a Cluster](/docs/tasks/administer-cluster/use-cascading-deletion/)
1450+
to learn about cascading deletion generally.
1451+
-->
1452+
阅读[在集群中使用级联删除](/zh-cn/docs/tasks/administer-cluster/use-cascading-deletion/)
1453+
以了解通用的级联删除。
13981454

13991455
<!--
14001456
### Non-cascading delete
@@ -1418,11 +1474,11 @@ kubectl get pods --watch -l app=nginx
14181474
Use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete the
14191475
StatefulSet. Make sure to supply the `--cascade=orphan` parameter to the
14201476
command. This parameter tells Kubernetes to only delete the StatefulSet, and to
1421-
not delete any of its Pods.
1477+
**not** delete any of its Pods.
14221478
-->
14231479
使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)
14241480
删除 StatefulSet。请确保提供了 `--cascade=orphan` 参数给命令。这个参数告诉
1425-
Kubernetes 只删除 StatefulSet 而不要删除它的任何 Pod。
1481+
Kubernetes 只删除 StatefulSet **不要**删除它的任何 Pod。
14261482

14271483
```shell
14281484
kubectl delete statefulset web --cascade=orphan
@@ -1556,10 +1612,10 @@ StatefulSet 会接收这个 Pod。由于你重新创建的 StatefulSet 的 `repl
15561612
一旦 `web-0` 被重新创建并且 `web-1` 被认为已经处于 Running 和 Ready 状态时,`web-2` 将会被终止。
15571613

15581614
<!--
1559-
Let's take another look at the contents of the `index.html` file served by the
1615+
Now take another look at the contents of the `index.html` file served by the
15601616
Pods' webservers:
15611617
-->
1562-
让我们再看看被 Pod 的 Web 服务器加载的 `index.html` 的内容:
1618+
现在再看看被 Pod 的 Web 服务器加载的 `index.html` 的内容:
15631619

15641620
```shell
15651621
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
@@ -1654,10 +1710,10 @@ the Pod's successor to be completely terminated.
16541710
{{< note >}}
16551711
<!--
16561712
Although a cascading delete removes a StatefulSet together with its Pods,
1657-
the cascade does not delete the headless Service associated with the StatefulSet.
1713+
the cascade does **not** delete the headless Service associated with the StatefulSet.
16581714
You must delete the `nginx` Service manually.
16591715
-->
1660-
尽管级联删除会删除 StatefulSet 及其 Pod,但级联不会删除与 StatefulSet
1716+
尽管级联删除会删除 StatefulSet 及其 Pod,但级联**不会**删除与 StatefulSet
16611717
关联的 Headless Service。你必须手动删除 `nginx` Service。
16621718
{{< /note >}}
16631719

@@ -1740,13 +1796,19 @@ statefulset "web" deleted
17401796
<!--
17411797
For some distributed systems, the StatefulSet ordering guarantees are
17421798
unnecessary and/or undesirable. These systems require only uniqueness and
1743-
identity. To address this, in Kubernetes 1.7, we introduced
1744-
`.spec.podManagementPolicy` to the StatefulSet API Object.
1799+
identity.
17451800
-->
17461801
对于某些分布式系统来说,StatefulSet 的顺序性保证是不必要和/或者不应该的。
1747-
这些系统仅仅要求唯一性和身份标志。为了解决这个问题,在 Kubernetes 1.7
1748-
中我们针对 StatefulSet API 对象引入了 `.spec.podManagementPolicy`
1749-
此选项仅影响扩缩操作的行为。更新不受影响。
1802+
这些系统仅仅要求唯一性和身份标志。
1803+
1804+
<!--
1805+
You can specify a Pod management policy to avoid this strict ordering;
1806+
either [`OrderedReady`](/docs/concepts/workloads/controllers/statefulset/#orderedready-pod-management) (the default)
1807+
or [`Parallel`](/docs/concepts/workloads/controllers/statefulset/#parallel-pod-management).
1808+
-->
1809+
你可以指定 Pod 管理策略以避免这个严格的顺序;
1810+
你可以选择 [`OrderedReady`](/zh-cn/docs/concepts/workloads/controllers/statefulset/#orderedready-pod-management)(默认)或
1811+
[`Parallel`](/zh-cn/docs/concepts/workloads/controllers/statefulset/#parallel-pod-management)
17501812

17511813
<!--
17521814
### OrderedReady Pod management
@@ -1775,7 +1837,7 @@ Pod. This option only affects the behavior for scaling operations. Updates are n
17751837
`Parallel` Pod 管理策略告诉 StatefulSet 控制器并行的终止所有 Pod,
17761838
在启动或终止另一个 Pod 前,不必等待这些 Pod 变成 Running 和 Ready 或者完全终止状态。
17771839

1778-
{{{% code_sample file="application/web/web-parallel.yaml" %}}
1840+
{{% code_sample file="application/web/web-parallel.yaml" %}}
17791841

17801842
<!--
17811843
This manifest is identical to the one you downloaded above except that the `.spec.podManagementPolicy`
@@ -1835,9 +1897,10 @@ web-1 1/1 Running 0 10s
18351897
```
18361898

18371899
<!--
1838-
The StatefulSet controller launched both `web-0` and `web-1` at the same time.
1900+
The StatefulSet controller launched both `web-0` and `web-1` at almost the
1901+
same time.
18391902
-->
1840-
StatefulSet 控制器同时启动了 `web-0``web-1`
1903+
StatefulSet 控制器几乎同时启动了 `web-0``web-1`
18411904

18421905
<!--
18431906
Keep the second terminal open, and, in another terminal window scale the

0 commit comments

Comments
 (0)