Merge pull request #34343 from Sea-n/zh-ref-gen

[zh] Fix link for /docs/reference/generated
2022-06-17 21:40:02 -07:00 · 2022-06-17 21:40:02 -07:00 · 3332857e51
parent f7cd4cbb93 0e89a437f2
commit 3332857e51
11 changed files with 132 additions and 138 deletions
--- a/content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md
+++ b/content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md
@ -132,7 +132,7 @@ In the bootstrap initialization process, the following occurs:
 9. Certificate is created for the kubelet
 -->
 1. kubelet 启动
-2. kubelet 看到自己 *没有* 对应的 `kubeconfig` 文件
+2. kubelet 看到自己**没有**对应的 `kubeconfig` 文件
 3. kubelet 搜索并发现 `bootstrap-kubeconfig` 文件
 4. kubelet 读取该启动引导文件，从中获得 API 服务器的 URL 和用途有限的
   一个“令牌（Token）”
@ -304,8 +304,8 @@ particular bootstrap group's access when you are done provisioning the nodes.
 -->
 随着这个功能特性的逐渐成熟，你需要确保令牌绑定到某基于角色的的访问控制（RBAC）
 策略上，从而严格限制请求（使用[启动引导令牌](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)）
-仅限于客户端申请提供证书。当 RBAC 被配置启用时，可以将令牌限制到某个组，从而
-提高灵活性。例如，你可以在准备节点期间禁止某特定启动引导组的访问。
+仅限于客户端申请提供证书。当 RBAC 被配置启用时，可以将令牌限制到某个组，
+从而提高灵活性。例如，你可以在准备节点期间禁止某特定启动引导组的访问。

 <!--
 #### Bootstrap tokens
@ -366,8 +366,8 @@ systems). There are multiple ways you can generate a token. For example:
 #### 令牌认证文件    {#token-authentication-file}

 kube-apiserver 能够将令牌视作身份认证依据。
-这些令牌可以是任意数据，但必须表示为基于某安全的随机数生成器而得到的
-至少 128 位混沌数据。这里的随机数生成器可以是现代 Linux 系统上的
+这些令牌可以是任意数据，但必须表示为基于某安全的随机数生成器而得到的至少
+128 位混沌数据。这里的随机数生成器可以是现代 Linux 系统上的
 `/dev/urandom`。生成令牌的方式有很多种。例如：

 ```shell
@ -380,10 +380,10 @@ will generate tokens that look like `02b50b05283e98dd0fd71db496ef01e8`.
 The token file should look like the following example, where the first three
 values can be anything and the quoted group name should be as depicted:
 -->
-上面的命令会生成类似于 `02b50b05283e98dd0fd71db496ef01e8` 这样的令牌。 
+上面的命令会生成类似于 `02b50b05283e98dd0fd71db496ef01e8` 这样的令牌。

-令牌文件看起来是下面的例子这样，其中前面三个值可以是任何值，用引号括起来
-的组名称则只能用例子中给的值。
+令牌文件看起来是下面的例子这样，其中前面三个值可以是任何值，
+用引号括起来的组名称则只能用例子中给的值。

 ```console
 02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"
