diff --git a/content/zh/docs/reference/_index.md b/content/zh/docs/reference/_index.md
index 75000a7708..5f9c8b5433 100644
--- a/content/zh/docs/reference/_index.md
+++ b/content/zh/docs/reference/_index.md
@@ -70,7 +70,8 @@ client libraries:
## CLI 参考
* [kubectl](/zh/docs/reference/kubectl/overview/) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。
- * [JSONPath](/zh/docs/reference/kubectl/jsonpath/) - 通过 kubectl 使用 [JSONPath 表达式](http://goessner.net/articles/JsonPath/) 的语法指南。
+ * [JSONPath](/zh/docs/reference/kubectl/jsonpath/) - 通过 kubectl 使用
+ [JSONPath 表达式](https://goessner.net/articles/JsonPath/) 的语法指南。
* [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。
## 设计文档
-Kubernetes 功能的设计文档归档，不妨考虑从 [Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 [Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals)开始阅读。
+Kubernetes 功能的设计文档归档，不妨考虑从
+[Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和
+[Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals)
+开始阅读。
diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md
index d5c847ab5f..2e0ad53a92 100644
--- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md
@@ -5,7 +5,6 @@ weight: 30
---
-
此页面概述了准入控制器。
-
有关对证书签名请求资源执行不同操作所需权限的详细信息，
-请参阅[证书签名请求](/docs/reference/access-authn-authz/certificate-signing-requests/)
+请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)
### CertificateSigning
diff --git a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md
index 9e42aa7bdf..f41d34c8ee 100644
--- a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md
+++ b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md
@@ -5,11 +5,9 @@ weight: 40
---
@@ -18,15 +16,15 @@ In addition to [compiled-in admission plugins](/docs/reference/access-authn-auth
admission plugins can be developed as extensions and run as webhooks configured at runtime.
This page describes how to build, configure, use, and monitor admission webhooks.
-->
-除了[内置的 admission 插件](/zh/docs/reference/access-authn-authz/admission-controllers/)，admission 插件可以作为扩展独立开发，并以运行时所配置的 webhook 的形式运行。
-此页面描述了如何构建、配置、使用和监视 admission webhook。
-
+除了[内置的 admission 插件](/zh/docs/reference/access-authn-authz/admission-controllers/)，
+准入插件可以作为扩展独立开发，并以运行时所配置的 Webhook 的形式运行。
+此页面描述了如何构建、配置、使用和监视准入 Webhook。
-## 什么是 admission webhook？
+## 什么是准入 Webhook？
-Admission webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。
-可以定义两种类型的 admission webhook，即 [validating admission webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) 和 [mutating admission webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。
-Mutating admission webhook 会先被调用。它们可以更改发送到 API 服务器的对象以执行自定义的设置默认值操作。
+准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。
+可以定义两种类型的准入 webhook，即
+[验证性质的准入 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) 和
+[修改性质的准入 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)。
+修改性质的准入 Webhook 会先被调用。它们可以更改发送到 API
+服务器的对象以执行自定义的设置默认值操作。
-在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后，validating admission webhook 会被调用，并通过拒绝请求的方式来强制实施自定义的策略。
+在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后，
+验证性质的 Webhook 会被调用，并通过拒绝请求的方式来强制实施自定义的策略。
{{< note >}}
-如果 admission webhook 需要保证它们所看到的是对象的最终状态以实施某种策略。则应使用 validating admission webhook，因为对象被 mutating webhook 看到之后仍然可能被修改。
+如果准入 Webhook 需要保证它们所看到的是对象的最终状态以实施某种策略。
+则应使用验证性质的准入 Webhook，因为对象被修改性质 Webhook 看到之后仍然可能被修改。
{{< /note >}}
@@ -64,11 +67,11 @@ guides](/docs/reference/access-authn-authz/extensible-admission-controllers/#wri
instructions if you intend to write/deploy production-grade admission webhooks.
In the following, we describe how to quickly experiment with admission webhooks.
-->
-### 尝试 admission webhook
+### 尝试准入 Webhook
-admission webhook 本质上是集群控制平面的一部分。您应该非常谨慎地编写和部署它们。
-如果您打算编写或者部署生产级 admission webhook，请阅读[用户指南](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。
-在下文中，我们将介绍如何快速试验 admission webhook。
+准入 Webhook 本质上是集群控制平面的一部分。你应该非常谨慎地编写和部署它们。
+如果你打算编写或者部署生产级准入 webhook，请阅读[用户指南](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server)以获取相关说明。
+在下文中，我们将介绍如何快速试验准入 Webhook。
-### 编写一个 admission webhook 服务器
+### 编写一个准入 Webhook 服务器
-示例 admission webhook 服务器置 `ClientAuth` 字段为[空](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48)，默认为 `NoClientCert` 。这意味着 webhook 服务器不会验证客户端的身份，认为其是 apiservers。
-如果您需要双向 TLS 或其他方式来验证客户端，请参阅如何[对 apiservers 进行身份认证](#authenticate-apiservers)。
+示例准入 Webhook 服务器置 `ClientAuth` 字段为[空](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48)，默认为 `NoClientCert` 。这意味着 webhook 服务器不会验证客户端的身份，认为其是 apiservers。
+如果你需要双向 TLS 或其他方式来验证客户端，请参阅如何[对 apiservers 进行身份认证](#authenticate-apiservers)。
-### 部署 admission webhook 服务
+### 部署准入 Webhook 服务
-您也可以在集群外部署 webhook。这样做需要相应地更新您的 webhook 配置。
+你也可以在集群外部署 webhook。这样做需要相应地更新你的 webhook 配置。
-### 即时配置 admission webhook
+### 即时配置准入 Webhook
-您可以通过 [ValidatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#validatingwebhookconfiguration-v1-admissionregistration-k8s-io) 或者 [MutatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io) 动态配置哪些资源要被哪些 admission webhook 处理。
+你可以通过 [ValidatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#validatingwebhookconfiguration-v1-admissionregistration-k8s-io) 或者 [MutatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io) 动态配置哪些资源要被哪些准入 Webhook 处理。
-scope 字段指定是仅集群范围的资源（Cluster）还是命名空间范围的资源资源（Namespaced）将与此规则匹配。`*` 表示没有范围限制。
+scope 字段指定是仅集群范围的资源（Cluster）还是名字空间范围的资源资源（Namespaced）将与此规则匹配。`*` 表示没有范围限制。
{{< note >}}
-对于使用 `admissionregistration.k8s.io/v1` 创建的 webhook 而言，其 webhook 调用的默认超时是 10 秒；对于使用 `admissionregistration.k8s.io/v1beta1` 创建的 webhook 而言，其默认超时是 30 秒。从 kubernetes 1.14 开始，可以设置超时。建议对 webhooks 设置较短的超时时间。
+对于使用 `admissionregistration.k8s.io/v1` 创建的 webhook 而言，其 webhook 调用的默认超时是 10 秒；
+对于使用 `admissionregistration.k8s.io/v1beta1` 创建的 webhook 而言，其默认超时是 30 秒。
+从 kubernetes 1.14 开始，可以设置超时。建议对 webhooks 设置较短的超时时间。
如果 webhook 调用超时，则根据 webhook 的失败策略处理请求。
{{< /note >}}
@@ -266,7 +271,7 @@ If your admission webhooks require authentication, you can configure the
apiservers to use basic auth, bearer token, or a cert to authenticate itself to
the webhooks. There are three steps to complete the configuration.
-->
-如果您的 webhook 需要身份验证，则可以将 apiserver 配置为使用基本身份验证、持有者令牌或证书来向 webhook 提供身份证明。完成此配置需要三个步骤。
+如果你的 webhook 需要身份验证，则可以将 apiserver 配置为使用基本身份验证、持有者令牌或证书来向 webhook 提供身份证明。完成此配置需要三个步骤。
-当然，您需要设置 webhook 服务器来处理这些身份验证。
+当然，你需要设置 webhook 服务器来处理这些身份验证。
-当拒绝请求时，webhook 可以使用 `status` 字段自定义 http 响应码和返回给用户的消息。
-有关状态类型的详细信息，请参见 [API 文档](/docs/reference/generated/kubernetes-api/v1.14/#status-v1-meta)。
+当拒绝请求时，Webhook 可以使用 `status` 字段自定义 http 响应码和返回给用户的消息。
+有关状态类型的详细信息，请参见
+[API 文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#status-v1-meta)。
禁止请求的响应示例，它定制了向用户显示的 HTTP 状态码和消息：
{{< tabs name="AdmissionReview_response_forbid_details" >}}
@@ -745,7 +751,7 @@ The only currently supported `patchType` is `JSONPatch`.
See [JSON patch](http://jsonpatch.com/) documentation for more details.
For `patchType: JSONPatch`, the `patch` field contains a base64-encoded array of JSON patch operations.
-->
-当允许请求时，mutating admission webhook 也可以选择修改传入的对象。
+当允许请求时，mutating准入 Webhook 也可以选择修改传入的对象。
这是通过在响应中使用 `patch` 和 `patchType` 字段来完成的。
当前唯一支持的 `patchType` 是 `JSONPatch`。
有关更多详细信息，请参见 [JSON patch](https://jsonpatch.com/)。
@@ -756,9 +762,11 @@ As an example, a single patch operation that would set `spec.replicas` would be
Base64-encoded, this would be `W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=`
-->
-例如，设置 `spec.replicas` 的单个补丁操作将是 `[{"op": "add", "path": "/spec/replicas", "value": 3}]`。
+例如，设置 `spec.replicas` 的单个补丁操作将是
+`[{"op": "add", "path": "/spec/replicas", "value": 3}]`。
-如果以 Base64 形式编码，这将是 `W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=`
+如果以 Base64 形式编码，结果将是
+`W3sib3AiOiAiYWRkIiwgInBhdGgiOiAiL3NwZWMvcmVwbGljYXMiLCAidmFsdWUiOiAzfV0=`
-## webhook 配置{#webhook-configuration}
+## Webhook 配置{#webhook-configuration}
-要注册 admssion webhook，请创建 `MutatingWebhookConfiguration` 或 `ValidatingWebhookConfiguration` API 对象。
+要注册准入 Webhook，请创建 `MutatingWebhookConfiguration` 或
+`ValidatingWebhookConfiguration` API 对象。
-每种配置可以包含一个或多个 webhook。如果在单个配置中指定了多个 webhook，则应为每个 webhook 赋予一个唯一的名称。
-这在 `admissionregistration.k8s.io/v1` 中是必需的，但是在使用 `admissionregistration.k8s.io/v1beta1` 时强烈建议使用，以使生成的审核日志和指标更易于与活动配置相匹配。
+每种配置可以包含一个或多个 Webhook。如果在单个配置中指定了多个
+Webhook，则应为每个 webhook 赋予一个唯一的名称。
+这在 `admissionregistration.k8s.io/v1` 中是必需的，但是在使用
+`admissionregistration.k8s.io/v1beta1` 时强烈建议使用，
+以使生成的审核日志和指标更易于与活动配置相匹配。
-每个 webhook 定义以下内容。
+每个 Webhook 定义以下内容。
-* `operations` 列出一个或多个要匹配的操作。可以是 `CREATE`、`UPDATE`、`DELETE`、`CONNECT` 或 `*` 以匹配所有内容。
+* `operations` 列出一个或多个要匹配的操作。
+ 可以是 `CREATE`、`UPDATE`、`DELETE`、`CONNECT` 或 `*` 以匹配所有内容。
* `apiGroups` 列出了一个或多个要匹配的 API 组。`""` 是核心 API 组。`"*"` 匹配所有 API 组。
* `apiVersions` 列出了一个或多个要匹配的 API 版本。`"*"` 匹配所有 API 版本。
* `resources` 列出了一个或多个要匹配的资源。
@@ -850,9 +863,11 @@ Each rule specifies one or more operations, apiGroups, apiVersions, and resource
* `"*/*"` 匹配所有资源，包括子资源。
* `"pods/*"` 匹配 pod 的所有子资源。
* `"*/status"` 匹配所有 status 子资源。
-* `scope` 指定要匹配的范围。有效值为 `"Cluster"`、`"Namespaced"` 和 `"*"`。子资源匹配其父资源的范围。在 Kubernetes v1.14+ 版本中才被支持。默认值为 `"*"`，对应 1.14 版本之前的行为。
+* `scope` 指定要匹配的范围。有效值为 `"Cluster"`、`"Namespaced"` 和 `"*"`。
+ 子资源匹配其父资源的范围。在 Kubernetes v1.14+ 版本中才被支持。
+ 默认值为 `"*"`，对应 1.14 版本之前的行为。
* `"Cluster"` 表示只有集群作用域的资源才能匹配此规则（API 对象 Namespace 是集群作用域的）。
- * `"Namespaced"` 意味着仅具有命名空间的资源才符合此规则。
+ * `"Namespaced"` 意味着仅具有名字空间的资源才符合此规则。
* `"*"` 表示没有范围限制。
-在版本 v1.15+ 中, 通过指定 `objectSelector`，webhook 能够根据可能发送的对象的标签来限制哪些请求被拦截。如果指定，则将对 `objectSelector` 和可能发送到 webhook 的 object 和 oldObject 进行评估。如果两个对象之一与选择器匹配，则认为该请求已匹配。
+在版本 v1.15+ 中, 通过指定 `objectSelector`，Webhook 能够根据
+可能发送的对象的标签来限制哪些请求被拦截。
+如果指定，则将对 `objectSelector` 和可能发送到 Webhook 的 object 和 oldObject
+进行评估。如果两个对象之一与选择器匹配，则认为该请求已匹配。
-空对象（对于创建操作而言为 oldObject，对于删除操作而言为 newObject），或不能带标签的对象（例如 `DeploymentRollback` 或 `PodProxyOptions` 对象）被认为不匹配。
+空对象（对于创建操作而言为 oldObject，对于删除操作而言为 newObject），
+或不能带标签的对象（例如 `DeploymentRollback` 或 `PodProxyOptions` 对象）
+被认为不匹配。
-仅当选择使用 webhook 时才使用对象选择器，因为最终用户可以通过设置标签来跳过 admission webhook。
+仅当选择使用 webhook 时才使用对象选择器，因为最终用户可以通过设置标签来
+跳过准入 Webhook。
-这个例子展示了一个 mutating webhook，它将匹配带有标签 `foo:bar` 的任何资源的 `CREATE` 的操作：
+这个例子展示了一个 mutating webhook，它将匹配带有标签 `foo:bar` 的任何资源的
+`CREATE` 的操作：
{{< tabs name="objectSelector_example" >}}
{{% tab name="admissionregistration.k8s.io/v1" %}}
@@ -1071,7 +1094,8 @@ See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for
Webhooks may optionally limit which requests for namespaced resources are intercepted,
based on the labels of the containing namespace, by specifying a `namespaceSelector`.
-->
-通过指定 `namespaceSelector`，Webhook 可以根据具有命名空间的资源所处的命名空间的标签来选择拦截哪些资源的操作。
+通过指定 `namespaceSelector`，Webhook 可以根据具有名字空间的资源所处的
+名字空间的标签来选择拦截哪些资源的操作。
-`namespaceSelector` 根据命名空间的标签是否匹配选择器，决定是否针对具命名空间的资源（或 Namespace 对象）的请求运行 webhook。
+`namespaceSelector` 根据名字空间的标签是否匹配选择器，决定是否针对具名字空间的资源
+（或 Namespace 对象）的请求运行 webhook。
如果对象是除 Namespace 以外的集群范围的资源，则 `namespaceSelector` 标签无效。
-本例给出的 mutating webhook 将匹配到对命名空间中具命名空间的资源的 `CREATE` 请求，前提是这些资源不含值为 "0" 或 "1" 的 "runlevel" 标签：
+本例给出的修改性质的 Webhook 将匹配到对名字空间中具名字空间的资源的 `CREATE` 请求，
+前提是这些资源不含值为 "0" 或 "1" 的 "runlevel" 标签：
{{< tabs name="MutatingWebhookConfiguration_namespaceSelector_1" >}}
{{% tab name="admissionregistration.k8s.io/v1" %}}
@@ -1138,7 +1164,9 @@ webhooks:
This example shows a validating webhook that matches a `CREATE` of any namespaced resource inside a namespace
that is associated with the "environment" of "prod" or "staging":
-->
-此示例显示了一个 validating webhook，它将匹配到对某命名空间中的任何具命名空间的资源的 `CREATE` 请求，前提是该命名空间具有值为 "prod" 或 "staging" 的 "environment" 标签：
+此示例显示了一个验证性质的 Webhook，它将匹配到对某名字空间中的任何具名字空间的资源的
+`CREATE` 请求，前提是该名字空间具有值为 "prod" 或 "staging" 的 "environment" 标签：
+
{{< tabs name="ValidatingWebhookConfiguration_namespaceSelector_2" >}}
{{% tab name="admissionregistration.k8s.io/v1" %}}
```yaml
@@ -1187,7 +1215,8 @@ webhooks:
-有关标签选择器的更多示例，请参见[标签](/zh/docs/concepts/overview/working-with-objects/labels)。
+有关标签选择器的更多示例，请参见
+[标签](/zh/docs/concepts/overview/working-with-objects/labels)。
API 服务器可以通过多个 API 组或版本来提供对象。
-例如，Kubernetes API 服务器允许通过 `extensions/v1beta1`、`apps/v1beta1`、`apps/v1beta2` 和 `apps/v1` API 创建和修改 `Deployment` 对象。
+例如，Kubernetes API 服务器允许通过 `extensions/v1beta1`、`apps/v1beta1`、
+`apps/v1beta2` 和 `apps/v1` API 创建和修改 `Deployment` 对象。
-例如，如果一个 webhook 仅为某些 API 组/版本指定了规则（例如 `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`），而修改资源的请求是通过另一个 API 组/版本（例如 `extensions/v1beta1`）发出的，该请求将不会被发送到 Webhook。
+例如，如果一个 webhook 仅为某些 API 组/版本指定了规则（例如
+`apiGroups:["apps"], apiVersions:["v1","v1beta1"]`），而修改资源的请求
+是通过另一个 API 组/版本（例如 `extensions/v1beta1`）发出的，
+该请求将不会被发送到 Webhook。
* `Exact` 表示仅当请求与指定规则完全匹配时才应拦截该请求。
-* `Equivalent` 表示如果某个请求意在修改 `rules` 中列出的资源，即使该请求是通过其他 API 组或版本发起，也应拦截该请求。
+* `Equivalent` 表示如果某个请求意在修改 `rules` 中列出的资源，
+ 即使该请求是通过其他 API 组或版本发起，也应拦截该请求。
在上面给出的示例中，仅为 `apps/v1` 注册的 webhook 可以使用 `matchPolicy`：
* `matchPolicy: Exact` 表示不会将 `extensions/v1beta1` 请求发送到 Webhook
-* `matchPolicy:Equivalent` 表示将 `extensions/v1beta1` 请求发送到 webhook（将对象转换为 webhook 指定的版本：`apps/v1`）
+* `matchPolicy:Equivalent` 表示将 `extensions/v1beta1` 请求发送到 webhook
+ （将对象转换为 webhook 指定的版本：`apps/v1`）
-建议指定 `Equivalent`，确保升级后启用 API 服务器中资源的新版本时，webhook 继续拦截他们期望的资源。
+建议指定 `Equivalent`，确保升级后启用 API 服务器中资源的新版本时，
+Webhook 继续拦截他们期望的资源。
当 API 服务器停止提供某资源时，该资源不再被视为等同于该资源的其他仍在提供服务的版本。
例如，`extensions/v1beta1` 中的 Deployment 已被废弃，计划在 v1.16 中默认停止使用。
-在这种情况下，带有 `apiGroups:["extensions"], apiVersions:["v1beta1"], resources: ["deployments"]` 规则的 webhook 将不再拦截通过 `apps/v1` API 来创建 Deployment 的请求。
+在这种情况下，带有 `apiGroups:["extensions"], apiVersions:["v1beta1"], resources: ["deployments"]`
+规则的 Webhook 将不再拦截通过 `apps/v1` API 来创建 Deployment 的请求。
["deployments"] 规则将不再拦截通过 `apps/v1` API 创建的部署。
+
-此示例显示了一个 validating webhook，该 Webhook 拦截对 Deployment 的修改（无论 API 组或版本是什么），
+此示例显示了一个验证性质的 Webhook，该 Webhook 拦截对 Deployment 的修改（无论 API 组或版本是什么），
始终会发送一个 `apps/v1` 版本的 Deployment 对象：
{{< tabs name="ValidatingWebhookConfiguration_matchPolicy" >}}
@@ -1300,7 +1338,7 @@ webhooks:
-使用 `admissionregistration.k8s.io/v1beta1` 创建的 admission webhhok 默认为 `Exact`。
+使用 `admissionregistration.k8s.io/v1beta1` 创建的准入 Webhook 默认为 `Exact`。
{{% /tab %}}
{{< /tabs >}}
@@ -1317,7 +1355,8 @@ stanza of the webhook configuration.
Webhooks can either be called via a URL or a service reference,
and can optionally include a custom CA bundle to use to verify the TLS connection.
-->
-API 服务器确定请求应发送到 webhook 后，它需要知道如何调用 webhook。此信息在 webhook 配置的 `clientConfig` 节中指定。
+API 服务器确定请求应发送到 webhook 后，它需要知道如何调用 webhook。
+此信息在 webhook 配置的 `clientConfig` 节中指定。
Webhook 可以通过 URL 或服务引用来调用，并且可以选择包含自定义 CA 包，以用于验证 TLS 连接。
@@ -1350,7 +1389,9 @@ which run an apiserver which might need to make calls to this
webhook. Such installs are likely to be non-portable, i.e., not easy
to turn up in a new cluster.
-->
-请注意，将 `localhost` 或 `127.0.0.1` 用作 `host` 是有风险的，除非您非常小心地在所有运行 apiserver 的、可能需要对此 webhook 进行调用的主机上运行。这样的安装可能不具有可移植性，即很难在新集群中启用。
+请注意，将 `localhost` 或 `127.0.0.1` 用作 `host` 是有风险的，
+除非你非常小心地在所有运行 apiserver 的、可能需要对此 webhook
+进行调用的主机上运行。这样的安装可能不具有可移植性，即很难在新集群中启用。
-这是配置为调用 URL 的 mutating Webhook 的示例（并且期望使用系统信任根证书来验证 TLS 证书，因此不指定 caBundle）：
+这是配置为调用 URL 的修改性质的 Webhook 的示例
+（并且期望使用系统信任根证书来验证 TLS 证书，因此不指定 caBundle）：
{{< tabs name="MutatingWebhookConfiguration_url" >}}
{{% tab name="admissionregistration.k8s.io/v1" %}}
@@ -1409,14 +1451,19 @@ If the webhook is running within the cluster, then you should use `service` inst
The service namespace and name are required. The port is optional and defaults to 443.
The path is optional and defaults to "/".
-->
-`clientConfig` 内部的 Service 是对该 Webhook 服务的引用。如果 Webhook 在集群中运行，则应使用 `service` 而不是 `url`。服务的 `namespace` 和 `name` 是必需的。`port` 是可选的，默认值为 443。`path` 是可选的，默认为 "/"。
+`clientConfig` 内部的 Service 是对该 Webhook 服务的引用。
+如果 Webhook 在集群中运行，则应使用 `service` 而不是 `url`。
+服务的 `namespace` 和 `name` 是必需的。
+`port` 是可选的，默认值为 443。`path` 是可选的，默认为 "/"。
-这是一个 mutating Webhook 的示例，该 mutating Webhook 配置为在子路径 "/my-path" 端口 "1234" 上调用服务，并使用自定义 CA 包针对 ServerName `my-service-name.my-service-namespace.svc` 验证 TLS 连接：
+这是一个 mutating Webhook 的示例，该 mutating Webhook 配置为在子路径 "/my-path" 端口
+"1234" 上调用服务，并使用自定义 CA 包针对 ServerName
+`my-service-name.my-service-namespace.svc` 验证 TLS 连接：
{{< tabs name="MutatingWebhookConfiguration_service" >}}
{{% tab name="admissionregistration.k8s.io/v1" %}}
@@ -1464,7 +1511,8 @@ webhooks:
Webhooks typically operate only on the content of the `AdmissionReview` sent to them.
Some webhooks, however, make out-of-band changes as part of processing admission requests.
-->
-Webhook 通常仅对发送给他们的 `AdmissionReview` 内容进行操作。但是，某些 Webhook 在处理 admission 请求时会进行带外更改。
+Webhook 通常仅对发送给他们的 `AdmissionReview` 内容进行操作。
+但是，某些 Webhook 在处理 admission 请求时会进行带外更改。
-进行带外更改的（产生“副作用”的） Webhook 必须具有协调机制（如控制器），该机制定期确定事物的实际状态，并调整由 admission Webhook 修改的带外数据以反映现实情况。
-这是因为对 admission Webhook 的调用不能保证所准入的对象将原样保留，或根本不保留。
-以后，webhook 可以修改对象的内容，在写入存储时可能会发生冲突，或者服务器可以在持久保存对象之前关闭电源。
+进行带外更改的（产生“副作用”的） Webhook 必须具有协调机制（如控制器），
+该机制定期确定事物的实际状态，并调整由准入 Webhook 修改的带外数据以反映现实情况。
+这是因为对准入 Webhook 的调用不能保证所准入的对象将原样保留，或根本不保留。
+以后，webhook 可以修改对象的内容，在写入存储时可能会发生冲突，或者
+服务器可以在持久保存对象之前关闭电源。
-此外，处理 `dryRun: true` admission 请求时，具有副作用的 webhook 必须避免产生副作用。
-一个 webhook 必须明确指出在使用 `dryRun` 运行时不会有副作用，否则 `dry-run` 请求将不会发送到该 webhook，而 API 请求将会失败。
+此外，处理 `dryRun: true` admission 请求时，具有副作用的 Webhook 必须避免产生副作用。
+一个 Webhook 必须明确指出在使用 `dryRun` 运行时不会有副作用，
+否则 `dry-run` 请求将不会发送到该 Webhook，而 API 请求将会失败。
允许值：
-* 在 `admissionregistration.k8s.io/v1beta1` 中，`sideEffects` 可以设置为 `Unknown`、`None`、`Some` 或者 `NoneOnDryRun`，并且默认值为 `Unknown`。
-* 在 `admissionregistration.k8s.io/v1` 中, `sideEffects` 必须设置为 `None` 或者 `NoneOnDryRun`。
+* 在 `admissionregistration.k8s.io/v1beta1` 中，`sideEffects` 可以设置为
+ `Unknown`、`None`、`Some` 或者 `NoneOnDryRun`，并且默认值为 `Unknown`。
+* 在 `admissionregistration.k8s.io/v1` 中, `sideEffects` 必须设置为
+ `None` 或者 `NoneOnDryRun`。
-如果超时在 Webhook 响应之前被触发，则基于[失败策略](#failure-policy)，将忽略 Webhook 调用或拒绝 API 调用。
+如果超时在 Webhook 响应之前被触发，则基于[失败策略](#failure-policy)，将忽略
+Webhook 调用或拒绝 API 调用。
超时值必须设置在 1 到 30 秒之间。
@@ -1586,7 +1642,7 @@ webhooks:
-使用 `admissionregistration.k8s.io/v1` 创建的 admission webhook 默认超时为 10 秒。
+使用 `admissionregistration.k8s.io/v1` 创建的准入 Webhook 默认超时为 10 秒。
{{% /tab %}}
{{% tab name="admissionregistration.k8s.io/v1beta1" %}}
```yaml
@@ -1603,7 +1659,7 @@ webhooks:
-使用 `admissionregistration.k8s.io/v1beta1` 创建的 admission webhook 默认超时为 30 秒。
+使用 `admissionregistration.k8s.io/v1beta1` 创建的准入 Webhook 默认超时为 30 秒。
{{% /tab %}}
{{< /tabs >}}
@@ -1618,14 +1674,20 @@ A single ordering of mutating admissions plugins (including webhooks) does not w
to the object (like adding a `container` to a `pod`), and other mutating plugins which have already
run may have opinions on those new structures (like setting an `imagePullPolicy` on all containers).
-->
-mutating 准入插件（包括 Webhook）的任何一种排序方式都不会适用于所有情况。(参见 https://issue.k8s.io/64333 示例)。mutating Webhook 可以向对象中添加新的子结构（例如向 `pod` 中添加 `container`），已经运行的其他 mutating 插件可能会对这些新结构有影响（就像在所有容器上设置 `imagePullPolicy` 一样）。
+修改性质的准入插件（包括 Webhook）的任何一种排序方式都不会适用于所有情况。
+(参见 https://issue.k8s.io/64333 示例)。
+修改性质的 Webhook 可以向对象中添加新的子结构（例如向 `pod` 中添加 `container`），
+已经运行的其他修改插件可能会对这些新结构有影响
+（就像在所有容器上设置 `imagePullPolicy` 一样）。
-在 v1.15+ 中，允许 mutating 准入插件感应到其他插件所做的更改，如果 mutating webhook 修改了一个对象，则会重新运行内置的 mutating 准入插件，并且 mutating webhook 可以指定 `reinvocationPolicy` 来控制是否也重新调用它们。
+在 v1.15+ 中，允许修改性质的准入插件感应到其他插件所做的更改，
+如果修改性质的 Webhook 修改了一个对象，则会重新运行内置的修改性质的准入插件，
+并且修改性质的 Webhook 可以指定 `reinvocationPolicy` 来控制是否也重新调用它们。
* `Never`: 在一次准入测试中，不得多次调用 Webhook。
-* `IfNeeded`: 如果在最初的 webhook 调用之后被其他对象的插件修改了被接纳的对象，则可以作为准入测试的一部分再次调用该 webhook。
+* `IfNeeded`: 如果在最初的 Webhook 调用之后被其他对象的插件修改了被接纳的对象，
+ 则可以作为准入测试的一部分再次调用该 webhook。
* 不能保证附加调用的次数恰好是一。
-* 如果其他调用导致对该对象的进一步修改，则不能保证再次调用 webhook。
+* 如果其他调用导致对该对象的进一步修改，则不能保证再次调用 Webhook。
* 使用此选项的 Webhook 可能会重新排序，以最大程度地减少额外调用的次数。
-* 要在确保所有 mutation 都完成后验证对象，请改用 validating admission webhook（推荐用于有副作用的 webhook）。
+* 要在确保所有修改都完成后验证对象，请改用验证性质的 Webhook
+ （推荐用于有副作用的 Webhook）。
-这是一个 mutating webhook 的示例，该 Webhook 在以后的准入插件修改对象时被重新调用：
+这是一个修改性质的 Webhook 的示例，该 Webhook 在以后的准入插件修改对象时被重新调用：
{{< tabs name="MutatingWebhookConfiguration_reinvocationPolicy" >}}
{{% tab name="admissionregistration.k8s.io/v1" %}}
@@ -1692,7 +1756,11 @@ Mutating webhooks must be [idempotent](#idempotence), able to successfully proce
and potentially modified. This is true for all mutating admission webhooks, since any change they can make
in an object could already exist in the user-provided object, but it is essential for webhooks that opt into reinvocation.
-->
-mutating webhook 必须具有 [幂等](#idempotence) 性，并且能够成功处理已被接纳并可能被修改的对象的 mutating Web 钩子。对于所有 mutating admission webhook 都是如此，因为它们可以在对象中进行的任何更改可能已经存在于用户提供的对象中，但是对于选择重新调用的 webhook 来说是必不可少的。
+修改性质的 Webhook 必须具有[幂等](#idempotence)性，并且能够成功处理
+已被接纳并可能被修改的对象的修改性质的 Webhook。
+对于所有修改性质的准入 Webhook 都是如此，因为它们可以在对象中进行的
+任何更改可能已经存在于用户提供的对象中，但是对于选择重新调用的 webhook
+来说是必不可少的。
-`failurePolicy` 定义了如何处理 admission webhook 中无法识别的错误和超时错误。允许的值为 `Ignore` 或 `Fail`。
+`failurePolicy` 定义了如何处理准入 webhook 中无法识别的错误和超时错误。允许的值为 `Ignore` 或 `Fail`。
* `Ignore` 表示调用 webhook 的错误将被忽略并且允许 API 请求继续。
* `Fail` 表示调用 webhook 的错误导致准入失败并且 API 请求被拒绝。
-这是一个 mutating webhook，配置为在调用准入 Webhook 遇到错误时拒绝 API 请求：
+这是一个修改性质的 webhook，配置为在调用准入 Webhook 遇到错误时拒绝 API 请求：
{{< tabs name="MutatingWebhookConfiguration_failurePolicy" >}}
{{% tab name="admissionregistration.k8s.io/v1" %}}
@@ -1730,7 +1798,8 @@ webhooks:
-使用 `admissionregistration.k8s.io/v1beta1` 创建的 admission webhook 将 `failurePolicy` 默认设置为 `Ignore`。
+使用 `admissionregistration.k8s.io/v1beta1` 创建的准入 Webhook 将
+`failurePolicy` 默认设置为 `Ignore`。
{{% /tab %}}
{{% tab name="admissionregistration.k8s.io/v1beta1" %}}
@@ -1747,7 +1816,8 @@ webhooks:
-使用 `admissionregistration.k8s.io/v1beta1` 创建的 admission webhook 将 `failurePolicy` 默认设置为 `Ignore`。
+使用 `admissionregistration.k8s.io/v1beta1` 创建的准入 Webhook 将
+`failurePolicy` 默认设置为 `Ignore`。
{{% /tab %}}
{{< /tabs >}}
@@ -1767,12 +1837,11 @@ monitoring mechanisms help cluster admins to answer questions like:
3. Which webhooks are frequently rejecting API requests? What's the reason for a
rejection?
-->
-API 服务器提供了监视 admission Webhook 行为的方法。这些监视机制可帮助集群管理员回答以下问题：
-
-1. 哪个 mutating webhook 改变了 API 请求中的对象？
-
-2. mutating webhook 对对象做了哪些更改？
+API 服务器提供了监视准入 Webhook 行为的方法。这些监视机制可帮助集群管理员
+回答以下问题：
+1. 哪个修改性质的 webhook 改变了 API 请求中的对象？
+2. 修改性质的 Webhook 对对象做了哪些更改？
3. 哪些 webhook 经常拒绝 API 请求？是什么原因拒绝？
-有时，了解 API 请求中的哪个 mutating Webhook 使对象改变以及该 Webhook 应用了哪些更改很有用。
+有时，了解 API 请求中的哪个修改性质的 Webhook 使对象改变以及该
+Webhook 应用了哪些更改很有用。
-在 v1.16+ 中，kube-apiserver 针对每个 mutating webhook 调用执行[审计](/zh/docs/tasks/debug-application-cluster/audit/)操作。
-每个调用都会生成一个审计注解，记述请求对象是否发生改变，可选地还可以根据 webhook 的准入响应生成一个注解，记述所应用的修补。
-针对给定请求的给定执行阶段，注解被添加到审计事件中，然后根据特定策略进行预处理并写入后端。
+在 v1.16+ 中，kube-apiserver 针对每个修改性质的 Webhook 调用执行
+[审计](/zh/docs/tasks/debug-application-cluster/audit/)操作。
+每个调用都会生成一个审计注解，记述请求对象是否发生改变，
+可选地还可以根据 webhook 的准入响应生成一个注解，记述所应用的修补。
+针对给定请求的给定执行阶段，注解被添加到审计事件中，
+然后根据特定策略进行预处理并写入后端。
-在 `Metadata` 或更高审计级别上，将使用 JSON 负载记录带有键名 `mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` 的注解，
+在 `Metadata` 或更高审计级别上，将使用 JSON 负载记录带有键名
+`mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` 的注解，
该注解表示针对给定请求调用了 Webhook，以及该 Webhook 是否更改了对象。
-在 `Request` 或更高审计级别上，将使用 JSON 负载记录带有键名为 `patch.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` 的注解，
+在 `Request` 或更高审计级别上，将使用 JSON 负载记录带有键名为
+`patch.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` 的注解，
该注解表明针对给定请求调用了 Webhook 以及应用于请求对象之上的修改。
例如，以下是针对正在被重新调用的某 Webhook 所记录的注解。
-Webhook 在 mutating Webhook 链中排在第四，并在其响应中包含一个 JSON 补丁，该补丁已被应用于请求对象。
+Webhook 在修改性质的 Webhook 链中排在第四，并在其响应中包含一个 JSON 补丁，
+该补丁已被应用于请求对象。
```yaml
# 审计事件相关记录
@@ -1921,18 +1997,19 @@ Webhook 在 mutating Webhook 链中排在第四，并在其响应中包含一个
-### Amission webhook metrics
+### 准入 Webhook 度量值
-Kube-apiserver 从 `/metrics` 端点公开 Prometheus 指标，这些指标可用于监控和诊断 apiserver 状态。以下指标记录了与 admission Webhook 相关的状态。
+Kube-apiserver 从 `/metrics` 端点公开 Prometheus 指标，这些指标可用于监控和诊断
+apiserver 状态。以下指标记录了与准入 Webhook 相关的状态。
-#### apiserver Admission Webhook rejection count
+#### apiserver 准入 Webhook 拒绝次数
-有时，了解哪些 admission webhook 经常拒绝 API 请求以及拒绝的原因是很有用的。
+有时，了解哪些准入 Webhook 经常拒绝 API 请求以及拒绝的原因是很有用的。
-在 v1.16+ 中，kube-apiserver 提供了 Prometheus 计数器度量值，记录了 admission Webhook 的拒绝次数。
+在 v1.16+ 中，kube-apiserver 提供了 Prometheus 计数器度量值，记录
+准入 Webhook 的拒绝次数。
度量值的标签给出了 Webhook 拒绝该请求的原因：
-幂等的 mutating admission Webhook 能够成功处理已经被它接纳甚或修改的对象。即使多次执行该准入测试，也不会产生与初次执行结果相异的结果。
+幂等的修改性质的准入 Webhook 能够成功处理已经被它接纳甚或修改的对象。
+即使多次执行该准入测试，也不会产生与初次执行结果相异的结果。
#### 幂等 mutating admission Webhook 的示例：
-1. 对于 `CREATE` Pod 请求，将 Pod 的字段 `.spec.securityContext.runAsNonRoot` 设置为 true，以实施安全最佳实践。
-
-2. 对于 `CREATE` Pod 请求，如果未设置容器的字段 `.spec.containers[].resources.limits`，设置默认资源限制值。
-
-3. 对于 `CREATE` pod 请求，如果 Pod 中不存在名为 `foo-sidecar` 的 sidecar 容器，向 Pod 注入一个 `foo-sidecar` 容器。
+1. 对于 `CREATE` Pod 请求，将 Pod 的字段 `.spec.securityContext.runAsNonRoot`
+ 设置为 true，以实施安全最佳实践。
+2. 对于 `CREATE` Pod 请求，如果未设置容器的字段
+ `.spec.containers[].resources.limits`，设置默认资源限制值。
+3. 对于 `CREATE` pod 请求，如果 Pod 中不存在名为 `foo-sidecar` 的边车容器，
+ 向 Pod 注入一个 `foo-sidecar` 容器。
在上述情况下，可以安全地重新调用 Webhook，或接受已经设置了字段的对象。
@@ -2038,11 +2120,12 @@ In the cases above, the webhook can be safely reinvoked, or admit an object that
`foo-sidecar` without looking to see if there is already a `foo-sidecar`
container in the pod.
-->
-1. 对于 `CREATE` pod 请求，注入名称为 `foo-sidecar` 并带有当前时间戳的 sidecar 容器（例如 `foo-sidecar-19700101-000000`）。
-
-2. 对于 `CREATE/UPDATE` pod 请求，如果容器已设置标签 `"env"` 则拒绝，否则将 `"env": "prod"` 标签添加到容器。
-
-3. 对于 `CREATE` pod 请求，盲目地添加一个名为 `foo-sidecar` 的 sidecar 容器，而未查看 Pod 中是否已经有 `foo-sidecar` 容器。
+1. 对于 `CREATE` pod 请求，注入名称为 `foo-sidecar` 并带有当前时间戳的
+ 边车容器（例如 `foo-sidecar-19700101-000000`）。
+2. 对于 `CREATE/UPDATE` pod 请求，如果容器已设置标签 `"env"` 则拒绝，
+ 否则将 `"env": "prod"` 标签添加到容器。
+3. 对于 `CREATE` pod 请求，盲目地添加一个名为 `foo-sidecar` 的边车容器，
+ 而未查看 Pod 中是否已经有 `foo-sidecar` 容器。
-在上述第一种情况下，重新调用该 Webhook 可能导致同一个 Sidecar 容器多次注入到 Pod 中，而且每次使用不同的容器名称。
+在上述第一种情况下，重新调用该 Webhook 可能导致同一个 Sidecar 容器
+多次注入到 Pod 中，而且每次使用不同的容器名称。
类似地，如果 Sidecar 已存在于用户提供的 Pod 中，则 Webhook 可能注入重复的容器。
在上述第二种情况下，重新调用 Webhook 将导致 Webhook 自身输出失败。
-在上述第三种情况下，重新调用 Webhook 将导致 Pod 规范中的容器重复，从而使请求无效并被 API 服务器拒绝。
+在上述第三种情况下，重新调用 Webhook 将导致 Pod 规范中的容器重复，
+从而使请求无效并被 API 服务器拒绝。
### 拦截对象的所有版本
-建议通过将 `.webhooks[].matchPolicy` 设置为 `Equivalent`，以确保 admission webhooks 始终拦截对象的所有版本。
-建议 admission webhooks 应该更偏向注册资源的稳定版本。如果无法拦截对象的所有版本，可能会导致准入策略未再某些版本的请求上执行。
+建议通过将 `.webhooks[].matchPolicy` 设置为 `Equivalent`，
+以确保准入 Webhooks 始终拦截对象的所有版本。
+建议准入 Webhooks 应该更偏向注册资源的稳定版本。
+如果无法拦截对象的所有版本，可能会导致准入策略未再某些版本的请求上执行。
有关示例，请参见[匹配请求：matchPolicy](#matching-requests-matchpolicy)。
### 可用性 {#availability}
-建议 admission webhook 尽快完成执行（时长通常是毫秒级），因为它们会增加 API 请求的延迟。
+建议准入 webhook 尽快完成执行（时长通常是毫秒级），因为它们会增加 API 请求的延迟。
建议对 Webhook 使用较小的超时值。有关更多详细信息，请参见[超时](#timeouts)。
建议 Admission Webhook 应该采用某种形式的负载均衡机制，以提供高可用性和高性能。
@@ -2106,13 +2193,16 @@ that a container with name "foo-sidecar" with the expected configuration exists
### 确保看到对象的最终状态
-如果某 Admission Webhook 需要保证自己能够看到对象的最终状态以实施策略，则应该使用一个 validating admission webhook，
+如果某准入 Webhook 需要保证自己能够看到对象的最终状态以实施策略，
+则应该使用一个验证性质的 webhook，
因为可以通过 mutating Webhook 看到对象后对其进行修改。
-例如，一个 mutating admission webhook 被配置为在每个 `CREATE` Pod 请求中注入一个名称为 "foo-sidecar" 的 sidecar 容器。
+例如，一个修改性质的准入Webhook 被配置为在每个 `CREATE` Pod 请求中
+注入一个名称为 "foo-sidecar" 的 sidecar 容器。
-例如，一个 mutating admission webhook 配置为在每个容器上注入一个名称为`foo-sidecar`的边车容器。如果*必须*存在边车容器，
-则还应配置一个 validating admisson webhook 以拦截 `CREATE` Pod 请求，并验证要创建的对象中是否存在具有预期配置的名称为 "foo-sidecar" 的容器。
+如果*必须*存在边车容器，则还应配置一个验证性质的准入 Webhook 以拦截
+`CREATE` Pod 请求，并验证要创建的对象中是否存在具有预期配置的名称为
+"foo-sidecar" 的容器。
### 避免自托管的 Webhooks 中出现死锁
-如果集群内的 Webhook 配置能够拦截启动其自己的 Pod 所需的资源，则该 Webhook 可能导致其自身部署时发生死锁。
+如果集群内的 Webhook 配置能够拦截启动其自己的 Pod 所需的资源，
+则该 Webhook 可能导致其自身部署时发生死锁。
-例如，某 mutating admission webhook 配置为仅当 Pod 中设置了某个标签（例如 `"env": "prod"`）时，才接受 `CREATE` Pod 请求。
-Webhook 服务器在未设置 `"env"` 标签的 Deployment 中运行。当运行 Webhook 服务器的容器的节点运行不正常时，Webhook 部署尝试将容器重新调度到另一个节点。
-但是，由于未设置 `"env"` 标签，因此请求将被现有的 webhook 服务器拒绝，并且调度迁移不会发生。
+例如，某修改性质的准入 Webhook 配置为仅当 Pod 中设置了某个标签
+（例如 `"env": "prod"`）时，才接受 `CREATE` Pod 请求。
+Webhook 服务器在未设置 `"env"` 标签的 Deployment 中运行。当运行 Webhook 服务器的
+容器的节点运行不正常时，Webhook 部署尝试将容器重新调度到另一个节点。
+但是，由于未设置 `"env"` 标签，因此请求将被现有的 Webhook 服务器拒绝，并且调度迁移不会发生。
-建议使用 [namespaceSelector](#matching-requests-namespaceselector) 排除 Webhook 所在的命名空间。
+建议使用 [namespaceSelector](#matching-requests-namespaceselector) 排除
+Webhook 所在的名字空间。
-### Side Effects
+### 副作用 {#side-effects}
-建议 admission webhook 应尽可能避免副作用，这意味着该 admission webhook 仅对发送给他们的 `AdmissionReview` 的内容起作用，并且不要进行额外更改。
-如果 Webhook 没有任何副作用，则 `.webhooks[].sideEffects` 字段应设置为 `None`。
+建议准入 Webhook 应尽可能避免副作用，这意味着该准入 webhook 仅对发送给他们的
+`AdmissionReview` 的内容起作用，并且不要进行额外更改。
+如果 Webhook 没有任何副作用，则 `.webhooks[].sideEffects` 字段应设置为
+`None`。
-如果在 admission 执行期间存在副作用，则应在处理 `dryRun` 为 `true` 的 `AdmissionReview` 对象时避免产生副作用，并且其 `.webhooks[].sideEffects` 字段应设置为 `NoneOnDryRun`。 有关更多详细信息，请参见[副作用](#side-effects)。
+如果在准入执行期间存在副作用，则应在处理 `dryRun` 为 `true` 的 `AdmissionReview`
+对象时避免产生副作用，并且其 `.webhooks[].sideEffects` 字段应设置为
+`NoneOnDryRun`。更多详细信息，请参见[副作用](#side-effects)。
-### 避免对 kube-system 命名空间进行操作
+### 避免对 kube-system 名字空间进行操作
-`kube-system` 命名空间包含由 Kubernetes 系统创建的对象，例如用于控制平面组件的服务账号，诸如 `kube-dns` 之类的 Pod 等。
-意外更改或拒绝 `kube-system` 命名空间中的请求可能会导致控制平面组件停止运行或者导致未知行为发生。
-如果您的 admission webhook 不想修改 Kubernetes 控制平面的行为，请使用 [`namespaceSelector`](#matching-requests-namespaceselector) 避免拦截 `kube-system` 命名空间。
+`kube-system` 名字空间包含由 Kubernetes 系统创建的对象，
+例如用于控制平面组件的服务账号，诸如 `kube-dns` 之类的 Pod 等。
+意外更改或拒绝 `kube-system` 名字空间中的请求可能会导致控制平面组件
+停止运行或者导致未知行为发生。
+如果你的准入 Webhook 不想修改 Kubernetes 控制平面的行为，请使用
+[`namespaceSelector`](#matching-requests-namespaceselector) 避免
+拦截 `kube-system` 名字空间。
+
diff --git a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
index 202b798491..7019f6cdc5 100644
--- a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
@@ -518,12 +518,20 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `CPUManager`: Enable container level CPU affinity support, see [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/).
-->
-- `AttachVolumeLimit`：启用卷插件用于报告可连接到节点的卷数限制。有关更多详细信息，请参见[动态卷限制](/zh/docs/concepts/storage/storage-limits/#dynamic-volume-limits)。
-- `BalanceAttachedNodeVolumes`：包括要在调度时进行平衡资源分配的节点上的卷数。scheduler 在决策时会优先考虑 CPU、内存利用率和卷数更近的节点。
-- `BlockVolume`：在 Pod 中启用原始块设备的定义和使用。有关更多详细信息，请参见[原始块卷支持](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。
-- `BoundServiceAccountTokenVolume`：迁移 ServiceAccount 卷以使用由 ServiceAccountTokenVolumeProjection 组成的预计卷。有关更多详细信息，请参见 [Service Account Token 卷](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)。
-- `ConfigurableFSGroupPolicy`：在 Pod 中挂载卷时，允许用户为 fsGroup 配置卷访问权限和属主变更策略。请参见 [为 Pod 配置卷访问权限和属主变更策略](/zh/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)。
-- `CPUManager`：启用容器级别的 CPU 亲和性支持，有关更多详细信息，请参见 [CPU 管理策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/)。
+- `AttachVolumeLimit`：启用卷插件用于报告可连接到节点的卷数限制。有关更多详细信息，请参见
+ [动态卷限制](/zh/docs/concepts/storage/storage-limits/#dynamic-volume-limits)。
+- `BalanceAttachedNodeVolumes`：包括要在调度时进行平衡资源分配的节点上的卷数。
+ 调度器在决策时会优先考虑 CPU、内存利用率和卷数更近的节点。
+- `BlockVolume`：在 Pod 中启用原始块设备的定义和使用。有关更多详细信息，请参见
+ [原始块卷支持](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。
+- `BoundServiceAccountTokenVolume`：迁移 ServiceAccount 卷以使用由
+ ServiceAccountTokenVolumeProjection 组成的预计卷。有关更多详细信息，请参见
+ [服务账号令牌卷](https://git.k8s.io/community/contributors/design-proposals/storage/svcacct-token-volume-source.md)。
+- `ConfigurableFSGroupPolicy`：在 Pod 中挂载卷时，允许用户为 fsGroup
+ 配置卷访问权限和属主变更策略。请参见
+ [为 Pod 配置卷访问权限和属主变更策略](/zh/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)。
+- `CPUManager`：启用容器级别的 CPU 亲和性支持，有关更多详细信息，请参见
+ [CPU 管理策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/)。
-
- `CRIContainerLogRotation`：为 cri 容器运行时启用容器日志轮换。
-- `CSIBlockVolume`：启用外部 CSI 卷驱动程序用于支持块存储。有关更多详细信息，请参见 [`csi` 原始块卷支持](/zh/docs/concepts/storage/volumes/#csi-raw-block-volume-support)。
+- `CSIBlockVolume`：启用外部 CSI 卷驱动程序用于支持块存储。有关更多详细信息，请参见
+ [`csi` 原始块卷支持](/zh/docs/concepts/storage/volumes/#csi-raw-block-volume-support)。
- `CSIDriverRegistry`：在 csi.storage.k8s.io 中启用与 CSIDriver API 对象有关的所有逻辑。
- `CSIInlineVolume`：为 Pod 启用 CSI 内联卷支持。
- `CSIMigration`：确保填充和转换逻辑能够将卷操作从内嵌插件路由到相应的预安装 CSI 插件。
-- `CSIMigrationAWS`：确保填充和转换逻辑能够将卷操作从 AWS-EBS 内嵌插件路由到 EBS CSI 插件。如果节点未安装和配置 EBS CSI 插件，则支持回退到内嵌 EBS 插件。这需要启用 CSIMigration 特性标志。
-- `CSIMigrationAWSComplete`：停止在 kubelet 和卷控制器中注册 EBS 内嵌插件，并启用 shims 和转换逻辑将卷操作从AWS-EBS 内嵌插件路由到 EBS CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAWS 特性标志，并在集群中的所有节点上安装和配置 EBS CSI 插件。
-- `CSIMigrationAzureDisk`：确保填充和转换逻辑能够将卷操作从 Azure 磁盘内嵌插件路由到 Azure 磁盘 CSI 插件。如果节点未安装和配置 AzureDisk CSI 插件，支持回退到内建 AzureDisk 插件。这需要启用 CSIMigration 特性标志。
-- `CSIMigrationAzureDiskComplete`：停止在 kubelet 和卷控制器中注册 Azure 磁盘内嵌插件，并启用 shims 和转换逻辑以将卷操作从 Azure 磁盘内嵌插件路由到 AzureDisk CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAzureDisk 特性标志，并在集群中的所有节点上安装和配置 AzureDisk CSI 插件。
-- `CSIMigrationAzureFile`：确保填充和转换逻辑能够将卷操作从 Azure 文件内嵌插件路由到 Azure 文件 CSI 插件。如果节点未安装和配置 AzureFile CSI 插件，支持回退到内嵌 AzureFile 插件。这需要启用 CSIMigration 特性标志。
-- `CSIMigrationAzureFileComplete`：停止在 kubelet 和卷控制器中注册 Azure-File 内嵌插件，并启用 shims 和转换逻辑以将卷操作从 Azure-File 内嵌插件路由到 AzureFile CSI 插件。这需要启用 CSIMigration 和 CSIMigrationAzureFile 特性标志，并在集群中的所有节点上安装和配置 AzureFile CSI 插件。
+- `CSIMigrationAWS`：确保填充和转换逻辑能够将卷操作从 AWS-EBS 内嵌插件路由到 EBS CSI 插件。
+ 如果节点未安装和配置 EBS CSI 插件，则支持回退到内嵌 EBS 插件。
+ 这需要启用 CSIMigration 特性标志。
+- `CSIMigrationAWSComplete`：停止在 kubelet 和卷控制器中注册 EBS 内嵌插件，
+ 并启用 shims 和转换逻辑将卷操作从AWS-EBS 内嵌插件路由到 EBS CSI 插件。
+ 这需要启用 CSIMigration 和 CSIMigrationAWS 特性标志，并在集群中的所有节点上安装和配置
+ EBS CSI 插件。
+- `CSIMigrationAzureDisk`：确保填充和转换逻辑能够将卷操作从 Azure 磁盘内嵌插件路由到
+ Azure 磁盘 CSI 插件。如果节点未安装和配置 AzureDisk CSI 插件，
+ 支持回退到内建 AzureDisk 插件。这需要启用 CSIMigration 特性标志。
+- `CSIMigrationAzureDiskComplete`：停止在 kubelet 和卷控制器中注册 Azure 磁盘内嵌插件，
+ 并启用 shims 和转换逻辑以将卷操作从 Azure 磁盘内嵌插件路由到 AzureDisk CSI 插件。
+ 这需要启用 CSIMigration 和 CSIMigrationAzureDisk 特性标志，
+ 并在集群中的所有节点上安装和配置 AzureDisk CSI 插件。
+- `CSIMigrationAzureFile`：确保填充和转换逻辑能够将卷操作从 Azure 文件内嵌插件路由到
+ Azure 文件 CSI 插件。如果节点未安装和配置 AzureFile CSI 插件，
+ 支持回退到内嵌 AzureFile 插件。这需要启用 CSIMigration 特性标志。
+- `CSIMigrationAzureFileComplete`：停止在 kubelet 和卷控制器中注册 Azure-File 内嵌插件，
+ 并启用 shims 和转换逻辑以将卷操作从 Azure-File 内嵌插件路由到 AzureFile CSI 插件。
+ 这需要启用 CSIMigration 和 CSIMigrationAzureFile 特性标志，
+ 并在集群中的所有节点上安装和配置 AzureFile CSI 插件。
-
-- `CSIMigrationGCE`：启用 shims 和转换逻辑，将卷操作从 GCE-PD 内嵌插件路由到 PD CSI 插件。如果节点未安装和配置 PD CSI 插件，支持回退到内嵌 GCE 插件。这需要启用 CSIMigration 特性标志。
-- `CSIMigrationGCEComplete`：停止在 kubelet 和卷控制器中注册 GCE-PD 内嵌插件，并启用 shims 和转换逻辑以将卷操作从 GCE-PD 内嵌插件路由到 PD CSI 插件。这需要启用 CSIMigration 和 CSIMigrationGCE 特性标志，并在集群中的所有节点上安装和配置 PD CSI 插件。
-- `CSIMigrationOpenStack`：确保填充和转换逻辑能够将卷操作从 Cinder 内嵌插件路由到 Cinder CSI 插件。如果节点未安装和配置 Cinder CSI 插件，支持回退到内嵌 Cinder 插件。这需要启用 CSIMigration 特性标志。
-- `CSIMigrationOpenStackComplete`：停止在 kubelet 和卷控制器中注册 Cinder 内嵌插件，并启用 shims 和转换逻辑将卷操作从 Cinder 内嵌插件路由到 Cinder CSI 插件。这需要启用 CSIMigration 和 CSIMigrationOpenStack 特性标志，并在集群中的所有节点上安装和配置 Cinder CSI 插件。
-- `CSIMigrationvSphere`: 启用 shims 和转换逻辑，将卷操作从 vSphere 内嵌插件路由到 vSphere CSI 插件。如果节点未安装和配置 vSphere CSI 插件，则支持回退到 vSphere 内嵌插件。这需要启用 CSIMigration 特性标志。
-- `CSIMigrationvSphereComplete`: 停止在 kubelet 和卷控制器中注册 vSphere 内嵌插件，并启用 shims 和转换逻辑以将卷操作从 vSphere 内嵌插件路由到 vSphere CSI 插件。这需要启用 CSIMigration 和 CSIMigrationvSphere 特性标志，并在集群中的所有节点上安装和配置 vSphere CSI 插件。
+- `CSIMigrationGCE`：启用 shims 和转换逻辑，将卷操作从 GCE-PD 内嵌插件路由到
+ PD CSI 插件。如果节点未安装和配置 PD CSI 插件，支持回退到内嵌 GCE 插件。
+ 这需要启用 CSIMigration 特性标志。
+- `CSIMigrationGCEComplete`：停止在 kubelet 和卷控制器中注册 GCE-PD 内嵌插件，
+ 并启用 shims 和转换逻辑以将卷操作从 GCE-PD 内嵌插件路由到 PD CSI 插件。
+ 这需要启用 CSIMigration 和 CSIMigrationGCE 特性标志，并在集群中的所有节点上
+ 安装和配置 PD CSI 插件。
+- `CSIMigrationOpenStack`：确保填充和转换逻辑能够将卷操作从 Cinder 内嵌插件路由到
+ Cinder CSI 插件。如果节点未安装和配置 Cinder CSI 插件，支持回退到内嵌 Cinder 插件。
+ 这需要启用 CSIMigration 特性标志。
+- `CSIMigrationOpenStackComplete`：停止在 kubelet 和卷控制器中注册 Cinder 内嵌插件，
+ 并启用 shims 和转换逻辑将卷操作从 Cinder 内嵌插件路由到 Cinder CSI 插件。
+ 这需要启用 CSIMigration 和 CSIMigrationOpenStack 特性标志，并在集群中的所有节点上
+ 安装和配置 Cinder CSI 插件。
+- `CSIMigrationvSphere`: 启用 shims 和转换逻辑，将卷操作从 vSphere 内嵌插件路由到
+ vSphere CSI 插件。
+ 如果节点未安装和配置 vSphere CSI 插件，则支持回退到 vSphere 内嵌插件。
+ 这需要启用 CSIMigration 特性标志。
+- `CSIMigrationvSphereComplete`: 停止在 kubelet 和卷控制器中注册 vSphere 内嵌插件，
+ 并启用 shims 和转换逻辑以将卷操作从 vSphere 内嵌插件路由到 vSphere CSI 插件。
+ 这需要启用 CSIMigration 和 CSIMigrationvSphere 特性标志，并在集群中的所有节点上
+ 安装和配置 vSphere CSI 插件。
- `CSINodeInfo`：在 csi.storage.k8s.io 中启用与 CSINodeInfo API 对象有关的所有逻辑。
-- `CSIPersistentVolume`：启用发现和挂载通过 [CSI（容器存储接口）](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)兼容卷插件配置的卷。
-- `CSIStorageCapacity`: 使 CSI 驱动程序可以发布存储容量信息，并使 Kubernetes 调度程序在调度 Pod 时使用该信息。 参见 [存储容量](/zh/docs/concepts/storage/storage-capacity/)。
+- `CSIPersistentVolume`：启用发现和挂载通过
+ [CSI（容器存储接口）](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
+ 兼容卷插件配置的卷。
+- `CSIStorageCapacity`: 使 CSI 驱动程序可以发布存储容量信息，并使 Kubernetes
+ 调度程序在调度 Pod 时使用该信息。参见
+ [存储容量](/zh/docs/concepts/storage/storage-capacity/)。
详情请参见 [`csi` 卷类型](/zh/docs/concepts/storage/volumes/#csi)。
-- `CSIVolumeFSGroupPolicy`: 允许 CSIDrivers 使用 `fsGroupPolicy` 字段. 该字段能控制由 CSIDriver 创建的卷在挂载这些卷时是否支持卷所有权和权限修改。
+- `CSIVolumeFSGroupPolicy`: 允许 CSIDrivers 使用 `fsGroupPolicy` 字段.
+ 该字段能控制由 CSIDriver 创建的卷在挂载这些卷时是否支持卷所有权和权限修改。
-
- `CustomCPUCFSQuotaPeriod`：使节点能够更改 CPUCFSQuotaPeriod。
-- `CustomPodDNS`：使用其 `dnsConfig` 属性启用 Pod 的自定义 DNS 设置。有关更多详细信息，请参见 [Pod 的 DNS 配置](/zh/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)。
+- `CustomPodDNS`：使用其 `dnsConfig` 属性启用 Pod 的自定义 DNS 设置。
+ 更多详细信息，请参见
+ [Pod 的 DNS 配置](/zh/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)。
- `CustomResourceDefaulting`：为 OpenAPI v3 验证架构中的默认值启用 CRD 支持。
- `CustomResourcePublishOpenAPI`：启用 CRD OpenAPI 规范的发布。
-- `CustomResourceSubresources`：对于从 [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 中创建的资源启用 `/status` 和 `/scale` 子资源。
-- `CustomResourceValidation`：对于从 [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 中创建的资源启用基于模式的验证。
-- `CustomResourceWebhookConversion`：对于从 [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 中创建的资源启用基于 Webhook 的转换。
+- `CustomResourceSubresources`：对于用
+ [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+ 创建的资源启用 `/status` 和 `/scale` 子资源。
+- `CustomResourceValidation`：对于用
+ [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+ 创建的资源启用基于模式的验证。
+- `CustomResourceWebhookConversion`：对于用
+ [CustomResourceDefinition](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+ 创建的资源启用基于 Webhook 的转换。
对正在运行的 Pod 进行故障排除。
-
-- `DisableAcceleratorUsageMetrics`: [禁用 kubelet 收集加速器指标](/zh/docs/concepts/cluster-administration/system-metrics/).
-- `DevicePlugins`：在节点上启用基于 [device-plugins](/zh/docs/concepts/cluster-administration/device-plugins/) 的资源供应。
+- `DisableAcceleratorUsageMetrics`:
+ [禁用 kubelet 收集加速器指标](/zh/docs/concepts/cluster-administration/system-metrics/).
+- `DevicePlugins`：在节点上启用基于
+ [设备插件](/zh/docs/concepts/cluster-administration/device-plugins/) 资源供应。
- `DefaultPodTopologySpread`: 启用 `PodTopologySpread` 调度插件来做
[默认的调度传播](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
-- `DryRun`：启用服务器端 [dry run](/zh/docs/reference/using-api/api-concepts/#dry-run) 请求，以便无需提交即可测试验证、合并和差异化。
+- `DryRun`：启用服务器端
+ [dry run](/zh/docs/reference/using-api/api-concepts/#dry-run) 请求，
+ 以便无需提交即可测试验证、合并和差异化。
- `DynamicAuditing`（ *已弃用* ）：在 v1.19 版本前用于启用动态审计。
-- `DynamicKubeletConfig`：启用 kubelet 的动态配置。请参阅[重新配置 kubelet](/zh/docs/tasks/administer-cluster/reconfigure-kubelet/)。
-- `DynamicProvisioningScheduling`：扩展默认 scheduler 以了解卷拓扑并处理 PV 配置。此特性已在 v1.12 中完全被 `VolumeScheduling` 特性取代。
-- `DynamicVolumeProvisioning`（ *已弃用* ）：启用持久化卷到 Pod 的[动态预配置](/zh/docs/concepts/storage/dynamic-provisioning/)。
+- `DynamicKubeletConfig`：启用 kubelet 的动态配置。请参阅
+ [重新配置 kubelet](/zh/docs/tasks/administer-cluster/reconfigure-kubelet/)。
+- `DynamicProvisioningScheduling`：扩展默认调度器以了解卷拓扑并处理 PV 配置。
+ 此特性已在 v1.12 中完全被 `VolumeScheduling` 特性取代。
+- `DynamicVolumeProvisioning`（ *已弃用* ）：启用持久化卷到 Pod 的
+ [动态预配置](/zh/docs/concepts/storage/dynamic-provisioning/)。
-
-- `EnableAggregatedDiscoveryTimeout` （ *已弃用* ）：对聚集的发现调用启用五秒钟超时设置。
+- `EnableAggregatedDiscoveryTimeout`（ *已弃用* ）：对聚集的发现调用启用五秒钟超时设置。
- `EnableEquivalenceClassCache`：调度 Pod 时，使 scheduler 缓存节点的等效项。
-- `EphemeralContainers`：启用添加 {{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}} 到正在运行的 Pod 的特性。
-- `EvenPodsSpread`：使 Pod 能够在拓扑域之间平衡调度。请参阅 [Pod 拓扑扩展约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
-- `ExpandInUsePersistentVolumes`：启用扩展使用中的 PVC。请查阅[调整使用中的 PersistentVolumeClaim 的大小](/zh/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)。
-- `ExpandPersistentVolumes`：启用持久卷的扩展。请查阅[扩展永久卷声明](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。
-- `ExperimentalCriticalPodAnnotation`：启用将特定 Pod 注解为 *critical* 的方式，用于[确保其调度](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。从 v1.13 开始，Pod 优先级和抢占功能已弃用此特性。
+- `EphemeralContainers`：启用添加
+ {{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}}
+ 到正在运行的 Pod 的特性。
+- `EvenPodsSpread`：使 Pod 能够在拓扑域之间平衡调度。请参阅
+ [Pod 拓扑扩展约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
+- `ExpandInUsePersistentVolumes`：启用扩展使用中的 PVC。请查阅
+ [调整使用中的 PersistentVolumeClaim 的大小](/zh/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)。
+- `ExpandPersistentVolumes`：启用持久卷的扩展。请查阅
+ [扩展永久卷声明](/zh/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。
+- `ExperimentalCriticalPodAnnotation`：启用将特定 Pod 注解为 *critical* 的方式，用于
+ [确保其调度](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。
+ 从 v1.13 开始，Pod 优先级和抢占功能已弃用此特性。
-
-- `ExperimentalHostUserNamespaceDefaultingGate`：启用主机默认的用户命名空间。这适用于使用其他主机命名空间、主机安装的容器，或具有特权或使用特定的非命名空间功能（例如MKNODE、SYS_MODULE等）的容器。如果在 Docker 守护程序中启用了用户命名空间重新映射，则启用此选项。
-- `EndpointSlice`：启用 EndpointSlice 以实现更多可扩展的网络端点。需要启用相应的 API 和控制器，请参阅[启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。
-- `EndpointSliceProxying`：启用此特性门控后，Linux 上运行的 kube-proxy 将使用 EndpointSlices 取代 Endpoints 作为主要数据源，可以提高扩展性和性能。 请参见
- [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。
-- `WindowsEndpointSliceProxying`：启用此特性门控后，Windows 上运行的 kube-proxy 将使用 EndpointSlices 取代 Endpoints 作为主要数据源，可以提高扩展性和性能。 请参见
- [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。
+- `ExperimentalHostUserNamespaceDefaultingGate`：启用主机默认的用户名字空间。
+ 这适用于使用其他主机名字空间、主机安装的容器，或具有特权或使用特定的非名字空间功能
+ （例如 MKNODE、SYS_MODULE 等）的容器。
+ 如果在 Docker 守护程序中启用了用户名字空间重新映射，则启用此选项。
+- `EndpointSlice`：启用 EndpointSlice 以实现更多可扩展的网络端点。
+ 需要启用相应的 API 和控制器，请参阅
+ [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。
+- `EndpointSliceProxying`：启用此特性门控后，Linux 上运行的 kube-proxy 将使用
+ EndpointSlices 取代 Endpoints 作为主要数据源，可以提高扩展性和性能。 请参见
+ [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。
+- `WindowsEndpointSliceProxying`：启用此特性门控后，Windows 上运行的 kube-proxy
+ 将使用 EndpointSlices 取代 Endpoints 作为主要数据源，可以提高扩展性和性能。 请参见
+ [启用 EndpointSlice](/zh/docs/tasks/administer-cluster/enabling-endpointslices/)。
- `GCERegionalPersistentDisk`：在 GCE 上启用区域 PD 特性。
-- `GenericEphemeralVolume`：启用支持临时卷和内联卷的（可以由第三方存储供应商提供，存储容量跟踪，从快照还原，等等）所有功能。请参见[临时卷](/zh/docs/concepts/storage/ephemeral-volumes/)。
-- `HugePages`：启用分配和使用预分配的[巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。
-- `HugePageStorageMediumSize`：启用支持多种大小的预分配[巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。
+- `GenericEphemeralVolume`：启用支持临时卷和内联卷的
+ （可以由第三方存储供应商提供、存储容量跟踪、从快照还原等等）所有功能。请参见
+ [临时卷](/zh/docs/concepts/storage/ephemeral-volumes/)。
+- `HugePages`：启用分配和使用预分配的
+ [巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。
+- `HugePageStorageMediumSize`：启用支持多种大小的预分配
+ [巨页资源](/zh/docs/tasks/manage-hugepages/scheduling-hugepages/)。
-
-- `HyperVContainer`：为 Windows 容器启用[Hyper-V 隔离](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)。
-- `HPAScaleToZero`：使用自定义指标或外部指标时，可将 `HorizontalPodAutoscaler` 资源的 `minReplicas` 设置为 0。
-- `ImmutableEphemeralVolumes`：允许将各个 Secret 和 ConfigMap 标记为不可变更的，以提高安全性和性能。
-- `KubeletConfigFile`：启用从使用配置文件指定的文件中加载 kubelet 配置。有关更多详细信息，请参见[通过配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file/)。
-- `KubeletPluginsWatcher`：启用基于探针的插件监视应用程序，使 kubelet 能够发现插件，例如 [CSI 卷驱动程序](/zh/docs/concepts/storage/volumes/#csi)。
-- `KubeletPodResources`：启用 kubelet 的 pod 资源 grpc 端点。有关更多详细信息，请参见[支持设备监控](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)。
-- `LegacyNodeRoleBehavior`：禁用此选项后，服务负载均衡中的传统行为和节点中断将忽略 `node-role.kubernetes.io/master` 标签，而使用 `NodeDisruptionExclusion` 和 `ServiceNodeExclusion` 提供的特性指定的标签。
+- `HyperVContainer`：为 Windows 容器启用
+ [Hyper-V 隔离](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)。
+- `HPAScaleToZero`：使用自定义指标或外部指标时，可将 `HorizontalPodAutoscaler`
+ 资源的 `minReplicas` 设置为 0。
+- `ImmutableEphemeralVolumes`：允许将各个 Secret 和 ConfigMap 标记为不可变更的，
+ 以提高安全性和性能。
+- `KubeletConfigFile`：启用从使用配置文件指定的文件中加载 kubelet 配置。
+ 有关更多详细信息，请参见
+ [通过配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file/)。
+- `KubeletPluginsWatcher`：启用基于探针的插件监视应用程序，使 kubelet 能够发现插件，
+ 例如 [CSI 卷驱动程序](/zh/docs/concepts/storage/volumes/#csi)。
+- `KubeletPodResources`：启用 kubelet 的 pod 资源 grpc 端点。更多详细信息，请参见
+ [支持设备监控](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)。
+- `LegacyNodeRoleBehavior`：禁用此选项后，服务负载均衡中的传统行为和节点中断将忽略
+ `node-role.kubernetes.io/master` 标签，而使用 `NodeDisruptionExclusion` 和
+ `ServiceNodeExclusion` 提供的特性指定的标签。
-
-- `LocalStorageCapacityIsolation`：允许使用[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)以及 [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir) 的 `sizeLimit` 属性。
-- `LocalStorageCapacityIsolationFSQuotaMonitoring`：如果[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)启用了 `LocalStorageCapacityIsolation`，并且 [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir) 的后备文件系统支持项目配额，并且启用了这些配额，请使用项目配额来监视 [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)的存储消耗而不是遍历文件系统，以此获得更好的性能和准确性。
+- `LocalStorageCapacityIsolation`：允许使用
+ [本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)以及
+ [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir) 的 `sizeLimit` 属性。
+- `LocalStorageCapacityIsolationFSQuotaMonitoring`：如果
+ [本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/)
+ 启用了 `LocalStorageCapacityIsolation`，并且
+ [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)
+ 的后备文件系统支持项目配额，并且启用了这些配额，请使用项目配额来监视
+ [emptyDir 卷](/zh/docs/concepts/storage/volumes/#emptydir)的存储消耗
+ 而不是遍历文件系统，以此获得更好的性能和准确性。
- `MountContainers`：在主机上启用将应用程序容器用作卷安装程序。
-- `MountPropagation`：启用将一个容器安装的共享卷共享到其他容器或 Pod。有关更多详细信息，请参见[挂载传播](/zh/docs/concepts/storage/volumes/#mount-propagation)。
-- `NodeDisruptionExclusion`：启用节点标签 `node.kubernetes.io/exclude-disruption`，以防止在区域故障期间驱逐节点。
+- `MountPropagation`：启用将一个容器安装的共享卷共享到其他容器或 Pod。
+ 更多详细信息，请参见
+ [挂载传播](/zh/docs/concepts/storage/volumes/#mount-propagation)。
+- `NodeDisruptionExclusion`：启用节点标签 `node.kubernetes.io/exclude-disruption`，
+ 以防止在区域故障期间驱逐节点。
-
- `NodeLease`：启用新的租赁 API 以报告节点心跳，可用作节点运行状况信号。
- `NonPreemptingPriority`：为 PriorityClass 和 Pod 启用 NonPreempting 选项。
-- `PersistentLocalVolumes`：在 Pod 中启用 “本地” 卷类型的使用。如果请求 “本地” 卷，则必须指定 Pod 亲和力。
-- `PodDisruptionBudget`：启用 [PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/) 特性。
-- `PodOverhead`：启用 [PodOverhead](/zh/docs/concepts/scheduling-eviction/pod-overhead/) 特性以考虑 Pod 开销。
-- `PodPriority`：根据[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)启用 Pod 的调度和抢占。
-- `PodReadinessGates`：启用 `PodReadinessGate` 字段的设置以扩展 Pod 准备状态评估。有关更多详细信息，请参见 [Pod readiness 特性门控](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。
+- `PersistentLocalVolumes`：在 Pod 中启用 “本地” 卷类型的使用。
+ 如果请求 “本地” 卷，则必须指定 Pod 亲和力。
+- `PodDisruptionBudget`：启用
+ [PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/) 特性。
+- `PodOverhead`：启用 [PodOverhead](/zh/docs/concepts/scheduling-eviction/pod-overhead/)
+ 特性以考虑 Pod 开销。
+- `PodPriority`：根据[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)
+ 启用 Pod 的调度和抢占。
+- `PodReadinessGates`：启用 `PodReadinessGate` 字段的设置以扩展 Pod 准备状态评估。
+ 有关更多详细信息，请参见
+ [Pod 就绪状态判别](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。
- `PodShareProcessNamespace`：在 Pod 中启用 `shareProcessNamespace` 的设置，
- 以便在 Pod 中运行的容器之间共享同一进程命名空间。更多详细信息，请参见[在 Pod 中的容器间共享同一进程名字空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)。
+ 以便在 Pod 中运行的容器之间共享同一进程名字空间。更多详细信息，请参见
+ [在 Pod 中的容器间共享同一进程名字空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)。
- `ProcMountType`：启用对容器的 ProcMountType 的控制。
-- `PVCProtection`：启用防止任何 Pod 仍使用 PersistentVolumeClaim(PVC) 删除的特性。可以在[此处](/zh/docs/tasks/administer-cluster/storage-object-in-use-protection/)中找到更多详细信息。
-- `QOSReserved`：允许在 QoS 级别进行资源预留，以防止处于较低 QoS 级别的 Pod 突发进入处于较高 QoS 级别的请求资源（仅适用于内存）。
-- `ResourceLimitsPriorityFunction` （ *已弃用* ）：启用某调度器优先级函数，该函数将最低得分 1
-指派给至少满足输入 Pod 的 cpu 和内存限制之一的节点，目的是打破得分相同的节点之间的关联。
+- `PVCProtection`：启用防止任何 Pod 仍使用 PersistentVolumeClaim(PVC) 删除的特性。
+- `QOSReserved`：允许在 QoS 级别进行资源预留，以防止处于较低 QoS 级别的 Pod
+ 突发进入处于较高 QoS 级别的请求资源（仅适用于内存）。
+- `ResourceLimitsPriorityFunction` （ *已弃用* ）：启用某调度器优先级函数，
+ 该函数将最低得分 1 指派给至少满足输入 Pod 的 CPU 和内存限制之一的节点，
+ 目的是打破得分相同的节点之间的关联。
+
-
- `ResourceQuotaScopeSelectors`：启用资源配额范围选择器。
-- `RotateKubeletClientCertificate`：在 kubelet 上启用客户端 TLS 证书的轮换。有关更多详细信息，请参见 [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。
-- `RotateKubeletServerCertificate`：在 kubelet 上启用服务器 TLS 证书的轮换。有关更多详细信息，请参见 [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。
+- `RotateKubeletClientCertificate`：在 kubelet 上启用客户端 TLS 证书的轮换。
+ 更多详细信息，请参见
+ [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。
+- `RotateKubeletServerCertificate`：在 kubelet 上启用服务器 TLS 证书的轮换。
+ 更多详细信息，请参见
+ [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。
- `RunAsGroup`：启用对容器初始化过程中设置的主要组 ID 的控制。
-- `RuntimeClass`：启用 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 特性用于选择容器运行时配置。
-- `ScheduleDaemonSetPods`：启用 DaemonSet Pods 由默认调度程序而不是 DaemonSet 控制器进行调度。
+- `RuntimeClass`：启用 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)
+ 特性用于选择容器运行时配置。
+- `ScheduleDaemonSetPods`：启用 DaemonSet Pods 由默认调度程序而不是
+ DaemonSet 控制器进行调度。
-
-- `SCTPSupport`：在 Service、Endpoints、NetworkPolicy 和 Pod 定义中，允许将 _SCTP_ 用作 `protocol` 值。
-- `ServerSideApply`：在 API 服务器上启用[服务器端应用（SSA）](/zh/docs/reference/using-api/server-side-apply/) 路径。
+- `SCTPSupport`：在 Service、Endpoints、NetworkPolicy 和 Pod 定义中，
+ 允许将 _SCTP_ 用作 `protocol` 值。
+- `ServerSideApply`：在 API 服务器上启用
+ [服务器端应用（SSA）](/zh/docs/reference/using-api/server-side-apply/) 路径。
- `ServiceAccountIssuerDiscovery`：在 API 服务器中为服务帐户颁发者启用 OIDC 发现端点。
- 颁发者和 JWKS URL）。 详情请参见[为 Pod 配置服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) 。
+ 颁发者和 JWKS URL）。详情请参见
+ [为 Pod 配置服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) 。
- `ServiceAppProtocol`：为 Service 和 Endpoints 启用 `AppProtocol` 字段。
- `ServiceLoadBalancerFinalizer`：为服务负载均衡启用终结器保护。
-- `ServiceNodeExclusion`：启用从云提供商创建的负载均衡中排除节点。如果节点标记有 `alpha.service-controller.kubernetes.io/exclude-balancer` 键或 `node.kubernetes.io/exclude-from-external-load-balancers`，则可以排除节点。
-- `ServiceTopology`：启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。有关更多详细信息，请参见 [Service 拓扑](/zh/docs/concepts/services-networking/service-topology/)。
-- `SetHostnameAsFQDN`：启用将全限定域名 （FQDN）设置为 Pod 主机名的功能。请参见[给 Pod 设置 `setHostnameAsFQDN` 字段](/zh/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)。
-- `StartupProbe`：在 kubelet 中启用 [startup](/zh/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) 探针。
-- `StorageObjectInUseProtection`：如果仍在使用 PersistentVolume 或 PersistentVolumeClaim 对象，则将其推迟。
+- `ServiceNodeExclusion`：启用从云提供商创建的负载均衡中排除节点。
+ 如果节点标记有 `alpha.service-controller.kubernetes.io/exclude-balancer`
+ 键或 `node.kubernetes.io/exclude-from-external-load-balancers`，
+ 则可以排除节点。
+- `ServiceTopology`：启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。
+ 有关更多详细信息，请参见
+ [服务拓扑](/zh/docs/concepts/services-networking/service-topology/)。
+- `SetHostnameAsFQDN`：启用将全限定域名（FQDN）设置为 Pod 主机名的功能。
+ 请参见[给 Pod 设置 `setHostnameAsFQDN` 字段](/zh/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)。
+- `StartupProbe`：在 kubelet 中启用
+ [启动探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe)。
+- `StorageObjectInUseProtection`：如果仍在使用 PersistentVolume 或
+ PersistentVolumeClaim 对象，则将其推迟。
-
- `StorageVersionHash`：允许 apiserver 在发现中公开存储版本的哈希值。
-- `StreamingProxyRedirects`：指示 API 服务器拦截（并遵循）从后端（kubelet）进行重定向以处理流请求。流请求的例子包括 `exec`、`attach` 和 `port-forward` 请求。
-- `SupportIPVSProxyMode`：启用使用 IPVS 提供内服务负载平衡。有关更多详细信息，请参见[服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)。
+- `StreamingProxyRedirects`：指示 API 服务器拦截（并遵循）从后端（kubelet）
+ 进行重定向以处理流请求。
+ 流请求的例子包括 `exec`、`attach` 和 `port-forward` 请求。
+- `SupportIPVSProxyMode`：启用使用 IPVS 提供内服务负载平衡。更多详细信息，请参见
+ [服务代理](/zh/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)。
- `SupportPodPidsLimit`：启用支持限制 Pod 中的进程 PID。
-- `Sysctls`：启用对可以为每个 Pod 设置的命名空间内核参数（sysctls）的支持。有关更多详细信息，请参见 [sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/)。
+- `Sysctls`：启用对可以为每个 Pod 设置的名字空间内核参数（sysctls）的支持。
+ 更多详细信息，请参见 [sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/)。
-
-- `TaintBasedEvictions`：根据节点上的污点和 Pod 上的容忍度启用从节点驱逐 Pod 的特性。有关更多详细信息，请参见[污点和容忍度](/zh/docs/concepts/configuration/taint-and-toleration/)。
-- `TaintNodesByCondition`：根据[节点条件](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)启用自动在节点标记污点。
+- `TaintBasedEvictions`：根据节点上的污点和 Pod 上的容忍度启用从节点驱逐 Pod 的特性。
+ 有关更多详细信息，请参见[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
+- `TaintNodesByCondition`：根据[节点状况](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)
+ 启用自动在节点标记污点。
- `TokenRequest`：在服务帐户资源上启用 `TokenRequest` 端点。
-- `TokenRequestProjection`：启用通过 [`projected` 卷](/zh/docs/concepts/storage/volumes/#projected) 将服务帐户令牌注入到 Pod 中的特性。
-- `TopologyManager`：启用一种机制来协调 Kubernetes 不同组件的细粒度硬件资源分配。详见[控制节点上的拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)。
-- `TTLAfterFinished`：完成执行后，允许 [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)清理资源。
+- `TokenRequestProjection`：启用通过
+ [`projected` 卷](/zh/docs/concepts/storage/volumes/#projected)
+ 将服务帐号令牌注入到 Pod 中的特性。
+- `TopologyManager`：启用一种机制来协调 Kubernetes 不同组件的细粒度硬件资源分配。
+ 详见[控制节点上的拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)。
+- `TTLAfterFinished`：完成执行后，允许
+ [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)清理资源。
-
- `VolumePVCDataSource`：启用对将现有 PVC 指定数据源的支持。
-- `VolumeScheduling`：启用卷拓扑感知调度，并使 PersistentVolumeClaim（PVC）绑定调度决策；当与 PersistentLocalVolumes 特性门控一起使用时，还可以使用 `PersistentLocalVolumes` 卷类型。
+- `VolumeScheduling`：启用卷拓扑感知调度，并使 PersistentVolumeClaim（PVC）
+ 绑定调度决策；当与 PersistentLocalVolumes 特性门控一起使用时，
+ 还可以使用 `PersistentLocalVolumes` 卷类型。
- `VolumeSnapshotDataSource`：启用卷快照数据源支持。
-
- `VolumeSubpathEnvExpansion`：启用 `subPathExpr` 字段用于将环境变量扩展为 `subPath`。
- `WatchBookmark`：启用对监测 bookmark 事件的支持。
- `WindowsGMSA`：允许将 GMSA 凭据规范从 Pod 传递到容器运行时。
@@ -870,15 +992,13 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `WinDSR`：允许 kube-proxy 为 Windows 创建 DSR 负载均衡。
- `WinOverlay`：允许 kube-proxy 在 Windows 的 overlay 模式下运行。
-
## {{% heading "whatsnext" %}}
-
-* Kubernetes 的[弃用策略](/zh/docs/reference/using-api/deprecation-policy/) 介绍了项目已移除的特性部件和组件的方法。
-
+* Kubernetes 的[弃用策略](/zh/docs/reference/using-api/deprecation-policy/)
+ 介绍了项目已移除的特性部件和组件的方法。
diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
index 9e629ae6ef..4cd4dfb7c2 100644
--- a/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
+++ b/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
@@ -28,7 +28,7 @@ This document describes how to authenticate and authorize access to the kubelet'
-## Kubelet 认证
+## Kubelet 身份认证
* 带 `--client-ca-file` 标志启动 kubelet，提供一个 CA 证书包以供验证客户端证书
* 带 `--kubelet-client-certificate` 和 `--kubelet-client-key` 标志启动 apiserver
-* 有关更多详细信息，请参见 [apiserver 身份验证文档](/zh/docs/admin/authentication/#x509-client-certs)
+* 有关更多详细信息，请参见
+ [apiserver 身份验证文档](/zh/docs/reference/access-authn-authz/authentication/#x509-client-certs)
* 确保在 API 服务器中启用了 `authorization.k8s.io/v1beta1` API 组
* 带 `--authorization-mode=Webhook` 和 `--kubeconfig` 标志启动 kubelet
-* kubelet 调用已配置的 API 服务器上的 `SubjectAccessReview` API，以确定每个请求是否得到鉴权
+* kubelet 调用已配置的 API 服务器上的 `SubjectAccessReview` API，
+ 以确定每个请求是否得到鉴权
-kubelet 使用与 apiserver 相同的[请求属性](/zh/docs/admin/authorization/#request-attributes)方法对 API 请求执行鉴权。
+kubelet 使用与 apiserver 相同的
+[请求属性](/zh/docs/reference/access-authn-authz/authorization/#review-your-request-attributes)
+方法对 API 请求执行鉴权。
+
+ 扩展组件是扩展并与 Kubernetes 深度集成以支持新型硬件的软件组件。
@@ -36,5 +36,5 @@ Most cluster administrators will use a hosted or distribution instance of Kubern
-->
大多数集群管理员会使用托管的 Kubernetes 或其某种发行包。因此，大多数 Kubernetes 用户将需要
-安装 [扩展组件](/docs/concepts/extend-kubernetes/extend-cluster/#extensions)，
-较少用户会需要编写新的扩展组件。
\ No newline at end of file
+安装[扩展组件](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions)，
+较少用户会需要编写新的扩展组件。
diff --git a/content/zh/docs/reference/glossary/flexvolume.md b/content/zh/docs/reference/glossary/flexvolume.md
index 51b0690392..df657c62ca 100644
--- a/content/zh/docs/reference/glossary/flexvolume.md
+++ b/content/zh/docs/reference/glossary/flexvolume.md
@@ -4,31 +4,32 @@ id: flexvolume
date: 2018-06-25
full_link: /zh/docs/concepts/storage/volumes/#flexvolume
short_description: >
- Flexvolume 是创建 out-of-tree 卷插件的一种接口。 {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} 是比 Flexvolume 更新的接口，它解决了 Flexvolumes 的一些问题。
-
+ Flexvolume 是创建树外卷插件的一种接口。
+ {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}}
+ 是比 Flexvolume 更新的接口，它解决了 Flexvolumes 的一些问题。
aka:
tags:
- storage
---
-
-
- Flexvolume 是创建 out-of-tree 卷插件的一种接口。 {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} 是比 Flexvolume 更新的接口，它解决了 Flexvolume 的一些问题。
+-->
+
+Flexvolume 是创建树外卷插件的一种接口。
+{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}}
+是比 Flexvolume 更新的接口，它解决了 Flexvolume 的一些问题。
@@ -37,7 +38,8 @@ FlexVolumes enable users to write their own drivers and add support for their vo
-->
Flexvolume 允许用户编写自己的驱动程序，并在 Kubernetes 中加入对用户自己的数据卷的支持。
FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。
-这需要 root 权限。如果可能的话，SIG Storage 建议实现 {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序，
+这需要 root 权限。如果可能的话，SIG Storage 建议实现
+{{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序，
因为它解决了 Flexvolumes 的限制。
-* [Kubernetes 文档中的 Flexvolume](/docs/concepts/storage/volumes/#flexvolume)
+* [Kubernetes 文档中的 Flexvolume](/zh/docs/concepts/storage/volumes/#flexvolume)
* [更多关于 Flexvolumes 的信息](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)
-* [存储供应商的卷插件 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)
\ No newline at end of file
+* [存储供应商的卷插件 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)
diff --git a/content/zh/docs/reference/glossary/managed-service.md b/content/zh/docs/reference/glossary/managed-service.md
index fb7d5440c9..3e04e50b60 100644
--- a/content/zh/docs/reference/glossary/managed-service.md
+++ b/content/zh/docs/reference/glossary/managed-service.md
@@ -27,7 +27,6 @@ tags:
-
由第三方供应商负责维护的一种软件产品。
@@ -35,8 +34,9 @@ tags:
-
托管服务的一些例子有 AWS EC2、Azure SQL 数据库和 GCP Pub/Sub 等，
不过它们也可以是可以被某应用使用的任何软件交付件。
-[服务目录](/docs/concepts/service-catalog/)提供了一种方法用来列举、供应和绑定到
-{{< glossary_tooltip text="服务代理商" term_id="service-broker" >}}所提供的托管服务。
+[服务目录](/zh/docs/concepts/extend-kubernetes/service-catalog/)
+提供了一种方法用来列举、制备和绑定到
+{{< glossary_tooltip text="服务代理商" term_id="service-broker" >}}
+所提供的托管服务。
diff --git a/content/zh/docs/reference/glossary/operator-pattern.md b/content/zh/docs/reference/glossary/operator-pattern.md
index e4b47f68c7..033383a111 100644
--- a/content/zh/docs/reference/glossary/operator-pattern.md
+++ b/content/zh/docs/reference/glossary/operator-pattern.md
@@ -10,10 +10,8 @@ aka:
tags:
- architecture
---
- [operator 模式](/docs/concepts/extend-kubernetes/operator/) 是一个系统设计, 将 {{< glossary_tooltip term_id="controller" >}} 关联到一个或多个自定义资源。
+
-
+[operator 模式](/zh/docs/concepts/extend-kubernetes/operator/) 是一种系统设计,
+将 {{< glossary_tooltip term_id="controller" >}} 关联到一个或多个自定义资源。
+除了使用作为 Kubernetes 自身一部分的内置控制器之外，你还可以通过
+将控制器添加到集群中来扩展 Kubernetes。
-除了使用作为 Kubernetes 自身一部分的内置控制器之外，您还可以通过将控制器添加到集群中来扩展 Kubernetes。
+如果正在运行的应用程序能够充当控制器并通过 API 访问的方式来执行任务操控
+那些在控制平面中定义的自定义资源，这就是一个 operator 模式的示例。
-如果正在运行的应用程序能够充当控制器并通过 API 访问的方式来执行任务操控那些在控制平面中定义的自定义资源，这就是一个 operator 模式的示例。
\ No newline at end of file
diff --git a/content/zh/docs/reference/glossary/platform-developer.md b/content/zh/docs/reference/glossary/platform-developer.md
index d18ad680b7..0f533b170c 100644
--- a/content/zh/docs/reference/glossary/platform-developer.md
+++ b/content/zh/docs/reference/glossary/platform-developer.md
@@ -42,7 +42,7 @@ Others develop closed-source commercial or site-specific extensions.
-->
平台开发人员可以使用[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
-或[使用汇聚层扩展 Kubernetes API](/zh/docs/concepts/api-extension/apiserver-aggregation/)
+或[使用汇聚层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
来为其 Kubernetes 实例增加功能，特别是为其应用程序添加功能。
一些平台开发人员也是 Kubrenetes {{< glossary_tooltip text="贡献者" term_id="contributor" >}}，
他们会开发贡献给 Kubernetes 社区的扩展。
diff --git a/content/zh/docs/reference/glossary/pod-lifecycle.md b/content/zh/docs/reference/glossary/pod-lifecycle.md
index 8d313b7cf0..4d68d78030 100644
--- a/content/zh/docs/reference/glossary/pod-lifecycle.md
+++ b/content/zh/docs/reference/glossary/pod-lifecycle.md
@@ -2,7 +2,7 @@
title: Pod 生命周期
id: pod-lifecycle
date: 2019-02-17
-full-link: /docs/concepts/workloads/pods/pod-lifecycle/
+full-link: /zh/docs/concepts/workloads/pods/pod-lifecycle/
related:
- pod
- container
@@ -13,7 +13,6 @@ short_description: >
---
-
- 关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。
+关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。
-[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。Pod 的`status` 字段是 [PodStatus](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) 对象, 该对象的 `phase` 字段包含了下面的状态: Running、Pending、Succeeded、Failed、Unknown、Completed 或 CrashLoopBackOff。
+[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod
+在其生命周期中处于哪个阶段的更高层次概述。Pod 的`status` 字段是
+[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
+对象, 该对象的 `phase` 字段包含了下面的状态: Running、Pending、Succeeded、
+Failed、Unknown、Completed 或 CrashLoopBackOff。
diff --git a/content/zh/docs/reference/issues-security/issues.md b/content/zh/docs/reference/issues-security/issues.md
index e43fa3d0e6..d2ac9ae7be 100644
--- a/content/zh/docs/reference/issues-security/issues.md
+++ b/content/zh/docs/reference/issues-security/issues.md
@@ -5,22 +5,22 @@ aliases: [cve/,cves/]
---
-要报告安全问题，请遵循 [Kubernetes 安全问题公开流程](/docs/reference/issues-security/security/#report-a-vulnerability)。
+要报告安全问题，请遵循
+[Kubernetes 安全问题公开流程](/zh/docs/reference/issues-security/security/#report-a-vulnerability)。
-使用 [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/) 跟踪 Kubernetes 编码工作和公开问题。
+使用 [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/)
+跟踪 Kubernetes 编码工作和公开问题。
-与安全性相关的公告请发送到 [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 邮件列表。
+与安全性相关的公告请发送到
+[kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce)
+邮件列表。
diff --git a/content/zh/docs/reference/kubectl/overview.md b/content/zh/docs/reference/kubectl/overview.md
index 4f4125e26a..aa3d13cdc6 100644
--- a/content/zh/docs/reference/kubectl/overview.md
+++ b/content/zh/docs/reference/kubectl/overview.md
@@ -9,7 +9,6 @@ card:
weight: 20
---
@@ -33,7 +31,8 @@ files by setting the KUBECONFIG environment variable or by setting the
-->
你可以使用 Kubectl 命令行工具管理 Kubernetes 集群。
`kubectl` 在 `$HOME/.kube` 目录中查找一个名为 `config` 的配置文件。
-你可以通过设置 KUBECONFIG 环境变量或设置 [`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+你可以通过设置 KUBECONFIG 环境变量或设置
+[`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
参数来指定其它 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。
-
## 语法
-
* `command`：指定要对一个或多个资源执行的操作，例如 `create`、`get`、`describe`、`delete`。
-* `TYPE`：指定[资源类型](#resource-types)。资源类型不区分大小写，可以指定单数、复数或缩写形式。例如，以下命令输出相同的结果:
+* `TYPE`：指定[资源类型](#resource-types)。资源类型不区分大小写，
+ 可以指定单数、复数或缩写形式。例如，以下命令输出相同的结果:
- ```shell
- kubectl get pod pod1
- kubectl get pods pod1
- kubectl get po pod1
- ```
+ ```shell
+ kubectl get pod pod1
+ kubectl get pods pod1
+ kubectl get po pod1
+ ```
-* `NAME`：指定资源的名称。名称区分大小写。如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。
+* `NAME`：指定资源的名称。名称区分大小写。
+ 如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。
在对多个资源执行操作时，你可以按类型和名称指定每个资源，或指定一个或多个文件：
-
+ * 要按类型和名称指定资源：
-* `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.
+ * 要对所有类型相同的资源进行分组，请执行以下操作：`TYPE1 name1 name2 name<#>`。
+
+ 例子：`kubectl get pod example-pod1 example-pod2`
+
+ * 分别指定多个资源类型：`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`。
+
+ 例子：`kubectl get pod/example-pod1 replicationcontroller/example-rc1`
+
+ * 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>`
+
+ * [使用 YAML 而不是 JSON](/zh/docs/concepts/configuration/overview/#general-configuration-tips)
+ 因为 YAML 更容易使用，特别是用于配置文件时。
+ 例子：`kubectl get -f ./pod.yaml`
+
+
-
- * 要按类型和名称指定资源：
-
- * 要对所有类型相同的资源进行分组，请执行以下操作：`TYPE1 name1 name2 name<#>`。
- 例子：`kubectl get pod example-pod1 example-pod2`
-
- * 分别指定多个资源类型：`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`。
- 例子：`kubectl get pod/example-pod1 replicationcontroller/example-rc1`
-
- * 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>`
-
- * [使用 YAML 而不是 JSON](/docs/concepts/configuration/overview/#general-configuration-tips) 因为 YAML 更容易使用，特别是用于配置文件时。
- 例子：`kubectl get -f ./pod.yaml`
-
-* `flags`: 指定可选的参数。例如，可以使用 `-s` 或 `-server` 参数指定 Kubernetes API 服务器的地址和端口。
+* `flags`: 指定可选的参数。例如，可以使用 `-s` 或 `-server` 参数指定
+ Kubernetes API 服务器的地址和端口。
{{< caution >}}
-
@@ -145,7 +146,6 @@ If you need help, just run `kubectl help` from the terminal window.
-
## 操作
{{< caution >}}
@@ -20,7 +19,8 @@ weight: 90
`kubeadm alpha` provides a preview of a set of features made available for gathering feedback
from the community. Please try it out and give us feedback!
-->
- `kubeadm alpha` 提供了一组可用于收集社区反馈的功能的预览。请尝试一下这些功能并给我们反馈！
+`kubeadm alpha` 提供了一组可用于收集社区反馈的功能的预览。
+请尝试一下这些功能并给我们反馈！
{{< /caution >}}
## kubeadm alpha certs {#cmd-certs}
@@ -32,7 +32,6 @@ Kubernetes 证书的操作集合。
{{< tab name="overview" include="generated/kubeadm_alpha_certs.md" />}}
{{< /tabs >}}
-
## kubeadm alpha certs renew {#cmd-certs-renew}
此命令检查 kubeadm 管理的本地 PKI 中证书的到期时间。
-有关证书到期和续订的更多详细信息，请参见[证书管理文档](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。
+有关证书到期和续订的更多详细信息，请参见
+[证书管理文档](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。
{{< tabs name="tab-certs-check-expiration" >}}
{{< tab name="check-expiration" include="generated/kubeadm_alpha_certs_check-expiration.md" />}}
@@ -128,7 +128,9 @@ Use the following command to enable the DynamicKubeletConfiguration feature.
-子命令 `pivot` 可用于将 Pod 托管的静态控制平面转换为自托管的控制平面。有关 `pivot` 更多信息，请参见[文档](zh/docs/setup/production-environment/tools/kubeadm/self-hosting/)。
+子命令 `pivot` 可用于将 Pod 托管的静态控制平面转换为自托管的控制平面。
+有关 `pivot` 更多信息，请参见
+[文档](/zh/docs/setup/production-environment/tools/kubeadm/self-hosting/)。
-`kubeadm join phase` 使你能够调用 `join` 过程的基本原子步骤。因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。
+`kubeadm join phase` 使你能够调用 `join` 过程的基本原子步骤。
+因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。
-`kubeadm join phase` 与 [kubeadm join 工作流程](/docs/reference/setup-tools/kubeadm/kubeadm-join/#join-workflow) 一致，后台都使用相同的代码。
+`kubeadm join phase` 与
+[kubeadm join 工作流程](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/#join-workflow)
+一致，后台都使用相同的代码。
## kubeadm join phase {#cmd-join-phase}
@@ -89,7 +91,11 @@ Using this phase you can join a node as a control-plane instance.
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) to try experimental functionality
-->
-* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导 Kubernetes 控制平面节点
-* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点连接到集群
-* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改
-* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) 尝试实验性功能
+* [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/)
+ 引导 Kubernetes 控制平面节点
+* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/)
+ 将节点添加到集群
+* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/)
+ 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改
+* [kubeadm alpha](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha/)
+ 尝试实验性功能
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
index 74a5118599..8d0f84af56 100644
--- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
+++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
@@ -3,12 +3,11 @@ title: kubeadm reset phase
content_type: concept
weight: 90
---
+
-`kubeadm reset phase` 使你能够调用 `reset` 过程的基本原子步骤。因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。
+`kubeadm reset phase` 使你能够调用 `reset` 过程的基本原子步骤。
+因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。
-`kubeadm reset phase` 与 [kubeadm reset 工作流程](/docs/reference/setup-tools/kubeadm/kubeadm-reset/#reset-workflow) 一致，后台都使用相同的代码。
+`kubeadm reset phase` 与
+[kubeadm reset 工作流程](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/#reset-workflow)
+一致，后台都使用相同的代码。
## kubeadm reset phase {#cmd-reset-phase}
@@ -91,7 +93,11 @@ Using this phase you can perform cleanup on this node.
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) to try experimental functionality
-->
-* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导 Kubernetes 控制平面节点
-* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点连接到集群
-* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改
-* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) 尝试实验性功能
+* [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/)
+ 引导 Kubernetes 控制平面节点
+* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/)
+ 将节点添加到集群
+* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/)
+ 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改
+* [kubeadm alpha](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha/)
+ 尝试实验性功能
diff --git a/content/zh/docs/reference/tools.md b/content/zh/docs/reference/tools.md
index eb348c89ce..b1cc69d433 100644
--- a/content/zh/docs/reference/tools.md
+++ b/content/zh/docs/reference/tools.md
@@ -6,37 +6,35 @@ content_type: concept
---
-
-
Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernetes 系统。
-
## Kubectl
-[`kubectl`](/docs/tasks/tools/install-kubectl/) 是 Kubernetes 命令行工具，可以用来操控 Kubernetes 集群。
+[`kubectl`](/zh/docs/tasks/tools/install-kubectl/) 是 Kubernetes 命令行工具，
+可以用来操控 Kubernetes 集群。
## Kubeadm
-[`kubeadm`](/docs/tasks/tools/install-kubeadm/) 是一个命令行工具，可以用来在物理机、云服务器或虚拟机（目前处于 alpha 阶段）上轻松部署一个安全可靠的 Kubernetes 集群。
+[`kubeadm`](/zh/docs/tasks/tools/install-kubeadm/) 是一个命令行工具，
+可以用来在物理机、云服务器或虚拟机（目前处于 alpha 阶段）
+上轻松部署一个安全可靠的 Kubernetes 集群。
## Minikube
@@ -45,8 +43,8 @@ Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernet
easy to run a single-node Kubernetes cluster locally on your workstation for
development and testing purposes.
-->
-[`minikube`](https://minikube.sigs.k8s.io/docs/) 是一个可以方便用户在其工作站点本地部署一个单节点 Kubernetes 集群的工具，用于开发和测试。
-
+[`minikube`](https://minikube.sigs.k8s.io/docs/) 是一个可以方便用户
+在其工作站点本地部署一个单节点 Kubernetes 集群的工具，用于开发和测试。
## Dashboard
@@ -54,7 +52,9 @@ development and testing purposes.
[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), the web-based user interface of Kubernetes, allows you to deploy containerized applications
to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself.
-->
-[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), 是 Kubernetes 基于 Web 的用户管理界面，允许用户部署容器化应用到 Kubernetes 集群，进行故障排查以及管理集群和集群资源。
+[`Dashboard`](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/)
+是 Kubernetes 基于 Web 的用户管理界面，允许用户部署容器化应用到 Kubernetes
+集群，进行故障排查以及管理集群和集群资源。
## Helm
@@ -62,7 +62,9 @@ to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resou
[`Kubernetes Helm`](https://github.com/kubernetes/helm) is a tool for managing packages of pre-configured
Kubernetes resources, aka Kubernetes charts.
-->
-[`Kubernetes Helm`](https://github.com/kubernetes/helm) 是一个管理预先配置 Kubernetes 资源包的工具，这里的资源在 Helm 中也被称作 Kubernetes charts。
+[`Kubernetes Helm`](https://github.com/kubernetes/helm) 是一个管理
+预先配置完毕的 Kubernetes 资源包的工具，这里的资源在 Helm 中也被称作
+Kubernetes charts。
-[`Kompose`](https://github.com/kubernetes/kompose) 一个转换工具，用来帮助 Docker Compose 用户迁移至 Kubernetes。
+[`Kompose`](https://github.com/kubernetes/kompose) 一个转换工具，
+用来帮助 Docker Compose 用户迁移至 Kubernetes。