diff --git a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md
index 44be9b9a68..265a1fa3cb 100644
--- a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md
@@ -19,6 +19,8 @@ A _CronJob_ creates {{< glossary_tooltip term_id="job" text="Jobs" >}} on a repe
 
 One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
 on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
+
+In addition, the CronJob schedule supports timezone handling, you can specify the timezone by adding "CRON_TZ=<time zone>" at the beginning of the CronJob schedule, and it is recommended to always set `CRON_TZ`.
 -->
 _CronJob_ 创建基于时隔重复调度的 {{< glossary_tooltip term_id="job" text="Jobs" >}}。
 
@@ -26,6 +28,8 @@ _CronJob_ 创建基于时隔重复调度的 {{< glossary_tooltip term_id="job" t
 它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写，
 并周期性地在给定的调度时间执行 Job。
 
+另外，CronJob 调度支持时区处理，你可以通过在 CronJob schedule 字段的开头添加 "CRON_TZ=<time zone>" 指定时区，且建议始终设置 `CRON_TZ`。
+
 <!--
 All **CronJob** `schedule:` times are based on the timezone of the
 
@@ -61,15 +65,16 @@ maximum length of a Job name is no more than 63 characters.
 <!--
 ## CronJob
 
-CronJobs are useful for creating periodic and recurring tasks, like running backups or
-sending emails. CronJobs can also schedule individual tasks for a specific time, such as
-scheduling a Job for when your cluster is likely to be idle.
+CronJobs are meant for performing regular scheduled actions such as backups,
+report generation, and so on. Each of those tasks should be configured to recur
+indefinitely (for example: once a day / week / month); you can define the point
+in time within that interval when the job should start.
 -->
 ## CronJob
 
-CronJobs 对于创建周期性的、反复重复的任务很有用，例如执行数据备份或者发送邮件。
-CronJobs 也可以用来计划在指定时间来执行的独立任务，例如计划当集群看起来很空闲时
-执行某个 Job。
+CronJob 用于执行周期性的动作，例如备份、报告生成等。
+这些任务中的每一个都应该配置为周期性重复的（例如：每天/每周/每月一次）；
+你可以定义任务开始执行的时间间隔。
 
 <!--
 ### Example
@@ -90,6 +95,19 @@ This example CronJob manifest prints the current time and a hello message every
 -->
 ### Cron 时间表语法
 
+```
+#      ┌────────────────── 时区 (可选)
+#      |      ┌───────────── 分钟 (0 - 59)
+#      |      │ ┌───────────── 小时 (0 - 23)
+#      |      │ │ ┌───────────── 月的某天 (1 - 31)
+#      |      │ │ │ ┌───────────── month (1 - 12)
+#      |      │ │ │ │ ┌───────────── 周的某天 (0 - 6)（周日到周一；在某些系统上，7 也是星期日）
+#      |      │ │ │ │ │                                
+#      |      │ │ │ │ │
+#      |      │ │ │ │ │
+# CRON_TZ=UTC * * * * *
+```
+
 ```
 # ┌───────────── 分钟 (0 - 59)
 # │ ┌───────────── 小时 (0 - 23)
@@ -120,11 +138,11 @@ This example CronJob manifest prints the current time and a hello message every
 | @hourly                   | 每小时的开始一次              | 0 * * * *      |
 
 <!--  
-For example, the line below states that the task must be started every Friday at midnight, as well as on the 13th of each month at midnight:
+For example, the line below states that the task must be started every Friday at midnight, as well as on the 13th of each month at midnight(in UTC):
 -->
-例如，下面这行指出必须在每个星期五的午夜以及每个月 13 号的午夜开始任务：
+例如，下面这行指出必须在每个星期五的午夜以及每个月 13 号的午夜开始任务（UTC 时间）：
 
-`0 0 13 * 5`
+`CRON_TZ=UTC 0 0 13 * 5`
 
 <!--  
 To generate CronJob schedule expressions, you can also use web tools like [crontab.guru](https://crontab.guru/).
@@ -237,14 +255,23 @@ and set this flag to `false`. For example:
 
 ## {{% heading "whatsnext" %}}
 <!--
-[Cron expression format](https://en.wikipedia.org/wiki/Cron)
-documents the format of CronJob `schedule` fields.
-
-For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
+* Learn about [Pods](/docs/concepts/workloads/pods/) and
+  [Jobs](/docs/concepts/workloads/controllers/job/), two concepts
+  that CronJobs rely upon.
+* Read about the [format](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-CRON_Expression_Format)
+  of CronJob `.spec.schedule` fields.
+* For instructions on creating and working with CronJobs, and for an example
+  of a CronJob manifest,
+  see [Running automated tasks with CronJobs](/docs/tasks/job/automated-tasks-with-cron-jobs/).
+* `CronJob` is part of the Kubernetes REST API.
+  Read the {{< api-reference page="workload-resources/cron-job-v1" >}}
+  object definition to understand the API for Kubernetes cron jobs.
 -->
 
-* 进一步了解 [Cron 表达式的格式](https://en.wikipedia.org/wiki/Cron)，学习设置
-  CronJob `schedule` 字段
+* 了解 CronJob 所依赖的 [Pods](/zh/docs/concepts/workloads/pods/) 与 [Job](/zh/docs/concepts/workloads/controllers/job/) 的概念。
+* 阅读 CronJob `.spec.schedule` 字段的[格式](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-CRON_Expression_Format)。
 * 有关创建和使用 CronJob 的说明及示例规约文件，请参见
   [使用 CronJob 运行自动化任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/)。
-
+* `CronJob` 是 Kubernetes REST API 的一部分，
+   阅读 {{< api-reference page="workload-resources/cron-job-v1" >}}
+   对象定义以了解关于该资源的 API。
diff --git a/content/zh/docs/concepts/workloads/controllers/daemonset.md b/content/zh/docs/concepts/workloads/controllers/daemonset.md
index 6ad8c561d9..81d63eaf3e 100644
--- a/content/zh/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/zh/docs/concepts/workloads/controllers/daemonset.md
@@ -50,12 +50,13 @@ different flags and/or different memory and cpu requests for different hardware
 
 ### Create a DaemonSet
 -->
-## 编写 DaemonSet Spec 
+## 编写 DaemonSet Spec   {#writing-a-daemon-set-spec}
 
-### 创建 DaemonSet
+### 创建 DaemonSet   {#create-a-daemon-set}
 
 <!--
-You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` file below describes a DaemonSet that runs the fluentd-elasticsearch Docker image:
+You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` file below
+describes a DaemonSet that runs the fluentd-elasticsearch Docker image:
 -->
 你可以在 YAML 文件中描述 DaemonSet。
 例如，下面的 daemonset.yaml 文件描述了一个运行 fluentd-elasticsearch Docker 镜像的 DaemonSet：
@@ -76,15 +77,17 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 
 As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and `metadata` fields.  For
 general information about working with config files, see
- [running stateless applications](/docs/tasks/run-application/run-stateless-application-deployment/),
-[configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/working-with-objects/object-management/) documents.
+[running stateless applications](/docs/tasks/run-application/run-stateless-application-deployment/)
+and [object management using kubectl](/docs/concepts/overview/working-with-objects/object-management/).
 
 The name of a DaemonSet object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 
-A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) section.
+A DaemonSet also needs a
+[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
+section.
 -->
-### 必需字段
+### 必需字段   {#required-fields}
 
 和所有其他 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata` 字段。
 有关配置文件的基本信息，参见
@@ -103,7 +106,9 @@ DaemonSet 也需要一个 [`.spec`](https://git.k8s.io/community/contributors/de
 
 The `.spec.template` is one of the required fields in `.spec`.
 
-The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
+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`.
 
 In addition to required fields for a Pod, a Pod template in a DaemonSet has to specify appropriate
 labels (see [pod selector](#pod-selector)).
@@ -154,7 +159,8 @@ The `.spec.selector` is an object consisting of two fields:
 `spec.selector` 是一个对象，如下两个字段组成：
 
 <!--
-* `matchLabels` - works the same as the `.spec.selector` of a [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
+* `matchLabels` - works the same as the `.spec.selector` of a
+  [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
 * `matchExpressions` - allows to build more sophisticated selectors by specifying key,
   list of values and an operator that relates the key and values.
 -->
@@ -169,7 +175,8 @@ When the two are specified the result is ANDed.
 当上述两个字段都指定时，结果会按逻辑与（AND）操作处理。
 
 <!--
-If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`. Config with these not matching will be rejected by the API.
+If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`.
+Config with these not matching will be rejected by the API.
 -->
 如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。
 如果与后者不匹配，则 DeamonSet 会被 API 拒绝。
@@ -178,12 +185,13 @@ If the `.spec.selector` is specified, it must match the `.spec.template.metadata
 ### Running Pods on Only Some Nodes
 
 If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
-create Pods on nodes which match that [node
-selector](/docs/concepts/configuration/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity`,
-then DaemonSet controller will create Pods on nodes which match that [node affinity](/docs/concepts/configuration/assign-pod-node/).
+create Pods on nodes which match that [node selector](/docs/concepts/scheduling-eviction/assign-pod-node/).
+Likewise if you specify a `.spec.template.spec.affinity`,
+then DaemonSet controller will create Pods on nodes which match that
+[node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/).
 If you do not specify either, then the DaemonSet controller will create Pods on all nodes.
 -->
-### 仅在某些节点上运行 Pod
+### 仅在某些节点上运行 Pod   {#running-pods-on-only-some-nodes}
 
 如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet 控制器将在能够与
 [Node 选择算符](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。
@@ -197,9 +205,9 @@ If you do not specify either, then the DaemonSet controller will create Pods on
 
 ### Scheduled by default scheduler
 -->
-## Daemon Pods 是如何被调度的
+## Daemon Pods 是如何被调度的   {#how-daemon-pods-are-scheduled}
 
-### 通过默认调度器调度
+### 通过默认调度器调度   {#scheduled-by-default-scheduler}
 
 {{< feature-state state="stable" for-kubernetes-version="1.17" >}}
 
@@ -209,12 +217,12 @@ node that a Pod runs on is selected by the Kubernetes scheduler. However,
 DaemonSet pods are created and scheduled by the DaemonSet controller instead.
 That introduces the following issues:
 
- * Inconsistent Pod behavior: Normal Pods waiting to be scheduled are created
-   and in `Pending` state, but DaemonSet pods are not created in `Pending`
-   state. This is confusing to the user.
- * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)
-   is handled by default scheduler. When preemption is enabled, the DaemonSet controller
-   will make scheduling decisions without considering pod priority and preemption.
+* Inconsistent Pod behavior: Normal Pods waiting to be scheduled are created
+  and in `Pending` state, but DaemonSet pods are not created in `Pending`
+  state. This is confusing to the user.
+* [Pod preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
+  is handled by default scheduler. When preemption is enabled, the DaemonSet controller
+  will make scheduling decisions without considering pod priority and preemption.
 -->
 DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。
 通常，运行 Pod 的节点由 Kubernetes 调度器选择。
@@ -231,7 +239,8 @@ DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。
 scheduler instead of the DaemonSet controller, by adding the `NodeAffinity` term
 to the DaemonSet pods, instead of the `.spec.nodeName` term. The default
 scheduler is then used to bind the pod to the target host. If node affinity of
-the DaemonSet pod already exists, it is replaced. The DaemonSet controller only
+the DaemonSet pod already exists, it is replaced (the original node affinity was
+taken into account before selecting the target host). The DaemonSet controller only
 performs these operations when creating or modifying DaemonSet pods, and no
 changes are made to the `spec.template` of the DaemonSet.
 -->
@@ -292,14 +301,16 @@ Some possible patterns for communicating with Pods in a DaemonSet are:
 
 - **Push**: Pods in the DaemonSet are configured to send updates to another service, such
   as a stats database.  They do not have clients.
-- **NodeIP and Known Port**: Pods in the DaemonSet can use a `hostPort`, so that the pods are reachable via the node IPs.  Clients know the list of node IPs somehow, and know the port by convention.
-- **DNS**: Create a [headless service](/docs/concepts/services-networking/service/#headless-services) with the same pod selector,
-  and then discover DaemonSets using the `endpoints` resource or retrieve multiple A records from
-  DNS.
+- **NodeIP and Known Port**: Pods in the DaemonSet can use a `hostPort`, so that the pods
+  are reachable via the node IPs.
+  Clients know the list of node IPs somehow, and know the port by convention.
+- **DNS**: Create a [headless service](/docs/concepts/services-networking/service/#headless-services)
+  with the same pod selector, and then discover DaemonSets using the `endpoints`
+  resource or retrieve multiple A records from DNS.
 - **Service**: Create a service with the same Pod selector, and use the service to reach a
   daemon on a random node. (No way to reach specific node.)
 -->
-## 与 Daemon Pods 通信
+## 与 Daemon Pods 通信   {#communicating-with-daemon-pods}
 
 与 DaemonSet 中的 Pod 进行通信的几种可能模式如下：
 
@@ -326,7 +337,7 @@ You can modify the Pods that a DaemonSet creates.  However, Pods do not allow al
 fields to be updated.  Also, the DaemonSet controller will use the original template the next
 time a node (even with the same name) is created.
 -->
-## 更新 DaemonSet
+## 更新 DaemonSet   {#updating-a-daemon-set}
 
 如果节点的标签被修改，DaemonSet 将立刻向新匹配上的节点添加 Pod，
 同时删除不匹配的节点上的 Pod。
@@ -335,14 +346,14 @@ time a node (even with the same name) is created.
 下次当某节点（即使具有相同的名称）被创建时，DaemonSet 控制器还会使用最初的模板。
 
 <!--
-You can delete a DaemonSet.  If you specify `-cascade=false` with `kubectl`, then the Pods
+You can delete a DaemonSet.  If you specify `--cascade=orphan` with `kubectl`, then the Pods
 will be left on the nodes.  If you subsequently create a new DaemonSet with the same selector,
 the new DaemonSet adopts the existing Pods. If any Pods need replacing the DaemonSet replaces
 them according to its `updateStrategy`.
 
 You can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/) on a DaemonSet.
 -->
-您可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=false` 选项，
+您可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=orphan` 选项，
 则 Pod 将被保留在节点上。接下来如果创建使用相同选择算符的新 DaemonSet，
 新的 DaemonSet 会收养已有的 Pod。
 如果有 Pod 需要被替换，DaemonSet 会根据其 `updateStrategy` 来替换。
@@ -354,9 +365,9 @@ You can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/)
 
 ### Init Scripts
 -->
-## DaemonSet 的替代方案
+## DaemonSet 的替代方案   {#alternatives-to-daemon-set}
 
-### init 脚本
+### init 脚本   {#init-scripts}
 
 <!--
 It is certainly possible to run daemon processes by directly starting them on a node (e.g. using
@@ -388,7 +399,7 @@ a DaemonSet replaces Pods that are deleted or terminated for any reason, such as
 node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, you should
 use a DaemonSet rather than creating individual Pods.
 -->
-### 裸 Pod
+### 裸 Pod   {#bare-pods}
 
 直接创建 Pod并指定其运行在特定的节点上也是可以的。
 然而，DaemonSet 能够替换由于任何原因（例如节点失败、例行节点维护、内核升级）
@@ -404,7 +415,7 @@ Unlike DaemonSet, static Pods cannot be managed with kubectl
 or other Kubernetes API clients.  Static Pods do not depend on the apiserver, making them useful
 in cluster bootstrapping cases.  Also, static Pods may be deprecated in the future.
 -->
-### 静态 Pod
+### 静态 Pod   {#static-pods}
 
 通过在一个指定的、受 `kubelet` 监视的目录下编写文件来创建 Pod 也是可行的。
 这类 Pod 被称为[静态 Pod](/zh/docs/tasks/configure-pod-container/static-pod/)。
@@ -422,14 +433,46 @@ storage servers).
 Use a Deployment for stateless services, like frontends, where scaling up and down the
 number of replicas and rolling out updates are more important than controlling exactly which host
 the Pod runs on.  Use a DaemonSet when it is important that a copy of a Pod always run on
-all or certain hosts, and when it needs to start before other Pods.
+all or certain hosts, if the DaemonSet provides node-level functionality that allows other Pods to run correctly on that particular node.
+
+For example, [network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) often include a component that runs as a DaemonSet. The DaemonSet component makes sure that the node where it's running has working cluster networking.
 -->
 ### Deployments
 
 DaemonSet 与 [Deployments](/zh/docs/concepts/workloads/controllers/deployment/) 非常类似，
 它们都能创建 Pod，并且 Pod 中的进程都不希望被终止（例如，Web 服务器、存储服务器）。
+
 建议为无状态的服务使用 Deployments，比如前端服务。
 对这些服务而言，对副本的数量进行扩缩容、平滑升级，比精确控制 Pod 运行在某个主机上要重要得多。
-当需要 Pod 副本总是运行在全部或特定主机上，并需要它们先于其他 Pod 启动时，
+当需要 Pod 副本总是运行在全部或特定主机上，并且当该 DaemonSet 提供了节点级别的功能（允许其他 Pod 在该特定节点上正确运行）时，
 应该使用 DaemonSet。
 
+例如，[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)通常包含一个以 DaemonSet 运行的组件。
+这个 DaemonSet 组件确保它所在的节点的集群网络正常工作。
+
+## {{% heading "whatsnext" %}}
+<!--
+* Learn about [Pods](/docs/concepts/workloads/pods).
+  * Learn about [static Pods](#static-pods), which are useful for running Kubernetes
+    {{< glossary_tooltip text="control plane" term_id="control-plane" >}} components.
+* Find out how to use DaemonSets
+  * [Perform a rolling update on a DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/)
+  * [Perform a rollback on a DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
+    (for example, if a roll out didn't work how you expected).
+* Understand [how Kubernetes assigns Pods to Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/).
+* Learn about [device plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) and
+  [add ons](/docs/concepts/cluster-administration/addons/), which often run as DaemonSets.
+* `DaemonSet` is a top-level resource in the Kubernetes REST API.
+  Read the {{< api-reference page="workload-resources/daemon-set-v1" >}}
+  object definition to understand the API for daemon sets.
+-->
+* 了解 [Pods](/zh/docs/concepts/workloads/pods)。
+  * 了解[静态 Pod](#static-pods)，这对运行 Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}}组件有帮助。
+* 了解如何使用 DaemonSet
+  * [对 DaemonSet 执行滚动更新](/zh/docs/tasks/manage-daemon/update-daemon-set/)
+  * [对 DaemonSet 执行回滚](/zh/docs/tasks/manage-daemon/rollback-daemon-set/)（例如：新的版本没有达到你的预期）
+* 理解[Kubernetes 如何将 Pod 分配给节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)。
+* 了解[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)和[扩展（Addons）](/zh/docs/concepts/cluster-administration/addons/)，它们常以 DaemonSet 运行。
+* `DaemonSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="workload-resources/daemon-set-v1" >}}
+   对象定义理解关于该资源的 API。
+
diff --git a/content/zh/docs/concepts/workloads/controllers/job.md b/content/zh/docs/concepts/workloads/controllers/job.md
index 27e97ef8bf..0aba94f417 100644
--- a/content/zh/docs/concepts/workloads/controllers/job.md
+++ b/content/zh/docs/concepts/workloads/controllers/job.md
@@ -320,22 +320,7 @@ parallelism, for a variety of reasons:
 -->
 ### 完成模式   {#completion-mode}
 
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
-
-{{< note >}}
-<!--
-To be able to create Indexed Jobs, make sure to enable the `IndexedJob`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-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/).
--->
-若想创建带索引的 Job（Indexed Job），请确保
-[API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
-和[控制器管理器](/docs/reference/command-line-tools-reference/kube-controller-manager/)
-上的
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
-`IndexedJob` 被启用。
-{{< /note >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 <!--
 Jobs with _fixed completion count_ - that is, jobs that have non null
@@ -350,18 +335,30 @@ Jobs with _fixed completion count_ - that is, jobs that have non null
   completion is homologous to each other. Note that Jobs that have null
   `.spec.completions` are implicitly `NonIndexed`.
 - `Indexed`: the Pods of a Job get an associated completion index from 0 to
-  `.spec.completions-1`, available in the annotation `batch.kubernetes.io/job-completion-index`.
+  `.spec.completions-1`. The index is available through three mechanisms:
+  - The Pod annotation `batch.kubernetes.io/job-completion-index`.
+  - As part of the Pod hostname, following the pattern `$(job-name)-$(index)`.
+    When you use an Indexed Job in combination with a
+    {{< glossary_tooltip term_id="Service" >}}, Pods within the Job can use
+    the deterministic hostnames to address each other via DNS.
+  - From the containarized task, in the environment variable `JOB_COMPLETION_INDEX`.
+
   The Job is considered complete when there is one successfully completed Pod
   for each index. For more information about how to use this mode, see
   [Indexed Job for Parallel Processing with Static Work Assignment](/docs/tasks/job/indexed-parallel-processing-static/).
   Note that, although rare, more than one Pod could be started for the same
   index, but only one of them will count towards the completion count.
 -->
-- `NonIndexed` （默认值）：当成功完成的 Pod 个数达到 `.spec.completions` 所
+- `NonIndexed`（默认值）：当成功完成的 Pod 个数达到 `.spec.completions` 所
   设值时认为 Job 已经完成。换言之，每个 Job 完成事件都是独立无关且同质的。
   要注意的是，当 `.spec.completions` 取值为 null 时，Job 被隐式处理为 `NonIndexed`。
-- `Indexed`：Job 的 Pod 会获得对应的完成索引，取值为 0 到 `.spec.completions-1`，
-  存放在注解 `batch.kubernetes.io/job-completion-index` 中。
+- `Indexed`：Job 的 Pod 会获得对应的完成索引，取值为 0 到 `.spec.completions-1`。
+  该索引可以通过三种方式获取：
+  - Pod 注解 `batch.kubernetes.io/job-completion-index`。
+  - 作为 Pod 主机名的一部分，遵循模式 `$(job-name)-$(index)`。
+    当你同时使用带索引的 Job（Indexed Job）与 {{< glossary_tooltip term_id="Service" >}}，Job 中的 Pods 可以通过 DNS 使用确切的主机名互相寻址。
+  - 对于容器化的任务，在环境变量 `JOB_COMPLETION_INDEX` 中。
+  
   当每个索引都对应一个完成完成的 Pod 时，Job 被认为是已完成的。
   关于如何使用这种模式的更多信息，可参阅
   [用带索引的 Job 执行基于静态任务分配的并行处理](/zh/docs/tasks/job/indexed-parallel-processing-static/)。
@@ -459,14 +456,15 @@ from failed Jobs is not lost inadvertently.
 <!--
 ## Job termination and cleanup
 
-When a Job completes, no more Pods are created, but the Pods are not deleted either.  Keeping them around
+When a Job completes, no more Pods are created, but the Pods are [usually](#pod-backoff-failure-policy) not deleted either.
+Keeping them around
 allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output.
 The job object also remains after it is completed so that you can view its status.  It is up to the user to delete
 old jobs after noting their status.  Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). When you delete the job using `kubectl`, all the pods it created are deleted too.
 -->
 ## Job 终止与清理
 
-Job 完成时不会再创建新的 Pod，不过已有的 Pod 也不会被删除。
+Job 完成时不会再创建新的 Pod，不过已有的 Pod [通常](#pod-backoff-failure-policy)也不会被删除。
 保留这些 Pod 使得你可以查看已完成的 Pod 的日志输出，以便检查错误、警告
 或者其它诊断性输出。
 Job 完成时 Job 对象也一样被保留下来，这样你就可以查看它的状态。
@@ -562,7 +560,7 @@ cleaned up by CronJobs based on the specified capacity-based cleanup policy.
 
 ### 已完成 Job 的 TTL 机制  {#ttl-mechanisms-for-finished-jobs}
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.21" state="beta" >}}
 
 <!--
 Another way to clean up finished Jobs (either `Complete` or `Failed`)
@@ -613,21 +611,12 @@ seconds after it finishes.
 If the field is set to `0`, the Job will be eligible to be automatically deleted
 immediately after it finishes. If the field is unset, this Job won't be cleaned
 up by the TTL controller after it finishes.
-
-Note that this TTL mechanism is alpha, with feature gate `TTLAfterFinished`. For
-more information, see the documentation for
-[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
-finished resources.
 -->
 Job `pi-with-ttl` 在结束 100 秒之后，可以成为被自动删除的对象。
 
 如果该字段设置为 `0`，Job 在结束之后立即成为可被自动删除的对象。
 如果该字段没有设置，Job 不会在结束之后被 TTL 控制器自动清除。
 
-注意这种 TTL 机制仍然是一种 Alpha 状态的功能特性，需要配合 `TTLAfterFinished`
-特性门控使用。有关详细信息，可参考
-[TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)的文档。
-
 <!--
 ## Job patterns
 
@@ -731,19 +720,12 @@ Here, `W` is the number of work items.
 
 {{< note >}}
 <!--
-Suspending Jobs is available in Kubernetes versions 1.21 and above. You must
-enable the `SuspendJob` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-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/)
-in order to use this feature.
+In Kubernetes version 1.21, this feature was in alpha, which required additional
+steps to enable this feature; make sure to read the [right documentation for the
+version of Kubernetes you're using](/docs/home/supported-doc-versions/).
 -->
-在 Kubernetes 1.21 及更高版本中可以执行挂起（Suspending）Job 的操作。
-你必须在
-[API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
-和[控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
-上启用 `SuspendJob` 这一
-[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)
-才能执行此操作，
+该特性在 Kubernetes 1.21 版本中是 Alpha 阶段，启用该特性需要额外的步骤；
+请确保你正在阅读[与集群版本一致的文档](/zh/docs/home/supported-doc-versions/)。
 {{< /note >}}
 
 <!--
@@ -920,7 +902,7 @@ to keep running, but you want the rest of the Pods it creates
 to use a different pod template and for the Job to have a new name.
 You cannot update the Job because these fields are not updatable.
 Therefore, you delete Job `old` but _leave its pods
-running_, using `kubectl delete jobs/old -cascade=false`.
+running_, using `kubectl delete jobs/old --cascade=orphan`.
 Before deleting it, you make a note of what selector it uses:
 -->
 下面是一个示例场景，在这种场景下你可能会使用刚刚讲述的特性。
@@ -930,7 +912,7 @@ Before deleting it, you make a note of what selector it uses:
 使用一个不同的 Pod 模版，甚至希望 Job 的名字也发生变化。
 你无法更新现有的 Job，因为这些字段都是不可更新的。
 因此，你会删除 `old` Job，但 _允许该 Job 的 Pod 集合继续运行_。
-这是通过 `kubectl delete jobs/old --cascade=false` 实现的。
+这是通过 `kubectl delete jobs/old --cascade=orphan` 实现的。
 在删除之前，我们先记下该 Job 所使用的选择算符。
 
 ```shell
@@ -988,6 +970,77 @@ mismatch.
 设置 `manualSelector: true` 是在告诉系统你知道自己在干什么并要求系统允许这种不匹配
 的存在。
 
+<!--
+### Job tracking with finalizers
+
+In order to use this behavior, you must enable the `JobTrackingWithFinalizers`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+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 disabled by default.
+
+When enabled, the control plane tracks new Jobs using the behavior described
+below. Existing Jobs are unaffected. As a user, the only difference you would
+see is that the control plane tracking of Job completion is more accurate.
+-->
+### 使用 Finalizer 追踪 Job   {#job-tracking-with-finalizers}
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+{{< note >}}
+要使用该行为，你必须为 [API 服务器](//zh/docs/reference/command-line-tools-reference/kube-apiserver/)
+和[控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
+启用 `JobTrackingWithFinalizers`
+[特性门控](/docs/reference/command-line-tools-reference/feature-gates/)。
+默认是禁用的。
+
+启用后，控制面基于下述行为追踪新的 Job。现有 Job 不受影响。
+作为用户，你会看到的唯一区别是控制面对 Job 完成情况的跟踪更加准确。
+{{< /note >}}
+
+<!--
+When this feature isn't enabled, the Job {{< glossary_tooltip term_id="controller" >}}
+relies on counting the Pods that exist in the cluster to track the Job status,
+that is, to keep the counters for `succeeded` and `failed` Pods.
+However, Pods can be removed for a number of reasons, including:
+- The garbage collector that removes orphan Pods when a Node goes down.
+- The garbage collector that removes finished Pods (in `Succeeded` or `Failed`
+  phase) after a threshold.
+- Human intervention to delete Pods belonging to a Job.
+- An external controller (not provided as part of Kubernetes) that removes or
+  replaces Pods.
+-->
+该功能未启用时，Job {{< glossary_tooltip term_id="controller" >}} 依靠计算集群中存在的 Pod 来跟踪作业状态。
+也就是说，维持一个统计 `succeeded` 和 `failed` 的 Pod 的计数器。
+然而，Pod 可以因为一些原因被移除，包括：
+- 当一个节点宕机时，垃圾收集器会删除孤立（Orphan）Pod。
+- 垃圾收集器在某个阈值后删除已完成的 Pod（处于 `Succeeded` 或 `Failed` 阶段）。
+- 人工干预删除 Job 的 Pod。
+- 一个外部控制器（不包含于 Kubernetes）来删除或取代 Pod。
+
+<!--
+If you enable the `JobTrackingWithFinalizers` feature for your cluster, the
+control plane keeps track of the Pods that belong to any Job and notices if any
+such Pod is removed from the API server. To do that, the Job controller creates Pods with
+the finalizer `batch.kubernetes.io/job-tracking`. The controller removes the
+finalizer only after the Pod has been accounted for in the Job status, allowing
+the Pod to be removed by other controllers or users.
+
+The Job controller uses the new algorithm for new Jobs only. Jobs created
+before the feature is enabled are unaffected. You can determine if the Job
+controller is tracking a Job using Pod finalizers by checking if the Job has the
+annotation `batch.kubernetes.io/job-tracking`. You should **not** manually add
+or remove this annotation from Jobs.
+-->
+如果你为你的集群启用了 `JobTrackingWithFinalizers` 特性，控制面会跟踪属于任何 Job 的 Pod。
+并注意是否有任何这样的 Pod 被从 API 服务器上删除。
+为了实现这一点，Job 控制器创建的 Pod 带有 Finalizer `batch.kubernetes.io/job-tracking`。
+控制器只有在 Pod 被记入 Job 状态后才会移除 Finalizer，允许 Pod 可以被其他控制器或用户删除。
+
+Job 控制器只对新的 Job 使用新的算法。在启用该特性之前创建的 Job 不受影响。
+你可以根据检查 Job 是否含有 `batch.kubernetes.io/job-tracking` 注解，来确定 Job 控制器是否正在使用 Pod Finalizer 追踪 Job。
+你**不**应该给 Job 手动添加或删除该注解。
+
 <!--
 ## Alternatives
 
@@ -1044,26 +1097,44 @@ complicated to get started with and offers less integration with Kubernetes.
 
 <!--
 One example of this pattern would be a Job which starts a Pod which runs a script that in turn
-starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)), runs a spark
+starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)), runs a spark
 driver, and then cleans up.
 
 An advantage of this approach is that the overall process gets the completion guarantee of a Job
 object, but maintains complete control over what Pods are created and how work is assigned to them.
 -->
 这种模式的实例之一是用 Job 来启动一个运行脚本的 Pod，脚本负责启动 Spark
-主控制器（参见 [Spark 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)），
+主控制器（参见 [Spark 示例](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)），
 运行 Spark 驱动，之后完成清理工作。
 
 这种方法的优点之一是整个过程得到了 Job 对象的完成保障，
 同时维持了对创建哪些 Pod、如何向其分派工作的完全控制能力，
 
+## {{% heading "whatsnext" %}}
+
 <!--
-## Cron Jobs {#cron-jobs}
-
-You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`.
+* Learn about [Pods](/docs/concepts/workloads/pods).
+* Read about different ways of running Jobs:
+   * [Coarse Parallel Processing Using a Work Queue](/docs/tasks/job/coarse-parallel-processing-work-queue/)
+   * [Fine Parallel Processing Using a Work Queue](/docs/tasks/job/fine-parallel-processing-work-queue/)
+   * Use an [indexed Job for parallel processing with static work assignment](/docs/tasks/job/indexed-parallel-processing-static/) (beta)
+   * Create multiple Jobs based on a template: [Parallel Processing using Expansions](/docs/tasks/job/parallel-processing-expansion/)
+* Follow the links within [Clean up finished jobs automatically](#clean-up-finished-jobs-automatically)
+  to learn more about how your cluster can clean up completed and / or failed tasks.
+* `Job` is part of the Kubernetes REST API.
+  Read the {{< api-reference page="workload-resources/job-v1" >}}
+  object definition to understand the API for jobs.
+* Read about [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/), which you
+  can use to define a series of Jobs that will run based on a schedule, similar to
+  the Unix tool `cron`.
 -->
-## Cron Jobs {#cron-jobs}
-
-你可以使用 [`CronJob`](/zh/docs/concepts/workloads/controllers/cron-jobs/)
-创建一个在指定时间/日期运行的 Job，类似于 UNIX 系统上的 `cron` 工具。
-
+* 了解 [Pods](/zh/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/)
+* 跟随[自动清理完成的 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`。
diff --git a/content/zh/docs/concepts/workloads/controllers/replicaset.md b/content/zh/docs/concepts/workloads/controllers/replicaset.md
index 14c86eb956..98efbc3c38 100644
--- a/content/zh/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/zh/docs/concepts/workloads/controllers/replicaset.md
@@ -563,7 +563,7 @@ prioritize scaling down pods based on the following general algorithm:
 -->
 ### Pod 删除开销   {#pod-deletion-cost}
 
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 <!--
 Using the [`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 
@@ -589,11 +589,11 @@ Pods 如果未设置此注解，则隐含的设置值为 0。负值也是可接
 如果注解值非法，API 服务器会拒绝对应的 Pod。
 
 <!--
-This feature is alpha and disabled by default. You can enable it by setting the
+This feature is beta and enabled by default. You can disable it using the
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 `PodDeletionCost` in both kube-apiserver and kube-controller-manager.
 -->
-此功能特性处于 Alpha 阶段，默认被禁用。你可以通过为 kube-apiserver 和
+此功能特性处于 Beta 阶段，默认被禁用。你可以通过为 kube-apiserver 和
 kube-controller-manager 设置
 [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
 `PodDeletionCost` 来启用此功能。
@@ -745,3 +745,22 @@ ReplicaSet 是 [ReplicationController](/zh/docs/concepts/workloads/controllers/r
 中讨论的基于集合的选择算符需求。
 因此，相比于 ReplicationController，应优先考虑 ReplicaSet。
 
+## {{% heading "whatsnext" %}}
+
+<!--
+* Learn about [Pods](/docs/concepts/workloads/pods).
+* Learn about [Deployments](/docs/concepts/workloads/controllers/deployment/).
+* [Run a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/),
+  which relies on ReplicaSets to work.
+* `ReplicaSet` is a top-level resource in the Kubernetes REST API.
+  Read the {{< api-reference page="workload-resources/replica-set-v1" >}}
+  object definition to understand the API for replica sets.
+* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
+  you can use it to manage application availability during disruptions.
+-->
+* 了解 [Pods](/zh/docs/concepts/workloads/pods)。
+* 了解 [Deployments](/zh/docs/concepts/workloads/controllers/deployment/)。
+* [使用 Deployment 运行一个无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)，它依赖于 ReplicaSet。
+* `ReplicaSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="workload-resources/replica-set-v1" >}}
+   对象定义理解关于该资源的 API。
+* 阅读[Pod 干扰预算（Disruption Budget）](/zh/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。
diff --git a/content/zh/docs/concepts/workloads/controllers/statefulset.md b/content/zh/docs/concepts/workloads/controllers/statefulset.md
index 56c27ae3ea..26f00ae25c 100644
--- a/content/zh/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/zh/docs/concepts/workloads/controllers/statefulset.md
@@ -63,7 +63,7 @@ that provides a set of stateless replicas.
 ## 限制  {#limitations}
 
 <!--
-* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
+* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
 * Deleting and/or scaling a StatefulSet down will *not* delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources.
 * StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service.
 * StatefulSets do not provide any guarantees on the termination of pods when a StatefulSet is deleted. To achieve ordered and graceful termination of the pods in the StatefulSet, it is possible to scale the StatefulSet down to 0 prior to deletion.
@@ -73,7 +73,7 @@ that provides a set of stateless replicas.
   [manual intervention to repair](#forced-rollback).
 -->
 * 给定 Pod 的存储必须由
-  [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)
+  [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)
   基于所请求的 `storage class` 来提供，或者由管理员预先提供。
 * 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。
   这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
@@ -289,9 +289,7 @@ Cluster Domain will be set to `cluster.local` unless
 <!--
 ### Stable Storage
 
-Kubernetes creates one [PersistentVolume](/docs/concepts/storage/persistent-volumes/) for each
-VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume
-with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass
+For each VolumeClaimTemplate entry defined in a StatefulSet, each Pod receives one PersistentVolumeClaim. In the nginx example above, each Pod receives a single PersistentVolume with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass
 is specified, then the default StorageClass will be used. When a Pod is (re)scheduled
 onto a node, its `volumeMounts` mount the PersistentVolumes associated with its
 PersistentVolume Claims. Note that, the PersistentVolumes associated with the
@@ -300,9 +298,9 @@ This must be done manually.
 -->
 ### 稳定的存储  {#stable-storage}
 
-Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/zh/docs/concepts/storage/persistent-volumes/)。
-在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的
-1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。
+对于 StatefulSet 中定义的每个 VolumeClaimTemplate，每个 Pod 接收到一个 PersistentVolumeClaim。在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的
+1 Gib 的 PersistentVolume。
+如果没有声明 StorageClass，就会使用默认的 StorageClass。
 当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其 
 PersistentVolumeClaims 相关联的 PersistentVolume。
 请注意，当 Pod 或者 StatefulSet 被删除时，与 PersistentVolumeClaims 相关联的 
@@ -411,52 +409,56 @@ Pod. This option only affects the behavior for scaling operations. Updates are n
 <!--
 ## Update Strategies
 
-In Kubernetes 1.7 and later, StatefulSet's `.spec.updateStrategy` field allows you to configure
+A StatefulSet's `.spec.updateStrategy` field allows you to configure
 and disable automated rolling updates for containers, labels, resource request/limits, and
-annotations for the Pods in a StatefulSet.
+annotations for the Pods in a StatefulSet. There are two possible values:
 -->
 ## 更新策略  {#update-strategies}
 
-在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让
+StatefulSet 的 `.spec.updateStrategy` 字段让
 你可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。
-
+有两个允许的值：
 <!--
-### On Delete
+`OnDelete`
+: When a StatefulSet's `.spec.updateStrategy.type` is set to `OnDelete`,
+  the StatefulSet controller will not automatically update the Pods in a
+  StatefulSet. Users must manually delete Pods to cause the controller to
+  create new Pods that reflect modifications made to a StatefulSet's `.spec.template`.
 
-The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior. When a StatefulSet's
-`.spec.updateStrategy.type` is set to `OnDelete`, the StatefulSet controller will not automatically
-update the Pods in a StatefulSet. Users must manually delete Pods to cause the controller to
-create new Pods that reflect modifications made to a StatefulSet's `.spec.template`.
+`RollingUpdate`
+: The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a StatefulSet. This is the default update strategy.
 -->
-### 关于删除策略  {#on-delete}
-
-`OnDelete` 更新策略实现了 1.6 及以前版本的历史遗留行为。当 StatefulSet 的
-`.spec.updateStrategy.type` 设置为 `OnDelete` 时，它的控制器将不会自动更新
-StatefulSet 中的 Pod。
-用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的
-`.spec.template` 的变动作出反应。
+`OnDelete`
+: 当 StatefulSet 的 `.spec.updateStrategy.type` 设置为 `OnDelete` 时，
+  它的控制器将不会自动更新 StatefulSet 中的 Pod。
+  用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的
+  `.spec.template` 的变动作出反应。
 
+`RollingUpdate`
+: `RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。这是默认的更新策略。
+ 
 <!--
-### Rolling Updates
+## Rolling Updates
 
-The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a
-StatefulSet. It is the default strategy when `.spec.updateStrategy` is left unspecified. When a StatefulSet's `.spec.updateStrategy.type` is set to `RollingUpdate`, the
+When a StatefulSet's `.spec.updateStrategy.type` is set to `RollingUpdate`, the
 StatefulSet controller will delete and recreate each Pod in the StatefulSet. It will proceed
 in the same order as Pod termination (from the largest ordinal to the smallest), updating
-each Pod one at a time. It will wait until an updated Pod is Running and Ready prior to
-updating its predecessor.
--->
-### 滚动更新 {#rolling-updates}
+each Pod one at a time.
+
+The Kubernetes control plane waits until an updated Pod is Running and Ready prior
+to updating its predecessor. If you have set `.spec.minReadySeconds` (see [Minimum Ready Seconds](#minimum-ready-seconds)), the control plane additionally waits that amount of time after the Pod turns ready, before moving on.
+-->
+## 滚动更新 {#rolling-updates}
 
-`RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。
-在没有声明 `.spec.updateStrategy` 时，`RollingUpdate` 是默认配置。
 当 StatefulSet 的 `.spec.updateStrategy.type` 被设置为 `RollingUpdate` 时，
 StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。
 它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。
-它会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。
+
+Kubernetes 控制面会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。
+如果你设置了 `.spec.minReadySeconds`（查看[最短就绪秒数](#minimum-ready-seconds)），控制面在 Pod 就绪后会额外等待一定的时间再执行下一步。
 
 <!--
-#### Partitions
+### Partitioned rolling updates {#partitions}
 
 The `RollingUpdate` update strategy can be partitioned, by specifying a
 `.spec.updateStrategy.rollingUpdate.partition`. If a partition is specified, all Pods with an
@@ -468,7 +470,7 @@ updates to its `.spec.template` will not be propagated to its Pods.
 In most cases you will not need to use a partition, but they are useful if you want to stage an
 update, roll out a canary, or perform a phased roll out.
 -->
-#### 分区   {#partitions}
+### 分区滚动更新   {#partitions}
 
 通过声明 `.spec.updateStrategy.rollingUpdate.partition` 的方式，`RollingUpdate`
 更新策略可以实现分区。
@@ -481,7 +483,7 @@ update, roll out a canary, or perform a phased roll out.
 分阶段上线，则这些分区会非常有用。
 
 <!--
-#### Forced Rollback
+### Forced Rollback
 
 When using [Rolling Updates](#rolling-updates) with the default
 [Pod Management Policy](#pod-management-policies) (`OrderedReady`),
@@ -491,7 +493,7 @@ If you update the Pod template to a configuration that never becomes Running and
 Ready (for example, due to a bad binary or application-level configuration error),
 StatefulSet will stop the rollout and wait.
 -->
-#### 强制回滚 {#forced-rollback}
+### 强制回滚 {#forced-rollback}
 
 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 下使用
 [滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。
@@ -517,13 +519,52 @@ StatefulSet will then begin to recreate the Pods using the reverted template.
 恢复模板后，还必须删除 StatefulSet 尝试使用错误的配置来运行的 Pod。这样，
 StatefulSet 才会开始使用被还原的模板来重新创建 Pod。
 
+<!--
+### Minimum ready seconds
+
+`.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly
+created Pod should be ready without any of its containers crashing, for it to be considered available.
+This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
+a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
+
+Please note that this field only works if you enable the `StatefulSetMinReadySeconds` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
+-->
+### 最短就绪秒数   {#minimum-ready-seconds}
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod 就绪（没有任何容器崩溃）后被认为可用的最小秒数。
+默认值是 0（Pod 就绪时就被认为可用）。要了解 Pod 何时被认为已就绪，请参阅[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。 
+
+请注意只有当你启用 `StatefulSetMinReadySeconds` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)时，该字段才会生效。
+
 ## {{% heading "whatsnext" %}}
 
 <!--
-* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/).
-* Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
-* Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
+* Learn about [Pods](/docs/concepts/workloads/pods).
+* Find out how to use StatefulSets
+  * Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/).
+  * Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
+  * Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
+  * Learn how to [scale a StatefulSet](/docs/tasks/run-application/scale-stateful-set/).
+  * Learn what's involved when you [delete a StatefulSet](/docs/tasks/run-application/delete-stateful-set/).
+  * Learn how to [configure a Pod to use a volume for storage](/docs/tasks/configure-pod-container/configure-volume-storage/).
+  * Learn how to [configure a Pod to use a PersistentVolume for storage](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
+* `StatefulSet` is a top-level resource in the Kubernetes REST API.
+  Read the {{< api-reference page="workload-resources/stateful-set-v1" >}}
+  object definition to understand the API for stateful sets.
+* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
+  you can use it to manage application availability during disruptions.
 -->
-* 示例一：[部署有状态应用](/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/)。
+* 了解 [Pods](/zh/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/)。
+* `StatefulSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="workload-resources/stateful-set-v1" >}}
+   对象定义理解关于该资源的 API。
+* 阅读[Pod 干扰预算（Disruption Budget）](/zh/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。