From db158fd8efaaac67315e9bebd773fb9f1b93bc76 Mon Sep 17 00:00:00 2001
From: my-git9 <xin.li@daocloud.io>
Date: Wed, 24 Jan 2024 10:23:06 +0800
Subject: [PATCH] [zh-cn]improve deployment.md

---
 .../workloads/controllers/deployment.md       | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md
index eb031308ef..3ef02bb331 100644
--- a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md
+++ b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md
@@ -320,7 +320,7 @@ Deployment 控制器将 `pod-template-hash` 标签添加到 Deployment
 This label ensures that child ReplicaSets of a Deployment do not overlap. It is generated by hashing the `PodTemplate` of the ReplicaSet and using the resulting hash as the label value that is added to the ReplicaSet selector, Pod template labels,
 and in any existing Pods that the ReplicaSet might have.
 -->
-此标签可确保 Deployment 的子 ReplicaSets 不重叠。
+此标签可确保 Deployment 的子 ReplicaSet 不重叠。
 标签是通过对 ReplicaSet 的 `PodTemplate` 进行哈希处理。
 所生成的哈希值被添加到 ReplicaSet 选择算符、Pod 模板标签，并存在于在 ReplicaSet
 可能拥有的任何现有 Pod 中。
@@ -606,7 +606,7 @@ ReplicaSet is scaled to `.spec.replicas` and all old ReplicaSets is scaled to 0.
 Deployment 控制器每次注意到新的 Deployment 时，都会创建一个 ReplicaSet 以启动所需的 Pod。
 如果更新了 Deployment，则控制标签匹配 `.spec.selector` 但模板不匹配 `.spec.template` 的 Pod 的现有 ReplicaSet 被缩容。
 最终，新的 ReplicaSet 缩放为 `.spec.replicas` 个副本，
-所有旧 ReplicaSets 缩放为 0 个副本。
+所有旧 ReplicaSet 缩放为 0 个副本。
 
 <!--
 If you update a Deployment while an existing rollout is in progress, the Deployment creates a new ReplicaSet
@@ -614,7 +614,7 @@ as per the update and start scaling that up, and rolls over the ReplicaSet that
 -- it will add it to its list of old ReplicaSets and start scaling it down.
 -->
 当 Deployment 正在上线时被更新，Deployment 会针对更新创建一个新的 ReplicaSet
-并开始对其扩容，之前正在被扩容的 ReplicaSet 会被翻转，添加到旧 ReplicaSets 列表
+并开始对其扩容，之前正在被扩容的 ReplicaSet 会被翻转，添加到旧 ReplicaSet 列表
 并开始缩容。
 
 <!--
@@ -1122,7 +1122,7 @@ ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *p
 
 RollingUpdate 的 Deployment 支持同时运行应用程序的多个版本。
 当自动缩放器缩放处于上线进程（仍在进行中或暂停）中的 RollingUpdate Deployment 时，
-Deployment 控制器会平衡现有的活跃状态的 ReplicaSets（含 Pod 的 ReplicaSets）中的额外副本，
+Deployment 控制器会平衡现有的活跃状态的 ReplicaSet（含 Pod 的 ReplicaSet）中的额外副本，
 以降低风险。这称为 *比例缩放（Proportional Scaling）*。
 
 <!--
@@ -1202,7 +1202,7 @@ ReplicaSet with the most replicas. ReplicaSets with zero replicas are not scaled
   都将添加到新的 ReplicaSet 中。使用比例缩放时，可以将额外的副本分布到所有 ReplicaSet。
   较大比例的副本会被添加到拥有最多副本的 ReplicaSet，而较低比例的副本会进入到
   副本较少的 ReplicaSet。所有剩下的副本都会添加到副本最多的 ReplicaSet。
-  具有零副本的 ReplicaSets 不会被扩容。
+  具有零副本的 ReplicaSet 不会被扩容。
 
 <!--
 In our example above, 3 replicas are added to the old ReplicaSet and 2 replicas are added to the
@@ -2094,8 +2094,8 @@ the rolling update process.
 #### 滚动更新 Deployment   {#rolling-update-deployment}
 
 Deployment 会在 `.spec.strategy.type==RollingUpdate`时，采取
-滚动更新的方式更新 Pod。你可以指定 `maxUnavailable` 和 `maxSurge` 来控制滚动更新
-过程。
+滚动更新的方式更新 Pod。你可以指定 `maxUnavailable` 和 `maxSurge`
+来控制滚动更新过程。
 
 <!--
 ##### Max Unavailable
@@ -2108,8 +2108,8 @@ of Pods that can be unavailable during the update process. The value can be an a
 or a percentage of desired Pods (for example, 10%). The absolute number is calculated from percentage by
 rounding down. The value cannot be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. The default value is 25%.
 -->
-`.spec.strategy.rollingUpdate.maxUnavailable` 是一个可选字段，用来指定
-更新过程中不可用的 Pod 的个数上限。该值可以是绝对数字（例如，5），也可以是所需
+`.spec.strategy.rollingUpdate.maxUnavailable` 是一个可选字段，
+用来指定更新过程中不可用的 Pod 的个数上限。该值可以是绝对数字（例如，5），也可以是所需
 Pod 的百分比（例如，10%）。百分比值会转换成绝对数并去除小数部分。
 如果 `.spec.strategy.rollingUpdate.maxSurge` 为 0，则此值不能为 0。
 默认值为 25%。
@@ -2263,7 +2263,7 @@ controller will roll back a Deployment as soon as it observes such a condition.
 ### 进度期限秒数    {#progress-deadline-seconds}
 
 `.spec.progressDeadlineSeconds` 是一个可选字段，用于指定系统在报告 Deployment
-[进展失败](#failed-deployment) 之前等待 Deployment 取得进展的秒数。
+[进展失败](#failed-deployment)之前等待 Deployment 取得进展的秒数。
 这类报告会在资源状态中体现为 `type: Progressing`、`status: False`、
 `reason: ProgressDeadlineExceeded`。Deployment 控制器将在默认 600 毫秒内持续重试 Deployment。
 将来，一旦实现了自动回滚，Deployment 控制器将在探测到这样的条件时立即回滚 Deployment。
@@ -2296,7 +2296,7 @@ A Deployment's revision history is stored in the ReplicaSets it controls.
 -->
 ### 修订历史限制
 
-Deployment 的修订历史记录存储在它所控制的 ReplicaSets 中。
+Deployment 的修订历史记录存储在它所控制的 ReplicaSet 中。
 
 <!--
 `.spec.revisionHistoryLimit` is an optional field that specifies the number of old ReplicaSets to retain
@@ -2307,7 +2307,7 @@ however its ideal value depends on the frequency and stability of new Deployment
 -->
 `.spec.revisionHistoryLimit` 是一个可选字段，用来设定出于回滚目的所要保留的旧 ReplicaSet 数量。
 这些旧 ReplicaSet 会消耗 etcd 中的资源，并占用 `kubectl get rs` 的输出。
-每个 Deployment 修订版本的配置都存储在其 ReplicaSets 中；因此，一旦删除了旧的 ReplicaSet，
+每个 Deployment 修订版本的配置都存储在其 ReplicaSet 中；因此，一旦删除了旧的 ReplicaSet，
 将失去回滚到 Deployment 的对应修订版本的能力。
 默认情况下，系统保留 10 个旧 ReplicaSet，但其理想值取决于新 Deployment 的频率和稳定性。