diff --git a/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md b/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md index 7bc7f7d145..e5c4322041 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md @@ -3,8 +3,14 @@ title: StatefulSet content_type: concept weight: 30 --- - * 给定 Pod 的存储必须由 - [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md) - 基于所请求的 `storage class` 来提供，或者由管理员预先提供。 + [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md) + 基于所请求的 `storage class` 来制备，或者由管理员预先制备。 * 删除或者扩缩 StatefulSet 并**不会**删除它关联的存储卷。 这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。 -* StatefulSet 当前需要[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services) - 来负责 Pod 的网络标识。你需要负责创建此服务。 +* StatefulSet 当前需要[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)来负责 Pod + 的网络标识。你需要负责创建此服务。 * 当删除一个 StatefulSet 时，该 StatefulSet 不提供任何终止 Pod 的保证。 为了实现 StatefulSet 中的 Pod 可以有序且体面地终止，可以在删除之前将 StatefulSet 缩容到 0。 -* 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 - [滚动更新](#rolling-updates)，可能进入需要[人工干预](#forced-rollback) - 才能修复的损坏状态。 +* 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用[滚动更新](#rolling-updates)， + 可能进入需要[人工干预](#forced-rollback)才能修复的损坏状态。 上述例子中： * 名为 `nginx` 的 Headless Service 用来控制网络域名。 * 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。 -* `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的 +* `volumeClaimTemplates` 将通过 PersistentVolume 制备程序所准备的 [PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。 StatefulSet 的命名需要遵循 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)规范。 @@ -172,7 +186,9 @@ StatefulSet 的命名需要遵循 [DNS 子域名](/zh-cn/docs/concepts/overview/ ### Pod 选择算符 {#pod-selector} 你必须设置 StatefulSet 的 `.spec.selector` 字段，使之匹配其在 `.spec.template.metadata.labels` 中设置的标签。 @@ -181,7 +197,9 @@ You must set the `.spec.selector` field of a StatefulSet to match the labels of ### 卷申领模板 {#volume-claim-templates} @@ -196,15 +214,14 @@ You can set the `.spec.volumeClaimTemplates` which can provide stable storage u -`.spec.minReadySeconds` 是一个可选字段， +`.spec.minReadySeconds` 是一个可选字段。 它指定新创建的 Pod 应该准备好且其任何容器不崩溃的最小秒数，以使其被视为可用。 -请注意，此功能是测试版，默认启用。如果你不希望启用此功能， -请通过取消设置 StatefulSetMinReadySeconds 标志来选择退出。 +这用于在使用[滚动更新](#rolling-updates)策略时检查滚动的进度。 该字段默认为 0（Pod 准备就绪后将被视为可用）。 要了解有关何时认为 Pod 准备就绪的更多信息， 请参阅[容器探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。 @@ -252,8 +269,8 @@ by the `serviceName` field on the StatefulSet. StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。 组合主机名的格式为`$(StatefulSet 名称)-$(序号)`。 上例将会创建三个名称分别为 `web-0、web-1、web-2` 的 Pod。 -StatefulSet 可以使用 [无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services) -控制它的 Pod 的网络域。管理域的这个服务的格式为： +StatefulSet 可以使用[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)控制它的 +Pod 的网络域。管理域的这个服务的格式为： `$(服务名称).$(名字空间).svc.cluster.local`，其中 `cluster.local` 是集群域。 一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为： `$(pod 名称).$(所属服务的 DNS 域名)`，其中所属服务由 StatefulSet 的 `serviceName` 域来设定。 @@ -268,13 +285,12 @@ remembered and reused, even after the Pod is running, for at least a few seconds If you need to discover Pods promptly after they are created, you have a few options: - Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups. -- Decrease the time of caching in your Kubernetes DNS provider (typically this means editing the config map for CoreDNS, which currently caches for 30 seconds). - +- Decrease the time of caching in your Kubernetes DNS provider (typically this means editing the + config map for CoreDNS, which currently caches for 30 seconds). As mentioned in the [limitations](#limitations) section, you are responsible for creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services) responsible for the network identity of the pods. - --> 取决于集群域内部 DNS 的配置，有可能无法查询一个刚刚启动的 Pod 的 DNS 命名。 当集群内其他客户端在 Pod 创建完成前发出 Pod 主机名查询时，就会发生这种情况。 @@ -286,14 +302,13 @@ responsible for the network identity of the pods. - 直接查询 Kubernetes API（比如，利用 watch 机制）而不是依赖于 DNS 查询 - 缩短 Kubernetes DNS 驱动的缓存时长（通常这意味着修改 CoreDNS 的 ConfigMap，目前缓存时长为 30 秒） -正如[限制](#limitations)中所述，你需要负责创建[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services) -以便为 Pod 提供网络标识。 +正如[限制](#limitations)中所述， +你需要负责创建[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)以便为 Pod 提供网络标识。 ### 稳定的存储 {#stable-storage} -对于 StatefulSet 中定义的每个 VolumeClaimTemplate，每个 Pod 接收到一个 PersistentVolumeClaim。在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的 +对于 StatefulSet 中定义的每个 VolumeClaimTemplate，每个 Pod 接收到一个 PersistentVolumeClaim。 +在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 制备的 1 Gib 的 PersistentVolume。 如果没有声明 StorageClass，就会使用默认的 StorageClass。 当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其 @@ -367,16 +385,18 @@ the StatefulSet. * 在一个 Pod 终止之前，所有的继任者必须完全关闭。 StatefulSet 不应将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0。 -这种做法是不安全的，要强烈阻止。更多的解释请参考 -[强制删除 StatefulSet Pod](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/)。 +这种做法是不安全的，要强烈阻止。 +更多的解释请参考[强制删除 StatefulSet Pod](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/)。 -如果用户想将示例中的 StatefulSet 缩放为 `replicas=1`，首先被终止的是 web-2。 +如果用户想将示例中的 StatefulSet 扩缩为 `replicas=1`，首先被终止的是 web-2。 在 web-2 没有被完全停止和删除前，web-1 不会被终止。 当 web-2 已被终止和删除、web-1 尚未被终止，如果在此期间发生 web-0 运行失败， 那么就不会终止 web-1，必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。 @@ -419,8 +439,8 @@ described [above](#deployment-and-scaling-guarantees). --> #### OrderedReady Pod 管理 {#orderedready-pod-management} -`OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了 -[上面](#deployment-and-scaling-guarantees)描述的功能。 +`OrderedReady` Pod 管理是 StatefulSet 的默认设置。 +它实现了[上面](#deployment-and-scaling-guarantees)描述的功能。 ## 更新策略 {#update-strategies} -StatefulSet 的 `.spec.updateStrategy` 字段让 -你可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。 -有两个允许的值： +StatefulSet 的 `.spec.updateStrategy` 字段让你可以配置和禁用掉自动滚动更新 Pod +的容器、标签、资源请求或限制、以及注解。有两个允许的值： + `OnDelete` : 当 StatefulSet 的 `.spec.updateStrategy.type` 设置为 `OnDelete` 时， @@ -513,8 +534,7 @@ update, roll out a canary, or perform a phased roll out. 所有序号小于该分区序号的 Pod 都不会被更新，并且，即使它们被删除也会依据之前的版本进行重建。 如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的 `.spec.replicas`，则对它的 `.spec.template` 的更新将不会传递到它的 Pod。 -在大多数情况下，你不需要使用分区，但如果你希望进行阶段更新、执行金丝雀或执行 -分阶段上线，则这些分区会非常有用。 +在大多数情况下，你不需要使用分区，但如果你希望进行阶段更新、执行金丝雀或执行分阶段上线，则这些分区会非常有用。 -{{< note >}} `maxUnavailable` 字段处于 Alpha 阶段，仅当 API 服务器启用了 `MaxUnavailableStatefulSet` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)时才起作用。 {{< /note >}} ### 强制回滚 {#forced-rollback} -在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 下使用 -[滚动更新](#rolling-updates)，可能进入需要人工干预才能修复的损坏状态。 +在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 下使用[滚动更新](#rolling-updates)， +可能进入需要人工干预才能修复的损坏状态。 如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如， 由于错误的二进制文件或应用程序级配置错误），StatefulSet 将停止回滚并等待。 @@ -587,8 +605,8 @@ After reverting the template, you must also delete any Pods that StatefulSet had already attempted to run with the bad configuration. StatefulSet will then begin to recreate the Pods using the reverted template. --> -在这种状态下，仅将 Pod 模板还原为正确的配置是不够的。由于 -[已知问题](https://github.com/kubernetes/kubernetes/issues/67250)，StatefulSet +在这种状态下，仅将 Pod 模板还原为正确的配置是不够的。 +由于[已知问题](https://github.com/kubernetes/kubernetes/issues/67250)，StatefulSet 将继续等待损坏状态的 Pod 准备就绪（永远不会发生），然后再尝试将其恢复为正常工作配置。 恢复模板后，还必须删除 StatefulSet 尝试使用错误的配置来运行的 Pod。这样， @@ -657,7 +675,7 @@ StatefulSet being deleted or scaled down. For example, if a Pod associated with fails due to node failure, and the control plane creates a replacement Pod, the StatefulSet retains the existing PVC. The existing volume is unaffected, and the cluster will attach it to the node where the new Pod is about to launch. - + The default for policies is `Retain`, matching the StatefulSet behavior before this new feature. Here is an example policy. @@ -683,17 +701,17 @@ spec: ``` -StatefulSet {{}}为其 PVC 添加了 -[属主引用](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)， +StatefulSet {{}}为其 PVC +添加了[属主引用](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)， 这些 PVC 在 Pod 终止后被{{}}删除。 这使 Pod 能够在删除 PVC 之前（以及在删除后备 PV 和卷之前，取决于保留策略）干净地卸载所有卷。 当你设置 `whenDeleted` 删除策略，对 StatefulSet 实例的属主引用放置在与该 StatefulSet 关联的所有 PVC 上。 @@ -758,7 +776,7 @@ Statefulset, don't set `.spec.replicas`. Instead, allow the Kubernetes the `.spec.replicas` field automatically. --> 如果 [HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) -（或任何类似的水平缩放 API）正在管理 StatefulSet 的缩放， +（或任何类似的水平扩缩 API）正在管理 StatefulSet 的扩缩， 请不要设置 `.spec.replicas`。 相反，允许 Kubernetes 控制平面自动管理 `.spec.replicas` 字段。