[zh] sync files in /tasks/run-application/

windsonsea · windsonsea · commit dd089f44e89f · 2023-03-18T19:34:18.000+08:00
diff --git a/content/zh-cn/docs/tasks/run-application/configure-pdb.md b/content/zh-cn/docs/tasks/run-application/configure-pdb.md
@@ -84,7 +84,9 @@ selector goes into the PDBs `.spec.selector`.
 `.spec.selector` 字段中加入同样的选择算符。
 
 <!--
-From version 1.15 PDBs support custom controllers where the [scale subresource](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) is enabled.
+From version 1.15 PDBs support custom controllers where the
+[scale subresource](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)
+is enabled.
 -->
 从 1.15 版本开始，PDB 支持启用
 [Scale 子资源](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)
@@ -122,7 +124,8 @@ due to a voluntary disruption.
 - Multiple-instance Stateful application such as Consul, ZooKeeper, or etcd:
   - Concern: Do not reduce number of instances below quorum, otherwise writes fail.
     - Possible Solution 1: set maxUnavailable to 1 (works with varying scale of application).
-    - Possible Solution 2: set minAvailable to quorum-size (e.g. 3 when scale is 5). (Allows more disruptions at once).
+    - Possible Solution 2: set minAvailable to quorum-size (e.g. 3 when scale is 5).
+      (Allows more disruptions at once).
 - Restartable Batch Job:
   - Concern: Job needs to complete in case of voluntary disruption.
     - Possible solution: Do not create a PDB. The Job controller will create a replacement pod.
@@ -155,23 +158,26 @@ Values for `minAvailable` or `maxUnavailable` can be expressed as integers or as
 `minAvailable` 或 `maxUnavailable` 的值可以表示为整数或百分比。
 
 <!--
-- When you specify an integer, it represents a number of Pods. For instance, if you set `minAvailable` to 10, then 10
-  Pods must always be available, even during a disruption.
-- When you specify a percentage by setting the value to a string representation of a percentage (eg. `"50%"`), it represents a percentage of
-  total Pods. For instance, if you set `minAvailable` to `"50%"`, then at least 50% of the Pods remain available during a
-  disruption.
+- When you specify an integer, it represents a number of Pods. For instance, if you set
+  `minAvailable` to 10, then 10 Pods must always be available, even during a disruption.
+- When you specify a percentage by setting the value to a string representation of a
+  percentage (eg. `"50%"`), it represents a percentage of total Pods. For instance, if
+  you set `minAvailable` to `"50%"`, then at least 50% of the Pods remain available
+  during a disruption.
 -->
 - 指定整数值时，它表示 Pod 个数。例如，如果将 `minAvailable` 设置为 10，
   那么即使在干扰期间，也必须始终有 10 个 Pod 可用。
 - 通过将值设置为百分比的字符串表示形式（例如 `"50％"`）来指定百分比时，它表示占总 Pod 数的百分比。
   例如，如果将 `minAvailable` 设置为 `"50％"`，则干扰期间至少 50％ 的 Pod 保持可用。
 
 <!--
