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

2022-06-23 20:05:25 +08:00
parent e0d6f94bf6
commit e06459c0c5
30 changed files with 120 additions and 120 deletions
@@ -22,8 +22,8 @@ the [application troubleshooting guide](/docs/tasks/debug/debug-application/) fo
 You may also visit the [troubleshooting overview document](/docs/tasks/debug/) for more information.
 -->
 本篇文档是介绍集群故障排查的；我们假设对于你碰到的问题，你已经排除了是由应用程序造成的。
-对于应用的调试，请参阅[应用故障排查指南](/zh/docs/tasks/debug/debug-application/)。
-你也可以访问[故障排查](/zh/docs/tasks/debug/)来获取更多的信息。
+对于应用的调试，请参阅[应用故障排查指南](/zh-cn/docs/tasks/debug/debug-application/)。
+你也可以访问[故障排查](/zh-cn/docs/tasks/debug/)来获取更多的信息。

 <!-- body -->

@@ -408,7 +408,7 @@ This is an incomplete list of things that could go wrong, and how to adjust your
 - 措施: 对于运行 API 服务器和 etcd 的 VM，使用 IaaS 提供的可靠的存储（例如 GCE PD 或者 AWS EBS 卷）
  - 缓解：API 服务器后端存储的丢失

- 措施：使用[高可用性](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)的配置
+- 措施：使用[高可用性](/zh-cn/docs/setup/production-environment/tools/kubeadm/high-availability/)的配置
  - 缓解：主控节点 VM 关机或者主控节点组件（调度器、API 服务器、控制器管理器）崩馈
    - 将容许一个或多个节点或组件同时出现故障
  - 缓解：API 服务器后端存储（例如 etcd 的数据目录）丢失
@@ -55,7 +55,7 @@ and the backends persist the records. The current backend implementations
 include logs files and webhooks.
 -->
 审计记录最初产生于
