whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh]Update concepts pages(part-4) for links with '/zh/' prefix, using new prefix '/zh-cn/'

Browse Source
This commit is contained in:
howieyuen
2022-06-23 20:20:11 +08:00
parent 7eca3dd28a
commit 3ecfa2da5a
25 changed files with 309 additions and 309 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh-cn/docs/concepts/workloads/_index.md
+19 -19
View File
@@ -26,7 +26,7 @@ Pod is running means that all the Pods on that node fail. Kubernetes treats that
of failure as final: you would need to create a new Pod even if the node later recovers.
-->
无论你的负载是单一组件还是由多个一同工作的组件构成，在 Kubernetes 中你
可以在一组 [Pods](/zh/docs/concepts/workloads/pods) 中运行它。
可以在一组 [Pods](/zh-cn/docs/concepts/workloads/pods) 中运行它。
在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组
{{< glossary_tooltip text="容器" term_id="container" >}}。
@@ -37,7 +37,7 @@ For example, once a pod is running in your cluster then a critical fault on the
all the pods on that node fail. Kubernetes treats that level of failure as final: you
would need to create a new `Pod` to recover, even if the node later becomes healthy.
-->
Kubernetes Pods 有[确定的生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)。
Kubernetes Pods 有[确定的生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)。
例如，当某 Pod 在你的集群中运行时，Pod 运行所在的
{{< glossary_tooltip text="节点" term_id="node" >}} 出现致命错误时，
所有该节点上的 Pods 都会失败。Kubernetes 将这类失败视为最终状态：
@@ -72,15 +72,15 @@ Kubernetes 提供若干种内置的工作负载资源：
`Pods` for that `StatefulSet`, can replicate data to other `Pods` in the same `StatefulSet`
to improve overall resilience.
-->
* [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 和
[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)
* [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 和
[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/)
（替换原来的资源 {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}）。
`Deployment` 很适合用来管理你的集群上的无状态应用，`Deployment` 中的所有
`Pod` 都是相互等价的，并且在需要的时候被换掉。
* [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)
* [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/)
让你能够运行一个或者多个以某种方式跟踪应用状态的 Pods。
例如，如果你的负载会将数据作持久存储，你可以运行一个 `StatefulSet`，将每个
`Pod` 与某个 [`PersistentVolume`](/zh/docs/concepts/storage/persistent-volumes/)
`Pod` 与某个 [`PersistentVolume`](/zh-cn/docs/concepts/storage/persistent-volumes/)
对应起来。你在 `StatefulSet` 中各个 `Pod` 内运行的代码可以将数据复制到同一
`StatefulSet` 中的其它 `Pod` 中以提高整体的服务可靠性。
<!--
@@ -95,14 +95,14 @@ Kubernetes 提供若干种内置的工作负载资源：
define tasks that run to completion and then stop. Jobs represent one-off tasks, whereas
`CronJobs` recur according to a schedule.
-->
* [DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/)
* [DaemonSet](/zh-cn/docs/concepts/workloads/controllers/daemonset/)
定义提供节点本地支撑设施的 `Pods`。这些 Pods 可能对于你的集群的运维是
非常重要的，例如作为网络链接的辅助工具或者作为网络
{{< glossary_tooltip text="插件" term_id="addons" >}}
的一部分等等。每次你向集群中添加一个新节点时，如果该节点与某 `DaemonSet`
的规约匹配，则控制面会为该 `DaemonSet` 调度一个 `Pod` 到该新节点上运行。
* [Job](/zh/docs/concepts/workloads/controllers/job/) 和
[CronJob](/zh/docs/concepts/workloads/controllers/cron-jobs/)。
* [Job](/zh-cn/docs/concepts/workloads/controllers/job/) 和
[CronJob](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)。
定义一些一直运行到结束并停止的任务。`Job` 用来表达的是一次性的任务，而
`CronJob` 会根据其时间规划反复运行。
@@ -117,7 +117,7 @@ then you can implement or install an extension that does provide that feature.
-->
在庞大的 Kubernetes 生态系统中，你还可以找到一些提供额外操作的第三方
工作负载资源。通过使用
[定制资源定义（CRD）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)，
[定制资源定义（CRD）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)，
你可以添加第三方工作负载资源，以完成原本不是 Kubernetes 核心功能的工作。
例如，如果你希望运行一组 `Pods`，但要求所有 Pods 都可用时才执行操作
（比如针对某种高吞吐量的分布式任务），你可以实现一个能够满足这一需求
@@ -135,18 +135,18 @@ As well as reading about each resource, you can learn about specific tasks that
-->
除了阅读了解每类资源外，你还可以了解与这些资源相关的任务：
* [使用 Deployment 运行一个无状态的应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)
* 以[单实例](/zh/docs/tasks/run-application/run-single-instance-stateful-application/)
或者[多副本集合](/zh/docs/tasks/run-application/run-replicated-stateful-application/)
* [使用 Deployment 运行一个无状态的应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)
* 以[单实例](/zh-cn/docs/tasks/run-application/run-single-instance-stateful-application/)
或者[多副本集合](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/)
的形式运行有状态的应用；
* [使用 `CronJob` 运行自动化的任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/)
* [使用 `CronJob` 运行自动化的任务](/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs/)
<!--
To learn about Kubernetes' mechanisms for separating code from configuration,
visit [Configuration](/docs/concepts/configuration/).
-->
要了解 Kubernetes 将代码与配置分离的实现机制，可参阅
[配置部分](/zh/docs/concepts/configuration/)。
[配置部分](/zh-cn/docs/concepts/configuration/)。
<!--
There are two supporting concepts that provide backgrounds about how Kubernetes manages pods
@@ -158,9 +158,9 @@ for applications:
-->
关于 Kubernetes 如何为应用管理 Pods，还有两个支撑概念能够提供相关背景信息：
* [垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)机制负责在
* [垃圾收集](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/)机制负责在
对象的 _属主资源_ 被删除时在集群中清理这些对象。
* [_Time-to-Live_ 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)
* [_Time-to-Live_ 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)
会在 Job 结束之后的指定时间间隔之后删除它们。
<!--
@@ -169,6 +169,6 @@ a [`Service`](/docs/concepts/services-networking/service/) or, for web applicati
using an [`Ingress`](/docs/concepts/services-networking/ingress).
-->
一旦你的应用处于运行状态，你就可能想要以
[`Service`](/zh/docs/concepts/services-networking/service/)
[`Service`](/zh-cn/docs/concepts/services-networking/service/)
的形式使之可在互联网上访问；或者对于 Web 应用而言，使用
[`Ingress`](/zh/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。
[`Ingress`](/zh-cn/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。
content/zh-cn/docs/concepts/workloads/controllers/deployment.md
+14 -14
View File
@@ -1063,7 +1063,7 @@ Assuming [horizontal Pod autoscaling](/docs/tasks/run-application/horizontal-pod
in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of
Pods you want to run based on the CPU utilization of your existing Pods.
-->
假设集群启用了[Pod 的水平自动缩放](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)，
假设集群启用了[Pod 的水平自动缩放](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)，
你可以为 Deployment 设置自动缩放器，并基于现有 Pod 的 CPU 利用率选择要运行的
Pod 个数下限和上限。
@@ -1854,7 +1854,7 @@ can create multiple Deployments, one for each release, following the canary patt
## 金丝雀部署 {#canary-deployment}
如果要使用 Deployment 向用户子集或服务器子集上线版本，
则可以遵循[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
则可以遵循[资源管理](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
所描述的金丝雀模式，创建多个 Deployment，每个版本一个。
<!--
@@ -1868,8 +1868,8 @@ configuring containers, and [using kubectl to manage resources](/docs/concepts/o
## 编写 Deployment 规约 {#writing-a-deployment-spec}
同其他 Kubernetes 配置一样， Deployment 需要 `apiVersion`，`kind` 和 `metadata` 字段。
有关配置文件的其他信息，请参考[部署 Deployment](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、
配置容器和[使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/)等相关文档。
有关配置文件的其他信息，请参考[部署 Deployment](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)、
配置容器和[使用 kubectl 管理资源](/zh-cn/docs/concepts/overview/working-with-objects/object-management/)等相关文档。
<!--
The name of a Deployment object must be a valid
@@ -1878,7 +1878,7 @@ The name of a Deployment object must be a valid
A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
-->
Deployment 对象的名称必须是合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
Deployment 还需要 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
<!--
@@ -1894,7 +1894,7 @@ The `.spec.template` and `.spec.selector` are the only required field of the `.s
The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
-->
`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。
`.spec.template` 是一个 [Pod 模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。
它和 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的语法规则完全相同。
只是这里它是嵌套的，因此不需要 `apiVersion` 或 `kind`。
@@ -1909,7 +1909,7 @@ labels and an appropriate restart policy. For labels, make sure not to overlap w
Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is
allowed, which is the default if not specified.
-->
只有 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
只有 [`.spec.template.spec.restartPolicy`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
等于 `Always` 才是被允许的，这也是在没有指定时的默认设置。
<!--
@@ -1936,7 +1936,7 @@ then applying that manifest overwrites the manual scaling that you previously di
If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (or any
similar API for horizontal scaling) is managing scaling for a Deployment, don't set `.spec.replicas`.
-->
如果一个 [HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
如果一个 [HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)
（或者其他执行水平扩缩操作的类似 API）在管理 Deployment 的扩缩，
则不要设置 `.spec.replicas`。
@@ -1960,7 +1960,7 @@ for the Pods targeted by this Deployment.
### 选择算符 {#selector}
`.spec.selector` 是指定本 Deployment 的 Pod
[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)的必需字段。
[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)的必需字段。
`.spec.selector` 必须匹配 `.spec.template.metadata.labels`，否则请求会被 API 拒绝。
@@ -2033,7 +2033,7 @@ replacement will be created immediately (even if the old Pod is still in a Termi
才会创建新版本的 Pod。如果你手动删除一个 Pod，其生命周期是由 ReplicaSet 来控制的，
后者会立即创建一个替换 Pod（即使旧的 Pod 仍然处于 Terminating 状态）。
如果你需要一种“最多 n 个”的 Pod 个数保证，你需要考虑使用
[StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)。
[StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/)。
{{< /note >}}
<!--
@@ -2138,7 +2138,7 @@ a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/
在没有任意容器崩溃情况下的最小就绪时间，
只有超出这个时间 Pod 才被视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。
要了解何时 Pod 被视为就绪，
可参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
可参考[容器探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
<!--
### Revision History Limit
@@ -2192,11 +2192,11 @@ Deployment 在创建时是默认不会处于暂停状态。
* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
you can use it to manage application availability during disruptions.
-->
* 了解 [Pod](/zh/docs/concepts/workloads/pods)。
* [使用 Deployment 运行一个无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。
* 了解 [Pod](/zh-cn/docs/concepts/workloads/pods)。
* [使用 Deployment 运行一个无状态应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)。
* `Deployment` 是 Kubernetes REST API 中的一个顶层资源。
阅读 {{< api-reference page="workload-resources/deployment-v1" >}}
对象定义，以了解 Deployment 的 API 细节。
* 阅读 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)
* 阅读 [PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)
了解如何使用它来在可能出现干扰的情况下管理应用的可用性。
content/zh-cn/docs/concepts/workloads/controllers/job.md
+29 -29
View File
@@ -193,7 +193,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d
## 编写 Job 规约 {#writing-a-job-spec}
与 Kubernetes 中其他资源的配置类似，Job 也需要 `apiVersion`、`kind` 和 `metadata` 字段。
Job 的名字必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
Job 的名字必须是合法的 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
Job 配置还需要一个 [`.spec` 节](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
@@ -213,14 +213,14 @@ Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-po
Job 的 `.spec` 中只有 `.spec.template` 是必需的字段。
字段 `.spec.template` 的值是一个 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)。
字段 `.spec.template` 的值是一个 [Pod 模版](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。
其定义规范与 {{< glossary_tooltip text="Pod" term_id="pod" >}}
完全相同，只是其中不再需要 `apiVersion` 或 `kind` 字段。
除了作为 Pod 所必需的字段之外，Job 中的 Pod 模版必需设置合适的标签
（参见 [Pod 选择算符](#pod-selector)）和合适的重启策略。
Job 中 Pod 的 [`RestartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
Job 中 Pod 的 [`RestartPolicy`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
只能设置为 `Never` 或 `OnFailure` 之一。
<!--
@@ -386,7 +386,7 @@ Jobs with _fixed completion count_ - that is, jobs that have non null
当每个索引都对应一个完成完成的 Pod 时，Job 被认为是已完成的。
关于如何使用这种模式的更多信息，可参阅
[用带索引的 Job 执行基于静态任务分配的并行处理](/zh/docs/tasks/job/indexed-parallel-processing-static/)。
[用带索引的 Job 执行基于静态任务分配的并行处理](/zh-cn/docs/tasks/job/indexed-parallel-processing-static/)。
需要注意的是，对同一索引值可能被启动的 Pod 不止一个，尽管这种情况很少发生。
这时，只有一个会被记入完成计数中。
@@ -410,7 +410,7 @@ Pod 则继续留在当前节点，但容器会被重新运行。
因此，你的程序需要能够处理在本地被重启的情况，或者要设置
`.spec.template.spec.restartPolicy = "Never"`。
关于 `restartPolicy` 的更多信息，可参阅
[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/#example-states)。
[Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#example-states)。
<!--
An entire Pod can also fail, for a number of reasons, such as when the pod is kicked off the node
@@ -574,7 +574,7 @@ Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job its
That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve.
-->
注意 Job 规约和 Job 中的
[Pod 模版规约](/zh/docs/concepts/workloads/pods/init-containers/#detailed-behavior)
[Pod 模版规约](/zh-cn/docs/concepts/workloads/pods/init-containers/#detailed-behavior)
都有 `activeDeadlineSeconds` 字段。
请确保你在合适的层次设置正确的字段。
@@ -599,7 +599,7 @@ cleaned up by CronJobs based on the specified capacity-based cleanup policy.
完成的 Job 通常不需要留存在系统中。在系统中一直保留它们会给 API
服务器带来额外的压力。
如果 Job 由某种更高级别的控制器来管理，例如
[CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs/)，
[CronJobs](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)，
则 Job 可以被 CronJob 基于特定的根据容量裁定的清理策略清理掉。
### 已完成 Job 的 TTL 机制 {#ttl-mechanisms-for-finished-jobs}
@@ -621,7 +621,7 @@ be honored.
For example:
-->
自动清理已完成 Job （状态为 `Complete` 或 `Failed`）的另一种方式是使用由
[TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)所提供
[TTL 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)所提供
的 TTL 机制。
通过设置 Job 的 `.spec.ttlSecondsAfterFinished` 字段，可以让该控制器清理掉
已结束的资源。
@@ -720,10 +720,10 @@ The pattern names are also links to examples and more detailed description.
| 模式 | 单个 Job 对象 | Pods 数少于工作条目数？ | 直接使用应用无需修改? |
| ----- |:-------------:|:-----------------------:|:---------------------:|
| [每工作条目一 Pod 的队列](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 有时 |
| [Pod 数量可变的队列](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | |
| [静态任务分派的带索引的 Job](/zh/docs/tasks/job/indexed-parallel-processing-static) | ✓ | | ✓ |
| [Job 模版扩展](/zh/docs/tasks/job/parallel-processing-expansion/) | | | ✓ |
| [每工作条目一 Pod 的队列](/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 有时 |
| [Pod 数量可变的队列](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | |
| [静态任务分派的带索引的 Job](/zh-cn/docs/tasks/job/indexed-parallel-processing-static) | ✓ | | ✓ |
| [Job 模版扩展](/zh-cn/docs/tasks/job/parallel-processing-expansion/) | | | ✓ |
<!--
When you specify completions with `.spec.completions`, each Pod created by the Job controller
@@ -746,10 +746,10 @@ Here, `W` is the number of work items.
| 模式 | `.spec.completions` | `.spec.parallelism` |
| ----- |:-------------------:|:--------------------:|
| [每工作条目一 Pod 的队列](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意值 |
| [Pod 个数可变的队列](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意值 |
| [静态任务分派的带索引的 Job](/zh/docs/tasks/job/indexed-parallel-processing-static) | W | | 任意值 |
| [Job 模版扩展](/zh/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 |
| [每工作条目一 Pod 的队列](/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意值 |
| [Pod 个数可变的队列](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意值 |
| [静态任务分派的带索引的 Job](/zh-cn/docs/tasks/job/indexed-parallel-processing-static) | W | | 任意值 |
| [Job 模版扩展](/zh-cn/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 |
<!--
## Advanced usage
@@ -912,8 +912,8 @@ on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/
It is enabled by default.
-->
{{< note >}}
为了使用此功能，你必须在 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)上启用
`JobMutableNodeSchedulingDirectives` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
为了使用此功能，你必须在 [API 服务器](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)上启用
`JobMutableNodeSchedulingDirectives` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
默认情况下启用。
{{< /note >}}
@@ -1084,10 +1084,10 @@ on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/
and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
It is enabled by default.
-->
要使用该行为，你必须为 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
和[控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
要使用该行为，你必须为 [API 服务器](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)
和[控制器管理器](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)
启用 `JobTrackingWithFinalizers`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
默认是启用的。
<!--
@@ -1175,11 +1175,11 @@ for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
-->
### 副本控制器 {#replication-controller}
Job 与[副本控制器](/zh/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。
Job 与[副本控制器](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。
副本控制器管理的是那些不希望被终止的 Pod （例如，Web 服务器），
Job 管理的是那些希望被终止的 Pod（例如，批处理作业）。
正如在 [Pod 生命期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 中讨论的，
正如在 [Pod 生命期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 中讨论的，
`Job` 仅适合于 `restartPolicy` 设置为 `OnFailure` 或 `Never` 的 Pod。
注意：如果 `restartPolicy` 未设置，其默认值是 `Always`。
@@ -1230,13 +1230,13 @@ object, but maintains complete control over what Pods are created and how work i
can use to define a series of Jobs that will run based on a schedule, similar to
the UNIX tool `cron`.
-->
* 了解 [Pods](/zh/docs/concepts/workloads/pods)。
* 了解 [Pods](/zh-cn/docs/concepts/workloads/pods)。
* 了解运行 Job 的不同的方式：
* [使用工作队列进行粗粒度并行处理](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/)
* [使用工作队列进行精细的并行处理](/zh/docs/tasks/job/fine-parallel-processing-work-queue/)
* [使用索引作业完成静态工作分配下的并行处理](/zh/docs/tasks/job/indexed-parallel-processing-static/)（Beta 阶段）
* 基于一个模板运行多个 Job：[使用展开的方式进行并行处理](/zh/docs/tasks/job/parallel-processing-expansion/)
* [使用工作队列进行粗粒度并行处理](/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue/)
* [使用工作队列进行精细的并行处理](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/)
* [使用索引作业完成静态工作分配下的并行处理](/zh-cn/docs/tasks/job/indexed-parallel-processing-static/)（Beta 阶段）
* 基于一个模板运行多个 Job：[使用展开的方式进行并行处理](/zh-cn/docs/tasks/job/parallel-processing-expansion/)
* 跟随[自动清理完成的 Job](#clean-up-finished-jobs-automatically) 文中的链接，了解你的集群如何清理完成和失败的任务。
* `Job` 是 Kubernetes REST API 的一部分。阅读 {{< api-reference page="workload-resources/job-v1" >}}
对象定义理解关于该资源的 API。
* 阅读 [`CronJob`](/zh/docs/concepts/workloads/controllers/cron-jobs/)，它允许你定义一系列定期运行的 Job，类似于 UNIX 工具 `cron`。
* 阅读 [`CronJob`](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)，它允许你定义一系列定期运行的 Job，类似于 UNIX 工具 `cron`。
content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md
+19 -19
View File
@@ -30,8 +30,8 @@ weight: 90
A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
-->
{{< note >}}
现在推荐使用配置 [`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 的
[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。
现在推荐使用配置 [`ReplicaSet`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 的
[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。
{{< /note >}}
<!--
@@ -196,7 +196,7 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun
与所有其它 Kubernetes 配置一样，ReplicationController 需要 `apiVersion`、
`kind` 和 `metadata` 字段。
有关使用配置文件的常规信息，参考
[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)。
[对象管理](/zh-cn/docs/concepts/overview/working-with-objects/object-management/)。
ReplicationController 也需要一个 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
@@ -211,8 +211,8 @@ The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overv
`.spec.template` 是 `.spec` 的唯一必需字段。
`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。
它的模式与 [Pod](/zh/docs/concepts/workloads/pods/) 完全相同，只是它是嵌套的，没有 `apiVersion` 或 `kind` 属性。
`.spec.template` 是一个 [Pod 模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。
它的模式与 [Pod](/zh-cn/docs/concepts/workloads/pods/) 完全相同，只是它是嵌套的，没有 `apiVersion` 或 `kind` 属性。
<!--
In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate
@@ -226,10 +226,10 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.
除了 Pod 所需的字段外，ReplicationController 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。
对于标签，请确保不与其他控制器重叠。参考 [Pod 选择算符](#pod-selector)。
只允许 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。
只允许 [`.spec.template.spec.restartPolicy`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。
对于本地容器重启，ReplicationController 委托给节点上的代理，
例如 [Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker。
例如 [Kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 或 Docker。
<!--
### Labels on the ReplicationController
@@ -256,7 +256,7 @@ deleted. This allows the ReplicationController to be replaced without affecting
-->
### Pod 选择算符 {#pod-selector}
`.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
`.spec.selector` 字段是一个[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
ReplicationController 管理标签与选择算符匹配的所有 Pod。
它不区分它创建或删除的 Pod 和其他人或进程创建或删除的 Pod。
这允许在不影响正在运行的 Pod 的情况下替换 ReplicationController。
@@ -323,7 +323,7 @@ When using the REST API or [client library](/docs/reference/using-api/client-lib
kubectl 将 ReplicationController 缩放为 0 并等待以便在删除 ReplicationController 本身之前删除每个 Pod。
如果这个 kubectl 命令被中断，可以重新启动它。
当使用 REST API 或[客户端库](/zh/docs/reference/using-api/client-libraries)时，你需要明确地执行这些步骤（缩放副本为 0、
当使用 REST API 或[客户端库](/zh-cn/docs/reference/using-api/client-libraries)时，你需要明确地执行这些步骤（缩放副本为 0、
等待 Pod 删除，之后删除 ReplicationController 资源）。
<!--
@@ -341,7 +341,7 @@ When using the REST API or [client library](/docs/reference/using-api/client-lib
使用 kubectl，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=orphan` 选项。
当使用 REST API 或客户端库(/zh/docs/reference/using-api/client-libraries)时，只需删除 ReplicationController 对象。
当使用 REST API 或客户端库(/zh-cn/docs/reference/using-api/client-libraries)时，只需删除 ReplicationController 对象。
<!--
Once the original is deleted, you can create a new ReplicationController to replace it. As long
@@ -416,7 +416,7 @@ Rolling update is implemented in the client tool
这两个 ReplicationController 将需要创建至少具有一个不同标签的 Pod，比如 Pod 主要容器的镜像标签，因为通常是镜像更新触发滚动更新。
滚动更新是在客户端工具 [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)
中实现的。访问 [`kubectl rolling-update` 任务](/zh/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。
中实现的。访问 [`kubectl rolling-update` 任务](/zh-cn/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。
<!--
### Multiple release tracks
@@ -534,9 +534,9 @@ Note that we recommend using Deployments instead of directly using Replica Sets,
### ReplicaSet
[`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 是下一代 ReplicationController，
支持新的[基于集合的标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)。
它主要被 [`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/)
[`ReplicaSet`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 是下一代 ReplicationController，
支持新的[基于集合的标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)。
它主要被 [`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/)
用来作为一种编排 Pod 创建、删除及更新的机制。
请注意，我们推荐使用 Deployment 而不是直接使用 ReplicaSet，除非
你需要自定义更新编排或根本不需要更新。
@@ -550,7 +550,7 @@ because they are declarative, server-side, and have additional features.
-->
### Deployment （推荐）
[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。
[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。
如果你想要这种滚动更新功能，那么推荐使用 Deployment，因为它们是声明式的、服务端的，并且具有其它特性。
<!--
@@ -575,7 +575,7 @@ Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead o
### Job
对于预期会自行终止的 Pod (即批处理任务)，使用
[`Job`](/zh/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
[`Job`](/zh-cn/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
<!--
### DaemonSet
@@ -588,7 +588,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
### DaemonSet
对于提供机器级功能（例如机器监控或机器日志记录）的 Pod，
使用 [`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) 而不是
使用 [`DaemonSet`](/zh-cn/docs/concepts/workloads/controllers/daemonset/) 而不是
ReplicationController。
这些 Pod 的生命期与机器的生命期绑定：它们需要在其他 Pod 启动之前在机器上运行，
并且在机器准备重新启动或者关闭时安全地终止。
@@ -605,8 +605,8 @@ ReplicationController。
-->
## {{% heading "whatsnext" %}}
- 了解 [Pods](/zh/docs/concepts/workloads/pods)。
- 了解 [Depolyment](/zh/docs/concepts/workloads/controllers/deployment/)，ReplicationController 的替代品。
- 了解 [Pods](/zh-cn/docs/concepts/workloads/pods)。
- 了解 [Depolyment](/zh-cn/docs/concepts/workloads/controllers/deployment/)，ReplicationController 的替代品。
- `ReplicationController` 是 Kubernetes REST API 的一部分，阅读 {{< api-reference page="workload-resources/replication-controller-v1" >}}
对象定义以了解 replication controllers 的 API。
content/zh-cn/docs/concepts/workloads/controllers/statefulset.md
+25 -25
View File
@@ -53,8 +53,8 @@ that provides a set of stateless replicas.
在上面描述中，“稳定的”意味着 Pod 调度或重调度的整个过程是有持久性的。
如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用
由一组无状态的副本控制器提供的工作负载来部署应用程序，比如
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 或者
[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)
[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 或者
[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/)
可能更适用于你的无状态应用部署需要。
<!--
@@ -77,7 +77,7 @@ that provides a set of stateless replicas.
基于所请求的 `storage class` 来提供，或者由管理员预先提供。
* 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。
这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
* StatefulSet 当前需要[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
* StatefulSet 当前需要[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
来负责 Pod 的网络标识。你需要负责创建此服务。
* 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。
为了实现 StatefulSet 中的 Pod 可以有序地且体面地终止，可以在删除之前将 StatefulSet
@@ -162,9 +162,9 @@ The name of a StatefulSet object must be a valid
* 名为 `nginx` 的 Headless Service 用来控制网络域名。
* 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
* `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
[PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
[PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
StatefulSet 的命名需要遵循[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)规范。
StatefulSet 的命名需要遵循[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)规范。
<!--
### Pod Selector
@@ -187,7 +187,7 @@ You can set the `.spec.volumeClaimTemplates` which can provide stable storage u
你可以设置 `.spec.volumeClaimTemplates`，
它可以使用 PersistentVolume 制备程序所准备的
[PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
[PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
<!-- ### Minimum ready seconds -->
### 最短就绪秒数 {#minimum-ready-seconds}
@@ -207,7 +207,7 @@ available as soon as it is ready). To learn more about when a Pod is considered
请通过取消设置 StatefulSetMinReadySeconds 标志来选择退出。
该字段默认为 0（Pod 准备就绪后将被视为可用）。
要了解有关何时认为 Pod 准备就绪的更多信息，
请参阅[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
请参阅[容器探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
<!--
## Pod Identity
@@ -252,7 +252,7 @@ by the `serviceName` field on the StatefulSet.
StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。
组合主机名的格式为`$(StatefulSet 名称)-$(序号)`。
上例将会创建三个名称分别为 `web-0、web-1、web-2` 的 Pod。
StatefulSet 可以使用 [无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
StatefulSet 可以使用 [无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
控制它的 Pod 的网络域。管理域的这个服务的格式为：
`$(服务名称).$(命名空间).svc.cluster.local`，其中 `cluster.local` 是集群域。
一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为：
@@ -286,7 +286,7 @@ responsible for the network identity of the pods.
- 直接查询 Kubernetes API（比如，利用 watch 机制）而不是依赖于 DNS 查询
- 缩短 Kubernetes DNS 驱动的缓存时长（通常这意味着修改 CoreDNS 的 ConfigMap，目前缓存时长为 30 秒）
正如[限制](#limitations)中所述，你需要负责创建[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
正如[限制](#limitations)中所述，你需要负责创建[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
以便为 Pod 提供网络标识。
<!--
@@ -314,7 +314,7 @@ Cluster Domain will be set to `cluster.local` unless
[otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
-->
{{< note >}}
集群域会被设置为 `cluster.local`，除非有[其他配置](/zh/docs/concepts/services-networking/dns-pod-service/)。
集群域会被设置为 `cluster.local`，除非有[其他配置](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。
{{< /note >}}
<!--
@@ -371,7 +371,7 @@ The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of
-->
StatefulSet 不应将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0。
这种做法是不安全的，要强烈阻止。更多的解释请参考
[强制删除 StatefulSet Pod](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/)。
[强制删除 StatefulSet Pod](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/)。
<!--
When the nginx example above is created, three Pods will be deployed in the order
@@ -382,7 +382,7 @@ web-2 is launched, web-2 will not be launched until web-0 is successfully relaun
becomes Running and Ready.
-->
在上面的 nginx 示例被创建后，会按照 web-0、web-1、web-2 的顺序部署三个 Pod。
在 web-0 进入 [Running 和 Ready](/zh/docs/concepts/workloads/pods/pod-lifecycle/)
在 web-0 进入 [Running 和 Ready](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)
状态前不会部署 web-1。在 web-1 进入 Running 和 Ready 状态前不会部署 web-2。
如果 web-1 已经处于 Running 和 Ready 状态，而 web-2 尚未部署，在此期间发生了
web-0 运行失败，那么 web-2 将不会被部署，要等到 web-0 部署完成并进入 Running 和
@@ -553,7 +553,7 @@ enabled.
-->
{{< note >}}
`maxUnavailable` 字段处于 Alpha 阶段，仅当 API 服务器启用了 `MaxUnavailableStatefulSet`
[特性门控](/zh/docs/reference/commmand-line-tools-reference/feature-gates/)时才起作用。
[特性门控](/zh-cn/docs/reference/commmand-line-tools-reference/feature-gates/)时才起作用。
{{< /note >}}
<!--
@@ -608,7 +608,7 @@ StatefulSet:
在 StatefulSet 的生命周期中，可选字段
`.spec.persistentVolumeClaimRetentionPolicy` 控制是否删除以及如何删除 PVC。
使用该字段，你必须启用 `StatefulSetAutoDeletePVC`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
启用后，你可以为每个 StatefulSet 配置两个策略：
<!--
@@ -692,7 +692,7 @@ policy to `Delete`, an owner reference to the StatefulSet instance is placed on
associated with that StatefulSet.
-->
StatefulSet {{<glossary_tooltip text="控制器" term_id="controller">}}为其 PVC 添加了
[属主引用](/zh/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)，
[属主引用](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)，
这些 PVC 在 Pod 终止后被{{<glossary_tooltip text="垃圾回收器" term_id="garbage-collection">}}删除。
这使 Pod 能够在删除 PVC 之前（以及在删除后备 PV 和卷之前，取决于保留策略）干净地卸载所有卷。
当你设置 `whenDeleted` 删除策略，对 StatefulSet 实例的属主引用放置在与该 StatefulSet 关联的所有 PVC 上。
@@ -756,7 +756,7 @@ Statefulset, don't set `.spec.replicas`. Instead, allow the Kubernetes
{{<glossary_tooltip text="control plane" term_id="control-plane" >}} to manage
the `.spec.replicas` field automatically.
-->
如果 [HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
如果 [HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)
（或任何类似的水平缩放 API）正在管理 Statefulset 的缩放，
请不要设置 `.spec.replicas`。
相反，允许 Kubernetes 控制平面自动管理 `.spec.replicas` 字段。
@@ -779,15 +779,15 @@ the `.spec.replicas` field automatically.
* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
you can use it to manage application availability during disruptions.
-->
* 了解 [Pod](/zh/docs/concepts/workloads/pods)。
* 了解 [Pod](/zh-cn/docs/concepts/workloads/pods)。
* 了解如何使用 StatefulSet
* 跟随示例[部署有状态应用](/zh/docs/tutorials/stateful-application/basic-stateful-set/)。
* 跟随示例[使用 StatefulSet 部署 Cassandra](/zh/docs/tutorials/stateful-application/cassandra/)。
* 跟随示例[运行多副本的有状态应用程序](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。
* 了解如何[扩缩 StatefulSet](/zh/docs/tasks/run-application/scale-stateful-set/)。
* 了解[删除 StatefulSet](/zh/docs/tasks/run-application/delete-stateful-set/)涉及到的操作。
* 了解如何[配置 Pod 以使用卷进行存储](/zh/docs/tasks/configure-pod-container/configure-volume-storage/)。
* 了解如何[配置 Pod 以使用 PersistentVolume 作为存储](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。
* 跟随示例[部署有状态应用](/zh-cn/docs/tutorials/stateful-application/basic-stateful-set/)。
* 跟随示例[使用 StatefulSet 部署 Cassandra](/zh-cn/docs/tutorials/stateful-application/cassandra/)。
* 跟随示例[运行多副本的有状态应用程序](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/)。
* 了解如何[扩缩 StatefulSet](/zh-cn/docs/tasks/run-application/scale-stateful-set/)。
* 了解[删除 StatefulSet](/zh-cn/docs/tasks/run-application/delete-stateful-set/)涉及到的操作。
* 了解如何[配置 Pod 以使用卷进行存储](/zh-cn/docs/tasks/configure-pod-container/configure-volume-storage/)。
* 了解如何[配置 Pod 以使用 PersistentVolume 作为存储](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。
* `StatefulSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="workload-resources/stateful-set-v1" >}}
对象定义理解关于该资源的 API。
* 阅读 [Pod 干扰预算（Disruption Budget）](/zh/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。
* 阅读 [Pod 干扰预算（Disruption Budget）](/zh-cn/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。
content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md
+4 -4
View File
@@ -37,7 +37,7 @@ up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
TTL-after-finished 控制器只支持 Job。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished`
字段来自动清理已结束的作业（`Complete` 或 `Failed`），如
[示例](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
[示例](/zh-cn/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
所示。
<!--
@@ -72,9 +72,9 @@ The TTL seconds can be set at any time. Here are some examples for setting the
-->
* 在作业清单（manifest）中指定此字段，以便 Job 在完成后的某个时间被自动清除。
* 将此字段设置为现有的、已完成的作业，以采用此新功能。
* 在创建作业时使用 [mutating admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
* 在创建作业时使用 [mutating admission webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
动态设置该字段。集群管理员可以使用它对完成的作业强制执行 TTL 策略。
* 使用 [mutating admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
* 使用 [mutating admission webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
在作业完成后动态设置该字段，并根据作业状态、标签等选择不同的 TTL 值。
<!--
@@ -123,6 +123,6 @@ very small. Please be aware of this risk when setting a non-zero TTL.
* [Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
* [Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md)
-->
* [自动清理 Job](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
* [自动清理 Job](/zh-cn/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
* [设计文档](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md)
content/zh-cn/docs/concepts/workloads/pods/_index.md
+16 -16
View File
@@ -52,8 +52,8 @@ during Pod startup. You can also inject
for debugging if your cluster offers this.
-->
除了应用容器，Pod 还可以包含在 Pod 启动期间运行的
[Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。
你也可以在集群中支持[临时性容器](/zh/docs/concepts/workloads/pods/ephemeral-containers/)
[Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)。
你也可以在集群中支持[临时性容器](/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/)
的情况下，为调试的目的注入临时性容器。
<!-- body -->
@@ -271,7 +271,7 @@ When you create the manifest for a Pod object, make sure the name specified is a
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-->
当你为 Pod 对象创建清单时，要确保所指定的 Pod 名称是合法的
[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
<!--
### Pods and controllers
@@ -314,9 +314,9 @@ PodTemplates are specifications for creating Pods, and are included in workload
_Pod 模板（Pod Template）_ 来替你创建 Pod 并管理它们。
Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
[Job](/zh/docs/concepts/workloads/controllers/job/) 和
[DaemonSets](/zh/docs/concepts/workloads/controllers/daemonset/) 等。
[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)、
[Job](/zh-cn/docs/concepts/workloads/controllers/job/) 和
[DaemonSets](/zh-cn/docs/concepts/workloads/controllers/daemonset/) 等。
<!--
Each controller for a workload resource uses the `PodTemplate` inside the workload
@@ -462,7 +462,7 @@ Kubernetes implements shared storage and makes it available to Pods.
Pod 中的所有容器都可以访问该共享卷，从而允许这些容器共享数据。
卷还允许 Pod 中的持久数据保留下来，即使其中的容器需要重新启动。
有关 Kubernetes 如何在 Pod 中实现共享存储并将其提供给 Pod 的更多信息，
请参考[卷](/zh/docs/concepts/storage/)。
请参考[卷](/zh-cn/docs/concepts/storage/)。
<!--
### Pod networking
@@ -503,7 +503,7 @@ Containers within the Pod see the system hostname as being the same as the confi
section.
-->
Pod 中的容器所看到的系统主机名与为 Pod 配置的 `name` 属性值相同。
[网络](/zh/docs/concepts/cluster-administration/networking/)部分提供了更多有关此内容的信息。
[网络](/zh-cn/docs/concepts/cluster-administration/networking/)部分提供了更多有关此内容的信息。
<!--
## Privileged mode for containers
@@ -515,14 +515,14 @@ If your cluster has the `WindowsHostProcessContainers` feature enabled, you can
## 容器的特权模式 {#privileged-mode-for-containers}
在 Linux 中，Pod 中的任何容器都可以使用容器规约中的
[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的
[安全性上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/)中的
`privileged`（Linux）参数启用特权模式。
这对于想要使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备）
的容器很有用。
如果你的集群启用了 `WindowsHostProcessContainers` 特性，你可以使用 Pod 规约中安全上下文的
`windowsOptions.hostProcess` 参数来创建
[Windows HostProcess Pod](/zh/docs/tasks/configure-pod-container/create-hostprocess-pod/)。
[Windows HostProcess Pod](/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod/)。
这些 Pod 中的所有容器都必须以 Windows HostProcess 容器方式运行。
HostProcess Pod 可以直接运行在主机上，它也能像 Linux 特权容器一样，用于执行管理任务。
@@ -564,7 +564,7 @@ but cannot be controlled from there.
静态 Pod 通常绑定到某个节点上的 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}。
其主要用途是运行自托管的控制面。
在自托管场景中，使用 `kubelet` 来管理各个独立的
[控制面组件](/zh/docs/concepts/overview/components/#control-plane-components)。
[控制面组件](/zh-cn/docs/concepts/overview/components/#control-plane-components)。
`kubelet` 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个
{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
@@ -601,7 +601,7 @@ _Probe_ 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubele
- `TCPSocketAction`（由 kubelet 直接检测）
- `HTTPGetAction`（由 kubelet 直接检测）
你可以参阅 Pod 的生命周期文档中的[探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)部分。
你可以参阅 Pod 的生命周期文档中的[探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)部分。
## {{% heading "whatsnext" %}}
@@ -616,11 +616,11 @@ _Probe_ 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubele
object definition describes the object in detail.
* [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) explains common layouts for Pods with more than one container.
-->
* 了解 [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)
* 了解 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)，以及如何使用它
* 了解 [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)
* 了解 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)，以及如何使用它
来配置不同的 Pod 使用不同的容器运行时配置
* 了解 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* 了解 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)，以及你
* 了解 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* 了解 [PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)，以及你
如何可以利用它在出现干扰因素时管理应用的可用性。
* Pod 在 Kubernetes REST API 中是一个顶层资源。
{{< api-reference page="workload-resources/pod-v1" >}}
content/zh-cn/docs/concepts/workloads/pods/disruptions.md
+13 -13
View File
@@ -60,7 +60,7 @@ an application. Examples are:
- 云提供商或虚拟机管理程序中的故障导致的虚拟机消失
- 内核错误
- 节点由于集群网络隔离从集群中消失
- 由于节点[资源不足](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)导致 pod 被驱逐。
- 由于节点[资源不足](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)导致 pod 被驱逐。
<!--
Except for the out-of-resources condition, all these conditions
@@ -98,7 +98,7 @@ Cluster Administrator actions include:
-->
集群管理员操作包括：
- [排空（drain）节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)进行修复或升级。
- [排空（drain）节点](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)进行修复或升级。
- 从集群中排空节点以缩小集群（了解[集群自动扩缩](https://github.com/kubernetes/autoscaler/#readme)）。
- 从节点中移除一个 Pod，以允许其他 Pod 使用该节点。
@@ -145,13 +145,13 @@ and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/)
or across zones (if using a
[multi-zone cluster](/docs/setup/multiple-zones).)
-->
- 确保 Pod 在请求中给出[所需资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)。
- 确保 Pod 在请求中给出[所需资源](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/)。
- 如果需要更高的可用性，请复制应用程序。
（了解有关运行多副本的[无状态](/zh/docs/tasks/run-application/run-stateless-application-deployment/)
和[有状态](/zh/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。）
（了解有关运行多副本的[无状态](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)
和[有状态](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。）
- 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用
[反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
或跨区域（如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
[反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
或跨区域（如果使用[多区域集群](/zh-cn/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
<!--
The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are
@@ -170,7 +170,7 @@ in your pod spec can also cause voluntary (and involuntary) disruptions.
实现可能导致碎片整理和紧缩节点的自愿干扰。集群
管理员或托管提供商应该已经记录了各级别的自愿干扰（如果有的话）。
有些配置选项，例如在 pod spec 中
[使用 PriorityClasses](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
[使用 PriorityClasses](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
也会产生自愿（和非自愿）的干扰。
<!--
@@ -213,7 +213,7 @@ instead of directly deleting pods or deployments. Examples are the `kubectl dra
and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
-->
集群管理员和托管提供商应该使用遵循 PodDisruptionBudgets 的接口
（通过调用[Eviction API](/zh/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
（通过调用[Eviction API](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
而不是直接删除 Pod 或 Deployment。
<!--
@@ -277,7 +277,7 @@ hornoring the
`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
-->
当使用驱逐 API 驱逐 Pod 时，Pod 会被体面地
[终止](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会
[终止](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会
参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
中的 `terminationGracePeriodSeconds` 配置值。
@@ -506,7 +506,7 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
* Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
including steps to maintain its availability during the rollout.
-->
* 参考[配置 Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。
* 进一步了解[排空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)的信息。
* 了解[更新 Deployment](/zh/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
* 参考[配置 Pod 干扰预算](/zh-cn/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。
* 进一步了解[排空节点](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)的信息。
* 了解[更新 Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
的过程，包括如何在其进程中维持应用的可用性
content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md
+2 -2
View File
@@ -124,11 +124,11 @@ sharing](/docs/tasks/configure-pod-container/share-process-namespace/) so
you can view processes in other containers.
-->
使用临时容器时，启用
[进程名字空间共享](/zh/docs/tasks/configure-pod-container/share-process-namespace/)
[进程名字空间共享](/zh-cn/docs/tasks/configure-pod-container/share-process-namespace/)
很有帮助，可以查看其他容器中的进程。
{{% heading "whatsnext" %}}
<!--
* Learn how to [debug pods using ephemeral containers](/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container).
-->
* 了解如何[使用临时调试容器来进行调试](/zh/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container)
* 了解如何[使用临时调试容器来进行调试](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container)
content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md
+14 -14
View File
@@ -45,7 +45,7 @@ or is [terminated](#pod-termination).
Pod 对象的状态包含了一组 [Pod 状况（Conditions）](#pod-conditions)。
如果应用需要的话，你也可以向其中注入[自定义的就绪性信息](#pod-readiness-gate)。
Pod 在其生命周期中只会被[调度](/zh/docs/concepts/scheduling-eviction/)一次。
Pod 在其生命周期中只会被[调度](/zh-cn/docs/concepts/scheduling-eviction/)一次。
一旦 Pod 被调度（分派）到某个节点，Pod 会一直在该节点运行，直到 Pod 停止或者
被[终止](#pod-termination)。
@@ -66,7 +66,7 @@ are [scheduled for deletion](#pod-garbage-collection) after a timeout period.
和一个个独立的应用容器一样，Pod 也被认为是相对临时性（而不是长期存在）的实体。
Pod 会被创建、赋予一个唯一的
ID（[UID](/zh/docs/concepts/overview/working-with-objects/names/#uids)），
ID（[UID](/zh-cn/docs/concepts/overview/working-with-objects/names/#uids)），
并被调度到节点，并在终止（根据重启策略）或删除之前一直运行在该节点。
如果一个{{< glossary_tooltip text="节点" term_id="node" >}}死掉了，调度到该节点
@@ -182,7 +182,7 @@ There are three possible container states: `Waiting`, `Running`, and `Terminated
## 容器状态 {#container-states}
Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的[阶段](#pod-phase)一样。
你可以使用[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)
你可以使用[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)
来在容器生命周期中的特定时间点触发事件。
一旦{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}将 Pod
@@ -306,7 +306,7 @@ Pod 有一个 PodStatus 对象，其中包含一个
-->
* `PodScheduled`：Pod 已经被调度到某节点；
* `ContainersReady`：Pod 中所有容器都已就绪；
* `Initialized`：所有的 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)
* `Initialized`：所有的 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)
都已成功完成；
* `Ready`：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。
@@ -383,7 +383,7 @@ status:
The Pod conditions you add must have names that meet the Kubernetes [label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
-->
你所添加的 Pod 状况名称必须满足 Kubernetes
[标签键名格式](/zh/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
[标签键名格式](/zh-cn/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
<!--
### Status for Pod readiness {#pod-readiness-status}
@@ -401,7 +401,7 @@ write code that sets custom Pod conditions for Pod readiness.
如果需要设置 Pod 的 `status.conditions`，应用或者
{{< glossary_tooltip term_id="operator-pattern" text="Operators">}}
需要使用 `PATCH` 操作。
你可以使用 [Kubernetes 客户端库](/zh/docs/reference/using-api/client-libraries/)
你可以使用 [Kubernetes 客户端库](/zh-cn/docs/reference/using-api/client-libraries/)
之一来编写代码，针对 Pod 就绪态设置定制的 Pod 状况。
<!--
@@ -434,7 +434,7 @@ a network request.
-->
## 容器探针 {#container-probes}
probe 是由 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
probe 是由 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。
<!--
@@ -484,7 +484,7 @@ Each probe must define exactly one of these four mechanisms:
[gRPC健康检查](https://grpc.io/grpc/core/md_doc_health-checking.html)。
如果响应的状态是 "SERVING"，则认为诊断成功。
gRPC 探针是一个 alpha 特性，只有在你启用了
"GRPCContainerProbe" [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gate/)时才能使用。
"GRPCContainerProbe" [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gate/)时才能使用。
`httpGet`
: 对容器的 IP 地址上指定端口和路径执行 HTTP `GET` 请求。如果响应的状态码大于等于 200
@@ -573,7 +573,7 @@ For more information about how to set up a liveness, readiness, or startup probe
see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
-->
如欲了解如何设置存活态、就绪态和启动探针的进一步细节，可以参阅
[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
[配置存活态、就绪态和启动探针](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
<!--
#### When should you use a liveness probe?
@@ -770,7 +770,7 @@ An example flow:
order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize.
-->
1. 如果 Pod 中的容器之一定义了 `preStop`
[回调](/zh/docs/concepts/containers/container-lifecycle-hooks)，
[回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks)，
`kubelet` 开始在容器内运行该回调逻辑。如果超出体面终止限期时，`preStop` 回调逻辑
仍在运行，`kubelet` 会请求给予该 Pod 的宽限期一次性增加 2 秒钟。
@@ -874,7 +874,7 @@ API 服务器直接删除 Pod 对象，这样新的与之同名的 Pod 即可以
在节点侧，被设置为立即终止的 Pod 仍然会在被强行杀死之前获得一点点的宽限时间。
如果你需要强制删除 StatefulSet 的 Pod，请参阅
[从 StatefulSet 中删除 Pod](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/)
[从 StatefulSet 中删除 Pod](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/)
的任务文档。
<!--
@@ -915,9 +915,9 @@ This avoids a resource leak as Pods are created and terminated over time.
the API reference documentation covering
[`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod.
-->
* 动手实践[为容器生命周期时间关联处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
* 动手实践[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。
* 动手实践[为容器生命周期时间关联处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
* 动手实践[配置存活态、就绪态和启动探针](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
* 进一步了解[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)。
* 关于 API 中定义的有关 Pod 和容器状态的详细规范信息，
可参阅 API 参考文档中 Pod 的 [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) 字段。
content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+5 -5
View File
@@ -76,7 +76,7 @@ graph TB
<!--
Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/labels-annotations-taints/) that are created and populated automatically on most clusters.
-->
你可以复用在大多数集群上自动创建和填充的[常用标签](/zh/docs/reference/labels-annotations-taints/)，
你可以复用在大多数集群上自动创建和填充的[常用标签](/zh-cn/docs/reference/labels-annotations-taints/)，
而不是手动添加标签。
<!--
@@ -166,7 +166,7 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s
in order to use it.
-->
`minDomains` 字段是在 1.24 版本中新增的 alpha 字段。你必须启用
`MinDomainsInPodToplogySpread` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)才能使用它。
`MinDomainsInPodToplogySpread` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)才能使用它。
{{< /note >}}
<!--
@@ -187,7 +187,7 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s
- **labelSelector** 用于查找匹配的 Pod。匹配此标签的 Pod 将被统计，
以确定相应拓扑域中 Pod 的数量。
有关详细信息，请参考[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
有关详细信息，请参考[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
<!--
When a Pod defines more than one `topologySpreadConstraint`, those constraints are ANDed: The kube-scheduler looks for a node for the incoming Pod that satisfies all the constraints.
@@ -524,7 +524,7 @@ replication controllers, replica sets or stateful sets that the Pod belongs to.
An example configuration might look like follows:
-->
你可以在 [调度方案（Scheduling Profile）](/zh/docs/reference/scheduling/config/#profiles)
你可以在 [调度方案（Scheduling Profile）](/zh-cn/docs/reference/scheduling/config/#profiles)
中将默认约束作为 `PodTopologySpread` 插件参数的一部分来设置。
约束的设置采用[如前所述的 API](#api)，只是 `labelSelector` 必须为空。
选择算符是根据 Pod 所属的服务、副本控制器、ReplicaSet 或 StatefulSet 来设置的。
@@ -553,7 +553,7 @@ profiles:
is disabled by default. It's recommended to use `PodTopologySpread` to achieve similar
behavior.
-->
[`SelectorSpread` 插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)默认是被禁用的。
[`SelectorSpread` 插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)默认是被禁用的。
建议使用 `PodTopologySpread` 来实现类似的行为。
{{< /note >}}