[zh]Update blog pages(2018-2022) for links with '/zh/' prefix, using new prefix '/zh-cn/'

2022-06-23 19:49:21 +08:00
parent e0d6f94bf6
commit 06b6a2dc6a
25 changed files with 90 additions and 90 deletions
@@ -87,7 +87,7 @@ customized Corefile for you, including all of the configuration for stub domains
 在 CoreDNS 中，您可以类似地修改 CoreDNS [Corefile](https://coredns.io/2017/07/23/corefile-explained/) 的 ConfigMap，以更改服务发现的工作方式。这种 Corefile 配置提供了比 kube-dns 中更多的选项，因为它是 CoreDNS 用于配置所有功能的主要配置文件，即使与 Kubernetes 不相关的功能也可以操作。

 使用 `kubeadm` 将 kube-dns 升级到 CoreDNS 时，现有的 ConfigMap 将被用来为您生成自定义的 Corefile，包括存根域、联盟和上游名称服务器的所有配置。更多详细信息，请参见
-[使用 CoreDNS 进行服务发现](/zh/docs/tasks/administer-cluster/coredns/)。
+[使用 CoreDNS 进行服务发现](/zh-cn/docs/tasks/administer-cluster/coredns/)。

 <!--
 ## Bug fixes and enhancements
@@ -58,7 +58,7 @@ Dynamic Kubelet configuration gives cluster administrators and service providers
 <!--
 Kubernetes v1.10 made it possible to configure the Kubelet via a beta [config file](/docs/tasks/administer-cluster/kubelet-config-file/) API. Kubernetes already provides the ConfigMap abstraction for storing arbitrary file data in the API server.
 -->
-Kubernetes v1.10 使得可以通过 Beta 版本的[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)
+Kubernetes v1.10 使得可以通过 Beta 版本的[配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)
 API 配置 kubelet。
 Kubernetes 已经提供了用于在 API 服务器中存储任意文件数据的 ConfigMap 抽象。

@@ -21,7 +21,7 @@ To learn more, see [Configure Liveness, Readiness and Startup Probes](/docs/task
 This article was originally written about an external tool to achieve the same task._
 -->
 **更新（2021 年 12 月）：** “Kubernetes 从 v1.23 开始具有内置 gRPC 健康探测。
-了解更多信息，请参阅[配置存活探针、就绪探针和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)。
+了解更多信息，请参阅[配置存活探针、就绪探针和启动探针](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)。
 本文最初是为有关实现相同任务的外部工具所写。”

 <!--
@@ -85,7 +85,7 @@ The RuntimeClass resource is an important foundation for surfacing runtime prope
 -->
 RuntimeClass 资源是将运行时属性显示到控制平面的重要基础。
 例如，要对具有支持不同运行时间的异构节点的集群实施调度程序支持，我们可以在 RuntimeClass 定义中添加
-[NodeAffinity](/zh/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)条件。
+[NodeAffinity](/zh-cn/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)条件。
 另一个需要解决的领域是管理可变资源需求以运行不同运行时的 Pod。
 [Pod Overhead 提案](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview)
 是一项较早的尝试，与 RuntimeClass 设计非常吻合，并且可能会进一步推广。
@@ -128,7 +128,7 @@ RuntimeClass will be under active development at least through 2019, and we’re
 -->

 - 试试吧！ 作为Alpha功能，还有一些其他设置步骤可以使用RuntimeClass。
-  有关如何使其运行，请参考 [RuntimeClass文档](/zh/docs/concepts/containers/runtime-class/#runtime-class) 。
+  有关如何使其运行，请参考 [RuntimeClass文档](/zh-cn/docs/concepts/containers/runtime-class/#runtime-class) 。
 - 查看 [RuntimeClass Kubernetes 增强建议](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) 以获取更多细节设计细节。
 - [沙盒隔离级别决策](https://docs.google.com/document/d/1fe7lQUjYKR0cijRmSbH_y0_l3CYPkwtQa5ViywuNo8Q/preview) 
  记录了最初使 RuntimeClass 成为 Pod 级别选项的思考过程。
@@ -8,7 +8,7 @@ date: 2019-04-26

 去年我们对 Kubernetes 网站进行了优化，加入了[多语言内容的支持](https://kubernetes.io/blog/2018/11/08/kubernetes-docs-updates-international-edition/)。贡献者们踊跃响应，加入了多种新的本地化内容：截至 2019 年 4 月，Kubernetes 文档有了 9 个不同语言的未完成版本，其中有 6 个是 2019 年加入的。在每个 Kubernetes 文档页面的上方，读者都可以看到一个语言选择器，其中列出了所有可用语言。

-不论是完成度最高的[中文版 v1.12](https://v1-12.docs.kubernetes.io/zh/)，还是最新加入的[葡萄牙文版 v1.14](https://kubernetes.io/pt/)，各语言的本地化内容还未完成，这是一个进行中的项目。如果读者有兴趣对现有本地化工作提供支持，请继续阅读。
+不论是完成度最高的[中文版 v1.12](https://v1-12.docs.kubernetes.io/zh-cn/)，还是最新加入的[葡萄牙文版 v1.14](https://kubernetes.io/pt/)，各语言的本地化内容还未完成，这是一个进行中的项目。如果读者有兴趣对现有本地化工作提供支持，请继续阅读。

 ## 什么是本地化

@@ -69,9 +69,9 @@ Standard labels are used by Kubernetes components to support some features. For
 The labels are reaching general availability in this release. Kubernetes components have been updated to populate the GA and beta labels and to react to both. However, if you are using the beta labels in your pod specs for features such as node affinity, or in your custom controllers, we recommend that you start migrating them to the new GA labels. You can find the documentation for the new labels here:
 -->

- [实例类型](/zh/docs/reference/labels-annotations-taints/#nodekubernetesioinstance-type)
- [地区](/zh/docs/reference/labels-annotations-taints/#topologykubernetesioregion)
- [区域](/zh/docs/reference/labels-annotations-taints/#topologykubernetesiozone)
+- [实例类型](/zh-cn/docs/reference/labels-annotations-taints/#nodekubernetesioinstance-type)
+- [地区](/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesioregion)
+- [区域](/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesiozone)

 <!--
 - [node.kubernetes.io/instance-type](/docs/reference/labels-annotations-taints/#nodekubernetesioinstance-type)
@@ -45,14 +45,14 @@ Most stateless systems, web servers for example, are created without the need to
 One of Kubernetes' responsibilities is to place "resources" (e.g, a disk or container) into the cluster and satisfy the constraints they request. For example: "I must be in availability zone _A_" (see [Running in multiple zones](/docs/setup/best-practices/multiple-zones/#nodes-are-labeled)), or "I can't be placed onto the same node as this other Pod" (see [Affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)).
 -->
 Kubernetes 的职责之一是将 "资源"（如磁盘或容器）放入集群中，并满足其请求的约束。
-例如。"我必须在可用性区域 _A_"（见[在多个区域运行](/zh/docs/setup/best-practices/multiple-zone/#nodes-are-labeled)），
+例如。"我必须在可用性区域 _A_"（见[在多个区域运行](/zh-cn/docs/setup/best-practices/multiple-zone/#nodes-are-labeled)），
 或者 "我不能被放置到与某个 Pod 相同的节点上"
-（见[亲和与反亲和](/zh/docs/setup/best-practices/multiple-zone/#nodes-are-labeled)）。
+（见[亲和与反亲和](/zh-cn/docs/setup/best-practices/multiple-zone/#nodes-are-labeled)）。

 <!--
 As an addition to those constraints, Kubernetes offers [Statefulsets](/docs/concepts/workloads/controllers/statefulset/) that provide identity to Pods as well as persistent storage that "follows" these identified pods. Identity in a StatefulSet is handled by an increasing integer at the end of a pod's name. It's important to note that this integer must always be contiguous: in a StatefulSet, if pods 1 and 3 exist then pod 2 must also exist.
 -->
-作为对这些约束的补充，Kubernetes 提供了 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/)，
+作为对这些约束的补充，Kubernetes 提供了 [StatefulSets](/zh-cn/docs/concepts/workloads/controllers/statefulset/)，
 为 Pod 提供身份，以及 "跟随" 这些指定 Pod 的持久化存储。
 在 StatefulSet 中，身份是由 Pod 名称末尾一个呈增序的整数处理的。
 值得注意的是，这个整数必须始终是连续的：在一个 StatefulSet 中，
@@ -115,7 +115,7 @@ Consider the cluster topology below:
 -->
 现在，请记住，规模为 _n_ 的 StatefulSet 中的 Pods 一定具有 `[0,n)` 范围内的 id。
 当把一个 StatefulSet 规模缩减了 _m_ 时，Kubernetes 会移除 _m_ 个 Pod，从最高的序号开始，向最低的序号移动，
-[与它们被添加的顺序相反](/zh/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees)。
+[与它们被添加的顺序相反](/zh-cn/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees)。
 考虑一下下面的集群拓扑结构。

 <!--
@@ -144,9 +144,9 @@ Our combined knowledge of the following is what lead to this misconception.
 * The behavior that a StatefulSet with _n_ replicas, when Pods are being deployed, they are created sequentially, in order from `{0..n-1}`. See [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees) for more details.
 -->
 我们对以下内容的综合认识是导致这种误解的原因。
-* Kubernetes [自动跨区分配 Pod](/zh/docs/setup/best-practices/multiple-zone/#pods-are-spread-across-zone) 的能力
+* Kubernetes [自动跨区分配 Pod](/zh-cn/docs/setup/best-practices/multiple-zone/#pods-are-spread-across-zone) 的能力
 * 一个有 _n_ 个副本的 StatefulSet，当 Pod 被部署时，它们会按照 `{0...n-1}` 的顺序依次创建。
-更多细节见 [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees)。
+更多细节见 [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees)。

 <!--
 Consider the following topology:
@@ -197,7 +197,7 @@ The entire endeavour was concerningly reminiscent of checking [caniuse.com](http

 虽然这似乎是一个完美的解决方案，但在写这篇文章的时候，Kubernetes 1.18 在公有云中两个最常见的
 托管 Kubernetes 服务（ EKS 和 GKE ）上是不可用的。
-此外，[Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)在 
+此外，[Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/)在 
 [1.18 中仍是测试版功能](https://v1-18.docs.kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/)，
 这意味着即使在 v1.18 可用时，它[也不能保证在托管集群中可用](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#kubernetes_feature_choices)。
 整个努力让人联想到在 Internet Explorer 8 还存在的时候访问 [caniuse.com](https://caniuse.com/)。
@@ -236,12 +236,12 @@ _[Chris Seto](https://twitter.com/_ostriches) is a software engineer at Cockroac
 ### 3. 编写一个自定义的 Kubernetes 调度器

 感谢 [Kelsey Hightower](https://github.com/kelseyhightower/scheduler) 的例子和 
-[Banzai Cloud](https://banzaicloud.com/blog/k8s-custom-scheduler/) 的博文，我们决定投入进去，编写自己的[自定义 Kubernetes 调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)。
+[Banzai Cloud](https://banzaicloud.com/blog/k8s-custom-scheduler/) 的博文，我们决定投入进去，编写自己的[自定义 Kubernetes 调度器](/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)。
 一旦我们的概念验证被部署和运行，我们很快就发现，Kubernetes 的调度器也负责将持久化卷映射到它所调度的 Pod 上。
-[`kubectl get events`](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/#verifying-that-the-pods-wer-scheduled-using-the-desired-schedulers)
+[`kubectl get events`](/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers/#verifying-that-the-pods-wer-scheduled-using-the-desired-schedulers)
 的输出让我们相信有另一个系统在发挥作用。
 在我们寻找负责存储声明映射的组件的过程中，我们发现了 
-[kube-scheduler 插件系统](/zh/docs/concepts/scheduling-eviction/scheduling-framework/)。
+[kube-scheduler 插件系统](/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework/)。
 我们的下一个 POC 是一个"过滤器"插件，它通过 Pod 的序号来确定适当的可用区域，并且工作得非常完美。

 我们的[自定义调度器插件](https://github.com/cockroachlabs/crl-scheduler)是开源的，并在我们所有的 CockroachCloud 集群中运行。
@@ -14,7 +14,7 @@ slug: dockershim-faq
 <!--
 _**Update**: There is a [newer version](/blog/2022/02/17/dockershim-faq/) of this article available._
 -->
-_**更新**：本文有[较新版本](/zh/blog/2022/02/17/dockershim-faq/)。_
+_**更新**：本文有[较新版本](/zh-cn/blog/2022/02/17/dockershim-faq/)。_

 <!-- 
 This document goes over some frequently asked questions regarding the Dockershim
@@ -29,7 +29,7 @@ Also, you can read [check whether Dockershim removal affects you](/docs/tasks/ad
 关于 Kubernetes kubelets 从容器运行时的角度弃用 Docker 的细节以及这些细节背后的含义，请参考博文
 [别慌: Kubernetes 和 Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。

-此外，你可以阅读[检查 Dockershim 移除是否影响你](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)以检查它是否会影响你。
+此外，你可以阅读[检查 Dockershim 移除是否影响你](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)以检查它是否会影响你。

 <!-- 
 ### Why is dockershim being deprecated?
@@ -76,7 +76,7 @@ Yes, the only thing changing in 1.20 is a single warning log printed at [kubelet
 startup if using Docker as the runtime.
 -->
 当然可以，在 1.20 版本中仅有的改变就是：如果使用 Docker 运行时，启动 
-[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 
+[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 
 的过程中将打印一条警告日志。

 <!-- 
@@ -292,7 +292,7 @@ latter you can use newer container build options like [img], [buildah],
 -->
 另外还有一个需要关注的点，那就是当创建镜像时，系统维护或嵌入容器方面的任务将无法工作。
 对于前者，可以用 [`crictl`](https://github.com/kubernetes-sigs/cri-tools) 工具作为临时替代方案
-(参见[从 docker 命令映射到 crictl](/zh/docs/reference/tools/map-crictl-dockercli/))；
+(参见[从 docker 命令映射到 crictl](/zh-cn/docs/reference/tools/map-crictl-dockercli/))；
 对于后者，可以用新的容器创建选项，比如
 [cr](https://github.com/kubernetes-sigs/cri-tools)、
 [img](https://github.com/genuinetools/img)、
@@ -315,7 +315,7 @@ For instructions on how to use containerd and CRI-O with Kubernetes, see the
 Kubernetes documentation on [Container Runtimes]
 -->
 对于如何协同 Kubernetes 使用 containerd 和 CRI-O 的说明，参见 Kubernetes 文档中这部分：
-[容器运行时](/zh/docs/setup/production-environment/container-runtimes)。
+[容器运行时](/zh-cn/docs/setup/production-environment/container-runtimes)。

 <!-- 
 ### What if I have more questions?
@@ -21,7 +21,7 @@ For more information, read the [removal FAQ](/dockershim).
 You can also discuss the deprecation via a dedicated [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
 -->
 **更新**：Kubernetes 通过 `dockershim` 对 Docker 的支持现已移除。
-有关更多信息，请阅读[移除 FAQ](/zh/dockershim)。
+有关更多信息，请阅读[移除 FAQ](/zh-cn/dockershim)。
 你还可以通过专门的 [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917) 讨论弃用。

 <!-- 
@@ -217,4 +217,4 @@ Kubernetes 有很多变化中的功能，没有人是100%的专家。
 Looking for more answers? Check out our accompanying [Dockershim Removal FAQ](/blog/2022/02/17/dockershim-faq/) _(updated February 2022)_.
 -->
 还在寻求更多答案吗？请参考我们附带的
-[移除 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/) _(2022年2月更新)_。
+[移除 Dockershim 的常见问题](/zh-cn/blog/2020/12/02/dockershim-faq/) _(2022年2月更新)_。
@@ -56,7 +56,7 @@ evergreen: true
 请注意，作为新的内置命令，`kubectl debug` 优先于任何名为 “debug” 的 kubectl 插件。你必须重命名受影响的插件。

 <!-- Invocations using `kubectl alpha debug` are now deprecated and will be removed in a subsequent release. Update your scripts to use `kubectl debug`. For more information about `kubectl debug`, see [Debugging Running Pods](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/). -->
-`kubectl alpha debug` 现在不推荐使用，并将在后续版本中删除。更新你的脚本以使用 `kubectl debug`。 有关更多信息 `kubectl debug`，请参阅[调试正在运行的 Pod]((https://kubernetes.io/zh/docs/tasks/debug/debug-application/debug-running-pod/)。
+`kubectl alpha debug` 现在不推荐使用，并将在后续版本中删除。更新你的脚本以使用 `kubectl debug`。 有关更多信息 `kubectl debug`，请参阅[调试正在运行的 Pod]((https://kubernetes.io/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/)。

 <!-- ### Beta: API Priority and Fairness -->
 ### 测试版：API 优先级和公平性 {#beta-api-priority-and-fairness)
@@ -110,7 +110,7 @@ Kubernetes 社区写了一篇关于弃用的详细[博客文章](https://blog.k8
 新引入的 `ExecProbeTimeout` 特性门控所提供的修复使集群操作员能够恢复到以前的行为，但这种行为将在后续版本中锁定并删除。为了恢复到以前的行为，集群运营商应该将此特性门控设置为 `false`。

 <!-- Please review the updated documentation regarding [configuring probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) for more details. -->
-有关更多详细信息，请查看有关配置探针的[更新文档](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)。
+有关更多详细信息，请查看有关配置探针的[更新文档](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)。

 <!-- ## Other Updates -->
 ## 其他更新 {#other-updates}
@@ -36,7 +36,7 @@ What does dual-stack networking mean for you? Let’s take a look…
 <!--
 [Services](/docs/concepts/services-networking/service/) were single-stack before 1.20, so using both IP families meant creating one Service per IP family. The user experience was simplified in 1.20, when Services were re-implemented to allow both IP families, meaning a single Service can handle both IPv4 and IPv6 workloads. Dual-stack load balancing is possible between services running any combination of IPv4 and IPv6.
 -->
-[Services](/zh/docs/concepts/services-networking/service/) 在 1.20 版本之前是单协议栈的，
+[Services](/zh-cn/docs/concepts/services-networking/service/) 在 1.20 版本之前是单协议栈的，
 因此，使用两个 IP 协议族意味着需为每个 IP 协议族创建一个 Service。在 1.20 版本中对用户体验进行简化，
 重新实现了 Service 以支持两个 IP 协议族，这意味着一个 Service 就可以处理 IPv4 和 IPv6 协议。
 对于 Service 而言，任意的 IPv4 和 IPv6 协议组合都可以实现负载均衡。
@@ -88,7 +88,7 @@ While Services are set according to what you configure, Pods default to whatever
 Even though dual-stack is possible, it is not mandatory to use it. Examples in the documentation show the variety possible in [dual-stack service configurations](/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios).
 -->
 尽管双协议栈是可用的，但并不强制你使用它。
-在[双协议栈服务配置](/zh/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios)
+在[双协议栈服务配置](/zh-cn/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios)
 文档中的示例列出了可能出现的各种场景.

 <!--
@@ -99,16 +99,16 @@ Even though dual-stack is possible, it is not mandatory to use it. Examples in t
 <!--
 While upstream Kubernetes now supports [dual-stack networking](/docs/concepts/services-networking/dual-stack/) as a GA or stable feature, each provider’s support of dual-stack Kubernetes may vary. Nodes need to be provisioned with routable IPv4/IPv6 network interfaces. Pods need to be dual-stack. The [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) is what assigns the IP addresses to the Pods, so it's the network plugin being used for the cluster that needs to support dual-stack. Some Container Network Interface (CNI) plugins support dual-stack, as does kubenet.
 -->
-虽然现在上游 Kubernetes 支持[双协议栈网络](/zh/docs/concepts/services-networking/dual-stack/)
+虽然现在上游 Kubernetes 支持[双协议栈网络](/zh-cn/docs/concepts/services-networking/dual-stack/)
 作为 GA 或稳定特性，但每个提供商对双协议栈 Kubernetes 的支持可能会有所不同。节点需要提供可路由的 IPv4/IPv6 网络接口。
-Pod 需要是双协议栈的。[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+Pod 需要是双协议栈的。[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
 是用来为 Pod 分配 IP 地址的，所以集群需要支持双协议栈的网络插件。一些容器网络接口（CNI）插件支持双协议栈，例如 kubenet。

 <!--
 Ecosystem support of dual-stack is increasing; you can create [dual-stack clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/), try a [dual-stack cluster locally with KIND](https://kind.sigs.k8s.io/docs/user/configuration/#ip-family), and deploy dual-stack clusters in cloud providers (after checking docs for CNI or kubenet availability).
 -->
 支持双协议栈的生态系统在不断壮大；你可以使用
-[kubeadm 创建双协议栈集群](/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support/),
+[kubeadm 创建双协议栈集群](/zh-cn/docs/setup/production-environment/tools/kubeadm/dual-stack-support/),
 在本地尝试用 [KIND 创建双协议栈集群](https://kind.sigs.k8s.io/docs/user/configuration/#ip-family)，
 还可以将双协议栈集群部署到云上（在查阅 CNI 或 kubenet 可用性的文档之后）

@@ -23,9 +23,9 @@ Kubernetes v1.23 introduced a new, alpha-level policy for
 StatefulSet spec template for cases when they should be deleted automatically when the StatefulSet
 is deleted or pods in the StatefulSet are scaled down.
 -->
-Kubernetes v1.23 为 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/)
+Kubernetes v1.23 为 [StatefulSets](/zh-cn/docs/concepts/workloads/controllers/statefulset/)
 引入了一个新的 alpha 级策略，用来控制由 StatefulSet 规约模板生成的
-[PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/) (PVCs) 的生命周期，
+[PersistentVolumeClaims](/zh-cn/docs/concepts/storage/persistent-volumes/) (PVCs) 的生命周期，
 用于当删除 StatefulSet 或减少 StatefulSet 中的 Pods 数量时 PVCs 应该被自动删除的场景。

 <!--
@@ -91,7 +91,7 @@ retention policies for the underlying PV are respected.
 第一种情况是 StatefulSet 资源被删除时（这意味着所有副本也被删除），这由 `whenDeleted` 策略控制的。
 第二种情况是 StatefulSet 缩小时，即删除 StatefulSet 部分副本，这由 `whenScaled` 策略控制。
 在这两种情况下，策略即可以是 `Retain` 不涉及相应 PVCs 的改变，也可以是 `Delete` 即删除对应的 PVCs。
-删除是通过普通的[对象删除](/zh/docs/concepts/architecture/garbage-collection/)完成的，
+删除是通过普通的[对象删除](/zh-cn/docs/concepts/architecture/garbage-collection/)完成的，
 因此，的所有保留策略都会被遵照执行。

 <!--
@@ -168,7 +168,7 @@ This policy forms a matrix with four cases. I’ll walk through and give an exam
 [documentation](/docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-policies) to
 see all the details.
 -->
-查阅[文档](/zh/docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-policies)
+查阅[文档](/zh-cn/docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-policies)
 获取更多详细信息。

 <!--
@@ -26,9 +26,9 @@ affected, refer to [Check whether dockershim removal affects you](/docs/tasks/ad
 -->
 Kubernetes 将在即将发布的 1.24 版本中移除 dockershim。我们很高兴能够通过支持开源容器运行时、支持更小的
 kubelet 以及为使用 Kubernetes 的团队提高工程速度来重申我们的社区价值。
-如果你[使用 Docker Engine 作为 Kubernetes 集群的容器运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)，
+如果你[使用 Docker Engine 作为 Kubernetes 集群的容器运行时](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)，
 请准备好在 1.24 中迁移！要检查你是否受到影响，
-请参考[检查移除 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)。
+请参考[检查移除 Dockershim 对你的影响](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)。

 <!--
 ## Why we’re moving away from dockershim
@@ -79,10 +79,10 @@ after their announced deprecation.
 -->
 ## 弃用时间线  {#deprecation-timeline}

-我们[正式宣布](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/)于
+我们[正式宣布](/zh-cn/blog/2020/12/08/kubernetes-1-20-release-announcement/)于
 2020 年 12 月弃用 dockershim。目标是在 2022 年 4 月，
 Kubernetes 1.24 中完全移除 dockershim。
-此时间线与我们的[弃用策略](/zh/docs/reference/using api/deprecation-policy/#deprecating-a-feature-or-behavior)一致，
+此时间线与我们的[弃用策略](/zh-cn/docs/reference/using api/deprecation-policy/#deprecating-a-feature-or-behavior)一致，
 即规定已弃用的行为必须在其宣布弃用后至少运行 1 年。

 <!--
@@ -96,7 +96,7 @@ to the [Dockershim Deprecation FAQ](/dockershim).
 包括 dockershim 的 Kubernetes 1.23 版本，在 Kubernetes 项目中将再支持一年。
 对于托管 Kubernetes 的供应商，供应商支持可能会持续更长时间，但这取决于公司本身。
 无论如何，我们相信所有集群操作都有时间进行迁移。如果你有更多关于 dockershim 移除的问题，
-请参考[弃用 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/)。
+请参考[弃用 Dockershim 的常见问题](/zh-cn/blog/2020/12/02/dockershim-faq/)。

 <!--
 We asked you whether you feel prepared for the migration from dockershim in this
@@ -23,7 +23,7 @@ slug: secure-your-admission-controllers-and-webhooks
 [Admission control](/docs/reference/access-authn-authz/admission-controllers/) is a key part of Kubernetes security, alongside authentication and authorization. 
 Webhook admission controllers are extensively used to help improve the security of Kubernetes clusters in a variety of ways including restricting the privileges of workloads and ensuring that images deployed to the cluster meet organization’s security requirements.
 -->
-[准入控制](/zh/docs/reference/access-authn-authz/admission-controllers/)和认证、授权都是 Kubernetes 安全性的关键部分。
+[准入控制](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)和认证、授权都是 Kubernetes 安全性的关键部分。
 Webhook 准入控制器被广泛用于以多种方式帮助提高 Kubernetes 集群的安全性，
 包括限制工作负载权限和确保部署到集群的镜像满足组织安全要求。

@@ -109,7 +109,7 @@ In most cases, the admission controller webhook used by a cluster will be instal
 <!--
 * **Restrict [RBAC](/docs/reference/access-authn-authz/rbac/) rights**. Any user who has rights which would allow them to modify the configuration of the webhook objects or the workload that the admission controller uses could disrupt its operation. So it’s important to make sure that only cluster administrators have those rights.
 -->
-* **限制 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) 权限**。
+* **限制 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 权限**。
  任何有权修改 webhook 对象的配置或准入控制器使用的工作负载的用户都可以破坏其运行。
  因此，确保只有集群管理员拥有这些权限非常重要。
 <!--
@@ -126,7 +126,7 @@ In most cases, the admission controller webhook used by a cluster will be instal
 * **严格控制外部系统访问**。
  作为集群中的安全服务，准入控制器系统将有权访问敏感信息，如凭证。
  为了降低此信息被发送到集群外的风险，
-  应使用[网络策略](/zh/docs/concepts/services-networking/network-policies/) 
+  应使用[网络策略](/zh-cn/docs/concepts/services-networking/network-policies/) 
  来限制准入控制器服务对外部网络的访问。
 <!--
 * **Each cluster has a dedicated webhook**. Whilst it may be possible to have admission controller webhooks that serve multiple clusters, there is a risk when using that model that an attack on the webhook service would have a larger impact where it’s shared. Also where multiple clusters use an admission controller there will be increased complexity and access requirements, making it harder to secure.
@@ -12,7 +12,7 @@ title: 'SIG Node CI Subproject Celebrates Two Years of Test Improvements'
 date: 2022-02-16
 slug: sig-node-ci-subproject-celebrates
 canonicalUrl: https://www.kubernetes.dev/blog/2022/02/16/sig-node-ci-subproject-celebrates-two-years-of-test-improvements/
-url: /zh/blog/2022/02/sig-node-ci-subproject-celebrates
+url: /zh-cn/blog/2022/02/sig-node-ci-subproject-celebrates
 ---
 -->

@@ -21,7 +21,7 @@ aliases: [ '/dockershim' ]
 published in late 2020. The article includes updates from the v1.24
 release of Kubernetes.**
 -->
-**本文是针对 2020 年末发布的[弃用 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/)的博客更新。
+**本文是针对 2020 年末发布的[弃用 Dockershim 的常见问题](/zh-cn/blog/2020/12/02/dockershim-faq/)的博客更新。
 本文包括 Kubernetes v1.24 版本的更新。**

 ---
@@ -36,7 +36,7 @@ from Kubernetes.
 -->
 本文介绍了一些关于从 Kubernetes 中移除 _dockershim_ 的常见问题。
 该移除最初是作为 Kubernetes v1.20
-版本的一部分[宣布](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/)的。
+版本的一部分[宣布](/zh-cn/blog/2020/12/08/kubernetes-1-20-release-announcement/)的。
 Kubernetes 在 [v1.24 版](/releases/#release-v1-24)移除了 dockershim。

 <!--
@@ -44,14 +44,14 @@ For more on what that means, check out the blog post
 [Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/).
 -->
 关于细节请参考博文
-[别慌: Kubernetes 和 Docker](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。
+[别慌: Kubernetes 和 Docker](/zh-cn/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。

 <!--
 To determine the impact that the removal of dockershim would have for you or your organization,
 you can read [Check whether dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/).
 -->
 要确定移除 dockershim 是否会对你或你的组织的影响，可以查阅：
-[检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
+[检查弃用 Dockershim 对你的影响](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
 这篇文章。

 <!--
@@ -70,9 +70,9 @@ In the months and days leading up to the Kubernetes 1.24 release, Kubernetes con
  (including vendor guides).
 -->
 - 一篇详细说明[承诺和后续操作](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)的博文。
- 检查是否存在迁移到其他 [容器运行时](/zh/docs/setup/production-environment/container-runtimes/#container-runtimes) 的主要障碍。
+- 检查是否存在迁移到其他 [容器运行时](/zh-cn/docs/setup/production-environment/container-runtimes/#container-runtimes) 的主要障碍。
 - 添加 [从 dockershim 迁移](/docs/tasks/administer-cluster/migrating-from-dockershim/)的指南。
- 创建了一个[有关 dockershim 移除和使用 CRI 兼容运行时的列表](/zh/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)。
+- 创建了一个[有关 dockershim 移除和使用 CRI 兼容运行时的列表](/zh-cn/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)。
  该列表包括一些已经提到的文档，还涵盖了选定的外部资源（包括供应商指南）。

 <!--
@@ -168,7 +168,7 @@ startup if using Docker Engine as the runtime. You'll see this warning in all ve
 in Kubernetes 1.24.
 -->
 可以使用，在 1.20 版本中唯一的改动是，如果使用 Docker Engine，
-在 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
+在 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)
 启动时会打印一个警告日志。
 你将在 1.23 版本及以前版本看到此警告，dockershim 已在 Kubernetes 1.24 版本中移除 。

@@ -341,7 +341,7 @@ and for the latter you can use newer container build options like [img], [builda
 -->
 另外还有一个需要关注的点，那就是当创建镜像时，系统维护或嵌入容器方面的任务将无法工作。
 对于前者，可以用 [`crictl`](https://github.com/kubernetes-sigs/cri-tools) 工具作为临时替代方案
-(参阅[从 docker cli 到 crictl 的映射](/zh/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl))。
+(参阅[从 docker cli 到 crictl 的映射](/zh-cn/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl))。
 对于后者，可以用新的容器创建选项，例如
 [img](https://github.com/genuinetools/img)、
 [buildah](https://github.com/containers/buildah)、
@@ -20,12 +20,12 @@ slug: ready-for-dockershim-removal
 <!--
 Way back in December of 2020, Kubernetes announced the [deprecation of Dockershim](/blog/2020/12/02/dont-panic-kubernetes-and-docker/). In Kubernetes, dockershim is a software shim that allows you to use the entire Docker engine as your container runtime within Kubernetes. In the upcoming v1.24 release, we are removing Dockershim - the delay between deprecation and removal in line with the [project’s policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) of supporting features for at least one year after deprecation. If you are a cluster operator, this guide includes the practical realities of what you need to know going into this release. Also, what do you need to do to ensure your cluster doesn’t fall over!
 -->
-早在 2020 年 12 月，Kubernetes 就宣布[弃用 Dockershim](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。
+早在 2020 年 12 月，Kubernetes 就宣布[弃用 Dockershim](/zh-cn/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。
 在 Kubernetes 中，dockershim 是一个软件 shim，
 它允许你将整个 Docker 引擎用作 Kubernetes 中的容器运行时。
 在即将发布的 v1.24 版本中，我们将移除 Dockershim - 
 在宣布弃用之后到彻底移除这段时间内，我们至少预留了一年的时间继续支持此功能，
-这符合相关的[项目策略](/zh/docs/reference/using-api/deprecation-policy/)。 
+这符合相关的[项目策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 
 如果你是集群操作员，则该指南包含你在此版本中需要了解的实际情况。
 另外还包括你需要做些什么来确保你的集群不会崩溃！

@@ -38,7 +38,7 @@ Way back in December of 2020, Kubernetes announced the [deprecation of Dockershi
 If you are rolling your own cluster or are otherwise unsure whether or not this removal affects you, stay on the safe side and [check to see if you have any dependencies on Docker Engine](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/). Please note that using Docker Desktop to build your application containers is not a Docker dependency for your cluster. Container images created by Docker are compliant with the [Open Container Initiative (OCI)](https://opencontainers.org/), a Linux Foundation governance structure that defines industry standards around container formats and runtimes. They will work just fine on any container runtime supported by Kubernetes.
 -->
 如果你正在管理自己的集群或不确定此删除是否会影响到你，
-请保持安全状态并[检查你对 Docker Engine 是否有依赖](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)。 
+请保持安全状态并[检查你对 Docker Engine 是否有依赖](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)。 
 请注意，使用 Docker Desktop 构建应用程序容器并不算是集群对 Docker 有依赖。
 Docker 创建的容器镜像符合 [Open Container Initiative (OCI)](https://opencontainers.org/) 规范，
 而 OCI 是 Linux 基金会的一种治理架构，负责围绕容器格式和运行时定义行业标准。 
@@ -51,13 +51,13 @@ If you are using a managed Kubernetes service from a cloud provider, and you hav
 并且你确定没有更改过容器运行时，那么你可能不需要做任何事情。 
 Amazon EKS、Azure AKS 和 Google GKE 现在都默认使用 containerd，
 但如果你的集群中有任何自定义的节点，你要确保它们不需要被更新。
-要检查节点的运行时，请参考[查明节点上所使用的容器运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)。
+要检查节点的运行时，请参考[查明节点上所使用的容器运行时](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)。

 <!--
 Regardless of whether you are rolling your own cluster or using a managed Kubernetes service from a cloud provider, you may need to [migrate telemetry or security agents that rely on Docker Engine](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/). 
 -->
 无论你是在管理自己的集群还是使用云服务提供商管理的 Kubernetes 服务，
-你可能都需要[迁移依赖 Docker Engine 的遥测或安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)。
+你可能都需要[迁移依赖 Docker Engine 的遥测或安全代理](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)。

 <!--
 ## I have a Docker dependency. What now?
@@ -73,7 +73,7 @@ If your Kubernetes cluster depends on Docker Engine and you intend to upgrade to
 由于 [containerd](https://containerd.io/) 是一个已经毕业的 CNCF 项目，
 并且是 Docker 本身的运行时，因此用它作为容器运行时的替代方式是一个安全的选择。
 幸运的是，Kubernetes 项目已经以 containerd 为例，
-提供了[更改节点容器运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/)的过程文档。
+提供了[更改节点容器运行时](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/)的过程文档。
 切换到其它支持的运行时的操作指令与此类似。

 <!--
@@ -101,11 +101,11 @@ Yes. As long as you go into this release aware of the changes being made and the
 是的。只要你深入了解此版本所做的变更和你自己集群的详细信息，
 并确保与你的开发团队进行清晰的沟通，它的不确定性就会降到最低。 
 你可能需要对集群、应用程序代码或脚本进行一些更改，但所有这些要求都已经有说明指导。 
-从使用 Docker Engine 作为运行时，切换到使用[其他任何一种支持的容器运行时](/zh/docs/setup/production-environment/container-runtimes/)，
+从使用 Docker Engine 作为运行时，切换到使用[其他任何一种支持的容器运行时](/zh-cn/docs/setup/production-environment/container-runtimes/)，
 这意味着移除了中间层的组件，因为 dockershim 的作用是访问 Docker 本身使用的容器运行时。 
 从实际角度长远来看，这种移除对你和 Kubernetes 维护者都更有好处。

 <!--
 If you still have questions, please first check the [Dockershim Removal FAQ](/blog/2022/02/17/dockershim-faq/).
 -->
-如果你仍有疑问，请先查看[弃用 Dockershim 的常见问题](/zh/blog/2022/02/17/dockershim-faq/)。
+如果你仍有疑问，请先查看[弃用 Dockershim 的常见问题](/zh-cn/blog/2022/02/17/dockershim-faq/)。
@@ -67,7 +67,7 @@ the authors succinctly captured the change's impact and encouraged users to rema
 > Container Runtime Interface (CRI) created for Kubernetes. Docker-produced images
 > will continue to work in your cluster with all runtimes, as they always have.
 -->
-在文章[别慌: Kubernetes 和 Docker](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/) 中，
+在文章[别慌: Kubernetes 和 Docker](/zh-cn/blog/2020/12/02/dont-panic-kubernetes-and-docker/) 中，
 作者简洁地记述了变化的影响，并鼓励用户保持冷静：
 >弃用 Docker 这个底层运行时，转而支持符合为 Kubernetes 创建的容器运行接口
 >Container Runtime Interface (CRI) 的运行时。
@@ -80,7 +80,7 @@ to container runtimes that are directly compatible with Kubernetes. You can find
 page in the Kubernetes documentation.
 -->
 已经有一些文档指南，提供了关于从 dockershim 迁移到与 Kubernetes 直接兼容的容器运行时的有用信息。
-你可以在 Kubernetes 文档中的[从 dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)
+你可以在 Kubernetes 文档中的[从 dockershim 迁移](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/)
 页面上找到它们。

 <!--
@@ -92,7 +92,7 @@ Take a look at the [Is Your Cluster Ready for v1.24?](/blog/2022/03/31/ready-for
 -->
 有关 Kubernetes 为何不再使用 dockershim 的更多信息，
 请参见：[Kubernetes 正在离开 Dockershim](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)
-和[最新的弃用 Dockershim 的常见问题](/zh/blog/2022/02/17/dockershim-faq/)。
+和[最新的弃用 Dockershim 的常见问题](/zh-cn/blog/2022/02/17/dockershim-faq/)。

 查看[你的集群准备好使用 v1.24 了吗？](/blog/2022/03/31/ready-for-dockershim-removal/) 一文，
 了解如何确保你的集群在从 1.23 版本升级到 1.24 版本后继续工作。
@@ -113,7 +113,7 @@ same API is available and that APIs have a minimum lifetime as indicated by the
 ## Kubernetes API 删除和弃用流程  {#the-Kubernetes-api-removal-and-deprecation-process}

 Kubernetes 包含大量随时间演变的组件。在某些情况下，这种演变会导致 API、标志或整个特性被删除。
-为了防止用户面对重大变化，Kubernetes 贡献者采用了一项特性[弃用策略](/zh/docs/reference/using-api/deprecation-policy/)。
+为了防止用户面对重大变化，Kubernetes 贡献者采用了一项特性[弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。
 此策略确保仅当同一 API 的较新稳定版本可用并且 
 API 具有以下稳定性级别所指示的最短生命周期时，才可能弃用稳定版本 API：

@@ -212,14 +212,14 @@ Docker Engine dependencies. Before upgrading to v1.24, you decide to either rema
 ## 需要做什么  {#what-to-do}

 ### 删除 Dockershim  {#dockershim-removal}
-如前所述，有一些关于从 [dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)的指南。
-你可以[从查明节点上所使用的容器运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)开始。
+如前所述，有一些关于从 [dockershim 迁移](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/)的指南。
+你可以[从查明节点上所使用的容器运行时](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)开始。
 如果你的节点使用 dockershim，则还有其他可能的 Docker Engine 依赖项，
 例如 Pod 或执行 Docker 命令的第三方工具或 Docker 配置文件中的私有注册表。
-你可以按照[检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
+你可以按照[检查弃用 Dockershim 对你的影响](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
 的指南来查看可能的 Docker 引擎依赖项。在升级到 1.24 版本之前， 你决定要么继续使用 Docker Engine 并
 [将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)，
-要么迁移到与 CRI 兼容的运行时。这是[将节点上的容器运行时从 Docker Engine 更改为 containerd](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/) 的指南。
+要么迁移到与 CRI 兼容的运行时。这是[将节点上的容器运行时从 Docker Engine 更改为 containerd](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/) 的指南。

 <!--
 ### `kubectl convert`
@@ -233,7 +233,7 @@ documentation to download and install the `kubectl-convert` binary.
 -->
 ### `kubectl convert`  {#kubectl-convert}

-kubectl 的 [`kubectl convert`](/zh/docs/tasks/tools/included/kubectl-convert-overview/)
+kubectl 的 [`kubectl convert`](/zh-cn/docs/tasks/tools/included/kubectl-convert-overview/)
 插件有助于解决弃用 API 的迁移问题。该插件方便了不同 API 版本之间清单的转换，
 例如，从弃用的 API 版本到非弃用的 API 版本。关于 API 迁移过程的更多信息可以在
 [已弃用 API 的迁移指南](/docs/reference/using-api/deprecation-guide/)中找到。按照
@@ -258,7 +258,7 @@ Kubernetes API 的 beta 版本，这些 API 当前为稳定版。1.25 版本还
 <!--
 The official [list of API removals planned for Kubernetes 1.25](/docs/reference/using-api/deprecation-guide/#v1-25) is:
 -->
-[Kubernetes 1.25 计划移除的 API 的官方列表](/zh/docs/reference/using-api/deprecation-guide/#v1-25)是：
+[Kubernetes 1.25 计划移除的 API 的官方列表](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-25)是：

 * The beta CronJob API (batch/v1beta1)
 * The beta EndpointSlice API (discovery.k8s.io/v1beta1)
@@ -274,7 +274,7 @@ The official [list of API removals planned for Kubernetes 1.26](/docs/reference/
 * The beta FlowSchema and PriorityLevelConfiguration APIs (flowcontrol.apiserver.k8s.io/v1beta1)
 * The beta HorizontalPodAutoscaler API (autoscaling/v2beta2)
 -->
-[Kubernetes 1.25 计划移除的 API 的官方列表](/zh/docs/reference/using-api/deprecation-guide/#v1-25)是：
+[Kubernetes 1.25 计划移除的 API 的官方列表](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-25)是：

 * The beta FlowSchema 和 PriorityLevelConfiguration API (flowcontrol.apiserver.k8s.io/v1beta1)
 * The beta HorizontalPodAutoscaler API (autoscaling/v2beta2)
@@ -297,5 +297,5 @@ Kubernetes 发行说明中宣告了弃用信息。你可以在以下版本的发
 * 我们将正式宣布 [Kubernetes 1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#deprecation) 的弃用信息，
  作为该版本 CHANGELOG 的一部分。

-有关弃用和删除过程的信息，请查看 Kubernetes 官方[弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) 文档。
+有关弃用和删除过程的信息，请查看 Kubernetes 官方[弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) 文档。

@@ -64,18 +64,18 @@ We didn’t do a great job communicating this, and unfortunately, the deprecatio
 我们没有很好地传达这一点，不幸的是，弃用公告在社区内引起了一些恐慌。关于这对 Docker 作为
 一家公司意味着什么，Docker 构建的容器镜像是否仍然可以运行，以及 Docker Engine 究竟是
 什么导致了社交媒体上的一场大火，人们感到困惑。这是我们的错；我们应该更清楚地传达当时发生
-的事情和原因。为了解决这个问题，我们发布了[一篇博客](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/)
-和[相应的 FAQ](/zh/blog/2020/12/02/dockershim-faq/ ) 以减轻社区的恐惧并纠正对
+的事情和原因。为了解决这个问题，我们发布了[一篇博客](/zh-cn/blog/2020/12/02/dont-panic-kubernetes-and-docker/)
+和[相应的 FAQ](/zh-cn/blog/2020/12/02/dockershim-faq/ ) 以减轻社区的恐惧并纠正对
 Docker 是什么以及容器如何在 Kubernetes 中工作的一些误解。由于社区的关注，Docker 和 Mirantis
 共同决定继续以 [cri-dockerd] 的形式支持 dockershim 代码（https://www.mirantis.com/blog/the-future-of-dockershim-is -cri-dockerd/)，
 允许你在需要时继续使用 Docker Engine 作为容器运行时。对于想要尝试其他运行时（如 containerd 或 cri-o）
-的用户，[已编写迁移文档](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/)。
+的用户，[已编写迁移文档](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/)。

 <!--
 We later [surveyed the community](https://kubernetes.io/blog/2021/11/12/are-you-ready-for-dockershim-removal/) and [discovered that there are still many users with questions and concerns](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim). In response, Kubernetes maintainers and the CNCF committed to addressing these concerns by extending documentation and other programs. In fact, this blog post is a part of this program. With so many end users successfully migrated to other runtimes, and improved documentation, we believe that everyone has a paved way to migration now.
 -->
 我们后来[调查了社区](https://kubernetes.io/blog/2021/11/12/are-you-ready-for-dockershim-removal/)
-[发现还有很多用户有疑问和顾虑](/zh/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim)。 
+[发现还有很多用户有疑问和顾虑](/zh-cn/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim)。 
 作为回应，Kubernetes 维护人员和 CNCF 承诺通过扩展文档和其他程序来解决这些问题。 事实上，这篇博文是 
 这个计划的一部分。 随着如此多的最终用户成功迁移到其他运行时，以及改进的文档，我们相信每个人现在都为迁移铺平了道路。

@@ -111,7 +111,7 @@ CSI 驱动必须在控制器或节点服务（如果合适，二者兼备）
 请参阅 CSI 驱动的文档，了解其是否支持卷扩充。

 有关支持卷扩充的树内（intree）卷类型，
-请参阅卷扩充文档：[扩充 PVC 申领](/zh/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。
+请参阅卷扩充文档：[扩充 PVC 申领](/zh-cn/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。

 <!-- 
 In general to provide some degree of control over volumes that can be expanded, only dynamically provisioned PVCs whose storage class has `allowVolumeExpansion` parameter set to `true` are expandable.
@@ -194,7 +194,7 @@ See [Recovering from volume expansion failure](/docs/concepts/storage/persistent
 但 SIG Storage 团队仍然在努力让 Kubernetes 用户扩充其持久性存储变得更简单。
 Kubernetes 1.23 引入了卷扩充失败后触发恢复机制的功能特性，
 允许用户在大小调整失败后尝试自助修复。
-更多详细信息，请参阅[处理扩充卷过程中的失败](/zh/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes)。
+更多详细信息，请参阅[处理扩充卷过程中的失败](/zh-cn/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes)。
 <!--
 The Kubernetes contributor community is also discussing the potential for StatefulSet-driven storage expansion. This proposed
 feature would let you trigger expansion for all underlying PVs that are providing storage to a StatefulSet,
@@ -20,7 +20,7 @@ slug: storage-capacity-ga
 The v1.24 release of Kubernetes brings [storage capacity](/docs/concepts/storage/storage-capacity/)
 tracking as a generally available feature.
 -->
-在 Kubernetes v1.24 版本中，[存储容量](/zh/docs/concepts/storage/storage-capacity/)跟踪已经成为一项正式发布的功能。
+在 Kubernetes v1.24 版本中，[存储容量](/zh-cn/docs/concepts/storage/storage-capacity/)跟踪已经成为一项正式发布的功能。

 <!--
 ## Problems we have solved
@@ -245,7 +245,7 @@ of this feature.
 [Volume populators and data sources](/docs/concepts/storage/persistent-volumes/#volume-populators-and-data-sources), within the documentation topic about persistent volumes,
 explains how to use this feature in your cluster.
 -->
-[卷填充器与数据源](/zh/docs/concepts/storage/persistent-volumes/#volume-populators-and-data-sources),
+[卷填充器与数据源](/zh-cn/docs/concepts/storage/persistent-volumes/#volume-populators-and-data-sources),
 在有关持久卷的文档主题中，解释了如何在集群中使用此功能。

 <!--
@@ -23,8 +23,8 @@ from modifying the volume mode of a [`PersistentVolumeClaim`](/docs/concepts/sto
 existing [`VolumeSnapshot`](/docs/concepts/storage/volume-snapshots/) in the Kubernetes cluster.  
 -->
 Kubernetes v1.24 引入了一个新的 alpha 级特性，可以防止未经授权的用户修改基于 Kubernetes
-集群中已有的 [`VolumeSnapshot`](/zh/docs/concepts/storage/volume-snapshots/)
-创建的 [`PersistentVolumeClaim`](/zh/docs/concepts/storage/persistent-volumes/) 的卷模式。
+集群中已有的 [`VolumeSnapshot`](/zh-cn/docs/concepts/storage/volume-snapshots/)
+创建的 [`PersistentVolumeClaim`](/zh-cn/docs/concepts/storage/persistent-volumes/) 的卷模式。

 <!--
 ### The problem
@@ -35,7 +35,7 @@ Kubernetes v1.24 引入了一个新的 alpha 级特性，可以防止未经授
 The [Volume Mode](/docs/concepts/storage/persistent-volumes/#volume-mode) determines whether a volume 
 is formatted into a filesystem or presented as a raw block device.   
 -->
-[卷模式](/zh/docs/concepts/storage/persistent-volumes/#volume-mode)确定卷是格式化为文件系统还是显示为原始块设备。
+[卷模式](/zh-cn/docs/concepts/storage/persistent-volumes/#volume-mode)确定卷是格式化为文件系统还是显示为原始块设备。

 <!--
 Users can leverage the `VolumeSnapshot` feature, which has been stable since Kubernetes v1.20, 
@@ -47,7 +47,7 @@ Visit [Create a PersistentVolumeClaim from a Volume Snapshot](/docs/concepts/sto
 用户可以使用自 Kubernetes v1.20 以来就稳定的 `VolumeSnapshot` 功能，
 基于 Kubernetes 集群中的已有的 `VolumeSnapshot` 创建一个 `PersistentVolumeClaim` (简称 PVC )。
 PVC 规约包括一个 `dataSource` 字段，它可以指向一个已有的 `VolumeSnapshot` 实例。
-查阅[基于卷快照创建 PVC](/zh/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-volume-snapshot)
+查阅[基于卷快照创建 PVC](/zh-cn/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-volume-snapshot)
 获取更多详细信息。

 <!--
@@ -116,7 +116,7 @@ created PVC in the given namespace.
 to the `VolumeSnapshotContent`. 
 -->
 3. 给 `VolumeSnapshotContent` 添加
-   [`snapshot.storage.kubernetes.io/allowVolumeModeChange`](/zh/docs/reference/labels-annotations-taints/#snapshot-storage-kubernetes-io-allowvolumemodechange)
+   [`snapshot.storage.kubernetes.io/allowVolumeModeChange`](/zh-cn/docs/reference/labels-annotations-taints/#snapshot-storage-kubernetes-io-allowvolumemodechange)
   注解。

 <!--
@@ -23,7 +23,7 @@ can have a cluster-scoped virtual IP address (using a Service of `type: ClusterI
 Clients can connect using that virtual IP address, and Kubernetes then load-balances traffic to that
 Service across the different backing Pods.
 -->
-在 Kubernetes 中，[Services](/zh/docs/concepts/services-networking/service/)
+在 Kubernetes 中，[Services](/zh-cn/docs/concepts/services-networking/service/)
 是一种抽象，用来暴露运行在一组 Pod 上的应用。
 Service 可以有一个集群范围的虚拟 IP 地址（使用 `type: ClusterIP` 的 Service）。
 客户端可以使用该虚拟 IP 地址进行连接， Kubernetes 为对该 Service 的访问流量提供负载均衡，以访问不同的后端 Pod。
@@ -22,7 +22,7 @@ block for running complex stateful applications. As the use of Kubernetes has gr
 StatefulSets. Many of these scenarios, require faster rolling updates than the currently supported one-pod-at-a-time updates, in the 
 case where you're using the `OrderedReady` Pod management policy for a StatefulSet.
 -->
-Kubernetes [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)，
+Kubernetes [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/)，
 自 1.5 版本中引入并在 1.9 版本中变得稳定以来，已被广泛用于运行有状态应用。它提供固定的 Pod 身份标识、
 每个 Pod 的持久存储以及 Pod 的有序部署、扩缩容和滚动更新功能。你可以将 StatefulSet
 视为运行复杂有状态应用程序的原子构建块。随着 Kubernetes 的使用增多，需要 StatefulSet 的场景也越来越多。
@@ -233,7 +233,7 @@ break applications or catch them by surprise? Please [open an issue](https://git
 - [Enhancement Tracking Issue](https://github.com/kubernetes/enhancements/issues/961)
 -->
 ## 进一步阅读和后续步骤 {#next-steps}
- [最多不可用 Pod 数](/zh/docs/concepts/workloads/controllers/statefulset/#maximum-unavailable-pods)
+- [最多不可用 Pod 数](/zh-cn/docs/concepts/workloads/controllers/statefulset/#maximum-unavailable-pods)
 - [KEP for MaxUnavailable for StatefulSet](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/961-maxunavailable-for-statefulset)
 - [代码实现](https://github.com/kubernetes/kubernetes/pull/82162/files)
 - [增强跟踪 Issue](https://github.com/kubernetes/enhancements/issues/961)