-[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
+[kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)
 内部。每个请求在不同执行阶段都会生成审计事件；这些审计事件会根据特定策略
 被预处理并写入后端。策略确定要记录的内容和用来存储记录的后端。
 当前的后端支持日志文件和 webhook。
@@ -90,7 +90,7 @@ is different from the
 API object.
 -->
 {{< note >}}
-[审计事件配置](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
+[审计事件配置](/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
 的配置与 [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
 API 对象不同。
 {{< /note >}}
@@ -117,7 +117,7 @@ _audit level_ of the event. The defined audit levels are:

 审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。
 审计策略对象结构定义在
-[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
+[`audit.k8s.io` API 组](/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
 处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的
 **审计级别（Audit Level）**。已定义的审计级别有：

@@ -179,7 +179,7 @@ for details about the fields defined.
 [configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)
 脚本，该脚本能够生成审计策略文件。你可以直接在脚本中看到审计策略的绝大部份内容。

-你也可以参考 [`Policy` 配置参考](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
+你也可以参考 [`Policy` 配置参考](/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
 以获取有关已定义字段的详细信息。

 <!--
@@ -203,7 +203,7 @@ In all cases, audit events follow a structure defined by the Kubernetes API in t
 - Webhook 后端，将事件发送到外部 HTTP API

 在这所有情况下，审计事件均遵循 Kubernetes API 在
-[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
+[`audit.k8s.io` API 组](/zh-cn/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
 中定义的结构。

 <!--
@@ -325,7 +325,7 @@ The webhook config file uses the kubeconfig format to specify the remote address
 the service and credentials used to connect to it.
 -->
 - `--audit-webhook-config-file` 设置 Webhook 配置文件的路径。Webhook 配置文件实际上是一个
-  [kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)。
+  [kubeconfig 文件](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/)。
 - `--audit-webhook-initial-backoff` 指定在第一次失败后重发请求等待的时间。随后的请求将以指数退避重试。

 Webhook 配置文件使用 kubeconfig 格式指定服务的远程地址和用于连接它的凭据。
@@ -449,4 +449,4 @@ By default truncate is disabled in both `webhook` and `log`, a cluster administr
 <!--
 * Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
 -->
-* 了解 [Mutating webhook 审计注解](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations)。
+* 了解 [Mutating webhook 审计注解](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations)。
@@ -560,4 +560,4 @@ CONTAINER ID   IMAGE    CREATED              STATE    NAME     ATTEMPT
 * [Map `docker` CLI commands to `crictl`](/docs/reference/tools/map-crictl-dockercli/).
 -->
 * [进一步了解 `crictl`](https://github.com/kubernetes-sigs/cri-tools)
-* [将 `docker` CLI 命令映射到 `crictl`](/zh/docs/reference/tools/map-crictl-dockercli/)
+* [将 `docker` CLI 命令映射到 `crictl`](/zh-cn/docs/reference/tools/map-crictl-dockercli/)
@@ -18,7 +18,7 @@ Kubernetes applications usually consist of multiple, separate services, each run

 Kubernetes 应用程序通常由多个独立的服务组成，每个服务都在自己的容器中运行。
 在远端的 Kubernetes 集群上开发和调试这些服务可能很麻烦，
-需要[在运行的容器上打开 Shell](/zh/docs/tasks/debug/debug-application/get-shell-running-container/)，
+需要[在运行的容器上打开 Shell](/zh-cn/docs/tasks/debug/debug-application/get-shell-running-container/)，
 以运行调试工具。

 <!--
@@ -27,7 +27,7 @@ To learn how to install and use Node Problem Detector, see
 *节点问题检测器（Node Problem Detector）* 是一个守护程序，用于监视和报告节点的健康状况。
 你可以将节点问题探测器以 `DaemonSet` 或独立守护程序运行。
 节点问题检测器从各种守护进程收集节点问题，并以
-[NodeCondition](/zh/docs/concepts/architecture/nodes/#condition) 和
+[NodeCondition](/zh-cn/docs/concepts/architecture/nodes/#condition) 和
 [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
 的形式报告给 API 服务器。 

@@ -140,7 +140,7 @@ is embedded when building the Docker image of Node Problem Detector.
 However, you can use a [`ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/)
 to overwrite the configuration:
 -->
-不过，你可以像下面这样使用 [`ConfigMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
+不过，你可以像下面这样使用 [`ConfigMap`](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)
 将其覆盖：

 <!-- 
@@ -35,7 +35,7 @@ command.
 包括 CPU 和内存的指标。如果将 Metrics API 部署到集群中，
 那么 Kubernetes API 的客户端就可以查询这些信息，并且可以使用 Kubernetes 的访问控制机制来管理权限。

-[HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) 和 
+[HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) 和 
 [VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) (VPA) 
 使用 metrics API 中的数据调整工作负载副本和资源，以满足客户需求。

@@ -52,7 +52,7 @@ that uses the _Custom Metrics API_.
 -->
 Metrics API 及其启用的指标管道仅提供最少的 CPU 和内存指标，以启用使用 HPA 和/或 VPA 的自动扩展。
 如果你想提供更完整的指标集，你可以通过部署使用 _Custom Metrics API_ 的第二个
-[指标管道](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/#full-metrics-pipeline)来作为简单的 Metrics API 的补充。
+[指标管道](/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring/#full-metrics-pipeline)来作为简单的 Metrics API 的补充。
 {{< /note >}}

 <!--
@@ -110,7 +110,7 @@ The architecture components, from right to left in the figure, consist of the fo
 图中从右到左的架构组件包括以下内容：

 * [cAdvisor](https://github.com/google/cadvisor): 用于收集、聚合和公开 Kubelet 中包含的容器指标的守护程序。
-* [kubelet](/zh/docs/concepts/overview/components/#kubelet): 用于管理容器资源的节点代理。
+* [kubelet](/zh-cn/docs/concepts/overview/components/#kubelet): 用于管理容器资源的节点代理。
  可以使用 `/metrics/resource` 和 `/stats` kubelet API 端点访问资源指标。
 * [Summary API](#summary-api-source): kubelet 提供的 API，用于发现和检索可通过 `/stats` 端点获得的每个节点的汇总统计信息。
 * [metrics-server](#metrics-server): 集群插件组件，用于收集和聚合从每个 kubelet 中提取的资源指标。
@@ -244,8 +244,8 @@ the [metrics-server repository](https://github.com/kubernetes-sigs/metrics-serve
 -->

 Metrics API 在 [k8s.io/metrics](https://github.com/kubernetes/metrics) 代码库中定义。
-你必须启用 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)并为 
-`metrics.k8s.io` API 注册一个 [APIService](/zh/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)。
+你必须启用 [API 聚合层](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/)并为 
+`metrics.k8s.io` API 注册一个 [APIService](/zh-cn/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)。

 要了解有关 Metrics API 的更多信息，
 请参阅资源 [Resource Metrics API Design](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/resource-metrics-api.md)、
@@ -286,7 +286,7 @@ CPU 报告为以 cpu 为单位测量的平均核心使用率。在 Kubernetes
 用于计算 CPU 的时间窗口显示在 Metrics API 的窗口字段下。

 要了解更多关于 Kubernetes 如何分配和测量 CPU 资源的信息，请参阅
-[CPU 的含义](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)。
+[CPU 的含义](/zh-cn/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)。

 <!--
 ### Memory
@@ -315,7 +315,7 @@ Kubernetes 模型中，容器工作集是由容器运行时计算的与相关容
 工作集指标通常还包括一些缓存（文件支持）内存，因为主机操作系统不能总是回收页面。

 要了解有关 Kubernetes 如何分配和测量内存资源的更多信息，
-请参阅[内存的含义](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory)。
+请参阅[内存的含义](/zh-cn/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory)。

 <!--
 ## Metrics Server
@@ -350,7 +350,7 @@ to collect metrics from each node. Depending on the metrics-server version it us
 * Metrics resource endpoint `/metrics/resource` in version v0.6.0+ or
 * Summary API endpoint `/stats/summary` in older versions
 -->
-metrics-server 调用 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) API
+metrics-server 调用 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) API
 从每个节点收集指标。根据它使用的度量服务器版本：

 * 版本 v0.6.0+ 中，使用指标资源端点 `/metrics/resource`
@@ -377,7 +377,7 @@ You can also check out the following:
 * [metrics-server FAQ](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md)
 * [metrics-server known issues](https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md)
 * [metrics-server releases](https://github.com/kubernetes-sigs/metrics-server/releases)
-* [Horizontal Pod Autoscaling](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
+* [Horizontal Pod Autoscaling](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)

 <!--
 ### Summary API Source
@@ -389,7 +389,7 @@ for consumers to read.

 ### Summary API 来源   {#summary-api-source}

-[Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 在节点、卷、Pod 和容器级别收集统计信息，
+[Kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 在节点、卷、Pod 和容器级别收集统计信息，
 并在 [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)
 中提供它们的统计信息供消费者阅读。

@@ -24,8 +24,8 @@ where bottlenecks can be removed to improve overall performance.
 -->
 要扩展应用程序并提供可靠的服务，你需要了解应用程序在部署时的行为。
 你可以通过检测容器检查 Kubernetes 集群中的应用程序性能，
-[Pods](/zh/docs/concepts/workloads/pods), 
-[服务](/zh/docs/concepts/services-networking/service/)
+[Pods](/zh-cn/docs/concepts/workloads/pods), 
+[服务](/zh-cn/docs/concepts/services-networking/service/)
 和整个集群的特征。
 Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。
 此信息使你可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。
@@ -55,7 +55,7 @@ These  metrics are collected by the lightweight, short-term, in-memory
 ## 资源度量管道  {#resource-metrics-pipeline}

 资源指标管道提供了一组与集群组件，例如
-[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
+[Horizontal Pod Autoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)
 控制器以及 `kubectl top` 实用程序相关的有限度量。
 这些指标是由轻量级的、短期、内存存储的
 [metrics-server](https://github.com/kubernetes-sigs/metrics-server) 收集的，
@@ -76,7 +76,7 @@ This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated
 read-only ports. 
 -->
 度量服务器发现集群中的所有节点，并且查询每个节点的
-[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
+[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/)
 以获取 CPU 和内存使用情况。
 Kubelet 充当 Kubernetes 主节点与节点之间的桥梁，管理机器上运行的 Pod 和容器。
 kubelet 将每个 Pod 转换为其组成的容器，并在容器运行时通过容器运行时接口
@@ -101,7 +101,7 @@ content_type: concept
   [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)
   的配置。你可以随时编辑这个静态文件。更新配置将应用于新的 Kubernetes 资源。

-   Kubernetes 的网络需求之一 (查看 [Kubernetes 模型](/zh/docs/concepts/cluster-administration/networking/)) 
+   Kubernetes 的网络需求之一 (查看 [Kubernetes 模型](/zh-cn/docs/concepts/cluster-administration/networking/)) 
   是集群通信不需要内部的 NAT。
   为了遵守这一要求， 对于你不希望发生的出站 NAT 通信，这里有一个
   [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) 。
@@ -138,7 +138,7 @@ content_type: concept

 4. 容器的 vnic 和 HNS endpoints 正在被删除

-   当 `hostname-override` 参数没有传递给 [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/)
+   当 `hostname-override` 参数没有传递给 [kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/)
   时可能引发这一问题。想要解决这个问题，用户需要将主机名传递给 kube-proxy，如下所示：

   ```powershell