Merge pull request #34519 from howieyuen/task-pages-4

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

Author: k8s-ci-robot

content/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes.md

@@ -134,5 +134,5 @@ a `disktype=ssd` label.
 Learn more about
 [labels and selectors](/docs/concepts/overview/working-with-objects/labels/).
 -->
-进一步了解[标签和选择器](/zh/docs/concepts/overview/working-with-objects/labels/)
+进一步了解[标签和选择器](/zh-cn/docs/concepts/overview/working-with-objects/labels/)
 

content/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md

@@ -126,7 +126,7 @@ unless the Pod's grace period expires. For more details, see
 -->
 Kubernetes 在容器结束前立即发送 preStop 事件。除非 Pod 宽限期限超时，Kubernetes 的容器管理逻辑
 会一直阻塞等待 preStop 处理函数执行完毕。更多的相关细节，可以参阅
-[Pods 的结束](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
+[Pods 的结束](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
 
 <!--
 Kubernetes only sends the preStop event when a Pod is *terminated*.
@@ -146,8 +146,8 @@ preStop 的事件处理逻辑不会被触发。这个限制在
 * Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
 * Learn more about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
 -->
-* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。
-* 进一步了解[Pod 的生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)。
+* 进一步了解[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)。
+* 进一步了解[Pod 的生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)。
 
 <!--
 ### Reference

content/zh-cn/docs/tasks/configure-pod-container/configure-gmsa.md

@@ -47,7 +47,7 @@ Next, install the CRD with `kubectl apply -f gmsa-crd.yaml`
 ### 安装 GMSACredentialSpec CRD
 
 你需要在集群上配置一个用于 GMSA 凭据规约资源的
-[CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD)，
+[CustomResourceDefinition](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD)，
 以便定义类型为 `GMSACredentialSpec` 的自定义资源。
 首先下载 GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml)
 并将其保存为 `gmsa-crd.yaml`。接下来执行 `kubectl apply -f gmsa-crd.yaml`

content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -16,7 +16,7 @@ despite bugs.
 -->
 这篇文章介绍如何给容器配置活跃（Liveness）、就绪（Readiness）和启动（Startup）探测器。
 
-[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
+[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)
 使用存活探测器来确定什么时候要重启容器。
 例如，存活探测器可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。
 重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。
@@ -354,7 +354,7 @@ Here is an example manifest:
 如果你的应用实现了 [gRPC 健康检查协议](https://github.com/grpc/grpc/blob/master/doc/health-checking.md)，
 kubelet 可以配置为使用该协议来执行应用活跃性检查。
 你必须启用 `GRPCContainerProbe`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
 才能配置依赖于 gRPC 的检查机制。
 
 下面是一个示例清单：
@@ -638,7 +638,7 @@ eventual removal of that feature gate.
 这一缺陷在 Kubernetes v1.20 版本中得到修复。你可能一直依赖于之前错误的探测行为，
 甚至都没有觉察到这一问题的存在，因为默认的超时值是 1 秒钟。
 作为集群管理员，你可以在所有的 kubelet 上禁用 `ExecProbeTimeout`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
 （将其设置为 `false`），从而恢复之前版本中的运行行为。之后当集群中所有的
 exec 探针都设置了 `timeoutSeconds` 参数后，移除此标志重载。
 如果你有 Pod 受到此默认 1 秒钟超时值的影响，你应该更新这些 Pod 对应的探针的超时值，
@@ -860,7 +860,7 @@ It will be rejected by the API server.
 * Learn more about
 [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
 -->
-* 进一步了解[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
+* 进一步了解[容器探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
 
 <!--
 You can also read the API references for:

content/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md

@@ -55,7 +55,7 @@ do not already have a single-node cluster, you can create one by using
   如果还没有单节点集群，可以使用
   [Minikube](https://minikube.sigs.k8s.io/docs/) 创建一个。
 .
-* 熟悉[持久卷](/zh/docs/concepts/storage/persistent-volumes/)中的材料。
+* 熟悉[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)中的材料。
 
 <!-- steps -->
 
@@ -464,7 +464,7 @@ PersistentVolume are not present on the Pod resource itself.
 * Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
 * Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md).
 -->
-* 进一步了解 [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/)
+* 进一步了解 [PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/)
 * 阅读[持久存储设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)
 
 <!--

content/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap.md

@@ -74,7 +74,7 @@ The name of a ConfigMap object must be a valid
 其中，`<映射名称>` 是为 ConfigMap 指定的名称，`<数据源>` 是要从中提取数据的目录、
 文件或者字面值。
 ConfigMap 对象的名称必须是合法的
-[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).
 
 <!--
 When you are creating a ConfigMap based on a file, the key in the \<data-source> defaults to the basename of the file, and the value defaults to the file content.
@@ -1053,7 +1053,7 @@ basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files
 ### 映射键到指定路径并设置文件访问权限    {#project-keys-to-specific-paths-and-file-permissions}
 
 你可以将指定键名投射到特定目录，也可以逐个文件地设定访问权限。
-[Secret 用户指南](/zh/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)
+[Secret 用户指南](/zh-cn/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)
 中为这一语法提供了解释。
 
 <!--
@@ -1098,7 +1098,7 @@ kubelet 同步周期（默认 1 分钟） + ConfigMap 在 kubelet 中缓存的 T
 A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.
 -->
 {{< note >}}
-使用 ConfigMap 作为 [subPath](/zh/docs/concepts/storage/volumes/#using-subpath)
+使用 ConfigMap 作为 [subPath](/zh-cn/docs/concepts/storage/volumes/#using-subpath)
 的数据卷将不会收到 ConfigMap 更新。
 {{< /note >}}
 
@@ -1113,7 +1113,7 @@ The ConfigMap API resource stores configuration data as key-value pairs. The dat
 
 ConfigMap API 资源将配置数据存储为键值对。
 数据可以在 Pod 中使用，也可以用来提供系统组件（如控制器）的配置。
-ConfigMap 与 [Secret](/zh/docs/concepts/configuration/secret/) 类似，
+ConfigMap 与 [Secret](/zh-cn/docs/concepts/configuration/secret/) 类似，
 但是提供的是一种处理不含敏感信息的字符串的方法。
 用户和系统组件都可以在 ConfigMap 中存储配置数据。
 
@@ -1123,7 +1123,7 @@ ConfigMaps should reference properties files, not replace them. Think of the Con
 {{< note >}}
 ConfigMap 应该引用属性文件，而不是替换它们。可以将 ConfigMap 理解为类似于 Linux
 `/etc` 目录及其内容的东西。例如，如果你基于 ConfigMap 创建
-[Kubernetes 卷](/zh/docs/concepts/storage/volumes/)，则 ConfigMap
+[Kubernetes 卷](/zh-cn/docs/concepts/storage/volumes/)，则 ConfigMap
 中的每个数据项都由该数据卷中的某个独立的文件表示。
 {{< /note >}}
 
@@ -1220,6 +1220,6 @@ data:
 <!--
 * Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/).
 -->
-* 浏览[使用 ConfigMap 配置 Redis](/zh/docs/tutorials/configuration/configure-redis-using-configmap/)
+* 浏览[使用 ConfigMap 配置 Redis](/zh-cn/docs/tutorials/configuration/configure-redis-using-configmap/)
   真实示例。
 

content/zh-cn/docs/tasks/configure-pod-container/configure-pod-initialization.md

@@ -138,8 +138,8 @@ The output shows that nginx is serving the web page that was written by the init
 * Learn more about [Debugging Init Containers](/docs/tasks/debug/debug-application/debug-init-containers/)
 -->
 
-* 进一步了解[同一 Pod 中的容器间的通信](/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)。
-* 进一步了解 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。
-* 进一步了解[卷](/zh/docs/concepts/storage/volumes/)。
-* 进一步了解 [Init 容器排错](/zh/docs/tasks/debug/debug-application/debug-init-containers/)。
+* 进一步了解[同一 Pod 中的容器间的通信](/zh-cn/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)。
+* 进一步了解 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)。
+* 进一步了解[卷](/zh-cn/docs/concepts/storage/volumes/)。
+* 进一步了解 [Init 容器排错](/zh-cn/docs/tasks/debug/debug-application/debug-init-containers/)。
 

content/zh-cn/docs/tasks/configure-pod-container/configure-projected-volume-storage.md

@@ -20,7 +20,7 @@ several existing volume sources into the same directory. Currently, `secret`, `c
 and `serviceAccountToken` volumes can be projected.
 -->
 
-本文介绍怎样通过[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷将现有的多个卷资源挂载到相同的目录。
+本文介绍怎样通过[`projected`](/zh-cn/docs/concepts/storage/volumes/#projected) 卷将现有的多个卷资源挂载到相同的目录。
 当前，`secret`、`configMap`、`downwardAPI` 和 `serviceAccountToken` 卷可以被投射。
 
 <!--
@@ -47,7 +47,7 @@ Here is the configuration file for the Pod:
 ## 为 Pod 配置 projected 卷
 
 本练习中，你将从本地文件来创建包含有用户名和密码的 Secret。然后创建运行一个容器的 Pod，
-该 Pod 使用[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷将 Secret 挂载到相同的路径下。
+该 Pod 使用[`projected`](/zh-cn/docs/concepts/storage/volumes/#projected) 卷将 Secret 挂载到相同的路径下。
 
 下面是 Pod 的配置文件：
 
@@ -126,6 +126,6 @@ kubectl delete secret user pass
 * Read the [all-in-one volume](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md) design document.
 -->
 
-* 进一步了解[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷。
+* 进一步了解[`projected`](/zh-cn/docs/concepts/storage/volumes/#projected) 卷。
 * 阅读[一体卷](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)设计文档。
 

content/zh-cn/docs/tasks/configure-pod-container/configure-runasusername.md

@@ -222,6 +222,6 @@ For more information about these limtations, check [here](https://support.micros
 * [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/concepts/windows/user-guide/#managing-workload-identity-with-group-managed-service-accounts)
 * [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/)
 -->
-* [Kubernetes 中调度 Windows 容器的指南](/zh/docs/concepts/windows/user-guide/)
-* [使用组托管服务帐户（GMSA）管理工作负载身份](/zh/docs/concepts/windows/user-guide/#managing-workload-identity-with-group-managed-service-accounts)
-* [Windows 下 pod 和容器的 GMSA 配置](/zh/docs/tasks/configure-pod-container/configure-gmsa/)
+* [Kubernetes 中调度 Windows 容器的指南](/zh-cn/docs/concepts/windows/user-guide/)
+* [使用组托管服务帐户（GMSA）管理工作负载身份](/zh-cn/docs/concepts/windows/user-guide/#managing-workload-identity-with-group-managed-service-accounts)
+* [Windows 下 pod 和容器的 GMSA 配置](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/)

content/zh-cn/docs/tasks/configure-pod-container/configure-service-account.md

@@ -73,9 +73,9 @@ In version 1.6+, you can opt out of automounting API credentials for a service a
 `automountServiceAccountToken: false` on the service account:
 -->
 你可以使用自动挂载给 Pod 的服务账户凭据访问 API，
-[访问集群](/zh/docs/tasks/access-application-cluster/access-cluster/)页面中有相关描述。
+[访问集群](/zh-cn/docs/tasks/access-application-cluster/access-cluster/)页面中有相关描述。
 服务账户的 API 许可取决于你所使用的
-[鉴权插件和策略](/zh/docs/reference/access-authn-authz/authorization/#authorization-modules)。
+[鉴权插件和策略](/zh-cn/docs/reference/access-authn-authz/authorization/#authorization-modules)。
 
 在 1.6 以上版本中，你可以通过在服务账户上设置 `automountServiceAccountToken: false`
 来实现不给服务账号自动挂载 API 凭据：
@@ -155,7 +155,7 @@ The name of a ServiceAccount object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 -->
 ServiceAccount 对象的名字必须是一个有效的
-[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).
 
 <!--
 If you get a complete dump of the service account object, like this:
@@ -195,7 +195,7 @@ field of a pod to the name of the service account you wish to use.
 那么你就能看到系统已经自动创建了一个令牌并且被服务账户所引用。
 
 你可以使用授权插件来
-[设置服务账户的访问许可](/zh/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
+[设置服务账户的访问许可](/zh-cn/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
 
 要使用非默认的服务账户，将 Pod 的 `spec.serviceAccountName` 字段设置为你想用的服务账户名称。
 
@@ -289,7 +289,7 @@ The content of `token` is elided here.
 
 ### 创建 ImagePullSecret
 
-- 创建一个 ImagePullSecret，如同[为 Pod 设置 ImagePullSecret](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)所述。
+- 创建一个 ImagePullSecret，如同[为 Pod 设置 ImagePullSecret](/zh-cn/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)所述。
 
   ```shell
   kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \
@@ -494,7 +494,7 @@ This behavior is configured on a PodSpec using a ProjectedVolume type called
 pod with a token with an audience of "vault" and a validity duration of two
 hours, you would configure the following in your PodSpec:
 -->
-使用名为 [ServiceAccountToken](/zh/docs/concepts/storage/volumes/#projected) 的
+使用名为 [ServiceAccountToken](/zh-cn/docs/concepts/storage/volumes/#projected) 的
 ProjectedVolume 类型在 PodSpec 上配置此功能。
 要向 Pod 提供具有 "vault" 用户以及两个小时有效期的令牌，可以在 PodSpec 中配置以下内容：
 
@@ -640,7 +640,7 @@ See also:
 -->
 另请参见：
 
-- [服务账号的集群管理员指南](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
+- [服务账号的集群管理员指南](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/)
 - [服务账号签署密钥检索 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1393-oidc-discovery)
 - [OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html)