@ -413,7 +413,7 @@ To do this, you only need to create a `ClusterRoleBinding` that binds the `syste
 -->
 ### 授权 kubelet 创建 CSR    {#authorize-kubelet-to-create-csr}

-现在启动引导节点被身份认证为 `system:bootstrapping` 组的成员，它需要被 _授权_
+现在启动引导节点被身份认证为 `system:bootstrapping` 组的成员，它需要被**授权**
 创建证书签名请求（CSR）并在证书被签名之后将其取回。
 幸运的是，Kubernetes 提供了一个 `ClusterRole`，其中精确地封装了这些许可，
 `system:node-bootstrapper`。
@ -491,7 +491,7 @@ To provide the Kubernetes CA key and certificate to kube-controller-manager, use
 由于这些被签名的证书反过来会被 kubelet 用来在 kube-apiserver 执行普通的
 kubelet 身份认证，很重要的一点是为控制器管理器所提供的 CA 也被 kube-apiserver
 信任用来执行身份认证。CA 密钥和证书是通过 kube-apiserver 的标志
-`--client-ca-file=FILENAME`（例如，`--client-ca-file=/var/lib/kubernetes/ca.pem`)，
+`--client-ca-file=FILENAME`（例如，`--client-ca-file=/var/lib/kubernetes/ca.pem`），
 来设定的，正如 kube-apiserver 配置节所述。

 要将 Kubernetes CA 密钥和证书提供给 kube-controller-manager，可使用以下标志：
@ -593,15 +593,15 @@ roleRef:
 <!--
 The `csrapproving` controller that ships as part of
 [kube-controller-manager](/docs/admin/kube-controller-manager/) and is enabled
-by default. The controller uses the [`SubjectAccessReview`
-API](/docs/reference/access-authn-authz/authorization/#checking-api-access) to
+by default. The controller uses the
+[`SubjectAccessReview` API](/docs/reference/access-authn-authz/authorization/#checking-api-access) to
 determine if a given user is authorized to request a CSR, then approves based on
 the authorization outcome. To prevent conflicts with other approvers, the
 builtin approver doesn't explicitly deny CSRs. It only ignores unauthorized
 requests. The controller also prunes expired certificates as part of garbage
 collection.
 -->
-作为 [kube-controller-manager](/zh/docs/reference/generated/kube-controller-manager/)
+作为 [kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)
 的一部分的 `csrapproving` 控制器是自动被启用的。
 该控制器使用 [`SubjectAccessReview` API](/zh/docs/reference/access-authn-authz/authorization/#checking-api-access)
 来确定是否某给定用户被授权请求 CSR，之后基于鉴权结果执行批复操作。
@ -612,7 +612,7 @@ collection.
 <!--
 ## kubelet configuration

-Finally, with the control plane properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet.
+Finally, with the control plane nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet.
 -->
 ## kubelet 配置   {#kubelet-configuration}

@ -678,7 +678,7 @@ The important elements to note are:

 * `certificate-authority`：指向 CA 文件的路径，用来对 kube-apiserver 所出示
  的服务器证书进行验证
-* `server`： 用来访问 kube-apiserver 的 URL
+* `server`：用来访问 kube-apiserver 的 URL
 * `token`：要使用的令牌

 <!--
@ -733,7 +733,7 @@ uses to authenticate to kube-apiserver.
 -->
 ### 客户和服务证书   {#client-and-serving-certificates}

-前文所述的内容都与 kubelet _客户端_ 证书相关，尤其是 kubelet 用来向
+前文所述的内容都与 kubelet **客户端**证书相关，尤其是 kubelet 用来向
 kube-apiserver 认证自身身份的证书。

 <!--
@ -744,7 +744,7 @@ To secure these, the kubelet can do one of:
 * create self-signed key and certificate, if a key and certificate are not provided
 * request serving certificates from the cluster server, via the CSR API
 -->
-kubelet 也可以使用 _服务（Serving）_ 证书。kubelet 自身向外提供一个
+kubelet 也可以使用**服务（Serving）**证书。kubelet 自身向外提供一个
 HTTPS 末端，包含若干功能特性。要保证这些末端的安全性，kubelet 可以执行以下操作
 之一：

@ -814,9 +814,9 @@ controller, or manually approve the serving certificate requests.
 -->
 Kubernetes 核心中所实现的 CSR 批复控制器出于
 [安全原因](https://github.com/kubernetes/community/pull/1982)
-并不会自动批复节点的 _服务_ 证书。
-要使用 `RotateKubeletServerCertificate` 功能特性，集群运维人员需要运行一个
-定制的控制器或者手动批复服务证书的请求。
+并不会自动批复节点的**服务**证书。
+要使用 `RotateKubeletServerCertificate` 功能特性，
+集群运维人员需要运行一个定制的控制器或者手动批复服务证书的请求。

 <!--
 A deployment-specific approval process for kubelet serving certificates should typically only approve CSRs which:
@ -833,11 +833,11 @@ A deployment-specific approval process for kubelet serving certificates should t

 1. 由节点发出的请求（确保 `spec.username` 字段形式为 `system:node:<nodeName>`
   且 `spec.groups` 包含 `system:nodes`）
-2. 请求中包含服务证书用法（确保 `spec.usages` 中包含 `server auth`，可选地也可 
-   包含 `digital signature` 和 `key encipherment`，且不包含其它用法）
+2. 请求中包含服务证书用法（确保 `spec.usages` 中包含 `server auth`，可选地也可包含
+   `digital signature` 和 `key encipherment`，且不包含其它用法）
 3. 仅包含隶属于请求节点的 IP 和 DNS 的 `subjectAltNames`，没有 URI 和 Email
-   形式的 `subjectAltNames`（解析 `spec.request` 中的 x509 证书签名请求可以
-   检查 `subjectAltNames`）
+   形式的 `subjectAltNames`（解析 `spec.request` 中的 x509 证书签名请求可以检查
+   `subjectAltNames`）
 {{< /note >}}

 <!--
@ -849,10 +849,9 @@ is part of the Kubernetes control plane and runs on every node, but may also inc
 -->
 ## 其它身份认证组件   {#other-authenticating-components}

-本文所描述的所有 TLS 启动引导内容都与 kubelet 相关。不过，其它组件也可能需要
-直接与 kube-apiserver 直接通信。容易想到的是 kube-proxy，同样隶属于
-Kubernetes 的控制面并且运行在所有节点之上，不过也可能包含一些其它负责
-监控或者联网的组件。
+本文所描述的所有 TLS 启动引导内容都与 kubelet 相关。不过，其它组件也可能需要直接与
+kube-apiserver 直接通信。容易想到的是 kube-proxy，同样隶属于
+Kubernetes 的控制面并且运行在所有节点之上，不过也可能包含一些其它负责监控或者联网的组件。

 <!--
 Like the kubelet, these other components also require a method of authenticating to kube-apiserver.
@ -865,13 +864,12 @@ You have several options for generating these credentials:
 * The old way: Create and distribute certificates the same way you did for kubelet before TLS bootstrapping
 * DaemonSet: Since the kubelet itself is loaded on each node, and is sufficient to start base services, you can run kube-proxy and other node-specific services not as a standalone process, but rather as a daemonset in the `kube-system` namespace. Since it will be in-cluster, you can give it a proper service account with appropriate permissions to perform its activities. This may be the simplest way to configure such services.
 -->
-* 较老的方式：和 kubelet 在 TLS 启动引导之前所做的一样，用类似的方式
-  创建和分发证书
+* 较老的方式：和 kubelet 在 TLS 启动引导之前所做的一样，用类似的方式创建和分发证书。
 * DaemonSet：由于 kubelet 自身被加载到所有节点之上，并且有足够能力来启动基本服务，
  你可以运行将 kube-proxy 和其它特定节点的服务作为 `kube-system` 名字空间中的
-  DaemonSet 来执行，而不是独立的进程。由于 DaemonSet 位于集群内部，你可以为其
-  指派一个合适的服务账户，使之具有适当的访问权限来完成其使命。这也许是配置此类
-  服务的最简单的方法。
+  DaemonSet 来执行，而不是独立的进程。由于 DaemonSet 位于集群内部，
+  你可以为其指派一个合适的服务账户，使之具有适当的访问权限来完成其使命。
+  这也许是配置此类服务的最简单的方法。

 <!--
 ## kubectl approval
@ -894,13 +892,12 @@ list CSRs with `kubectl get csr` and describe one in detail with `kubectl
 describe csr <name>`. An administrator can approve or deny a CSR with `kubectl
 certificate approve <name>` and `kubectl certificate deny <name>`.
 -->
-签名控制器并不会立即对所有证书请求执行签名操作。相反，它会等待这些请求被某
-具有适当特权的用户标记为 “Approved（已批准）”状态。
-这一流程有意允许由外部批复控制器来自动执行的批复，或者由控制器管理器内置的
-批复控制器来自动批复。
+签名控制器并不会立即对所有证书请求执行签名操作。相反，
+它会等待这些请求被某具有适当特权的用户标记为 “Approved（已批准）”状态。
+这一流程有意允许由外部批复控制器来自动执行的批复，
+或者由控制器管理器内置的批复控制器来自动批复。
 不过，集群管理员也可以使用 `kubectl` 来手动批准证书请求。
 管理员可以通过 `kubectl get csr` 来列举所有的 CSR，使用
 `kubectl descsribe csr <name>` 来描述某个 CSR 的细节。
 管理员可以使用 `kubectl certificate approve <name` 来批准某 CSR，或者
-`kubectl certificate deny <name>` 来拒绝某 CSR。
-
+`kubectl certificate deny <name>` 来拒绝某 CSR。
--- a/content/zh-cn/docs/reference/glossary/host-aliases.md
+++ b/content/zh-cn/docs/reference/glossary/host-aliases.md
@ -2,7 +2,7 @@
 title: HostAliases
 id: HostAliases
 date: 2019-01-31
-full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core
+full_link: /zh-cn/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core
 short_description: >
  主机别名 (HostAliases) 是一组 IP 地址和主机名的映射，用于注入到 Pod 内的 hosts 文件。

@ -10,10 +10,7 @@ aka:
 tags:
 - operation
 ---
- 主机别名 (HostAliases) 是一组 IP 地址和主机名的映射，用于注入到 {{< glossary_tooltip text="Pod" term_id="pod" >}} 内的 hosts 文件。
-
 <!--
---
 title: HostAliases
 id: HostAliases
 date: 2019-01-31
@ -24,9 +21,13 @@ short_description: >
 aka:
 tags:
 - operation
---
+-->
+
+<!--
 A HostAliases is a mapping between the IP address and hostname to be injected into a {{< glossary_tooltip text="Pod" term_id="pod" >}}'s hosts file.
 -->
+ 主机别名 (HostAliases) 是一组 IP 地址和主机名的映射，用于注入到 {{< glossary_tooltip text="Pod" term_id="pod" >}} 内的 hosts 文件。
+

 <!--more-->

--- a/content/zh-cn/docs/reference/glossary/kube-apiserver.md
+++ b/content/zh-cn/docs/reference/glossary/kube-apiserver.md
@ -1,26 +1,27 @@
 ---
-title: kube-apiserver
+title: API 服务器
 id: kube-apiserver
 date: 2018-04-12
-full_link: /zh/docs/reference/command-line-tools-reference/kube-apiserver/
+full_link: /zh-cn/docs/concepts/overview/components/#kube-apiserver
 short_description: >
  提供 Kubernetes API 服务的控制面组件。

-aka: 
+aka:
+- kube-apiserver
 tags:
 - architecture
 - fundamental
 ---
-
 <!--
-title: kube-apiserver
+title: API server
 id: kube-apiserver
 date: 2018-04-12
-full_link: /zh/docs/reference/command-line-tools-reference/kube-apiserver/
+full_link: /docs/concepts/overview/components/#kube-apiserver
 short_description: >
-  Control plane component that serves the Kubernetes API. 
+  Control plane component that serves the Kubernetes API.

-aka: 
+aka:
+- kube-apiserver
 tags:
 - architecture
 - fundamental
@ -35,13 +36,13 @@ API 服务器是 Kubernetes {{< glossary_tooltip text="控制平面" term_id="co
 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。
 API 服务器是 Kubernetes 控制平面的前端。

-<!--more--> 
+<!--more-->

 <!--
 The main implementation of a Kubernetes API server is [kube-apiserver](/docs/reference/generated/kube-apiserver/).
 kube-apiserver is designed to scale horizontally&mdash;that is, it scales by deploying more instances.
 You can run several instances of kube-apiserver and balance traffic between those instances.
 -->
-Kubernetes API 服务器的主要实现是 [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)。
+Kubernetes API 服务器的主要实现是 [kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)。
 `kube-apiserver` 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。
 你可以运行 `kube-apiserver` 的多个实例，并在这些实例之间平衡流量。
--- a/content/zh-cn/docs/reference/glossary/kube-controller-manager.md
+++ b/content/zh-cn/docs/reference/glossary/kube-controller-manager.md
@ -2,7 +2,7 @@
 title: kube-controller-manager
 id: kube-controller-manager
 date: 2018-04-12
-full_link: /docs/reference/generated/kube-controller-manager/
+full_link: /zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/
 short_description: >
  主节点上运行控制器的组件。

@ -11,13 +11,11 @@ tags:
 - architecture
 - fundamental
 ---
-
 <!--
---
 title: kube-controller-manager
 id: kube-controller-manager
 date: 2018-04-12
-full_link: /docs/reference/generated/kube-controller-manager/
+full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
 short_description: >
  Component on the master that runs controllers.

@ -25,20 +23,21 @@ aka:
 tags:
 - architecture
 - fundamental
---
 -->

 <!--
- Control plane component that runs 
+ Control plane component that runs
 {{< glossary_tooltip text="controller" term_id="controller" >}} processes.
 -->
-[kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 是{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件，
+[kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
+是{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件，
 负责运行{{< glossary_tooltip text="控制器" term_id="controller" >}}进程。

 <!--more-->
+
 <!--
-Logically, each {{< glossary_tooltip text="controller" term_id="controller" >}} 
-is a separate process, but to reduce complexity, 
+Logically, each {{< glossary_tooltip text="controller" term_id="controller" >}}
+is a separate process, but to reduce complexity,
 they are all compiled into a single binary and run in a single process.
 --> 
 从逻辑上讲，
--- a/content/zh-cn/docs/reference/glossary/kubelet.md
+++ b/content/zh-cn/docs/reference/glossary/kubelet.md
@ -2,14 +2,13 @@
 title: Kubelet
 id: kubelet
 date: 2018-04-12
-full_link: /docs/reference/generated/kubelet
+full_link: /zh-cn/docs/reference/generated/kubelet
 short_description: >
  一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。

-aka: 
+aka:
 tags:
 - fundamental
- core-object
 ---
 <!--
 title: Kubelet
@ -19,10 +18,9 @@ full_link: /docs/reference/generated/kubelet
 short_description: >
  An agent that runs on each node in the cluster. It makes sure that containers are running in a pod.

-aka: 
+aka:
 tags:
 - fundamental
- core-object
 -->

 <!--
@ -32,7 +30,7 @@ tags:
 它保证{{< glossary_tooltip text="容器（containers）" term_id="container" >}}都运行在
 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中。

-<!--more--> 
+<!--more-->

 <!--
 The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes.
--- a/content/zh-cn/docs/reference/using-api/api-concepts.md
+++ b/content/zh-cn/docs/reference/using-api/api-concepts.md
@ -127,7 +127,7 @@ HTTP verb for a **patch** is PATCH.
 -->
 ### API 动词 {#api-verbs}

-几乎所有对象资源类型都支持标准 HTTP 动词 - GET、POST、PUT、PATCH 和 DELETE。 
+几乎所有对象资源类型都支持标准 HTTP 动词 - GET、POST、PUT、PATCH 和 DELETE。
 Kubernetes 也使用自己的动词，这些动词通常写成小写，以区别于 HTTP 动词。

 Kubernetes 使用术语 **list** 来描述返回资源[集合](#collections)，
@ -315,7 +315,7 @@ this is called a `Reflector` and is located in the `k8s.io/client-go/tools/cache
 并基于新返回的 `resourceVersion` 来开始新的 **watch** 操作。

 对于订阅集合，Kubernetes 客户端库通常会为 **list** -然后- **watch** 的逻辑提供某种形式的标准工具。
