[zh]Update setup pages for links with '/zh/' prefix, using new prefix '/zh-cn/'

2022-06-23 20:00:50 +08:00
parent e0d6f94bf6
commit 648bf637a2
18 changed files with 189 additions and 189 deletions
@@ -20,7 +20,7 @@ You can also generate your own certificates -- for example, to keep your private
 This page explains the certificates that your cluster requires.
 -->
 Kubernetes 需要 PKI 证书才能进行基于 TLS 的身份验证。如果你是使用
-[kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 安装的 Kubernetes，
+[kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/) 安装的 Kubernetes，
 则会自动生成集群所需的证书。你还可以生成自己的证书。
 例如，不将私钥存储在 API 服务器上，可以让私钥更加安全。此页面说明了集群必需的证书。

@@ -48,7 +48,7 @@ Kubernetes 需要 PKI 才能执行以下操作：
 * Client and server certificates for the [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
 -->
 * Kubelet 的客户端证书，用于 API 服务器身份验证
-* Kubelet [服务端证书](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates)，
+* Kubelet [服务端证书](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates)，
  用于 API 服务器与 Kubelet 的会话
 * API 服务器端点的证书
 * 集群管理员的客户端证书，用于 API 服务器身份认证
@@ -56,14 +56,14 @@ Kubernetes 需要 PKI 才能执行以下操作：
 * API 服务器的客户端证书，用于和 etcd 的会话
 * 控制器管理器的客户端证书/kubeconfig，用于和 API 服务器的会话
 * 调度器的客户端证书/kubeconfig，用于和 API 服务器的会话
-* [前端代理](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 的客户端及服务端证书
+* [前端代理](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 的客户端及服务端证书

 <!--
 `front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/).
 -->
 {{< note >}}
 只有当你运行 kube-proxy 并要支持
-[扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)
+[扩展 API 服务器](/zh-cn/docs/tasks/extend-kubernetes/setup-extension-api-server/)
 时，才需要 `front-proxy` 证书
 {{< /note >}}

@@ -92,8 +92,8 @@ See [Certificate Management with kubeadm](/docs/tasks/administer-cluster/kubeadm

 如果你不想通过 kubeadm 生成这些必需的证书，你可以使用一个单一的根 CA
 来创建这些证书或者直接提供所有证书。
-参见[证书](/zh/docs/tasks/administer-cluster/certificates/)以进一步了解创建自己的证书机构。
-关于管理证书的更多信息，请参见[使用 kubeadm 进行证书管理](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。
+参见[证书](/zh-cn/docs/tasks/administer-cluster/certificates/)以进一步了解创建自己的证书机构。
+关于管理证书的更多信息，请参见[使用 kubeadm 进行证书管理](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。

 <!--
 ### Single root CA
@@ -121,7 +121,7 @@ On top of the above CAs, it is also necessary to get a public/private key pair f
 |------------------------|---------------------------|----------------------------------|
 | ca.crt,key             | kubernetes-ca             | Kubernetes 通用 CA                |
 | etcd/ca.crt,key        | etcd-ca                   | 与 etcd 相关的所有功能              |
-| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | 用于 [前端代理](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) |
+| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | 用于 [前端代理](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/) |

 上面的 CA 之外，还需要获取用于服务账户管理的密钥对，也就是 `sa.key` 和 `sa.pub`。

@@ -181,7 +181,7 @@ the load balancer stable IP and/or DNS name, `kubernetes`, `kubernetes.default`,
 where `kind` maps to one or more of the [x509 key usage](https://pkg.go.dev/k8s.io/api/certificates/v1beta1#KeyUsage) types:
 -->
 [1]: 用来连接到集群的不同 IP 或 DNS 名
-（就像 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 为负载均衡所使用的固定
+（就像 [kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/) 为负载均衡所使用的固定
 IP 或 DNS 名，`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、
 `kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`）。

@@ -228,7 +228,7 @@ Paths should be specified using the given argument regardless of location.
 -->
 ### 证书路径    {#certificate-paths}

-证书应放置在建议的路径中（以便 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/)
+证书应放置在建议的路径中（以便 [kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/)
 使用）。无论使用什么位置，都应使用给定的参数指定路径。

 <!--
@@ -286,7 +286,7 @@ Same considerations apply for the service account key pair:
 The following example illustrates the file paths [from the previous tables](/docs/setup/best-practices/certificates/#certificate-paths) you need to provide if you are generating all of your own keys and certificates:
 -->
 下面的例子展示了自行生成所有密钥和证书时所需要提供的文件路径。
-这些路径基于[前面的表格](/zh/docs/setup/best-practices/certificates/#certificate-paths)。
+这些路径基于[前面的表格](/zh-cn/docs/setup/best-practices/certificates/#certificate-paths)。

 ```console
 /etc/kubernetes/pki/etcd/ca.key
@@ -342,7 +342,7 @@ The value of `<nodeName>` for `kubelet.conf` **must** match precisely the value
 -->
 {{< note >}}
 `kubelet.conf` 中 `<nodeName>` 的值 **必须** 与 kubelet 向 apiserver 注册时提供的节点名称的值完全匹配。
-有关更多详细信息，请阅读[节点授权](/zh/docs/reference/access-authn-authz/node/)。
+有关更多详细信息，请阅读[节点授权](/zh-cn/docs/reference/access-authn-authz/node/)。
 {{< /note >}}

 <!--
@@ -138,8 +138,8 @@ See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/conf
 for details on configuring and managing etcd for a large cluster.
 -->
 有关为大型集群配置和管理 etcd 的详细信息，请参阅
-[为 Kubernetes 运行 etcd 集群](/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/)
-和使用 [kubeadm 创建一个高可用 etcd 集群](/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)。
+[为 Kubernetes 运行 etcd 集群](/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/)
+和使用 [kubeadm 创建一个高可用 etcd 集群](/zh-cn/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)。

 <!--
 ### Addon Resources
@@ -154,7 +154,7 @@ impact on other components. These resource limits apply to

  For example, you can set CPU and memory limits for a logging component:
 -->
-Kubernetes [资源限制](/zh/docs/concepts/configuration/manage-resources-containers/)
+Kubernetes [资源限制](/zh-cn/docs/concepts/configuration/manage-resources-containers/)
 有助于最大程度地减少内存泄漏的影响以及 Pod 和容器可能对其他组件的其他方式的影响。
 这些资源限制适用于{{< glossary_tooltip text="插件" term_id="addons" >}}资源，
 就像它们适用于应用程序工作负载一样。
@@ -17,7 +17,7 @@ weight: 40
 This page provides an overview of best practices when it comes to enforcing
 [Pod Security Standards](/docs/concepts/security/pod-security-standards).
 -->
-本页提供实施 [Pod 安全标准（Pod Security Standards）](/zh/docs/concepts/security/pod-security-standards)
+本页提供实施 [Pod 安全标准（Pod Security Standards）](/zh-cn/docs/concepts/security/pod-security-standards)
 时的一些最佳实践。

 <!-- body -->
@@ -33,7 +33,7 @@ This page provides an overview of best practices when it comes to enforcing
 The [Pod Security Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
 intends to replace the deprecated PodSecurityPolicies. 
 -->
-[Pod 安全性准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
+[Pod 安全性准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
 尝试替换已被废弃的 PodSecurityPolicies。

 <!--
@@ -58,7 +58,7 @@ we provide an [example](/docs/concepts/security/pod-security-admission/#applying
 that illustrates how the PodSecurity labels can be applied in bulk.
 -->
 针对所有名字空间中的所有负载都具有相同的安全性需求的场景，
-我们提供了一个[示例](/zh/docs/concepts/security/pod-security-admission/#applying-to-all-namespaces)
+我们提供了一个[示例](/zh-cn/docs/concepts/security/pod-security-admission/#applying-to-all-namespaces)
 用来展示如何批量应用 Pod 安全性标签。

 <!--
@@ -53,7 +53,7 @@ component.
 -->
 ## 控制面行为   {#control-plane-behavior}

-所有的[控制面组件](/zh/docs/concepts/overview/components/#control-plane-components)
+所有的[控制面组件](/zh-cn/docs/concepts/overview/components/#control-plane-components)
 都支持以一组可相互替换的资源池的形式来运行，每个组件都有多个副本。

 <!--
@@ -108,7 +108,7 @@ These labels can include
 -->
 节点启动时，每个节点上的 kubelet 会向 Kubernetes API 中代表该 kubelet 的 Node 对象
 添加 {{< glossary_tooltip text="标签" term_id="label" >}}。
-这些标签可能包含[区信息](/zh/docs/reference/labels-annotations-taints/#topologykubernetesiozone)。
+这些标签可能包含[区信息](/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesiozone)。

 <!--
 If your cluster spans multiple zones or regions, you can use node labels
@@ -122,7 +122,7 @@ Pods for better expected availability, reducing the risk that a correlated
 failure affects your whole workload.
 -->
 如果你的集群跨了多个可用区或者地理区域，你可以使用节点标签，结合
-[Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+[Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
 来控制如何在你的集群中多个失效域之间分布 Pods。这里的失效域可以是
 地理区域、可用区甚至是特定节点。
 这些提示信息使得{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}
@@ -178,7 +178,7 @@ You can apply [node selector constraints](/docs/concepts/scheduling-eviction/ass
 to Pods that you create, as well as to Pod templates in workload resources
 such as Deployment, StatefulSet, or Job.
 -->
-你可以应用[节点选择算符约束](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
+你可以应用[节点选择算符约束](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
 到你所创建的 Pods 上，或者为 Deployment、StatefulSet 或 Job 这类工作负载资源
 中的 Pod 模板设置此类约束。

@@ -195,7 +195,7 @@ are only placed into the same zone as that volume.
 ## 跨区的存储访问

 当创建持久卷时，`PersistentVolumeLabel` 
-[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
+[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)
 会自动向那些链接到特定区的 PersistentVolume 添加区标签。
 {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}通过其
 `NoVolumeZoneConflict` 断言确保申领给定 PersistentVolume 的 Pods 只会
@@ -211,7 +211,7 @@ see [Allowed topologies](/docs/concepts/storage/storage-classes/#allowed-topolog
 你可以为 PersistentVolumeClaim 指定{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}
 以设置该类中的存储可以使用的失效域（区）。
 要了解如何配置能够感知失效域或区的 StorageClass，请参阅
-[可用的拓扑逻辑](/zh/docs/concepts/storage/storage-classes/#allowed-topologies)。
+[可用的拓扑逻辑](/zh-cn/docs/concepts/storage/storage-classes/#allowed-topologies)。

 <!--
 ## Networking
@@ -227,7 +227,7 @@ Check your cloud provider's documentation for details.
 ## 网络  {#networking}

 Kubernetes 自身不提供与可用区相关的联网配置。
-你可以使用[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+你可以使用[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
 来配置集群的联网，该网络解决方案可能拥有一些与可用区相关的元素。
 例如，如果你的云提供商支持 `type=LoadBalancer` 的 Service，则负载均衡器
 可能仅会将请求流量发送到运行在负责处理给定连接的负载均衡器组件所在的区。
@@ -278,5 +278,5 @@ To learn how the scheduler places Pods in a cluster, honoring the configured con
 visit [Scheduling and Eviction](/docs/concepts/scheduling-eviction/).
 -->
 要了解调度器如何在集群中放置 Pods 并遵从所配置的约束，可参阅
-[调度与驱逐](/zh/docs/concepts/scheduling-eviction/)。
+[调度与驱逐](/zh-cn/docs/concepts/scheduling-eviction/)。