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

2022-06-23 20:18:40 +08:00
parent e0d6f94bf6
commit 5f0ec40aaa
29 changed files with 260 additions and 260 deletions
@@ -21,7 +21,7 @@ application configuration, and migration.
 独一无二的 IP 地址，
 这就意味着你不需要显式地在 `Pod` 之间创建链接，你几乎不需要处理容器端口到主机端口之间的映射。
 这将形成一个干净的、向后兼容的模型；在这个模型里，从端口分配、命名、服务发现、
-[负载均衡](/zh/docs/concepts/services-networking/ingress/#load-balancing)、
+[负载均衡](/zh-cn/docs/concepts/services-networking/ingress/#load-balancing)、
 应用配置和迁移的角度来看，`Pod` 可以被视作虚拟机或者物理主机。

 <!--
@@ -82,7 +82,7 @@ You can read more about the [Kubernetes Networking Model](/docs/concepts/cluster
 Pod 或节点上使用 IP 的方式访问到它们。
 如果你想的话，你依然可以将宿主节点的某个端口的流量转发到 Pod 中，但是出于网络模型的原因，你不必这么做。

-如果对此好奇，请参考 [Kubernetes 网络模型](/zh/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model)。
+如果对此好奇，请参考 [Kubernetes 网络模型](/zh-cn/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model)。

 <!--
 ## Creating a Service
@@ -193,7 +193,7 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip

 现在，你应该能够从集群中任意节点上使用 curl 命令向 `<CLUSTER-IP>:<PORT>` 发送请求以访问 Nginx Service。
 注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇，
-可以进一步阅读[服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
+可以进一步阅读[服务代理](/zh-cn/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)
 的内容。

 <!--
@@ -312,7 +312,7 @@ IP 分配名称的 DNS 服务器。 这里我们使用 CoreDNS 集群插件（
 所以在集群中的任何 Pod 中，你都可以使用标准方法（例如：`gethostbyname()`）与该 Service 通信。
 如果 CoreDNS 没有在运行，你可以参照
 [CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes)
-或者[安装 CoreDNS](/zh/docs/tasks/administer-cluster/coredns/#installing-coredns) 来启用它。
+或者[安装 CoreDNS](/zh-cn/docs/tasks/administer-cluster/coredns/#installing-coredns) 来启用它。
 让我们运行另一个 curl 应用来进行测试：

 ```shell
@@ -357,7 +357,7 @@ You can acquire all these from the [nginx https example](https://github.com/kube

 * 用于 HTTPS 的自签名证书（除非已经有了一个身份证书）
 * 使用证书配置的 Nginx 服务器
-* 使 Pod 可以访问证书的 [Secret](/zh/docs/concepts/configuration/secret/)
+* 使 Pod 可以访问证书的 [Secret](/zh-cn/docs/concepts/configuration/secret/)

 你可以从
 [Nginx https 示例](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/)获取所有上述内容。
@@ -620,6 +620,6 @@ LoadBalancer Ingress:   a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
 * Learn more about [Connecting a Front End to a Back End Using a Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/)
 * Learn more about [Creating an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)
 -->
-* 进一步了解如何[使用 Service 访问集群中的应用](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)
-* 进一步了解如何[使用 Service 将前端连接到后端](/zh/docs/tasks/access-application-cluster/connecting-frontend-backend/)
-* 进一步了解如何[创建外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)
+* 进一步了解如何[使用 Service 访问集群中的应用](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/)
+* 进一步了解如何[使用 Service 将前端连接到后端](/zh-cn/docs/tasks/access-application-cluster/connecting-frontend-backend/)
+* 进一步了解如何[创建外部负载均衡器](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/)
@@ -168,7 +168,7 @@ of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`
 #### SRV 记录  {#srv-records}

 Kubernetes 根据普通 Service 或
-[Headless Service](/zh/docs/concepts/services-networking/service/#headless-services)
+[Headless Service](/zh-cn/docs/concepts/services-networking/service/#headless-services)
 中的命名端口创建 SRV 记录。每个命名端口，
 SRV 记录格式为 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`。
 普通 Service，该记录会被解析成端口号和域名：`my-svc.my-namespace.svc.cluster-domain.example`。
@@ -370,7 +370,7 @@ Pod 会一直出于 `Pending` 状态（通过 `kubectl` 所看到的 `ContainerC
 （无法基于 Pod 主机名和集群域名构造 FQDN，FQDN `long-FQDN` 过长，至多 64
 字符，请求字符数为 70）。
 对于这种场景而言，改善用户体验的一种方式是创建一个
-[准入 Webhook 控制器](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)，
+[准入 Webhook 控制器](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)，
 在用户创建顶层对象（如 Deployment）的时候控制 FQDN 的长度。
 {{< /note >}}

@@ -405,11 +405,11 @@ DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod
 这些策略可以在 Pod 规约中的 `dnsPolicy` 字段设置：

 - "`Default`": Pod 从运行所在的节点继承名称解析配置。参考
-  [相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers)
+  [相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers)
  获取更多信息。
 - "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "www.kubernetes.io"）
  都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。
-  参阅[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers)
+  参阅[相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers)
  了解在这些场景中如何处理 DNS 查询的信息。
 - "`ClusterFirstWithHostNet`"：对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略
  "`ClusterFirstWithHostNet`"。
@@ -609,5 +609,5 @@ For guidance on administering DNS configurations, check
 [Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/)
 -->
 有关管理 DNS 配置的指导，请查看
-[配置 DNS 服务](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/)
+[配置 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/)

@@ -82,7 +82,7 @@ Kubernetes Service.
 这些 EndpointSlice 将包含对与 Service 选择算符匹配的所有 Pod 的引用。
 EndpointSlice 通过唯一的协议、端口号和 Service 名称将网络端点组织在一起。
 EndpointSlice 的名称必须是合法的
-[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)。

 例如，下面是 Kubernetes Service `example` 的 EndpointSlice 资源示例。

@@ -459,5 +459,5 @@ implementation in `kube-proxy`.
 <!--
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
 -->
-* 阅读[使用 Service 连接到应用](/zh/docs/concepts/services-networking/connect-applications-service/)
+* 阅读[使用 Service 连接到应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/)

@@ -143,13 +143,13 @@ You may deploy any number of ingress controllers using [ingress class](/docs/con
 within a cluster. Note the `.metadata.name` of your ingress class resource. When you create an ingress you would need that name to specify the `ingressClassName` field on your Ingress object (refer to [IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec). `ingressClassName` is a replacement of the older [annotation method](/docs/concepts/services-networking/ingress/#deprecated-annotation).
 -->
 你可以使用
-[Ingress 类](/zh/docs/concepts/services-networking/ingress/#ingress-class)在集群中部署任意数量的
+[Ingress 类](/zh-cn/docs/concepts/services-networking/ingress/#ingress-class)在集群中部署任意数量的
 Ingress 控制器。
 请注意你的 Ingress 类资源的 `.metadata.name` 字段。
 当你创建 Ingress 时，你需要用此字段的值来设置 Ingress 对象的 `ingressClassName` 字段（请参考
 [IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec)）。
 `ingressClassName`
-是之前的[注解](/zh/docs/concepts/services-networking/ingress/#deprecated-annotation)做法的替代。
+是之前的[注解](/zh-cn/docs/concepts/services-networking/ingress/#deprecated-annotation)做法的替代。

 <!--
 If you do not specify an IngressClass for an Ingress, and your cluster has exactly one IngressClass marked as default, then Kubernetes [applies](/docs/concepts/services-networking/ingress/#default-ingress-class) the cluster's default IngressClass to the Ingress.
@@ -160,10 +160,10 @@ controllers operate slightly differently.
 -->
 如果你不为 Ingress 指定 IngressClass，并且你的集群中只有一个 IngressClass 被标记为默认，那么
 Kubernetes 会将此集群的默认 IngressClass
-[应用](/zh/docs/concepts/services-networking/ingress/#default-ingress-class)到 Ingress 上。
+[应用](/zh-cn/docs/concepts/services-networking/ingress/#default-ingress-class)到 Ingress 上。
 IngressClass。
 你可以通过将
-[`ingressclass.kubernetes.io/is-default-class` 注解](/zh/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class)
+[`ingressclass.kubernetes.io/is-default-class` 注解](/zh-cn/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class)
 的值设置为 `"true"` 来将一个 IngressClass 标记为集群默认。

 理想情况下，所有 Ingress 控制器都应满足此规范，但各种 Ingress 控制器的操作略有不同。
@@ -181,6 +181,6 @@ Make sure you review your ingress controller's documentation to understand the c
 * Learn more about [Ingress](/docs/concepts/services-networking/ingress/).
 * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube).
 -->
-* 进一步了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)。
-* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube)。
+* 进一步了解 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)。
+* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/zh-cn/docs/tasks/access-application-cluster/ingress-minikube)。

@@ -36,7 +36,7 @@ For clarity, this guide defines the following terms:
  在此示例和在大多数常见的 Kubernetes 部署环境中，集群中的节点都不在公共网络中。
 * 边缘路由器（Edge Router）: 在集群中强制执行防火墙策略的路由器。可以是由云提供商管理的网关，也可以是物理硬件。
 * 集群网络（Cluster Network）: 一组逻辑的或物理的连接，根据 Kubernetes
-  [网络模型](/zh/docs/concepts/cluster-administration/networking/)在集群内实现通信。
+  [网络模型](/zh-cn/docs/concepts/cluster-administration/networking/)在集群内实现通信。
 * 服务（Service）：Kubernetes {{< glossary_tooltip term_id="service" >}}，
  使用{{< glossary_tooltip text="标签" term_id="label" >}}选择器（selectors）辨认一组 Pod。
  除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。
@@ -51,7 +51,7 @@ Traffic routing is controlled by rules defined on the Ingress resource.
 ## Ingress 是什么？  {#what-is-ingress}

 [Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
-公开从集群外部到集群内[服务](/zh/docs/concepts/services-networking/service/)的
+公开从集群外部到集群内[服务](/zh-cn/docs/concepts/services-networking/service/)的
 HTTP 和 HTTPS 路由。
 流量路由由 Ingress 资源上定义的规则控制。

@@ -66,7 +66,7 @@ Here is a simple example where an Ingress sends all its traffic to one Service:
 An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic.
 -->
 Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及基于名称的虚拟托管。
-[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)
+[Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)
 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。

 <!-- 
@@ -76,8 +76,8 @@ uses a service of type [Service.Type=NodePort](/docs/concepts/services-networkin
 -->
 Ingress 不会公开任意端口或协议。
 将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用
-[Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport)
-或 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer)
+[Service.Type=NodePort](/zh-cn/docs/concepts/services-networking/service/#type-nodeport)
+或 [Service.Type=LoadBalancer](/zh-cn/docs/concepts/services-networking/service/#loadbalancer)
 类型的 Service。

 <!--
@@ -87,7 +87,7 @@ You must have an [ingress controller](/docs/concepts/services-networking/ingress
 -->
 ## 环境准备

-你必须拥有一个 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。
+你必须拥有一个 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。
 仅创建 Ingress 资源本身没有任何效果。

 <!-- 
@@ -95,7 +95,7 @@ You may need to deploy an Ingress controller such as [ingress-nginx](https://kub
 [Ingress controllers](/docs/concepts/services-networking/ingress-controllers).
 -->
 你可能需要部署 Ingress 控制器，例如 [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)。
-你可以从许多 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 中进行选择。
+你可以从许多 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers) 中进行选择。

 <!-- 
 Ideally, all Ingress controllers should fit the reference specification. In reality, the various Ingress
@@ -133,13 +133,13 @@ Different [Ingress controllers](/docs/concepts/services-networking/ingress-contr
 your choice of Ingress controller to learn which annotations are supported.
 -->
 Ingress 需要指定 `apiVersion`、`kind`、 `metadata`和 `spec` 字段。
-Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
-关于如何使用配置文件，请参见[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、
-[配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)、
-[管理资源](/zh/docs/concepts/cluster-administration/manage-deployment/)。
+Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+关于如何使用配置文件，请参见[部署应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)、
+[配置容器](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)、
+[管理资源](/zh-cn/docs/concepts/cluster-administration/manage-deployment/)。
 Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress
 控制器，例如[重写目标注解](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。
-不同的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)支持不同的注解。
+不同的 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)支持不同的注解。
 查看你所选的 Ingress 控制器的文档，以了解其支持哪些注解。

 <!-- 
@@ -195,7 +195,7 @@ Each HTTP rule contains the following information:
  如果提供了 `host`（例如 foo.bar.com），则 `rules` 适用于该 `host`。
 * 路径列表 paths（例如，`/testpath`）,每个路径都有一个由 `serviceName` 和 `servicePort` 定义的关联后端。
  在负载均衡器将流量定向到引用的服务之前，主机和路径都必须匹配传入请求的内容。
-* `backend`（后端）是 [Service 文档](/zh/docs/concepts/services-networking/service/)中所述的服务和端口名称的组合。
+* `backend`（后端）是 [Service 文档](/zh-cn/docs/concepts/services-networking/service/)中所述的服务和端口名称的组合。
  与规则的 `host` 和 `path` 匹配的对 Ingress 的 HTTP（和 HTTPS ）请求将发送到列出的 `backend`。

 <!-- 
@@ -224,7 +224,7 @@ routed to your default backend.
 没有设置规则的 Ingress 将所有流量发送到同一个默认后端，而
 `.spec.defaultBackend` 则是在这种情况下处理请求的那个默认后端。
 `defaultBackend` 通常是
-[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)的配置选项，而非在
+[Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)的配置选项，而非在
 Ingress 资源中指定。
 如果未设置任何的 `.spec.rules`，那么必须指定 `.spec.defaultBackend`。
 如果未设置 `defaultBackend`，那么如何处理所有与规则不匹配的流量将交由
@@ -524,7 +524,7 @@ that is used for a workload. If you used a cluster-scoped parameter then either:
 网关定义）。如果你使用集群作用域的参数，那么你必须从以下两项中选择一项执行：

 - 每次修改配置，集群操作团队需要批准其他团队的修改。
- 集群操作团队定义具体的准入控制，比如 [RBAC](/zh/docs/reference/access-authn-authz/rbac/)
+- 集群操作团队定义具体的准入控制，比如 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)
  角色与角色绑定，以使得应用程序团队可以修改集群作用域的配置参数资源。

 <!--
@@ -739,8 +739,8 @@ you are using, you may need to create a default-http-backend
 [Service](/docs/concepts/services-networking/service/).
 -->
 {{< note >}}
-取决于你所使用的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)，
-你可能需要创建默认 HTTP 后端[服务](/zh/docs/concepts/services-networking/service/)。
+取决于你所使用的 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)，
+你可能需要创建默认 HTTP 后端[服务](/zh-cn/docs/concepts/services-networking/service/)。
 {{< /note >}}

 <!--
@@ -881,7 +881,7 @@ specific documentation to see how they handle health checks (
 -->
 值得注意的是，尽管健康检查不是通过 Ingress 直接暴露的，在 Kubernetes
 中存在并行的概念，比如
-[就绪检查](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)，
+[就绪检查](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)，
 允许你实现相同的目的。
 请检查特定控制器的说明文档（[nginx](https://git.k8s.io/ingress-nginx/README.md)、
 [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)）以了解它们是怎样处理健康检查的。
@@ -1000,7 +1000,7 @@ Please check the documentation of the relevant [Ingress controller](/docs/concep
 ## 跨可用区失败  {#failing-across-availability-zones}

 不同的云厂商使用不同的技术来实现跨故障域的流量分布。详情请查阅相关 Ingress 控制器的文档。
-请查看相关 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。
+请查看相关 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。

 <!--
 ## Alternatives
@@ -1015,8 +1015,8 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
 * Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
 * Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
 -->
-* 使用 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer)
-* 使用 [Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#nodeport)
+* 使用 [Service.Type=LoadBalancer](/zh-cn/docs/concepts/services-networking/service/#loadbalancer)
+* 使用 [Service.Type=NodePort](/zh-cn/docs/concepts/services-networking/service/#nodeport)

 ## {{% heading "whatsnext" %}}

@@ -1026,6 +1026,6 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
 * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube/)
 -->
 * 进一步了解 [Ingress](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API
-* 进一步了解 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/)
-* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube/)
+* 进一步了解 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers/)
+* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh-cn/docs/tasks/access-application-cluster/ingress-minikube/)

@@ -58,7 +58,7 @@ Network policies are implemented by the [network plugin](/docs/concepts/extend-k
 -->
 ## 前置条件   {#prerequisites}

-网络策略通过[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+网络策略通过[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
 来实现。要使用网络策略，你必须使用支持 NetworkPolicy 的网络解决方案。
 创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。

@@ -144,8 +144,8 @@ __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the g
 -->
 __必需字段__：与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、
 `kind` 和 `metadata` 字段。关于配置文件操作的一般信息，请参考
-[配置 Pod 以使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/),
-和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。
+[配置 Pod 以使用 ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/),
+和[对象管理](/zh-cn/docs/concepts/overview/working-with-objects/object-management)。

 __spec__：NetworkPolicy [规约](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
 中包含了在一个名字空间中定义特定网络策略所需的所有信息。
@@ -204,7 +204,7 @@ See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-
 3. （Egress 规则）允许 “default” 命名空间中任何带有标签 “role=db” 的 Pod 到 CIDR
   10.0.0.0/24 下 5978 TCP 端口的连接。

-参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)演练
+参阅[声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/)演练
 了解更多示例。

 <!--
@@ -422,7 +422,7 @@ When the feature gate is enabled, you can set the `protocol` field of a NetworkP
 作为一个稳定特性，SCTP 支持默认是被启用的。
 要在集群层面禁用 SCTP，你（或你的集群管理员）需要为 API 服务器指定
 `--feature-gates=SCTPSupport=false,...`
-来禁用 `SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+来禁用 `SCTPSupport` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
 启用该特性门控后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。

 {{< note >}}
@@ -494,7 +494,7 @@ The following restrictions apply when using this field:
  范围内禁止使用 `endPort` 字段，你（或者你的集群管理员）需要为 API
  服务器设置 `--feature-gates=NetworkPolicyEndPort=false,...` 以禁用
  `NetworkPolicyEndPort`
-  [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+  [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
 * `endPort` 字段必须等于或者大于 `port` 字段的值。
 * 两个字段的设置值都只能是数字。

@@ -508,7 +508,7 @@ the policy will be applied only for the single `port` field.
 -->
 你的集群所使用的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件
 必须支持在 NetworkPolicy 规约中使用 `endPort` 字段。
-如果你的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+如果你的[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
 不支持 `endPort` 字段，而你指定了一个包含 `endPort` 字段的 NetworkPolicy，
 策略只对单个 `port` 字段生效。
 {{< /note >}}
@@ -530,7 +530,7 @@ While NetworkPolicy cannot target a namespace by its name with some object field
 standardized label to target a specific namespace.
 -->
 只要 `NamespaceDefaultLabelName`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
 被启用，Kubernetes 控制面会在所有名字空间上设置一个不可变更的标签
 `kubernetes.io/metadata.name`。该标签的值是名字空间的名称。

@@ -588,7 +588,7 @@ As of Kubernetes {{< skew latestVersion >}}, the following functionality does no
  walkthrough for further examples.
 - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource.
 -->
- 参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
+- 参阅[声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/)
  演练了解更多示例；
 - 有关 NetworkPolicy 资源所支持的常见场景的更多信息，请参见
  [此指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。
@@ -25,7 +25,7 @@ introduced in Kubernetes v1.21, provide similar functionality.
 -->
 此功能特性，尤其是 Alpha 阶段的 `topologyKeys` API，在 Kubernetes v1.21
 版本中已被废弃。Kubernetes v1.21 版本中引入的
-[拓扑感知的提示](/zh/docs/concepts/services-networking/topology-aware-hints/),
+[拓扑感知的提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints/),
 提供类似的功能。
 {{</ note >}}

@@ -104,7 +104,7 @@ as the last value in the list.
 ## 使用服务拓扑 {#using-service-topology}

 如果集群启用了 `ServiceTopology`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
 你就可以在 Service 规约中设定 `topologyKeys` 字段，从而控制其流量路由。
 此字段是 `Node` 标签的优先顺序字段，将用于在访问这个 `Service` 时对端点进行排序。
 流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`。
@@ -300,6 +300,6 @@ spec:
 * Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology)
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
 -->
-* 阅读关于[启用服务拓扑](/zh/docs/tasks/administer-cluster/enabling-service-topology/)
-* 阅读[用服务连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/)
+* 阅读关于[启用服务拓扑](/zh-cn/docs/tasks/administer-cluster/enabling-service-topology/)
+* 阅读[用服务连接应用程序](/zh-cn/docs/concepts/services-networking/connect-applications-service/)

@@ -43,7 +43,7 @@ When the feature is enabled, you can enable the internal-only traffic policy for
 This tells kube-proxy to only use node local endpoints for cluster internal traffic.
 -->
 `ServiceInternalTrafficPolicy` 
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 是 Beta 功能，默认启用。
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 是 Beta 功能，默认启用。
 启用该功能后，你就可以通过将 {{< glossary_tooltip text="Services" term_id="service" >}} 的 
 `.spec.internalTrafficPolicy` 项设置为 `Local`，
 来为它指定一个内部专用的流量策略。
@@ -99,7 +99,7 @@ When the [feature gate](/docs/reference/command-line-tools-reference/feature-gat
 kube-proxy 基于 `spec.internalTrafficPolicy` 的设置来过滤路由的目标服务端点。
 当它的值设为 `Local` 时，只选择节点本地的服务端点。
 当它的值设为 `Cluster` 或缺省时，则选择所有的服务端点。
-启用[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
 `ServiceInternalTrafficPolicy` 后，
 `spec.internalTrafficPolicy` 的值默认设为 `Cluster`。

@@ -123,6 +123,6 @@ kube-proxy 基于 `spec.internalTrafficPolicy` 的设置来过滤路由的目标
 * Read about [Service External Traffic Policy](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
 -->
-* 请阅读[拓扑感知提示](/zh/docs/concepts/services-networking/topology-aware-hints)
-* 请阅读[Service 的外部流量策略](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)
-* 请阅读[用 Service 连接应用](/zh/docs/concepts/services-networking/connect-applications-service/)
+* 请阅读[拓扑感知提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints)
+* 请阅读[Service 的外部流量策略](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)
+* 请阅读[用 Service 连接应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/)
@@ -320,7 +320,7 @@ The name of the Endpoints object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 -->
 Endpoints 对象的名称必须是合法的
-[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 create an [Endpoints](docs/reference/kubernetes-api/service-resources/endpoints-v1/)
@@ -401,7 +401,7 @@ EndpointSlices 是一种 API 资源，可以为 Endpoints 提供更可扩展的
 届时将创建其他 EndpointSlices 来存储任何其他 Endpoints。

 EndpointSlices 提供了附加的属性和功能，这些属性和功能在
-[EndpointSlices](/zh/docs/concepts/services-networking/endpoint-slices/)
+[EndpointSlices](/zh-cn/docs/concepts/services-networking/endpoint-slices/)
 中有详细描述。

 <!-- 
@@ -546,7 +546,7 @@ having traffic sent via kube-proxy to a Pod that's known to have failed.
 这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败，
 并会自动使用其他后端 Pod 重试。

-你可以使用 Pod [就绪探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
+你可以使用 Pod [就绪探测器](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
 验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。
 这样做意味着你避免将流量通过 kube-proxy 发送到已知已失败的 Pod。

@@ -752,7 +752,7 @@ has local endpoints and whether or not all the local endpoints are marked as ter
 -->

 如果你启用了 kube-proxy 的 `ProxyTerminatingEndpoints`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
 kube-proxy 会检查节点是否有本地的端点，以及是否所有的本地端点都被标记为终止中。

 <!--
@@ -864,7 +864,7 @@ Services and creates a set of DNS records for each one.  If DNS has been enabled
 throughout your cluster then all Pods should automatically be able to resolve
 Services by their DNS name.
 -->
-你可以（几乎总是应该）使用[附加组件](/zh/docs/concepts/cluster-administration/addons/)
+你可以（几乎总是应该）使用[附加组件](/zh-cn/docs/concepts/cluster-administration/addons/)
 为 Kubernetes 集群设置 DNS 服务。

 支持集群的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。
@@ -905,7 +905,7 @@ Kubernetes 还支持命名端口的 DNS SRV（服务）记录。

 Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的 Service 的方式。
 更多关于 `ExternalName` 信息可以查看
-[DNS Pod 和 Service](/zh/docs/concepts/services-networking/dns-pod-service/)。
+[DNS Pod 和 Service](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。

 <!--
 ## Headless Services  {#headless-services}
@@ -1023,7 +1023,7 @@ Kubernetes `ServiceTypes` 允许指定你所需要的 Service 类型，默认是
 <!--
 You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple services under the same IP address.
 -->
-你也可以使用 [Ingress](/zh/docs/concepts/services-networking/ingress/) 来暴露自己的服务。
+你也可以使用 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) 来暴露自己的服务。
 Ingress 不是一种服务类型，但它充当集群的入口点。
 它可以将路由规则整合到一个资源中，因为它可以在同一IP地址下公开多个服务。

@@ -1735,10 +1735,10 @@ groups are modified with the following IP rules:
 -->

 为了获得均衡流量，请使用 DaemonSet 或指定
-[Pod 反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
+[Pod 反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
 使其不在同一节点上。

-你还可以将 NLB 服务与[内部负载平衡器](/zh/docs/concepts/services-networking/service/#internal-load-balancer)
+你还可以将 NLB 服务与[内部负载平衡器](/zh-cn/docs/concepts/services-networking/service/#internal-load-balancer)
 注解一起使用。

 为了使客户端流量能够到达 NLB 后面的实例，使用以下 IP 规则修改了节点安全组：
@@ -2089,7 +2089,7 @@ assigned from the lower band.
 This allows users to use the lower band of the `service-cluster-ip-range` for their
 Services with static IPs assigned with a very low risk of running into conflicts.
 -->
-如果启用 `ServiceIPStaticSubrange`[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
+如果启用 `ServiceIPStaticSubrange`[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
 分配策略根据配置的 `service-cluster-ip-range` 的大小，使用以下公式
 `min(max(16, cidrSize / 16), 256)` 进行划分，该公式可描述为
 “在不小于 16 且不大于 256 之间有一个步进量（Graduated Step）”，将
@@ -2351,7 +2351,7 @@ followed by the data from the client.
 * Read about [Ingress](/docs/concepts/services-networking/ingress/)
 * Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/)
 -->
-* 阅读[使用服务访问应用](/zh/docs/concepts/services-networking/connect-applications-service/)
-* 阅读了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)
-* 阅读了解[端点切片（Endpoint Slices）](/zh/docs/concepts/services-networking/endpoint-slices/)
+* 阅读[使用服务访问应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/)
+* 阅读了解 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)
+* 阅读了解[端点切片（Endpoint Slices）](/zh-cn/docs/concepts/services-networking/endpoint-slices/)

@@ -41,7 +41,7 @@ by default. To try out this feature, you have to enable the `TopologyAwareHints`
 {{< note >}}
 “拓扑感知提示”特性处于 Beta 阶段，并且默认情况下**未**启用。 
 要试用此特性，你必须启用 `TopologyAwareHints`
-[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
 {{< /note >}}

 <!-- body -->
@@ -117,7 +117,7 @@ as many endpoints to the zone with 2 CPU cores.
 此特性开启后，EndpointSlice 控制器负责在 EndpointSlice 上设置提示信息。
 控制器按比例给每个区域分配一定比例数量的端点。
 这个比例来源于此区域中运行节点的
-[可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
+[可分配](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
 CPU 核心数。
 例如，如果一个区域拥有 2 CPU 核心，而另一个区域只有 1 CPU 核心，
 那控制器将给那个有 2 CPU 的区域分配两倍数量的端点。
@@ -292,4 +292,4 @@ Kubernetes 控制平面和每个节点上的 kube-proxy，在使用拓扑感知
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
 -->

-* 参阅[通过服务连通应用](/zh/docs/concepts/services-networking/connect-applications-service/)
+* 参阅[通过服务连通应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/)
@@ -42,7 +42,7 @@ is responsible for the management of networking resources such as:
 -->
 ## Windows 容器网络 {#networking}

-Windows 容器网络通过 [CNI 插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)暴露。
+Windows 容器网络通过 [CNI 插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)暴露。
 Windows 容器网络的工作方式与虚拟机类似。
 每个容器都有一个连接到 Hyper-V 虚拟交换机（vSwitch）的虚拟网络适配器（vNIC）。
 主机网络服务（Host Networking Service，HNS）和主机计算服务（Host Comute Service，HCS）