-When you specify the value as a percentage, it may not map to an exact number of Pods. For example, if you have 7 Pods and
-you set `minAvailable` to `"50%"`, it's not immediately obvious whether that means 3 Pods or 4 Pods must be available.
-Kubernetes rounds up to the nearest integer, so in this case, 4 Pods must be available. When you specify the value 
-`maxUnavailable` as a percentage, Kubernetes rounds up the number of Pods that may be disrupted. Thereby a disruption 
-can exceed your defined `maxUnavailable` percentage. You can examine the
+When you specify the value as a percentage, it may not map to an exact number of Pods.
+For example, if you have 7 Pods and you set `minAvailable` to `"50%"`, it's not
+immediately obvious whether that means 3 Pods or 4 Pods must be available. Kubernetes
+rounds up to the nearest integer, so in this case, 4 Pods must be available. When you
+specify the value `maxUnavailable` as a percentage, Kubernetes rounds up the number of
+Pods that may be disrupted. Thereby a disruption can exceed your defined
+`maxUnavailable` percentage. You can examine the
 [code](https://github.com/kubernetes/kubernetes/blob/23be9587a0f8677eb8091464098881df939c44a9/pkg/controller/disruption/disruption.go#L539)
 that controls this behavior.
 -->
@@ -285,8 +291,8 @@ Pod 的数量低于预算指定值。预算只能够针对自发的驱逐提供
 If you set `maxUnavailable` to 0% or 0, or you set `minAvailable` to 100% or the number of replicas,
 you are requiring zero voluntary evictions. When you set zero voluntary evictions for a workload
 object such as ReplicaSet, then you cannot successfully drain a Node running one of those Pods.
-If you try to drain a Node where an unevictable Pod is running, the drain never completes. This is permitted as per the
-semantics of `PodDisruptionBudget`.
+If you try to drain a Node where an unevictable Pod is running, the drain never completes.
+This is permitted as per the semantics of `PodDisruptionBudget`.
 -->
 如果你将 `maxUnavailable` 的值设置为 0%（或 0）或设置 `minAvailable` 值为 100%（或等于副本数）
 则会阻止所有的自愿驱逐。
@@ -409,7 +415,8 @@ status:
 <!--
 ### Healthiness of a Pod
 
-The current implementation considers healthy pods, as pods that have `.status.conditions` item with `type="Ready"` and `status="True"`.
+The current implementation considers healthy pods, as pods that have `.status.conditions`
+item with `type="Ready"` and `status="True"`.
 These pods are tracked via `.status.currentHealthy` field in the PDB status.
 -->
 ### Pod 的健康  {#healthiness-of-a-pod}
@@ -454,13 +461,16 @@ Policies:
 
 <!--
 `IfHealthyBudget`
-: Running pods (`.status.phase="Running"`), but not yet healthy can be evicted only if the guarded application is not
-disrupted (`.status.currentHealthy` is at least equal to `.status.desiredHealthy`).
+: Running pods (`.status.phase="Running"`), but not yet healthy can be evicted only
+  if the guarded application is not disrupted (`.status.currentHealthy` is at least
+  equal to `.status.desiredHealthy`).
 
-: This policy ensures that running pods of an already disrupted application have the best chance to become healthy.
-This has negative implications for draining nodes, which can be blocked by misbehaving applications that are guarded by a PDB.
-More specifically applications with pods in `CrashLoopBackOff` state (due to a bug or misconfiguration),
-or pods that are just failing to report the `Ready` condition.
+: This policy ensures that running pods of an already disrupted application have
+  the best chance to become healthy. This has negative implications for draining
+  nodes, which can be blocked by misbehaving applications that are guarded by a PDB.
+  More specifically applications with pods in `CrashLoopBackOff` state
+  (due to a bug or misconfiguration), or pods that are just failing to report the
+  `Ready` condition.
 -->
 `IfHealthyBudget`
 : 对于运行中但还不健康的 Pod（`.status.phase="Running"`），只有所守护的应用程序不受干扰
@@ -473,13 +483,14 @@ or pods that are just failing to report the `Ready` condition.
 
 <!--
 `AlwaysAllow`
-: Running pods (`.status.phase="Running"`), but not yet healthy are considered disrupted and can be evicted
-regardless of whether the criteria in a PDB is met.
-
-: This means prospective running pods of a disrupted application might not get a chance to become healthy.
-By using this policy, cluster managers can easily evict misbehaving applications that are guarded by a PDB.
-More specifically applications with pods in `CrashLoopBackOff` state (due to a bug or misconfiguration),
-or pods that are just failing to report the `Ready` condition.
+: Running pods (`.status.phase="Running"`), but not yet healthy are considered
+  disrupted and can be evicted regardless of whether the criteria in a PDB is met.
+
+: This means prospective running pods of a disrupted application might not get a
+  chance to become healthy. By using this policy, cluster managers can easily evict
+  misbehaving applications that are guarded by a PDB. More specifically applications
+  with pods in `CrashLoopBackOff` state (due to a bug or misconfiguration), or pods
+  that are just failing to report the `Ready` condition.
 -->
 `AlwaysAllow`
 : 运行中但还不健康的 Pod（`.status.phase="Running"`）将被视为已受干扰且可以被驱逐，
diff --git a/content/zh-cn/docs/tasks/run-application/delete-stateful-set.md b/content/zh-cn/docs/tasks/run-application/delete-stateful-set.md
@@ -34,7 +34,8 @@ This task shows you how to delete a {{< glossary_tooltip term_id="StatefulSet" >
 <!--
 ## Deleting a StatefulSet
 
-You can delete a StatefulSet in the same way you delete other resources in Kubernetes: use the `kubectl delete` command, and specify the StatefulSet either by file or by name.
+You can delete a StatefulSet in the same way you delete other resources in Kubernetes:
+use the `kubectl delete` command, and specify the StatefulSet either by file or by name.
 -->
 ## 删除 StatefulSet   {#deleting-a-statefulset}
 
@@ -68,8 +69,9 @@ kubectl delete service <服务名称>
 ```
 
 <!--
-When deleting a StatefulSet through `kubectl`, the StatefulSet scales down to 0. All Pods that are part of this workload are also deleted. If you want to delete only the StatefulSet and not the Pods, use `--cascade=orphan`.
-For example:
+When deleting a StatefulSet through `kubectl`, the StatefulSet scales down to 0.
+All Pods that are part of this workload are also deleted. If you want to delete
+only the StatefulSet and not the Pods, use `--cascade=orphan`. For example:
 --->
 当通过 `kubectl` 删除 StatefulSet 时，StatefulSet 会被缩容为 0。
 属于该 StatefulSet 的所有 Pod 也被删除。
@@ -80,7 +82,9 @@ kubectl delete -f <file.yaml> --cascade=orphan
 ```
 
 <!--
-By passing `--cascade=orphan` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app.kubernetes.io/name=MyApp`, you can then delete them as follows:
+By passing `--cascade=orphan` to `kubectl delete`, the Pods managed by the StatefulSet
+are left behind even after the StatefulSet object itself is deleted. If the pods have
+a label `app.kubernetes.io/name=MyApp`, you can then delete them as follows:
 --->
 通过将 `--cascade=orphan` 传递给 `kubectl delete`，在删除 StatefulSet 对象之后，
 StatefulSet 管理的 Pod 会被保留下来。如果 Pod 具有标签 `app.kubernetes.io/name=MyApp`，
@@ -93,7 +97,12 @@ kubectl delete pods -l app.kubernetes.io/name=MyApp
 <!--
 ### Persistent Volumes
 
-Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have terminated might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
+Deleting the Pods in a StatefulSet will not delete the associated volumes.
+This is to ensure that you have the chance to copy data off the volume before
+deleting it. Deleting the PVC after the pods have terminated might trigger
+deletion of the backing Persistent Volumes depending on the storage class
+and reclaim policy. You should never assume ability to access a volume
+after claim deletion.
 -->
 ### 持久卷  {#persistent-volumes}
 
@@ -111,7 +120,8 @@ Use caution when deleting a PVC, as it may lead to data loss.
 <!--
 ### Complete deletion of a StatefulSet
 
-To delete everything in a StatefulSet, including the associated pods, you can run a series of commands similar to the following:
+To delete everything in a StatefulSet, including the associated pods,
+you can run a series of commands similar to the following:
 -->
 ### 完全删除 StatefulSet  {#complete-deletion-of-a-statefulset}
 
@@ -126,14 +136,19 @@ kubectl delete pvc -l app.kubernetes.io/name=MyApp
 ```
 
 <!--
-In the example above, the Pods have the label `app.kubernetes.io/name=MyApp`; substitute your own label as appropriate.
+In the example above, the Pods have the label `app.kubernetes.io/name=MyApp`;
+substitute your own label as appropriate.
 -->
 在上面的例子中，Pod 的标签为 `app.kubernetes.io/name=MyApp`；适当地替换你自己的标签。
 
 <!--
 ### Force deletion of StatefulSet pods
 
-If you find that some pods in your StatefulSet are stuck in the 'Terminating' or 'Unknown' states for an extended period of time, you may need to manually intervene to forcefully delete the pods from the apiserver. This is a potentially dangerous task. Refer to [Force Delete StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/) for details.
+If you find that some pods in your StatefulSet are stuck in the 'Terminating'
+or 'Unknown' states for an extended period of time, you may need to manually
+intervene to forcefully delete the pods from the apiserver.
+This is a potentially dangerous task. Refer to
+[Force Delete StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/)
 -->
 ### 强制删除 StatefulSet 的 Pod   {#force-deletion-of-statefulset-pods}
 
diff --git a/content/zh-cn/docs/tasks/run-application/scale-stateful-set.md b/content/zh-cn/docs/tasks/run-application/scale-stateful-set.md
@@ -19,7 +19,8 @@ weight: 50
 
 <!-- overview -->
 <!--
-This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to increasing or decreasing the number of replicas.
+This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to
+increasing or decreasing the number of replicas.
 -->
 本文介绍如何扩缩 StatefulSet。StatefulSet 的扩缩指的是增加或者减少副本个数。
 
@@ -29,7 +30,9 @@ This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to incr
 - StatefulSets are only available in Kubernetes version 1.5 or later.
   To check your version of Kubernetes, run `kubectl version`.
 
-- Not all stateful applications scale nicely. If you are unsure about whether to scale your StatefulSets, see [StatefulSet concepts](/docs/concepts/workloads/controllers/statefulset/) or [StatefulSet tutorial](/docs/tutorials/stateful-application/basic-stateful-set/) for further information.
+- Not all stateful applications scale nicely. If you are unsure about whether
+  to scale your StatefulSets, see [StatefulSet concepts](/docs/concepts/workloads/controllers/statefulset/)
+  or [StatefulSet tutorial](/docs/tutorials/stateful-application/basic-stateful-set/) for further information.
 
 - You should perform scaling only when you are confident that your stateful application
   cluster is completely healthy.
@@ -82,7 +85,9 @@ kubectl scale statefulsets <statefulset 名称> --replicas=<新的副本数>
 <!--
 ### Make in-place updates on your StatefulSets
 
-Alternatively, you can do [in-place updates](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) on your StatefulSets.
+Alternatively, you can do
+[in-place updates](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources)
+on your StatefulSets.
 
 If your StatefulSet was initially created with `kubectl apply`,
 update `.spec.replicas` of the StatefulSet manifests, and then do a `kubectl apply`:
@@ -137,10 +142,12 @@ kubectl patch statefulsets <statefulset 名称> -p '{"spec":{"replicas":<new-rep
 ### 缩容操作无法正常工作   {#scaling-down-does-not-work}
 
 <!--
-You cannot scale down a StatefulSet when any of the stateful Pods it manages is unhealthy. Scaling down only takes place
-after those stateful Pods become running and ready.
+You cannot scale down a StatefulSet when any of the stateful Pods it manages is
+unhealthy. Scaling down only takes place after those stateful Pods become running and ready.
 
-If spec.replicas > 1, Kubernetes cannot determine the reason for an unhealthy Pod. It might be the result of a permanent fault or of a transient fault. A transient fault can be caused by a restart required by upgrading or maintenance.
+If spec.replicas > 1, Kubernetes cannot determine the reason for an unhealthy Pod.
+It might be the result of a permanent fault or of a transient fault. A transient
+fault can be caused by a restart required by upgrading or maintenance.
 -->
 当 Stateful 所管理的任何 Pod 不健康时，你不能对该 StatefulSet 执行缩容操作。
 仅当 StatefulSet 的所有 Pod 都处于运行状态和 Ready 状况后才可缩容。
