kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #25405 from tengqm/zh-fix-links-4 

[zh] Fix links in zh localization (4)
pull/25418/head
Kubernetes Prow Robot 2020-12-06 01:21:25 -08:00 committed by GitHub
parent 434f5e96bd abab517ffc
commit 5636e8732f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
18 changed files with 628 additions and 376 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
content/zh/docs/reference/_index.md
View File

@ -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 集群。
<!--
@ -100,5 +101,8 @@ An archive of the design docs for Kubernetes functionality. Good starting points
-->
## 设计文档
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)
开始阅读。

6
content/zh/docs/reference/access-authn-authz/admission-controllers.md
View File

@ -5,7 +5,6 @@ weight: 30
---
<!--
---
reviewers:
- lavalamp
- davidopp
@ -16,17 +15,14 @@ reviewers:
title: Using Admission Controllers
content_type: concept
weight: 30
---
-->
<!-- overview -->
<!--
This page provides an overview of Admission Controllers.
-->
此页面概述了准入控制器。
<!-- body -->
<!--
@ -228,7 +224,7 @@ to perform different actions on CertificateSigningRequest resources.
-->
有关对证书签名请求资源执行不同操作所需权限的详细信息，
请参阅[证书签名请求](/docs/reference/access-authn-authz/certificate-signing-requests/)
请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)
### CertificateSigning

387
content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md
View File