-（在 Go 客户端库中，这称为`反射器（Reflector）`，位于 `k8s.io/client-go/tools/cache` 包中。）
+（在 Go 客户端库中，这称为 `反射器（Reflector）`，位于 `k8s.io/client-go/tools/cache` 包中。）

 <!--
 ### Watch bookmarks
@ -525,7 +525,7 @@ last chunk), then there are no more remaining items and the API server does not
 is estimating the size of a collection.
 -->
 `remainingItemCount` 是集合中未包含在此响应中的后续项目的数量。
-如果 **list** 请求包含标签或字段{{< glossary_tooltip text="选择器" term_id="selector">}} ，
+如果 **list** 请求包含标签或字段{{< glossary_tooltip text="选择器" term_id="selector">}}，
 则剩余项目的数量是未知的，并且 API 服务器在其响应中不包含 `remainingItemCount` 字段。
 如果 **list** 是完整的（因为它没有分块，或者因为这是最后一个块），没有更多的剩余项目，
 API 服务器在其响应中不包含 `remainingItemCount` 字段。
@ -660,7 +660,7 @@ had to be in place for types unrecognized by a client.
 -->
 ## 以表格形式接收资源  {#receiving-resources-as-tables}

-当你执行`kubectl get` 时，默认的输出格式是特定资源类型的一个或多个实例的简单表格形式。
+当你执行 `kubectl get` 时，默认的输出格式是特定资源类型的一个或多个实例的简单表格形式。
 过去，客户端需要重复 `kubectl` 中所实现的表格输出和描述输出逻辑，以执行
 简单的对象列表操作。
 该方法的一些限制包括处理某些对象时的不可忽视逻辑。
