[zh] Resync tasks for 1.21 (4)

Author: tengqm

content/zh/docs/tasks/run-application/configure-pdb.md

@@ -2,6 +2,7 @@
 title: 为应用程序设置干扰预算（Disruption Budget）
 content_type: task
 weight: 110
+min-kubernetes-server-version: v1.21
 ---
 
 <!--
@@ -12,7 +13,7 @@ weight: 110
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.5" state="beta" >}}
+{{< feature-state for_k8s_version="v1.21" state="stable" >}}
 
 <!--
 This page shows how to limit the number of concurrent disruptions
@@ -24,6 +25,8 @@ nodes.
 
 ## {{% heading "prerequisites" %}}
 
+{{< version-check >}}
+
 <!--
 * You are the owner of an application running on a Kubernetes cluster that requires
   high availability.
@@ -205,15 +208,15 @@ It can be either an absolute number or a percentage.
 * `.spec.maxUnavailable` （Kubernetes 1.7 及更高的版本中可用）表示驱逐后允许不可用的
   Pod 的最大数量。其值可以是绝对值或是百分比。
 
+{{< note >}}
 <!--
-For versions 1.8 and earlier: When creating a `PodDisruptionBudget`
-object using the `kubectl` command line tool, the `minAvailable` field has a
-default value of 1 if neither `minAvailable` nor `maxUnavailable` is specified.
+The behavior for an empty selector differs between the policy/v1beta1 and policy/v1 APIs for
+PodDisruptionBudgets. For policy/v1beta1 an empty selector matches zero pods, while
+for policy/v1 an empty selector matches every pod in the namespace.
 -->
-{{< note >}}
-对于1.8及更早的版本：当你用 `kubectl` 命令行工具创建 `PodDisruptionBudget` 对象时，
-如果既未指定 `minAvailable` 也未指定 `maxUnavailable`，
-则 `minAvailable` 字段有一个默认值 1。
+`policy/v1beta1` 和 `policy/v1` API 中 PodDisruptionBudget 的空选择算符的行为
+略有不同。在 `policy/v1beta1` 中，空的选择算符不会匹配任何 Pods，而
+`policy/v1` 中，空的选择算符会匹配名字空间中所有 Pods。
 {{< /note >}}
 
 <!--
