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

2022-06-23 20:20:11 +08:00
parent 7eca3dd28a
commit 3ecfa2da5a
25 changed files with 309 additions and 309 deletions
@@ -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" >}}
@@ -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)
  的过程，包括如何在其进程中维持应用的可用性
@@ -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)
@@ -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) 字段。

@@ -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 >}}