@ -5,11 +5,9 @@ weight: 40
---
<!--
---
title: Dynamic Admission Control
content_type: concept
weight: 40
---
-->
<!-- overview -->
@ -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。
<!-- body -->
<!--
## What are admission webhooks?
-->
## 什么是 admission webhook？
## 什么是准入 Webhook？
<!--
Admission webhooks are HTTP callbacks that receive admission requests and do
@ -36,22 +34,27 @@ and
[mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook).
Mutating admission Webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults.
-->
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
服务器的对象以执行自定义的设置默认值操作。
<!--
After all object modifications are complete, and after the incoming object is validated by the API server,
validating admission webhooks are invoked and can reject requests to enforce custom policies.
-->
在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后，validating admission webhook 会被调用，并通过拒绝请求的方式来强制实施自定义的策略。
在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后，
验证性质的 Webhook 会被调用，并通过拒绝请求的方式来强制实施自定义的策略。
<!--
Admission webhooks that need to guarantee they see the final state of the object in order to enforce policy
should use a validating admission webhook, since objects can be modified after being seen by mutating webhooks.
-->
{{< 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。
<!--
### Prerequisites
@ -96,7 +99,7 @@ admission webhook 本质上是集群控制平面的一部分。您应该非常
<!--
### Write an admission webhook server
-->
### 编写一个 admission webhook 服务器
### 编写一个准入 Webhook 服务器
<!--
Please refer to the implementation of the [admission webhook
@ -125,13 +128,13 @@ authenticate the identity of the clients, supposedly apiservers. If you need
mutual TLS or other ways to authenticate the clients, see
how to [authenticate apiservers](#authenticate-apiservers).
-->
示例 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)。
<!--
### Deploy the admission webhook service
-->
### 部署 admission webhook 服务
### 部署准入 Webhook 服务
<!--
The webhook server in the e2e test is deployed in the Kubernetes cluster, via
@ -146,12 +149,12 @@ e2e 测试中的 webhook 服务器通过 [deployment API](/docs/reference/genera
You may also deploy your webhooks outside of the cluster. You will need to update
your webhook configurations accordingly.
-->
您也可以在集群外部署 webhook。这样做需要相应地更新您的 webhook 配置。
你也可以在集群外部署 webhook。这样做需要相应地更新你的 webhook 配置。
<!--
### Configure admission webhooks on the fly
### Configure准入 Webhooks on the fly
-->
### 即时配置 admission webhook
### 即时配置准入 Webhook
<!--
You can dynamically configure what resources are subject to what admission
@ -160,7 +163,7 @@ webhooks via
or
[MutatingWebhookConfiguration](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#mutatingwebhookconfiguration-v1-admissionregistration-k8s-io).
-->
您可以通过 [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 处理。
<!--
The following is an example `ValidatingWebhookConfiguration`, a mutating webhook configuration is similar.
See the [webhook configuration](#webhook-configuration) section for details about each config field.
@ -222,7 +225,7 @@ webhooks:
The scope field specifies if only cluster-scoped resources ("Cluster") or namespace-scoped
resources ("Namespaced") will match this rule. "*" means that there are no scope restrictions.
-->
scope 字段指定是仅集群范围的资源（Cluster）还是命名空间范围的资源资源（Namespaced）将与此规则匹配。`*` 表示没有范围限制。
scope 字段指定是仅集群范围的资源（Cluster）还是名字空间范围的资源资源（Namespaced）将与此规则匹配。`*` 表示没有范围限制。
<!--
When using `clientConfig.service`, the server cert must be valid for
@ -240,7 +243,9 @@ If the webhook call times out, the request is handled according to the webhook's
failure policy.
-->
{{< 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 提供身份证明。完成此配置需要三个步骤。
<!--
* When starting the apiserver, specify the location of the admission control
@ -391,7 +396,7 @@ See the [webhook configuration](#webhook-configuration) section for details abou
<!--
Of course you need to set up the webhook server to handle these authentications.
-->
当然，您需要设置 webhook 服务器来处理这些身份验证。
当然，你需要设置 webhook 服务器来处理这些身份验证。
<!--
### Request
@ -495,7 +500,7 @@ API 服务器将发送的是 `admissionReviewVersions` 列表中所支持的第
# 被修改资源的名称
"name": "my-deployment",
# 如果资源是属于命名空间（或者是命名空间对象），则这是被修改的资源的命名空间
# 如果资源是属于名字空间（或者是名字空间对象），则这是被修改的资源的名字空间
"namespace": "my-namespace",
# 操作可以是 CREATE、UPDATE、DELETE 或 CONNECT
@ -565,7 +570,7 @@ API 服务器将发送的是 `admissionReviewVersions` 列表中所支持的第
# 被修改资源的名称
"name": "my-deployment",
# 如果资源是属于命名空间（或者是命名空间对象），则这是被修改的资源的命名空间
# 如果资源是属于名字空间（或者是名字空间对象），则这是被修改的资源的名字空间
"namespace": "my-namespace",
# 操作可以是 CREATE、UPDATE、DELETE 或 CONNECT
@ -699,8 +704,9 @@ The specified status object is returned to the user.
See the [API documentation](/docs/reference/generated/kubernetes-api/v1.14/#status-v1-meta) for details about the status type.
Example of a response to forbid a request, customizing the HTTP status code and message presented to the user:
-->
当拒绝请求时，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=`
<!--
So a webhook response to add that label would be:
@ -797,7 +805,7 @@ So a webhook response to add that label would be:
<!--
## Webhook configuration
-->
## webhook 配置{#webhook-configuration}
## Webhook 配置{#webhook-configuration}
<!--
To register admission webhooks, create `MutatingWebhookConfiguration` or `ValidatingWebhookConfiguration` API objects.
@ -809,12 +817,16 @@ in order to make resulting audit logs and metrics easier to match up to active c
Each webhook defines the following things.
-->
要注册 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 定义以下内容。
<!--
### Matching requests: rules
@ -842,7 +854,8 @@ Each rule specifies one or more operations, apiGroups, apiVersions, and resource
* `"Namespaced"` means that only namespaced resources will match this rule.
* `"*"` means that there are no scope restrictions.
-->
* `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"` 意味着仅具有名字空间的资源才符合此规则。
* `"*"` 表示没有范围限制。
<!--
@ -866,7 +881,8 @@ Match `CREATE` or `UPDATE` requests to `apps/v1` and `apps/v1beta1` `deployments
以下是可用于指定应拦截哪些资源的规则的其他示例。
匹配针对 `apps/v1` 和 `apps/v1beta1` 组中 `deployments` 和 `replicasets` 资源的 `CREATE` 或 `UPDATE` 请求：
匹配针对 `apps/v1` 和 `apps/v1beta1` 组中 `deployments` 和 `replicasets`
资源的 `CREATE` 或 `UPDATE` 请求：
{{< tabs name="ValidatingWebhookConfiguration_rules_1" >}}
{{% tab name="admissionregistration.k8s.io/v1" %}}
@ -997,24 +1013,31 @@ objects they would be sent, by specifying an `objectSelector`. If specified, the
is evaluated against both the object and oldObject that would be sent to the webhook,
and is considered to match if either object matches the selector.
-->
在版本 v1.15+ 中, 通过指定 `objectSelector`，webhook 能够根据可能发送的对象的标签来限制哪些请求被拦截。如果指定，则将对 `objectSelector` 和可能发送到 webhook 的 object 和 oldObject 进行评估。如果两个对象之一与选择器匹配，则认为该请求已匹配。
在版本 v1.15+ 中, 通过指定 `objectSelector`，Webhook 能够根据
可能发送的对象的标签来限制哪些请求被拦截。
如果指定，则将对 `objectSelector` 和可能发送到 Webhook 的 object 和 oldObject
进行评估。如果两个对象之一与选择器匹配，则认为该请求已匹配。
<!--
A null object (oldObject in the case of create, or newObject in the case of delete),
or an object that cannot have labels (like a `DeploymentRollback` or a `PodProxyOptions` object)
is not considered to match.
-->
空对象（对于创建操作而言为 oldObject，对于删除操作而言为 newObject），或不能带标签的对象（例如 `DeploymentRollback` 或 `PodProxyOptions` 对象）被认为不匹配。
空对象（对于创建操作而言为 oldObject，对于删除操作而言为 newObject），
或不能带标签的对象（例如 `DeploymentRollback` 或 `PodProxyOptions` 对象）
被认为不匹配。
<!--
Use the object selector only if the webhook is opt-in, because end users may skip the admission webhook by setting the labels.
-->
仅当选择使用 webhook 时才使用对象选择器，因为最终用户可以通过设置标签来跳过 admission webhook。
仅当选择使用 webhook 时才使用对象选择器，因为最终用户可以通过设置标签来
跳过准入 Webhook。
<!--
This example shows a mutating webhook that would match a `CREATE` of any resource with the label `foo: bar`:
-->
这个例子展示了一个 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 可以根据具有名字空间的资源所处的
名字空间的标签来选择拦截哪些资源的操作。
<!--
The `namespaceSelector` decides whether to run the webhook on a request for a namespaced resource
@ -1079,14 +1103,16 @@ The `namespaceSelector` decides whether to run the webhook on a request for a na
If the object itself is a namespace, the matching is performed on object.metadata.labels.
If the object is a cluster scoped resource other than a Namespace, `namespaceSelector` has no effect.
-->
`namespaceSelector` 根据命名空间的标签是否匹配选择器，决定是否针对具命名空间的资源（或 Namespace 对象）的请求运行 webhook。
`namespaceSelector` 根据名字空间的标签是否匹配选择器，决定是否针对具名字空间的资源
（或 Namespace 对象）的请求运行 webhook。
如果对象是除 Namespace 以外的集群范围的资源，则 `namespaceSelector` 标签无效。
<!--
This example shows a mutating webhook that matches a `CREATE` of any namespaced resource inside a namespace
that does not have a "runlevel" label of "0" or "1":
-->
本例给出的 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:
<!--
See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for more examples of label selectors.
-->
有关标签选择器的更多示例，请参见[标签](/zh/docs/concepts/overview/working-with-objects/labels)。
有关标签选择器的更多示例，请参见
[标签](/zh/docs/concepts/overview/working-with-objects/labels)。
<!--
### Matching requests: matchPolicy
@ -1200,14 +1229,18 @@ For example, the Kubernetes API server allows creating and modifying `Deployment
via `extensions/v1beta1`, `apps/v1beta1`, `apps/v1beta2`, and `apps/v1` APIs.
-->
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` 对象。
<!--
For example, if a webhook only specified a rule for some API groups/versions (like `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`),
and a request was made to modify the resource via another API group/version (like `extensions/v1beta1`),
the request would not be sent to the webhook.
-->
例如，如果一个 webhook 仅为某些 API 组/版本指定了规则（例如 `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`），而修改资源的请求是通过另一个 API 组/版本（例如 `extensions/v1beta1`）发出的，该请求将不会被发送到 Webhook。
例如，如果一个 webhook 仅为某些 API 组/版本指定了规则（例如
`apiGroups:["apps"], apiVersions:["v1","v1beta1"]`），而修改资源的请求
是通过另一个 API 组/版本（例如 `extensions/v1beta1`）发出的，
该请求将不会被发送到 Webhook。
<!--
In v1.15+, `matchPolicy` lets a webhook define how its `rules` are used to match incoming requests.
@ -1225,17 +1258,20 @@ In the example given above, the webhook that only registered for `apps/v1` could
* `matchPolicy: Equivalent` means the `extensions/v1beta1` request would be sent to the webhook (with the objects converted to a version the webhook had specified: `apps/v1`)
-->
* `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`）
<!--
Specifying `Equivalent` is recommended, and ensures that webhooks continue to intercept the
resources they expect when upgrades enable new versions of the resource in the API server.
-->
建议指定 `Equivalent`，确保升级后启用 API 服务器中资源的新版本时，webhook 继续拦截他们期望的资源。
建议指定 `Equivalent`，确保升级后启用 API 服务器中资源的新版本时，
Webhook 继续拦截他们期望的资源。
<!--
When a resource stops being served by the API server, it is no longer considered equivalent to other versions of that resource that are still served.
@ -1246,13 +1282,15 @@ for stable versions of resources.
-->
当 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 创建的部署。
<!--
This example shows a validating webhook that intercepts modifications to deployments (no matter the API group or version),
and is always sent an `apps/v1` `Deployment` object:
-->
此示例显示了一个 validating webhook，该 Webhook 拦截对 Deployment 的修改（无论 API 组或版本是什么），
此示例显示了一个验证性质的 Webhook，该 Webhook 拦截对 Deployment 的修改（无论 API 组或版本是什么），
始终会发送一个 `apps/v1` 版本的 Deployment 对象：
{{< tabs name="ValidatingWebhookConfiguration_matchPolicy" >}}
@ -1300,7 +1338,7 @@ webhooks:
<!--
Admission webhooks created using `admissionregistration.k8s.io/v1beta1` default to `Exact`.
-->
使用 `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
进行调用的主机上运行。这样的安装可能不具有可移植性，即很难在新集群中启用。
<!--
The scheme must be "https"; the URL must begin with "https://".
@ -1368,7 +1409,8 @@ Fragments ("#...") and query parameters ("?...") are also not allowed.
Here is an example of a mutating webhook configured to call a URL
(and expects the TLS certificate to be verified using system trust roots, so does not specify a caBundle):
-->
这是配置为调用 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` 是可选的，默认为 "/"。
<!--
Here is an example of a mutating webhook configured to call a service on port "1234"
at the subpath "/my-path", and to verify the TLS connection against the ServerName
`my-service-name.my-service-namespace.svc` using a custom CA bundle:
-->
这是一个 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 请求时会进行带外更改。
<!--
Webhooks that make out-of-band changes ("side effects") must also have a reconcilation mechanism
@ -1474,17 +1522,20 @@ This is because a call to an admission webhook does not guarantee the admitted o
Later webhooks can modify the content of the object, a conflict could be encountered while writing to storage,
or the server could power off before persisting the object.
-->
进行带外更改的（产生“副作用”的） Webhook 必须具有协调机制（如控制器），该机制定期确定事物的实际状态，并调整由 admission Webhook 修改的带外数据以反映现实情况。
这是因为对 admission Webhook 的调用不能保证所准入的对象将原样保留，或根本不保留。
以后，webhook 可以修改对象的内容，在写入存储时可能会发生冲突，或者服务器可以在持久保存对象之前关闭电源。
进行带外更改的（产生“副作用”的） Webhook 必须具有协调机制（如控制器），
该机制定期确定事物的实际状态，并调整由准入 Webhook 修改的带外数据以反映现实情况。
这是因为对准入 Webhook 的调用不能保证所准入的对象将原样保留，或根本不保留。
以后，webhook 可以修改对象的内容，在写入存储时可能会发生冲突，或者
服务器可以在持久保存对象之前关闭电源。
<!--
Additionally, webhooks with side effects must skip those side-effects when `dryRun: true` admission requests are handled.
A webhook must explicitly indicate that it will not have side-effects when run with `dryRun`,
or the dry-run request will not be sent to the webhook and the API request will fail instead.
-->
此外，处理 `dryRun: true` admission 请求时，具有副作用的 webhook 必须避免产生副作用。
一个 webhook 必须明确指出在使用 `dryRun` 运行时不会有副作用，否则 `dry-run` 请求将不会发送到该 webhook，而 API 请求将会失败。
此外，处理 `dryRun: true` admission 请求时，具有副作用的 Webhook 必须避免产生副作用。
一个 Webhook 必须明确指出在使用 `dryRun` 运行时不会有副作用，
否则 `dry-run` 请求将不会发送到该 Webhook，而 API 请求将会失败。
<!--
Webhooks indicate whether they have side effects using the `sideEffects` field in the webhook configuration:
@ -1501,8 +1552,10 @@ Webhook 使用 webhook 配置中的 `sideEffects` 字段显示它们是否有副
如果带有 `dryRun：true` 的请求将触发对该 Webhook 的调用，则该请求将失败，并且不会调用该 Webhook。
* `None`：调用 webhook 没有副作用。
* `Some`：调用 webhook 可能会有副作用。
如果请求具有 `dry-run` 属性将触发对此 Webhook 的调用，则该请求将会失败，并且不会调用该 Webhook。
* `NoneOnDryRun`：调用 webhook 可能会有副作用，但是如果将带有 `dryRun: true` 属性的请求发送到 webhook，则 webhook 将抑制副作用（该 webhook 可识别 `dryRun`）。
如果请求具有 `dry-run` 属性将触发对此 Webhook 的调用，
则该请求将会失败，并且不会调用该 Webhook。
* `NoneOnDryRun`：调用 webhook 可能会有副作用，但是如果将带有 `dryRun: true`
属性的请求发送到 webhook，则 webhook 将抑制副作用（该 webhook 可识别 `dryRun`）。
<!--
Allowed values:
@ -1510,8 +1563,10 @@ Allowed values:
* In `admissionregistration.k8s.io/v1`, `sideEffects` must be set to `None` or `NoneOnDryRun`.
-->
允许值：
* 在 `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`。
<!--
Here is an example of a validating webhook indicating it has no side effects on `dryRun: true` requests:
@ -1565,7 +1620,8 @@ The timeout value must be between 1 and 30 seconds.
Here is an example of a validating webhook with a custom timeout of 2 seconds:
-->
如果超时在 Webhook 响应之前被触发，则基于[失败策略](#failure-policy)，将忽略 Webhook 调用或拒绝 API 调用。
如果超时在 Webhook 响应之前被触发，则基于[失败策略](#failure-policy)，将忽略
Webhook 调用或拒绝 API 调用。
超时值必须设置在 1 到 30 秒之间。
@ -1586,7 +1642,7 @@ webhooks:
<!--
Admission webhooks created using `admissionregistration.k8s.io/v1` default timeouts to 10 seconds.
-->
使用 `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:
<!--
Admission webhooks created using `admissionregistration.k8s.io/v1beta1` default timeouts to 30 seconds.
-->
使用 `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` 一样）。
<!--
In v1.15+, to allow mutating admission plugins to observe changes made by other plugins,
built-in mutating admission plugins are re-run if a mutating webhook modifies an object,
and mutating webhooks can specify a `reinvocationPolicy` to control whether they are reinvoked as well.
-->
在 v1.15+ 中，允许 mutating 准入插件感应到其他插件所做的更改，如果 mutating webhook 修改了一个对象，则会重新运行内置的 mutating 准入插件，并且 mutating webhook 可以指定 `reinvocationPolicy` 来控制是否也重新调用它们。
在 v1.15+ 中，允许修改性质的准入插件感应到其他插件所做的更改，
如果修改性质的 Webhook 修改了一个对象，则会重新运行内置的修改性质的准入插件，
并且修改性质的 Webhook 可以指定 `reinvocationPolicy` 来控制是否也重新调用它们。
<!--
`reinvocationPolicy` may be set to `Never` or `IfNeeded`. It defaults to `Never`.
@ -1638,7 +1700,8 @@ and mutating webhooks can specify a `reinvocationPolicy` to control whether they
being admitted is modified by other admission plugins after the initial webhook call.
-->
* `Never`: 在一次准入测试中，不得多次调用 Webhook。
* `IfNeeded`: 如果在最初的 webhook 调用之后被其他对象的插件修改了被接纳的对象，则可以作为准入测试的一部分再次调用该 webhook。
* `IfNeeded`: 如果在最初的 Webhook 调用之后被其他对象的插件修改了被接纳的对象，
则可以作为准入测试的一部分再次调用该 webhook。
<!--
The important elements to note are:
@ -1652,14 +1715,15 @@ The important elements to note are:
* To validate an object after all mutations are guaranteed complete, use a validating admission webhook instead (recommended for webhooks with side-effects).
-->
* 不能保证附加调用的次数恰好是一。
* 如果其他调用导致对该对象的进一步修改，则不能保证再次调用 webhook。
* 如果其他调用导致对该对象的进一步修改，则不能保证再次调用 Webhook。
* 使用此选项的 Webhook 可能会重新排序，以最大程度地减少额外调用的次数。
* 要在确保所有 mutation 都完成后验证对象，请改用 validating admission webhook（推荐用于有副作用的 webhook）。
* 要在确保所有修改都完成后验证对象，请改用验证性质的 Webhook
（推荐用于有副作用的 Webhook）。
<!--
Here is an example of a mutating webhook opting into being re-invoked if later admission plugins modify the object:
-->
这是一个 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
来说是必不可少的。
<!--
### Failure policy
@ -1708,12 +1776,12 @@ are handled. Allowed values are `Ignore` or `Fail`.
Here is a mutating webhook configured to reject an API request if errors are encountered calling the admission 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:
<!--
Admission webhooks created using `admissionregistration.k8s.io/v1` default `failurePolicy` to `Fail`.
-->
使用 `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:
<!--
Admission webhooks created using `admissionregistration.k8s.io/v1beta1` default `failurePolicy` to `Ignore`.
-->
使用 `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 请求？是什么原因拒绝？
<!--
@ -1784,7 +1853,8 @@ API 服务器提供了监视 admission Webhook 行为的方法。这些监视机
Sometimes it's useful to know which mutating webhook mutated the object in a API request, and what change did the
webhook apply.
-->
有时，了解 API 请求中的哪个 mutating Webhook 使对象改变以及该 Webhook 应用了哪些更改很有用。
有时，了解 API 请求中的哪个修改性质的 Webhook 使对象改变以及该
Webhook 应用了哪些更改很有用。
<!--
In v1.16+, kube-apiserver performs [auditing](/docs/tasks/debug-application-cluster/audit/) on each mutating webhook
@ -1793,9 +1863,12 @@ capturing if a request object is mutated by the invocation, and optionally gener
patch from the webhook admission response. The annotations are set in the audit event for given request on given stage of
its execution, which is then pre-processed according to a certain policy and written to a backend.
-->
在 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 的准入响应生成一个注解，记述所应用的修补。
针对给定请求的给定执行阶段，注解被添加到审计事件中，
然后根据特定策略进行预处理并写入后端。
<!--
The audit level of a event determines which annotations get recorded:
@ -1807,7 +1880,8 @@ The audit level of a event determines which annotations get recorded:
`mutation.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` gets logged with JSON payload indicating
a webhook gets invoked for given request and whether it mutated the object or not.
-->
在 `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 是否更改了对象。
<!--
@ -1877,7 +1951,8 @@ Webhook 在 mutating Webhook 链中排在第一位，并在调用期间改变了
`patch.webhook.admission.k8s.io/round_{round idx}_index_{order idx}` gets logged with JSON payload indicating
a webhook gets invoked for given request and what patch gets applied to the request object.
-->
在 `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 以及应用于请求对象之上的修改。
<!--
@ -1885,7 +1960,8 @@ For example, the following annotation gets recorded for a webhook being reinvoke
mutating webhook chain, and responded with a JSON patch which got applied to the request object.
-->
例如，以下是针对正在被重新调用的某 Webhook 所记录的注解。
Webhook 在 mutating Webhook 链中排在第四，并在其响应中包含一个 JSON 补丁，该补丁已被应用于请求对象。
Webhook 在修改性质的 Webhook 链中排在第四，并在其响应中包含一个 JSON 补丁，
该补丁已被应用于请求对象。
```yaml
# 审计事件相关记录
@ -1921,18 +1997,19 @@ Webhook 在 mutating Webhook 链中排在第四，并在其响应中包含一个
<!--
### Admission webhook metrics
-->
### Amission webhook metrics
### 准入 Webhook 度量值
<!--
Kube-apiserver exposes Prometheus metrics from the `/metrics` endpoint, which can be used for monitoring and
diagnosing API server status. The following metrics record status related to admission webhooks.
-->
Kube-apiserver 从 `/metrics` 端点公开 Prometheus 指标，这些指标可用于监控和诊断 apiserver 状态。以下指标记录了与 admission Webhook 相关的状态。
Kube-apiserver 从 `/metrics` 端点公开 Prometheus 指标，这些指标可用于监控和诊断
apiserver 状态。以下指标记录了与准入 Webhook 相关的状态。
<!--
#### API server admission webhook rejection count
-->
#### apiserver Admission Webhook rejection count
#### apiserver 准入 Webhook 拒绝次数
<!--
Sometimes it's useful to know which admission webhooks are frequently rejecting API requests, and the
@ -1941,9 +2018,10 @@ reason for a rejection.
In v1.16+, kube-apiserver exposes a Prometheus counter metric recording admission webhook rejections. The
metrics are labelled to identify the causes of webhook rejection(s):
-->
有时，了解哪些 admission webhook 经常拒绝 API 请求以及拒绝的原因是很有用的。
有时，了解哪些准入 Webhook 经常拒绝 API 请求以及拒绝的原因是很有用的。
在 v1.16+ 中，kube-apiserver 提供了 Prometheus 计数器度量值，记录了 admission Webhook 的拒绝次数。
在 v1.16+ 中，kube-apiserver 提供了 Prometheus 计数器度量值，记录
准入 Webhook 的拒绝次数。
度量值的标签给出了 Webhook 拒绝该请求的原因：
<!--
@ -1965,8 +2043,10 @@ metrics are labelled to identify the causes of webhook rejection(s):
- `operation`：请求的操作类型可以是 `CREATE`、`UPDATE`、`DELETE` 和 `CONNECT` 其中之一。
- `type`：Admission webhook 类型，可以是 `admit` 和 `validating` 其中之一。
- `error_type`：标识在 webhook 调用期间是否发生了错误并且导致了拒绝。其值可以是以下之一：
- `calling_webhook_error`：发生了来自 Admission Webhook 的无法识别的错误或超时错误，并且 webhook 的 [失败策略](#failure-policy) 设置为 `Fail`。
- `no_error`：未发生错误。Webhook 在准入响应中以 `allowed: false` 值拒绝了请求。度量标签 `rejection_code` 记录了在准入响应中设置的 `.status.code`。
- `calling_webhook_error`：发生了来自准入 Webhook 的无法识别的错误或超时错误，
并且 webhook 的 [失败策略](#failure-policy) 设置为 `Fail`。
- `no_error`：未发生错误。Webhook 在准入响应中以 `allowed: false` 值拒绝了请求。
度量标签 `rejection_code` 记录了在准入响应中设置的 `.status.code`。
- `apiserver_internal_error`：apiserver 发生内部错误。
- `rejection_code`：当 Webhook 拒绝请求时，在准入响应中设置的 HTTP 状态码。
@ -1997,7 +2077,8 @@ An idempotent mutating admission webhook is able to successfully process an obje
and potentially modified. The admission can be applied multiple times without changing the result beyond
the initial application.
-->
幂等的 mutating admission Webhook 能够成功处理已经被它接纳甚或修改的对象。即使多次执行该准入测试，也不会产生与初次执行结果相异的结果。
幂等的修改性质的准入 Webhook 能够成功处理已经被它接纳甚或修改的对象。
即使多次执行该准入测试，也不会产生与初次执行结果相异的结果。
<!--
#### Example of idempotent mutating admission webhooks:
@ -2014,11 +2095,12 @@ In the cases above, the webhook can be safely reinvoked, or admit an object that
-->
#### 幂等 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` 容器。
<!--
In the first case above, reinvoking the webhook can result in the same sidecar being injected multiple times to a pod, each time
@ -2054,12 +2137,14 @@ In the second case above, reinvoking the webhook will result in the webhook fail
In the third case above, reinvoking the webhook will result in duplicated containers in the pod spec, which makes
the request invalid and rejected by the API server.
-->
在上述第一种情况下，重新调用该 Webhook 可能导致同一个 Sidecar 容器多次注入到 Pod 中，而且每次使用不同的容器名称。
在上述第一种情况下，重新调用该 Webhook 可能导致同一个 Sidecar 容器
多次注入到 Pod 中，而且每次使用不同的容器名称。
类似地，如果 Sidecar 已存在于用户提供的 Pod 中，则 Webhook 可能注入重复的容器。
在上述第二种情况下，重新调用 Webhook 将导致 Webhook 自身输出失败。
在上述第三种情况下，重新调用 Webhook 将导致 Pod 规范中的容器重复，从而使请求无效并被 API 服务器拒绝。
在上述第三种情况下，重新调用 Webhook 将导致 Pod 规范中的容器重复，
从而使请求无效并被 API 服务器拒绝。
<!--
### Intercepting all versions of an object
@ -2071,14 +2156,16 @@ versions. See [Matching requests: matchPolicy](#matching-requests-matchpolicy) f
-->
### 拦截对象的所有版本
建议通过将 `.webhooks[].matchPolicy` 设置为 `Equivalent`，以确保 admission webhooks 始终拦截对象的所有版本。
建议 admission webhooks 应该更偏向注册资源的稳定版本。如果无法拦截对象的所有版本，可能会导致准入策略未再某些版本的请求上执行。
建议通过将 `.webhooks[].matchPolicy` 设置为 `Equivalent`，
以确保准入 Webhooks 始终拦截对象的所有版本。
建议准入 Webhooks 应该更偏向注册资源的稳定版本。
如果无法拦截对象的所有版本，可能会导致准入策略未再某些版本的请求上执行。
有关示例，请参见[匹配请求：matchPolicy](#matching-requests-matchpolicy)。
<!--
### Availability
It is recommended that admission webhooks should evaluate as quickly as possible (typically in milliseconds), since they add to API request latency.
It is recommended that admission Webhooks should evaluate as quickly as possible (typically in milliseconds), since they add to API request latency.
It is encouraged to use a small timeout for webhooks. See [Timeouts](#timeouts) for more detail.
It is recommended that admission webhooks should leverage some format of load-balancing, to provide high availability and
@ -2087,7 +2174,7 @@ to leverage the load-balancing that service supports.
-->
### 可用性 {#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" 的容器。
<!--
### Avoiding deadlocks in self-hosted webhooks
@ -2130,13 +2220,17 @@ It is recommended to exclude the namespace where your webhook is running with a
-->
### 避免自托管的 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
@ -2149,17 +2243,21 @@ If side effects are required during the admission evaluation, they must be suppr
`AdmissionReview` object with `dryRun` set to `true`, and the `.webhooks[].sideEffects` field should be
set to `NoneOnDryRun`. See [Side effects](#side-effects) for more detail.
-->
### 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)。
<!--
### Avoiding operating on the kube-system namespace
-->
### 避免对 kube-system 命名空间进行操作
### 避免对 kube-system 名字空间进行操作
<!--
The `kube-system` namespace contains objects created by the Kubernetes system,
@ -2170,6 +2268,11 @@ If your admission webhooks don't intend to modify the behavior of the Kubernetes
plane, exclude the `kube-system` namespace from being intercepted using a
[`namespaceSelector`](#matching-requests-namespaceselector).
-->
`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` 名字空间。

336
content/zh/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -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`: Enable container log rotation for cri container runtime.
@ -538,18 +546,33 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `CSIMigrationAzureFile`: Enables shims and translation logic to route volume operations from the Azure-File in-tree plugin to AzureFile CSI plugin. Supports falling back to in-tree AzureFile plugin if a node does not have AzureFile CSI plugin installed and configured. Requires CSIMigration feature flag enabled.
- `CSIMigrationAzureFileComplete`: Stops registering the Azure-File in-tree plugin in kubelet and volume controllers and enables shims and translation logic to route volume operations from the Azure-File in-tree plugin to AzureFile CSI plugin. Requires CSIMigration and CSIMigrationAzureFile feature flags enabled and AzureFile CSI plugin installed and configured on all nodes in the cluster.
-->
- `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`: Enables shims and translation logic to route volume operations from the GCE-PD in-tree plugin to PD CSI plugin. Supports falling back to in-tree GCE plugin if a node does not have PD CSI plugin installed and configured. Requires CSIMigration feature flag enabled.
@ -563,18 +586,38 @@ Each feature gate is designed for enabling/disabling a specific feature:
[CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
compatible volume plugin.
-->
- `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`: Enable nodes to change CPUCFSQuotaPeriod.
@ -591,14 +634,21 @@ Each feature gate is designed for enabling/disabling a specific feature:
on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
troubleshoot a running Pod.
-->
- `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 进行故障排除。
<!--
@ -615,16 +665,22 @@ Each feature gate is designed for enabling/disabling a specific feature:
This feature is superseded by the `VolumeScheduling` feature completely in v1.12.
- `DynamicVolumeProvisioning`(*deprecated*): Enable the [dynamic provisioning](/docs/concepts/storage/dynamic-provisioning/) of persistent volumes to Pods.
-->
- `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` (*deprecated*): Enable the five second timeout on aggregated discovery calls.
@ -637,14 +693,20 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `ExperimentalCriticalPodAnnotation`: Enable annotating specific pods as *critical* so that their [scheduling is guaranteed](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/).
This feature is deprecated by Pod Priority and Preemption as of v1.13.
-->
- `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`: Enabling the defaulting user
@ -667,17 +729,27 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `HugePages`: Enable the allocation and consumption of pre-allocated [huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/).
- `HugePageStorageMediumSize`: Enable support for multiple sizes pre-allocated [huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/).
-->
- `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`: Enable [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) for Windows containers.
@ -691,14 +763,22 @@ Each feature gate is designed for enabling/disabling a specific feature:
See [Support Device Monitoring](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md) for more details.
- `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels provided by `NodeDisruptionExclusion` and `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` 提供的特性指定的标签。
- `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`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
@ -708,12 +788,22 @@ Each feature gate is designed for enabling/disabling a specific feature:
For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
- `NodeDisruptionExclusion`: Enable use of the node label `node.kubernetes.io/exclude-disruption` which prevents nodes from being evacuated during zone failures.
-->
- `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`: Enable the new Lease API to report node heartbeats, which could be used as a node health signal.
@ -727,14 +817,19 @@ Each feature gate is designed for enabling/disabling a specific feature:
Pod readiness evaluation. See [Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)
for more details.
-->
- `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`: Enable the setting of `shareProcessNamespace` in a Pod for sharing
@ -752,12 +847,16 @@ Each feature gate is designed for enabling/disabling a specific feature:
-->
- `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`: Enable resource quota scope selectors.
- `RotateKubeletClientCertificate`: Enable the rotation of the client TLS certificate on the kubelet.
@ -768,13 +867,18 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `RuntimeClass`: Enable the [RuntimeClass](/docs/concepts/containers/runtime-class/) feature for selecting container runtime configurations.
- `ScheduleDaemonSetPods`: Enable DaemonSet Pods to be scheduled by the default scheduler instead of the DaemonSet controller.
-->
- `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`: Enables the _SCTP_ `protocol` value in Pod, Service, Endpoints, EndpointSlice, and NetworkPolicy definitions.
@ -790,18 +894,28 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or
PersistentVolumeClaim objects if they are still being used.
-->
- `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`: Allow apiservers to expose the storage version hash in the discovery.
@ -814,12 +928,15 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `Sysctls`: Enable support for namespaced kernel parameters (sysctls) that can be set for each pod.
See [sysctls](/docs/tasks/administer-cluster/sysctl-cluster/) for more details.
-->
- `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`: Enable evicting pods from nodes based on taints on nodes and tolerations on Pods.
@ -831,13 +948,18 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `TopologyManager`: Enable a mechanism to coordinate fine-grained hardware resource assignments for different components in Kubernetes. See [Control Topology Management Policies on a node](/docs/tasks/administer-cluster/topology-manager/).
- `TTLAfterFinished`: Allow a [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) to clean up resources after they finish execution.
-->
- `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`: Enable support for specifying an existing PVC as a DataSource.
@ -847,9 +969,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
type when used together with the `PersistentLocalVolumes` feature gate.
- `VolumeSnapshotDataSource`: Enable volume snapshot data source support.
-->
- `VolumePVCDataSource`：启用对将现有 PVC 指定数据源的支持。
- `VolumeScheduling`：启用卷拓扑感知调度，并使 PersistentVolumeClaim（PVC）绑定调度决策；当与 PersistentLocalVolumes 特性门控一起使用时，还可以使用 `PersistentLocalVolumes` 卷类型。
- `VolumeScheduling`：启用卷拓扑感知调度，并使 PersistentVolumeClaim（PVC）
绑定调度决策；当与 PersistentLocalVolumes 特性门控一起使用时，
还可以使用 `PersistentLocalVolumes` 卷类型。
- `VolumeSnapshotDataSource`：启用卷快照数据源支持。
<!--
@ -861,7 +984,6 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `WinDSR`: Allows kube-proxy to create DSR loadbalancers for Windows.
- `WinOverlay`: Allows kube-proxy to run in overlay mode for Windows.
-->
- `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" %}}
<!--
* The [deprecation policy](/docs/reference/using-api/deprecation-policy/) for Kubernetes explains
the project's approach to removing features and components.
-->
* Kubernetes 的[弃用策略](/zh/docs/reference/using-api/deprecation-policy/) 介绍了项目已移除的特性部件和组件的方法。
* Kubernetes 的[弃用策略](/zh/docs/reference/using-api/deprecation-policy/)
介绍了项目已移除的特性部件和组件的方法。

18
content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
View File

@ -28,7 +28,7 @@ This document describes how to authenticate and authorize access to the kubelet'
<!--
## Kubelet authentication
-->
## Kubelet 认证
## Kubelet 身份认证
<!--
By default, requests to the kubelet's HTTPS endpoint that are not rejected by other configured
@ -56,11 +56,12 @@ To enable X509 client certificate authentication to the kubelet's HTTPS endpoint
<!--
* start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with
* start the apiserver with `--kubelet-client-certificate` and `--kubelet-client-key` flags
* see the [apiserver authentication documentation](/docs/admin/authentication/#x509-client-certs) for more details
* see the [apiserver authentication documentation](/docs/reference/access-authn-authz/authentication/#x509-client-certs) for more details
-->
* 带 `--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)
<!--
To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint:
@ -113,12 +114,15 @@ To subdivide access to the kubelet API, delegate authorization to the API server
-->
* 确保在 API 服务器中启用了 `authorization.k8s.io/v1beta1` API 组
* 带 `--authorization-mode=Webhook` 和 `--kubeconfig` 标志启动 kubelet
* kubelet 调用已配置的 API 服务器上的 `SubjectAccessReview` API，以确定每个请求是否得到鉴权
* kubelet 调用已配置的 API 服务器上的 `SubjectAccessReview` API，
以确定每个请求是否得到鉴权
<!--
The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver.
The kubelet authorizes API requests using the same [request attributes](/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) approach as the apiserver.
-->
kubelet 使用与 apiserver 相同的[请求属性](/zh/docs/admin/authorization/#request-attributes)方法对 API 请求执行鉴权。
kubelet 使用与 apiserver 相同的
[请求属性](/zh/docs/reference/access-authn-authz/authorization/#review-your-request-attributes)
方法对 API 请求执行鉴权。
<!--
The verb is determined from the incoming request's HTTP verb:
@ -170,4 +174,4 @@ flags passed to the apiserver is authorized for the following attributes:
* verb=\*, resource=nodes, subresource=stats
* verb=\*, resource=nodes, subresource=log
* verb=\*, resource=nodes, subresource=spec
* verb=\*, resource=nodes, subresource=metrics
* verb=\*, resource=nodes, subresource=metrics

2
content/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
View File

@ -16,7 +16,7 @@ and progress on the feature is being tracked as [feature #43](https://github.com
## kube-apiserver configuration
The API server should be configured with an [authenticator](/docs/admin/authentication/) that can authenticate tokens as a user in the `system:bootstrappers` group.
The API server should be configured with an [authenticator](/zh/docs/reference/access-authn-authz/authentication/) that can authenticate tokens as a user in the `system:bootstrappers` group.
This group will later be used in the controller-manager configuration to scope approvals in the default approval
controller. As this feature matures, you should ensure tokens are bound to a Role-Based Access Control (RBAC) policy which limits requests

10
content/zh/docs/reference/glossary/extensions.md
View File

@ -10,10 +10,8 @@ tags:
- fundamental
- extension
---
扩展组件是扩展并与 Kubernetes 深度集成以支持新型硬件的软件组件。
<!--
---
title: Extensions
id: Extensions
date: 2019-02-01
@ -25,9 +23,11 @@ aka:
tags:
- fundamental
- extension
---
-->
<!--
Extensions are software components that extend and deeply integrate with Kubernetes to support new types of hardware.
-->
扩展组件是扩展并与 Kubernetes 深度集成以支持新型硬件的软件组件。
<!--more-->
@ -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)，
较少用户会需要编写新的扩展组件。
安装[扩展组件](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions)，
较少用户会需要编写新的扩展组件。

28
content/zh/docs/reference/glossary/flexvolume.md
View File

@ -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
---
<!-- ---
<!--
title: FlexVolume
id: flexvolume
date: 2018-06-25
full_link: /docs/concepts/storage/volumes/#flexvolume
short_description: >
FlexVolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with FlexVolumes.
aka:
tags:
- storage
--- -->
<!--
FlexVolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with FlexVolumes.
-->
Flexvolume 是创建 out-of-tree 卷插件的一种接口。 {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} 是比 Flexvolume 更新的接口，它解决了 Flexvolume 的一些问题。
-->
<!--
FlexVolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with FlexVolumes.
-->
Flexvolume 是创建树外卷插件的一种接口。
{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}}
是比 Flexvolume 更新的接口，它解决了 Flexvolume 的一些问题。
<!--more-->
@ -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 的限制。
<!--
@ -45,6 +47,6 @@ FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。
* [More information on FlexVolumes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)
* [Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)
-->
* [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)
* [存储供应商的卷插件 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)

8
content/zh/docs/reference/glossary/managed-service.md
View File

@ -27,7 +27,6 @@ tags:
<!--
A software offering maintained by a third-party provider.
-->
由第三方供应商负责维护的一种软件产品。
<!--more-->
@ -35,8 +34,9 @@ tags:
<!--
Some examples of Managed Services are AWS EC2, Azure SQL Database, and GCP Pub/Sub, but they can be any software offering that can be used by an application. [Service Catalog](/docs/concepts/service-catalog/) provides a way to list, provision, and bind with Managed Services offered by {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}.
-->
托管服务的一些例子有 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" >}}
所提供的托管服务。

16
content/zh/docs/reference/glossary/operator-pattern.md
View File

@ -10,10 +10,8 @@ aka:
tags:
- architecture
---
[operator 模式](/docs/concepts/extend-kubernetes/operator/) 是一个系统设计, 将 {{< glossary_tooltip term_id="controller" >}} 关联到一个或多个自定义资源。
<!--
---
title: Operator pattern
id: operator-pattern
date: 2019-05-21
@ -24,12 +22,14 @@ short_description: >
aka:
tags:
- architecture
---
The [operator pattern](/docs/concepts/extend-kubernetes/operator/) is a system
-->
<!--
The [operator pattern](/docs/concepts/extend-kubernetes/operator/) is a system
design that links a {{< glossary_tooltip term_id="controller" >}} to one or more custom
resources.
-->
[operator 模式](/zh/docs/concepts/extend-kubernetes/operator/) 是一种系统设计,
将 {{< glossary_tooltip term_id="controller" >}} 关联到一个或多个自定义资源。
<!--more-->
<!--
@ -40,7 +40,9 @@ If a running application acts as a controller and has API access to carry out ta
against a custom resource that's defined in the control plane, that's an example of
the Operator pattern.
-->
除了使用作为 Kubernetes 自身一部分的内置控制器之外，你还可以通过
将控制器添加到集群中来扩展 Kubernetes。
除了使用作为 Kubernetes 自身一部分的内置控制器之外，您还可以通过将控制器添加到集群中来扩展 Kubernetes。
如果正在运行的应用程序能够充当控制器并通过 API 访问的方式来执行任务操控
那些在控制平面中定义的自定义资源，这就是一个 operator 模式的示例。
如果正在运行的应用程序能够充当控制器并通过 API 访问的方式来执行任务操控那些在控制平面中定义的自定义资源，这就是一个 operator 模式的示例。

2
content/zh/docs/reference/glossary/platform-developer.md
View File

@ -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 社区的扩展。

15
content/zh/docs/reference/glossary/pod-lifecycle.md
View File

@ -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: >
---
<!--
---
title: Pod Lifecycle
id: pod-lifecycle
date: 2019-02-17
@ -25,18 +24,20 @@ tags:
- fundamental
short_description: >
A high-level summary of what phase the Pod is in within its lifecyle.
---
-->
<!--
A high-level summary of what phase the Pod is in within its lifecyle.
A high-level summary of what phase the Pod is in within its lifecyle.
-->
关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。
关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。
<!--more-->
<!--
The [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) is a high level summary of where a Pod is in its lifecyle. A Pod’s `status` field is a [PodStatus](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) object, which has a `phase` field that displays one of the following phases: Running, Pending, Succeeded, Failed, Unknown, Completed, or CrashLoopBackOff.
-->
[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。

12
content/zh/docs/reference/issues-security/issues.md
View File

@ -5,22 +5,22 @@ aliases: [cve/,cves/]
---
<!--
---
title: Kubernetes Issue Tracker
weight: 10
aliases: [/cve/,/cves/]
---
-->
<!--
To report a security issue, please follow the [Kubernetes security disclosure process](/docs/reference/issues-security/security/#report-a-vulnerability).
-->
要报告安全问题，请遵循 [Kubernetes 安全问题公开流程](/docs/reference/issues-security/security/#report-a-vulnerability)。
要报告安全问题，请遵循
[Kubernetes 安全问题公开流程](/zh/docs/reference/issues-security/security/#report-a-vulnerability)。
<!--
Work on Kubernetes code and public issues are tracked using [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/).
-->
使用 [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/) 跟踪 Kubernetes 编码工作和公开问题。
使用 [GitHub Issues](https://github.com/kubernetes/kubernetes/issues/)
跟踪 Kubernetes 编码工作和公开问题。
<!--
* [CVE-related issues](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE)
@ -30,4 +30,6 @@ Work on Kubernetes code and public issues are tracked using [GitHub Issues](http
<!--
Security-related announcements are sent to the [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) mailing list.
-->
与安全性相关的公告请发送到 [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)
邮件列表。

68
content/zh/docs/reference/kubectl/overview.md
View File

@ -9,7 +9,6 @@ card:
weight: 20
---
<!--
---
reviewers:
- bgrant0607
- hw-qiaolei
@ -19,7 +18,6 @@ weight: 20
card:
name: reference
weight: 20
---
-->
<!-- overview -->
@ -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/) 文件。
<!--
@ -47,14 +46,11 @@ For installation instructions see [installing kubectl](/docs/tasks/tools/install
请参阅 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 参考文档。
有关安装说明，请参见[安装 kubectl](/zh/docs/tasks/tools/install-kubectl/) 。
<!-- body -->
<!--
## Syntax
-->
## 语法
<!--
@ -76,16 +72,16 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output:
-->
* `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`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example `kubectl get pods`.
@ -93,11 +89,12 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
When performing an operation on multiple resources, you can specify each resource by type and name or specify one or more files:
-->
* `NAME`：指定资源的名称。名称区分大小写。如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。
* `NAME`：指定资源的名称。名称区分大小写。
如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。
在对多个资源执行操作时，你可以按类型和名称指定每个资源，或指定一个或多个文件：
<!--
<!--
* To specify resources by type and name:
* To group resources if they are all the same type: `TYPE1 name1 name2 name<#>`.<br/>
@ -108,29 +105,33 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
* To specify resources with one or more files: `-f file1 -f file2 -f file<#>`
* [Use YAML rather than JSON](/docs/concepts/configuration/overview/#general-configuration-tips) since YAML tends to be more user-friendly, especially for configuration files.<br/>
* [Use YAML rather than JSON](/docs/concepts/configuration/overview/#general-configuration-tips)
since YAML tends to be more user-friendly, especially for configuration files.<br/>
Example: `kubectl get -f ./pod.yaml`
-->
* 要按类型和名称指定资源：
* `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.<br/>
* 要对所有类型相同的资源进行分组，请执行以下操作：`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`
<!--
* `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<#>`。<br/>
例子：`kubectl get pod example-pod1 example-pod2`
* 分别指定多个资源类型：`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`。<br/>
例子：`kubectl get pod/example-pod1 replicationcontroller/example-rc1`
* 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>`
* [使用 YAML 而不是 JSON](/docs/concepts/configuration/overview/#general-configuration-tips) 因为 YAML 更容易使用，特别是用于配置文件时。<br/>
例子：`kubectl get -f ./pod.yaml`
* `flags`: 指定可选的参数。例如，可以使用 `-s` 或 `-server` 参数指定 Kubernetes API 服务器的地址和端口。<br/>
* `flags`: 指定可选的参数。例如，可以使用 `-s` 或 `-server` 参数指定
Kubernetes API 服务器的地址和端口。
{{< caution >}}
<!--
Flags that you specify from the command line override default values and any corresponding environment variables.
-->
@ -145,7 +146,6 @@ If you need help, just run `kubectl help` from the terminal window.
<!--
## Operations
-->
## 操作
<!--

14
content/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
View File

@ -4,7 +4,7 @@ content_type: concept
weight: 90
---
<!--
---
reviewers:
- mikedanese
- luxas
@ -12,7 +12,6 @@ reviewers:
title: kubeadm alpha
content_type: concept
weight: 90
---
-->
{{< 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}
<!--
@ -92,7 +91,8 @@ This command checks expiration for the certificates in the local PKI managed by
For more details about certificate expiration and renewal see the [certificate management documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/).
-->
此命令检查 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.
<!--
The subcommand `pivot` can be used to convert a static Pod-hosted control plane into a self-hosted one.
-->
子命令 `pivot` 可用于将 Pod 托管的静态控制平面转换为自托管的控制平面。有关 `pivot` 更多信息，请参见[文档](zh/docs/setup/production-environment/tools/kubeadm/self-hosting/)。
子命令 `pivot` 可用于将 Pod 托管的静态控制平面转换为自托管的控制平面。
有关 `pivot` 更多信息，请参见
[文档](/zh/docs/setup/production-environment/tools/kubeadm/self-hosting/)。
<!--
[Documentation](/docs/setup/production-environment/tools/kubeadm/self-hosting/)

22
content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md
View File

@ -2,11 +2,10 @@
title: kubeadm join phase
weight: 90
---
<!--
---
title: kubeadm join phase
weight: 90
---
-->
<!--
@ -14,13 +13,16 @@ weight: 90
Hence, you can let kubeadm do some of the work and you can fill in the gaps
if you wish to apply customization.
-->
`kubeadm join phase` 使你能够调用 `join` 过程的基本原子步骤。因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。
`kubeadm join phase` 使你能够调用 `join` 过程的基本原子步骤。
因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。
<!--
`kubeadm join phase` is consistent with the [kubeadm join workflow](/docs/reference/setup-tools/kubeadm/kubeadm-join/#join-workflow),
and behind the scene both use the same code.
-->
`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/)
尝试实验性功能

22
content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md
View File

@ -3,12 +3,11 @@ title: kubeadm reset phase
content_type: concept
weight: 90
---
<!--
---
title: kubeadm reset phase
content_type: concept
weight: 90
---
-->
<!--
@ -16,13 +15,16 @@ weight: 90
Hence, you can let kubeadm do some of the work and you can fill in the gaps
if you wish to apply customization.
-->
`kubeadm reset phase` 使你能够调用 `reset` 过程的基本原子步骤。因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。
`kubeadm reset phase` 使你能够调用 `reset` 过程的基本原子步骤。
因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。
<!--
`kubeadm reset phase` is consistent with the [kubeadm reset workflow](/docs/reference/setup-tools/kubeadm/kubeadm-reset/#reset-workflow),
and behind the scene both use the same code.
-->
`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/)
尝试实验性功能

30
content/zh/docs/reference/tools.md
View File

@ -6,37 +6,35 @@ content_type: concept
---
<!--
---
reviewers:
- janetkuo
title: Tools
content_type: concept
---
-->
<!--
Kubernetes contains several built-in tools to help you work with the Kubernetes system.
-->
<!-- overview -->
Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernetes 系统。
<!-- body -->
## Kubectl
<!--
[`kubectl`](/docs/tasks/tools/install-kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager.
-->
[`kubectl`](/docs/tasks/tools/install-kubectl/) 是 Kubernetes 命令行工具，可以用来操控 Kubernetes 集群。
[`kubectl`](/zh/docs/tasks/tools/install-kubectl/) 是 Kubernetes 命令行工具，
可以用来操控 Kubernetes 集群。
## Kubeadm
<!--
[`kubeadm`](/docs/tasks/tools/install-kubeadm/) is the command line tool for easily provisioning a secure Kubernetes cluster on top of physical or cloud servers or virtual machines (currently in alpha).
-->
[`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。
<!--
Use Helm to:
@ -86,7 +88,8 @@ Use Helm to:
<!--
[`Kompose`](https://github.com/kubernetes/kompose) is a tool to help Docker Compose users move to Kubernetes.
-->
[`Kompose`](https://github.com/kubernetes/kompose) 一个转换工具，用来帮助 Docker Compose 用户迁移至 Kubernetes。
[`Kompose`](https://github.com/kubernetes/kompose) 一个转换工具，
用来帮助 Docker Compose 用户迁移至 Kubernetes。
<!--
Use Kompose to:
@ -99,5 +102,6 @@ Use Kompose to:
* 将一个 Docker Compose 文件解释成 Kubernetes 对象
* 将本地 Docker 开发 转变成通过 Kubernetes 来管理
* 转换 v1 或 v2 Docker Compose `yaml` 文件 或 [分布式应用程序包](https://docs.docker.com/compose/bundles/)
* 转换 v1 或 v2 Docker Compose `yaml` 文件 或
[已发布的应用程序包](https://docs.docker.com/compose/bundles/)