@ -775,7 +775,7 @@ header appropriately.
 默认情况下，Kubernetes 返回序列化为 JSON 的对象，内容类型为 `application/json`。
 这是 API 的默认序列化格式。
 但是，客户端可能会使用更有效的 [Protobuf 表示](#protobuf-encoding) 请求这些对象，
-以获得更好的大规模性能。 Kubernetes API 实现标准的 HTTP 内容类型协商：
+以获得更好的大规模性能。Kubernetes API 实现标准的 HTTP 内容类型协商：
 带有 `Accept` 请求头部的 `GET` 调用会请求服务器尝试以你的首选媒体类型返回响应，
 而将 Protobuf 中的对象发送到服务器以进行 `PUT` 或 `POST` 调用意味着你必须适当地设置
 `Content-Type` 请求头。
@ -846,7 +846,7 @@ content types in the request `Accept` header to support fallback to JSON.
 For example:
 -->
 并非所有 API 资源类型都支持 Protobuf；具体来说，
-Protobuf 不适用于定义为 {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} 
+Protobuf 不适用于定义为 {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}}
 或通过{{< glossary_tooltip text="聚合层" term_id="aggregation-layer" >}}提供服务的资源。
 作为客户端，如果你可能需要使用扩展类型，则应在请求 `Accept` 请求头中指定多种内容类型以支持回退到 JSON。
 例如：