@@ -296,9 +299,9 @@ Example PDB Using minAvailable:
 {{< codenew file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" >}}
 
 <!--
-Example PDB Using maxUnavailable (Kubernetes 1.7 or higher):
+Example PDB Using maxUnavailable:
 -->
-使用 maxUnavailable 的 PDB 示例（Kubernetes 1.7 或更高的版本）：
+使用 maxUnavailable 的 PDB 示例：
 
 {{< codenew file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" >}}
 
@@ -378,7 +381,7 @@ kubectl get poddisruptionbudgets zk-pdb -o yaml
 ```
 
 ```yaml
-apiVersion: policy/v1beta1
+apiVersion: policy/v1
 kind: PodDisruptionBudget
 metadata:
   anntation: {}

content/zh/docs/tasks/run-application/delete-stateful-set.md

@@ -20,14 +20,14 @@ weight: 60
 
 <!--
 This task shows you how to delete a StatefulSet.
---->
+-->
 本任务展示如何删除 StatefulSet。
 
 ## {{% heading "prerequisites" %}}
 
 <!--
 * This task assumes you have an application running on your cluster represented by a StatefulSet.
---->
+-->
 * 本任务假设在你的集群上已经运行了由 StatefulSet 创建的应用。
 
 <!-- steps -->
@@ -36,7 +36,7 @@ This task shows you how to delete 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.
---->
+-->
 你可以像删除 Kubernetes 中的其他资源一样删除 StatefulSet：使用 `kubectl delete` 命令，并按文件或者名字指定 StatefulSet。
 
 ```shell
@@ -66,10 +66,11 @@ kubectl delete service <服务名称>
 ```
 
 <!--
-Deleting a StatefulSet through kubectl will scale it down to 0, thereby deleting all pods that are a part of it.
-If you want to delete just the StatefulSet and not the pods, use `--cascade=false`.
+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=false`.
+For example:
 --->
-通过 `kubectl` 删除 StatefulSet 会将其缩容为 0，因此删除属于它的所有 Pod。
+当通过 `kubectl` 删除 StatefulSet 时，StatefulSet 会被缩容为 0。
+属于该 StatefulSet 的所有 Pod 也被删除。
 如果你只想删除 StatefulSet 而不删除 Pod，使用 `--cascade=false`。
 
 ```shell
@@ -114,7 +115,8 @@ To simply delete everything in a StatefulSet, including the associated pods, you
 -->
 ### 完全删除 StatefulSet  {#complete-deletion-of-a-statefulset}
 
-要简单地删除 StatefulSet 中的所有内容，包括关联的 pods，你可能需要运行一系列类似于以下内容的命令：
+要删除 StatefulSet 中的所有内容，包括关联的 pods，你可以运行
+一系列如下所示的命令：
 
 ```shell
 grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')
@@ -144,7 +146,7 @@ If you find that some pods in your StatefulSet are stuck in the 'Terminating' or
 
 <!--
 Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
---->
+-->
 进一步了解[强制删除 StatefulSet 的 Pods](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/)。
 
 

content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md

@@ -1,5 +1,5 @@
 ---
-title: 强制删除 StatefulSet 类型的 Pods
+title: 强制删除 StatefulSet 中的 Pods
 content_type: task
 weight: 70
 ---
@@ -19,8 +19,8 @@ weight: 70
 <!--
 This page shows how to delete Pods which are part of a {{< glossary_tooltip text="stateful set" term_id="StatefulSet" >}}, and explains the considerations to keep in mind when doing so.
 -->
-本文介绍了如何删除 {{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}
-管理的 Pods，并且解释了这样操作时需要记住的注意事项。
+本文介绍如何删除 {{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}
+管理的 Pods，并解释这样操作时需要记住的注意事项。
 
 ## {{% heading "prerequisites" %}}
 
@@ -76,11 +76,16 @@ Pod 不要使用。体面删除是安全的，并且会在 kubelet 从 API 服
 [体面地结束 pod ](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
 
 <!--
-Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
+A Pod is not deleted automatically when a Node is unreachable.
+The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a
+[timeout](/docs/concepts/architecture/nodes/#condition).
+Pods may also enter these states when the user attempts graceful deletion of a Pod
+on an unreachable Node.
+The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
 -->
-Kubernetes（1.5 版本或者更新版本）不会因为一个节点无法访问而删除 Pod。
+当某个节点不可达时，不会引发自动删除 Pod。
 在无法访问的节点上运行的 Pod 在
-[超时](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-condition)
+[超时](/zh/docs/concepts/architecture/nodes/#condition)
 后会进入'Terminating' 或者 'Unknown' 状态。
 当用户尝试体面地删除无法访问的节点上的 Pod 时 Pod 也可能会进入这些状态。
 从 API 服务器上删除处于这些状态 Pod 的仅有可行方法如下：

content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md

@@ -571,7 +571,7 @@ with *external metrics*.
 <!--
 Using external metrics requires knowledge of your monitoring system; the setup is
 similar to that required when using custom metrics. External metrics allow you to autoscale your cluster
-based on any metric available in your monitoring system. Just provide a `metric` block with a
+based on any metric available in your monitoring system. Provide a `metric` block with a
 `name` and `selector`, as above, and use the `External` metric type instead of `Object`.
 If multiple time series are matched by the `metricSelector`,
 the sum of their values is used by the HorizontalPodAutoscaler.
@@ -580,7 +580,7 @@ as when you use the `Object` type.
 -->
 使用外部度量指标时，需要了解你所使用的监控系统，相关的设置与使用自定义指标时类似。
 外部度量指标使得你可以使用你的监控系统的任何指标来自动扩缩你的集群。
-你只需要在 `metric` 块中提供 `name` 和 `selector`，同时将类型由 `Object` 改为 `External`。
+你需要在 `metric` 块中提供 `name` 和 `selector`，同时将类型由 `Object` 改为 `External`。
 如果 `metricSelector` 匹配到多个度量指标，HorizontalPodAutoscaler 将会把它们加和。
 外部度量指标同时支持 `Value` 和 `AverageValue` 类型，这与 `Object` 类型的度量指标相同。