From 57f8e103ff4f503f14b001bca5718cae0740604e Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Wed, 15 May 2024 01:19:37 +0800 Subject: [PATCH] [zh-cn] sync basic-stateful-set.md Signed-off-by: xin.li --- .../basic-stateful-set.md | 196 ++++++++++++------ 1 file changed, 128 insertions(+), 68 deletions(-) diff --git a/content/zh-cn/docs/tutorials/stateful-application/basic-stateful-set.md b/content/zh-cn/docs/tutorials/stateful-application/basic-stateful-set.md index 346ac3d884..001cd9423f 100644 --- a/content/zh-cn/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/zh-cn/docs/tutorials/stateful-application/basic-stateful-set.md @@ -123,13 +123,13 @@ After this tutorial, you will be familiar with the following. ## 创建 StatefulSet {#creating-a-statefulset} -作为开始，使用如下示例创建一个 StatefulSet。它和 +作为开始，使用如下示例创建一个 StatefulSet（以及它所依赖的 Service）。它和 [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/) 概念中的示例相似。 它创建了一个 [Headless Service](/zh-cn/docs/concepts/services-networking/service/#headless-services) `nginx` 用来发布 StatefulSet `web` 中的 Pod 的 IP 地址。 @@ -204,6 +204,11 @@ web 2 1 20s --> ### 顺序创建 Pod {#ordered-pod-creation} + +StatefulSet 默认以严格的顺序创建其 Pod。 + 请注意，直到 `web-0` Pod 处于 **Running**（请参阅 [Pod 阶段](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)） 并 **Ready**（请参阅 [Pod 状况](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)中的 `type`）状态后，`web-1` Pod 才会被启动。 +在本教程的后面部分，你将练习[并行启动](#parallel-pod-management)。 + {{< note >}} Pod 的序号、主机名、SRV 条目和记录名称没有改变，但和 Pod 相关联的 IP 地址可能发生了改变。 在本教程中使用的集群中它们就改变了。这就是为什么不要在其他应用中使用 -StatefulSet 中 Pod 的 IP 地址进行连接，这点很重要。 +StatefulSet 中特定 Pod 的 IP 地址进行连接，这点很重要 +（可以通过解析 Pod 的主机名来连接到 Pod）。 +如果你的应用程序想要在 StatefulSet 中找到任一健康的 Pod， +且不需要跟踪每个特定的 Pod，你还可以连接到由该 StatefulSet 中的 Pod 关联的 +`type: ClusterIP` Service 的 IP 地址。 +你可以使用跟踪 StatefulSet 的同一 Service +（StatefulSet 中 `serviceName` 所指定的）或选择正确的 Pod 集的单独 Service。 + @@ -701,12 +726,13 @@ PersistentVolumeClaim 相关联的 PersistentVolume 卷被重新挂载到了各 ## 扩容/缩容 StatefulSet {#scaling-a-statefulset} -扩容/缩容 StatefulSet 指增加或减少它的副本数。这通过更新 `replicas` 字段完成。 +扩容/缩容 StatefulSet 指增加或减少它的副本数。这通过更新 `replicas` 字段完成（水平缩放）。 你可以使用 [`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale) 或者 [`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch) 来扩容/缩容一个 StatefulSet。 @@ -715,6 +741,14 @@ This is accomplished by updating the `replicas` field. You can use either --> ### 扩容 {#scaling-up} + +扩容意味着添加更多副本。 +如果你的应用程序能够在整个 StatefulSet 范围内分派工作，则新的更大的 Pod 集可以执行更多的工作。 + @@ -793,6 +827,14 @@ Pod，并且会等待前一个 Pod 变为 Running 和 Ready 才会启动下一 --> ### 缩容 {#scaling-down} + +缩容意味着减少副本数量。 +例如，你可能因为服务的流量水平已降低并且在当前规模下存在空闲资源的原因执行缩容操作。 + @@ -854,9 +896,9 @@ web-3 1/1 Terminating 0 42s ### 顺序终止 Pod {#ordered-pod-termination} 控制器会按照与 Pod 序号索引相反的顺序每次删除一个 Pod。在删除下一个 Pod 前会等待上一个被完全关闭。 @@ -879,12 +921,13 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO 五个 PersistentVolumeClaims 和五个 PersistentVolume 卷仍然存在。 -查看 Pod 的[稳定存储](#stable-storage)，我们发现当删除 StatefulSet 的 +查看 Pod 的[稳定存储](#stable-storage)，你会发现当删除 StatefulSet 的 Pod 时，挂载到 StatefulSet 的 Pod 的 PersistentVolume 卷不会被删除。 当这种删除行为是由 StatefulSet 缩容引起时也是一样的。 @@ -1802,13 +1845,12 @@ identity. 这些系统仅仅要求唯一性和身份标志。 -你可以指定 Pod 管理策略以避免这个严格的顺序； -你可以选择 [`OrderedReady`](/zh-cn/docs/concepts/workloads/controllers/statefulset/#orderedready-pod-management)（默认）或 -[`Parallel`](/zh-cn/docs/concepts/workloads/controllers/statefulset/#parallel-pod-management)。 +你可以指定 [Pod 管理策略](/zh-cn/docs/concepts/workloads/controllers/statefulset/#pod-management-policies) +以避免这个严格的顺序； +你可以选择 `OrderedReady`（默认）或 `Parallel`。 +当你的应用程序需要或期望变更（例如推出应用程序的新版本）按照 StatefulSet +提供的序号（Pod 编号）的严格顺序发生时，请使用此选项。 +换句话说，如果你已经有了 Pod `app-0`、`app-1` 和 `app-2`，Kubernetes 将首先更新 `app-0` 并检查它。 +一旦检查良好，Kubernetes 就会更新 `app-1`，最后更新 `app-2`。 + + +如果你再添加两个 Pod，Kubernetes 将设置 `app-3` 并等待其正常运行，然后再部署 `app-4`。 + +因为这是默认设置，所以你已经在练习使用它，本教程不会让你再次执行类似的步骤。 + ### Parallel Pod 管理策略 {#parallel-pod-management} -`Parallel` Pod 管理策略告诉 StatefulSet 控制器并行的终止所有 Pod， +另一种选择，`Parallel` Pod 管理策略告诉 StatefulSet 控制器并行的终止所有 Pod， 在启动或终止另一个 Pod 前，不必等待这些 Pod 变成 Running 和 Ready 或者完全终止状态。 + +`Parallel` Pod 管理选项仅影响扩缩容操作的行为。 +变更操作不受其影响；Kubernetes 仍然按顺序推出变更。 +对于本教程，应用本身非常简单：它是一个告诉你其主机名的网络服务器（因为这是一个 +StatefulSet，每个 Pod 的主机名都是不同的且可预测的）。 + {{% code_sample file="application/web/web-parallel.yaml" %}} -在另一个终端窗口创建清单中的 StatefulSet 和 Service： +在另一个终端中，重新配置 StatefulSet 以进行 `Parallel` Pod 管理： ```shell kubectl apply -f https://k8s.io/examples/application/web/web-parallel.yaml ``` ``` -service/nginx created -statefulset.apps/web created +service/nginx updated +statefulset.apps/web updated ``` -查看你在第一个终端中运行的 `kubectl get` 命令的输出。 - - -```shell -# 这应该已经处于 Running 状态 -kubectl get pod -l app=nginx --watch -``` -``` -NAME READY STATUS RESTARTS AGE -web-0 0/1 Pending 0 0s -web-0 0/1 Pending 0 0s -web-1 0/1 Pending 0 0s -web-1 0/1 Pending 0 0s -web-0 0/1 ContainerCreating 0 0s -web-1 0/1 ContainerCreating 0 0s -web-0 1/1 Running 0 10s -web-1 1/1 Running 0 10s -``` - - -StatefulSet 控制器几乎同时启动了 `web-0` 和 `web-1`。 - - -保持第二个终端打开，并在另一个终端窗口中扩容 StatefulSet： +保持你运行监视进程的终端为打开状态，并在另一个终端窗口中扩容 StatefulSet： ```shell -kubectl scale statefulset/web --replicas=4 +kubectl scale statefulset/web --replicas=5 ``` ``` statefulset.apps/web scaled ``` -在 `kubectl get` 命令运行的终端里检查它的输出。 +在 `kubectl get` 命令运行的终端里检查它的输出。它可能看起来像： ``` web-3 0/1 Pending 0 0s web-3 0/1 Pending 0 0s web-3 0/1 Pending 0 7s web-3 0/1 ContainerCreating 0 7s -web-2 1/1 Running 0 10s +web-2 0/1 Pending 0 0s +web-4 0/1 Pending 0 0s +web-2 1/1 Running 0 8s +web-4 0/1 ContainerCreating 0 4s web-3 1/1 Running 0 26s +web-4 1/1 Running 0 2s ``` -StatefulSet 启动了两个新的 Pod，而且在启动第二个之前并没有等待第一个变成 Running 和 Ready 状态。 +StatefulSet 启动了三个新的 Pod，而且在启动第二和第三个之前并没有等待第一个变成 Running 和 Ready 状态。 + + +如果你的工作负载具有有状态元素，或者需要 Pod 能够通过可预测的命名来相互识别， +特别是当你有时需要快速提供更多容量时，此方法非常有用。 +如果本教程的这个简单 Web 服务突然每分钟收到额外 1,000,000 个请求， +那么你可能会想要运行更多 Pod，但你也不想等待每个新 Pod 启动。 +并行启动额外的 Pod 可以缩短请求额外容量和使其可供使用之间的时间。 ## {{% heading "cleanup" %}}