@ -1100,7 +1100,7 @@ that they do not have side effects, by setting their `sideEffects` field to `Non
 -->
 如果请求的非试运行版本会触发具有副作用的准入控制器，则该请求将失败，而不是冒不希望的副作用的风险。
 所有内置准入控制插件都支持试运行。
-此外，准入 Webhook 还可以设置[配置对象](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#webhook-v1beta1-admissionregistration-k8s-io)
+此外，准入 Webhook 还可以设置[配置对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#webhook-v1beta1-admissionregistration-k8s-io)
 的 `sideEffects` 字段为 `None`，借此声明它们没有副作用。

 <!--
@ -1154,7 +1154,7 @@ Some values of an object are typically generated before the object is persisted.
 * `creationTimestamp` / `deletionTimestamp`：记录对象的创建/删除时间
 * `UID`：[唯一标识](/zh/docs/concepts/overview/working-with-objects/names/#uids)对象，
  取值随机生成（非确定性）
-* `resourceVersion`： 跟踪对象的持久化（存储）版本
+* `resourceVersion`：跟踪对象的持久化（存储）版本
 * 变更性准入控制器所设置的字段
 * 对于 `Service` 资源：`kube-apiserver` 为 `Service` 对象分配的端口和 IP 地址

@ -1281,9 +1281,9 @@ API 服务器根据你请求的操作和 `resourceVersion` 的值对 `resourceVe
 For **get** and **list**, the semantics of `resourceVersion` are:

 -->
-### **get** 和 **list** 语义
+### **get** 和 **list** 语义   {#semantics-for-get-and-list}

-对于 **get** 和 **list** 而言，`resourceVersion`的语义为：
+对于 **get** 和 **list** 而言，`resourceVersion` 的语义为：

 **get:**

@ -1453,8 +1453,8 @@ the object is when served.

 {{< note >}}
 当你 **list** 资源并收到集合响应时，
-响应包括集合的[元数据](/zh/docs/reference/generated/kubernetes-api/v1.21/#listmeta-v1-meta)
-以及该集合中每个项目的[对象元数据](/zh/docs/reference/generated/kubernetes-api/v1.21/#listmeta-v1-meta)。
+响应包括集合的[元数据](/docs/reference/generated/kubernetes-api/v1.21/#listmeta-v1-meta)
+以及该集合中每个项目的[对象元数据](/docs/reference/generated/kubernetes-api/v1.21/#listmeta-v1-meta)。
 对于在集合响应中找到的单个对象，`.metadata.resourceVersion` 跟踪该对象的最后更新时间，
 而不是对象在服务时的最新程度。
 {{< /note >}}
@ -1484,7 +1484,7 @@ example, the client might fall back to a request with `limit` set.

 For watch, the semantics of resource version are:
 -->
-### **watch** 语义
+### **watch** 语义   {#semantics-for-watch}

 对于 watch 操作而言，资源版本的语义如下：

@ -1628,4 +1628,4 @@ available.
 kube-apiserver 还会使用 “Too large resource version” 消息额外标识其错误响应。

 如果你对无法识别的资源版本发出 **watch** 请求，
-API 服务器可能会无限期地等待（直到请求超时）资源版本变为可用。
+API 服务器可能会无限期地等待（直到请求超时）资源版本变为可用。
--- a/content/zh-cn/docs/tasks/configure-pod-container/configure-runasusername.md
+++ b/content/zh-cn/docs/tasks/configure-pod-container/configure-runasusername.md
@ -119,9 +119,9 @@ in the Container manifest, and within it, the
 ## 为容器设置 Username    {#set-the-username-for-a-container}

 要指定运行容器时所使用的用户名，请在容器清单中包含 `securityContext`
-([SecurityContext](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core))
+([SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core))
 字段，并在其内部包含 `windowsOptions`
-（[WindowsSecurityContextOptions](/zh/docs/reference/generated/kubernetes-api/{{< param
+（[WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param
 "version" >}}/#windowssecuritycontextoptions-v1-core)）
 字段的 `runAsUserName` 字段。

--- a/content/zh-cn/docs/tasks/debug/debug-cluster/audit.md
+++ b/content/zh-cn/docs/tasks/debug/debug-cluster/audit.md
@ -21,7 +21,7 @@ by applications that use the Kubernetes API, and by the control plane itself.

 Auditing allows cluster administrators to answer the following questions:
 -->
-Kubernetes _审计（Auditing）_ 功能提供了与安全相关的、按时间顺序排列的记录集，
+Kubernetes **审计（Auditing）**功能提供了与安全相关的、按时间顺序排列的记录集，
 记录每个用户、使用 Kubernetes API 的应用以及控制面自身引发的活动。

 审计功能使得集群管理员能够回答以下问题：
@ -73,7 +73,7 @@ Each request can be recorded with an associated _stage_. The defined stages are:
  will be sent.
 - `Panic` - Events generated when a panic occurred.
 -->
-每个请求都可被记录其相关的 _阶段（stage）_。已定义的阶段有：
+每个请求都可被记录其相关的**阶段（stage）**。已定义的阶段有：

 - `RequestReceived` - 此阶段对应审计处理器接收到请求后，并且在委托给
  其余处理器之前生成的事件。
@ -91,7 +91,7 @@ API object.
 -->
 {{< note >}}
 [审计事件配置](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
-的配置与 [Event](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
+的配置与 [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
 API 对象不同。
 {{< /note >}}

@ -119,7 +119,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 Level）_。已定义的审计级别有：
+**审计级别（Audit Level）**。已定义的审计级别有：

 <!--
 - `None` - don't log events that match this rule.
@ -147,7 +147,7 @@ Below is an example audit policy file:
 -->
 你可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 `kube-apiserver`。
 如果不设置该标志，则不记录事件。
-注意 `rules` 字段 __必须__ 在审计策略文件中提供。没有（0）规则的策略将被视为非法配置。
+注意 `rules` 字段**必须**在审计策略文件中提供。没有（0）规则的策略将被视为非法配置。

 以下是一个审计策略文件的示例：

@ -241,7 +241,7 @@ You can configure the log audit backend using the following `kube-apiserver` fla
 Log backend writes audit events to a file in JSON format. You can configure
 log audit backend using the following [kube-apiserver][kube-apiserver] flags:
 -->
-### Log 后端
+### Log 后端   {#log-backend}

 Log 后端将审计事件写入 [JSONlines](https://jsonlines.org/)  格式的文件。
 你可以使用以下 `kube-apiserver` 标志配置 Log 审计后端：
@ -449,5 +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/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations)。
--- a/content/zh-cn/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md
+++ b/content/zh-cn/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md
@ -39,7 +39,7 @@ command.
 [VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) (VPA) 
 使用 metrics API 中的数据调整工作负载副本和资源，以满足客户需求。

-你也可以通过 [`kubectl top`](/zh/docs/reference/generated/kubectl/kubectl-commands#top) 命令来查看资源指标。
+你也可以通过 [`kubectl top`](/docs/reference/generated/kubectl/kubectl-commands#top) 命令来查看资源指标。

 {{< note >}}
 <!--
@ -114,7 +114,7 @@ The architecture components, from right to left in the figure, consist of the fo
  可以使用 `/metrics/resource` 和 `/stats` kubelet API 端点访问资源指标。
 * [Summary API](#summary-api-source): kubelet 提供的 API，用于发现和检索可通过 `/stats` 端点获得的每个节点的汇总统计信息。
 * [metrics-server](#metrics-server): 集群插件组件，用于收集和聚合从每个 kubelet 中提取的资源指标。
-  API 服务器提供 Metrics API 以供 HPA、VPA 和 `kubectl top` 命令使用。 Metrics Server 是 Metrics API 的参考实现。
+  API 服务器提供 Metrics API 以供 HPA、VPA 和 `kubectl top` 命令使用。Metrics Server 是 Metrics API 的参考实现。
 * [Metrics API](#metrics-api): Kubernetes API 支持访问用于工作负载自动缩放的 CPU 和内存。
  要在你的集群中进行这项工作，你需要一个提供 Metrics API 的 API 扩展服务器。

@ -387,10 +387,10 @@ them in the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e01
 for consumers to read.
 -->

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

 [Kubelet](/zh/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)
+并在 [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)
 中提供它们的统计信息供消费者阅读。

 <!--
@ -416,4 +416,4 @@ The summary API `/stats/summary` endpoint will be replaced by the `/metrics/reso
 beginning with metrics-server 0.6.x.
 -->
 从 metrics-server 0.6.x 开始，Summary API `/stats/summary` 端点被 `/metrics/resource` 端点替换。
-{{< /note >}}
+{{< /note >}}
--- a/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@ -33,7 +33,7 @@ assigning more resources (for example: memory or CPU) to the Pods that are alrea
 running for the workload.
 -->
 [HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) （简称 HPA ）
-自动更新工作负载资源（例如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或者 
+自动更新工作负载资源（例如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或者
 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}），
 目的是自动扩缩工作负载以满足需求。

@ -80,7 +80,7 @@ new kinds of resource that represent metric readings.
 To learn how to deploy the Metrics Server, see the
 [metrics-server documentation](https://github.com/kubernetes-sigs/metrics-server#deployment).
 -->
-按照本演练进行操作，你需要一个部署并配置了 
+按照本演练进行操作，你需要一个部署并配置了
 [Metrics Server](https://github.com/kubernetes-sigs/metrics-server#readme) 的集群。
 Kubernetes Metrics Server 从集群中的 {{<glossary_tooltip term_id="kubelet" text="kubelets">}} 收集资源指标，
 并通过 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) 公开这些指标，
@ -175,7 +175,7 @@ on the algorithm.
 ## 创建 HorizontalPodAutoscaler  {#create-horizontal-pod-autoscaler}

 现在服务器正在运行，使用 `kubectl` 创建自动扩缩器。
-[`kubectl autoscale`](/zh/docs/reference/generated/kubectl/kubectl-commands#autoscale) 子命令是 `kubectl` 的一部分，
+[`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands#autoscale) 子命令是 `kubectl` 的一部分，
 可以帮助你执行此操作。

 你将很快运行一个创建 HorizontalPodAutoscaler 的命令，
@ -183,7 +183,7 @@ on the algorithm.

 粗略地说，HPA {{<glossary_tooltip text="控制器" term_id="controller">}}将增加和减少副本的数量
 （通过更新 Deployment）以保持所有 Pod 的平均 CPU 利用率为 50%。
-Deployment 然后更新 ReplicaSet —— 这是所有 Deployment 在 Kubernetes 中工作方式的一部分 —— 
+Deployment 然后更新 ReplicaSet —— 这是所有 Deployment 在 Kubernetes 中工作方式的一部分 ——
 然后 ReplicaSet 根据其 `.spec` 的更改添加或删除 Pod。

 由于每个 Pod 通过 `kubectl run` 请求 200 milli-cores，这意味着平均 CPU 使用率为 100 milli-cores。
@ -649,7 +649,7 @@ relationship to any object in the Kubernetes cluster, such as metrics describing
 no direct correlation to Kubernetes namespaces. In Kubernetes 1.10 and later, you can address this use case
 with *external metrics*.
 -->
-### 基于与 Kubernetes 对象无关的度量指标执行扩缩
+### 基于与 Kubernetes 对象无关的度量指标执行扩缩   {#autoscaling-on-metrics-not-related-to-kubernetes-objects}

 运行在 Kubernetes 上的应用程序可能需要基于与 Kubernetes 集群中的任何对象
 没有明显关系的度量指标进行自动扩缩，
@ -710,7 +710,7 @@ When using the `autoscaling/v2` form of the HorizontalPodAutoscaler, you will be
 whether or not the HorizontalPodAutoscaler is able to scale, and whether or not it is currently restricted
 in any way.
 -->
-## 附录：Horizontal Pod Autoscaler 状态条件
+## 附录：Horizontal Pod Autoscaler 状态条件   {#appendix-horizontal-pod-autoscaler-status-conditions}

 使用 `autoscaling/v2` 格式的 HorizontalPodAutoscaler 时，你将可以看到
 Kubernetes 为 HorizongtalPodAutoscaler 设置的状态条件（Status Conditions）。
@ -816,5 +816,4 @@ kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml

 ```
 horizontalpodautoscaler.autoscaling/php-apache created
-```
-
+```
--- a/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md
@ -1,7 +1,7 @@
 ---
 title: Pod 水平自动扩缩
 feature:
-  title: 水平扩缩 
+  title: 水平扩缩
  description: >
    使用一个简单的命令、一个 UI 或基于 CPU 使用情况自动对应用程序进行扩缩。

@ -18,7 +18,7 @@ a {{< glossary_tooltip text="Deployment" term_id="deployment" >}} or
 aim of automatically scaling the workload to match demand.
 -->
 在 Kubernetes 中，_HorizontalPodAutoscaler_ 自动更新工作负载资源
-（例如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或者 
+（例如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或者
 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}），
 目的是自动扩缩工作负载以满足需求。

@ -83,8 +83,8 @@ Kubernetes implements horizontal pod autoscaling as a control loop that runs int
 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)
 (and the default interval is 15 seconds).
 -->
-Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路（它不是一个连续的过程）。间隔由 
-[`kube-controller-manager`](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 
+Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路（它不是一个连续的过程）。间隔由
+[`kube-controller-manager`](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
 的 `--horizontal-pod-autoscaler-sync-period` 参数设置（默认间隔为 15 秒）。

 <!--
@ -238,7 +238,7 @@ When scaling on CPU, if any pod has yet to become ready (it's still
 initializing, or possibly is unhealthy) *or* the most recent metric point for the pod was before it
 became ready, that pod is set aside as well.
 -->
-当使用 CPU 指标来扩缩时，任何还未就绪（还在初始化，或者可能是不健康的）状态的 Pod **或** 
+当使用 CPU 指标来扩缩时，任何还未就绪（还在初始化，或者可能是不健康的）状态的 Pod **或**
 最近的指标度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。

 <!--
@ -398,7 +398,7 @@ If you perform a rolling update of a StatefulSet that has an autoscaled number o
 replicas, the StatefulSet directly manages its set of Pods (there is no intermediate resource
 similar to ReplicaSet).
 -->
-如果你对一个副本个数被自动扩缩的 StatefulSet 执行滚动更新， 该 StatefulSet
+如果你对一个副本个数被自动扩缩的 StatefulSet 执行滚动更新，该 StatefulSet
 会直接管理它的 Pod 集合 （不存在类似 ReplicaSet 这样的中间资源）。

 <!--
@ -540,7 +540,7 @@ See [Support for metrics APIs](#support-for-metrics-apis) for the requirements.

 （之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）

-如果你使用 `autoscaling/v2` API 版本，则可以将 HorizontalPodAutoscaler 
+如果你使用 `autoscaling/v2` API 版本，则可以将 HorizontalPodAutoscaler
 配置为基于自定义指标（未内置于 Kubernetes 或任何 Kubernetes 组件）进行扩缩。
 HorizontalPodAutoscaler 控制器能够从 Kubernetes API 查询这些自定义指标。

@ -598,14 +598,14 @@ APIs, cluster administrators must ensure that:

   * 对于资源指标，将使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。
     它可以作为集群插件启动。
-    
+
   * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。
    它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。
    检查你的指标管道以查看是否有可用的 Kubernetes 指标适配器。
-   
+
   * 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。

-<!--  
+<!--
 For more information on these different metrics paths and how they differ please see the relevant design proposals for
 [the HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md),
 [custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md)
@ -613,18 +613,18 @@ and [external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-arc
 -->
 关于指标来源以及其区别的更多信息，请参阅相关的设计文档，
 [HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md)，
-[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md) 和 
+[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md) 和
 [external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md)。

 <!--
 For examples of how to use them see [the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
 and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects).
 -->
-关于如何使用它们的示例，请参考 
+关于如何使用它们的示例，请参考
 [使用自定义指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
 和[使用外部指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。

-<!--  
+<!--
 ## Configurable scaling behavior

 (the `autoscaling/v2beta2` API version previously provided this ability as a beta feature)
@ -651,10 +651,10 @@ the replica count for a scaling target. Scaling policies also let you controls t
 rate of change of replicas while scaling.
 -->

-你可以指定一个 “稳定窗口” ，以防止扩缩目标的副本计数发生[波动](#flapping)。
+你可以指定一个 “稳定窗口”，以防止扩缩目标的副本计数发生[波动](#flapping)。
 扩缩策略还允许你在扩缩时控制副本的变化率。

-<!--  
+<!--
 ### Scaling Policies

 One or more scaling policies can be specified in the `behavior` section of the spec.
@ -678,7 +678,7 @@ behavior:
      periodSeconds: 60
 ```

-<!--  
+<!--
 `periodSeconds` indicates the length of time in the past for which the policy must hold true.
 The first policy _(Pods)_ allows at most 4 replicas to be scaled down in one minute. The second policy
 _(Percent)_ allows at most 10% of the current replicas to be scaled down in one minute.
@ -703,7 +703,7 @@ and 4 replicas will be reduced at a time.
 在 autoscaler 控制器的每个循环中，将根据当前副本的数量重新计算要更改的 Pod 数量。
 当副本数量低于 40 时，应用第一个策略（Pods），一次减少 4 个副本。

-<!--  
+<!--
 The policy selection can be changed by specifying the `selectPolicy` field for a scaling
 direction. By setting the value to `Min` which would select the policy which allows the
 smallest change in the replica count. Setting the value to `Disabled` completely disables
@ -713,7 +713,7 @@ scaling in that direction.
 通过设置 `Min` 的值，它将选择副本数变化最小的策略。
 将该值设置为 `Disabled` 将完全禁用该方向的扩缩。

-<!--  
+<!--
 ### Stabilization Window

 The stabilization window is used to restrict the [flapping](#flapping) of
@ -736,7 +736,7 @@ behavior:
    stabilizationWindowSeconds: 300
 ```

-<!--  
+<!--
 When the metrics indicate that the target should be scaled down the algorithm looks
 into previously computed desired states, and uses the highest value from the specified
 interval. In the above example, all desired states from the past 5 minutes will be considered.
@ -750,7 +750,7 @@ remove Pods only to trigger recreating an equivalent Pod just moments later.
 -->
 这近似于滚动最大值，并避免了扩缩算法频繁删除 Pod 而又触发重新创建等效 Pod。

-<!--  
+<!--
 ### Default Behavior

 To use the custom scaling not all fields have to be specified. Only values which need to be
@ -784,7 +784,7 @@ behavior:
    selectPolicy: Max
 ```

-<!--  
+<!--
 For scaling down the stabilization window is _300_ seconds (or the value of the
 `--horizontal-pod-autoscaler-downscale-stabilization` flag if provided). There is only a single policy
 for scaling down which allows a 100% of the currently running replicas to be removed which
@ -793,18 +793,18 @@ For scaling up there is no stabilization window. When the metrics indicate that
 scaled up the target is scaled up immediately. There are 2 policies where 4 pods or a 100% of the currently
 running replicas will be added every 15 seconds till the HPA reaches its steady state.
 -->
-用于缩小稳定窗口的时间为 _300_  秒(或是 `--horizontal-pod-autoscaler-downscale-stabilization`
+用于缩小稳定窗口的时间为 _300_ 秒(或是 `--horizontal-pod-autoscaler-downscale-stabilization`
 参数设定值)。
 只有一种缩容的策略，允许 100% 删除当前运行的副本，这意味着扩缩目标可以缩小到允许的最小副本数。
 对于扩容，没有稳定窗口。当指标显示目标应该扩容时，目标会立即扩容。
 这里有两种策略，每 15 秒添加 4 个 Pod 或 100% 当前运行的副本数，直到 HPA 达到稳定状态。

-<!--  
+<!--
 ### Example: change downscale stabilization window

 To provide a custom downscale stabilization window of 1 minute, the following
 behavior would be added to the HPA:
--> 
+-->
 ### 示例：更改缩容稳定窗口 {#example-change-downscale-stabilization-window}

 将下面的 behavior 配置添加到 HPA 中，可提供一个 1 分钟的自定义缩容稳定窗口：
@ -815,7 +815,7 @@ behavior:
    stabilizationWindowSeconds: 60
 ```

-<!--  
+<!--
 ### Example: limit scale down rate

 To limit the rate at which pods are removed by the HPA to 10% per minute, the
@ -834,7 +834,7 @@ behavior:
      periodSeconds: 60
 ```

-<!--  
+<!--
 To ensure that no more than 5 Pods are removed per minute, you can add a second scale-down
 policy with a fixed size of 5, and set `selectPolicy` to minimum. Setting `selectPolicy` to `Min` means
 that the autoscaler chooses the policy that affects the smallest number of Pods:
@ -855,7 +855,7 @@ behavior:
    selectPolicy: Min
 ```

-<!--  
+<!--
 ### Example: disable scale down

 The `selectPolicy` value of `Disabled` turns off scaling the given direction.
@ -894,7 +894,7 @@ will create an autoscaler for ReplicaSet *foo*, with target CPU utilization set
 and the number of replicas between 2 and 5.
 -->
 此外，还有一个特殊的 `kubectl autoscale` 命令用于创建 HorizontalPodAutoscaler 对象。
-例如，执行 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` 
+例如，执行 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`
 将为 ReplicaSet *foo* 创建一个自动扩缩器，目标 CPU 利用率设置为 `80%`，副本数在 2 到 5 之间。

 <!--
@ -962,9 +962,9 @@ methods based on how you are modifying your deployments:
 -->
 1. `kubectl apply edit-last-applied deployment/<Deployment 名称>`
 2. 在编辑器中，删除 `spec.replicas`。当你保存并退出编辑器时，`kubectl` 会应用更新。
-  在此步骤中不会更改 Pod 计数。
+   在此步骤中不会更改 Pod 计数。
 3. 你现在可以从清单中删除 `spec.replicas`。如果你使用源代码管理，
-  还应提交你的更改或采取任何其他步骤来修改源代码，以适应你如何跟踪更新。
+   还应提交你的更改或采取任何其他步骤来修改源代码，以适应你如何跟踪更新。
 4. 从这里开始，你可以运行 `kubectl apply -f deployment.yaml`

 {{% /tab %}}
@ -1002,7 +1002,7 @@ For more information on HorizontalPodAutoscaler:
 * Read the [API reference](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/) for HorizontalPodAutoscaler.
 -->
 * 阅读水平 Pod 自动扩缩的[演练示例](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)。
-* 阅读 [`kubectl autoscale`](/zh/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 的文档。
+* 阅读 [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 的文档。
 * 如果你想编写自己的自定义指标适配器，
  请查看 [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) 以开始使用。
-* 阅读 [API 参考](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/)。
+* 阅读 [API 参考](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/)。