[zh-cn]sync extensible-admission-controllers

Signed-off-by: xin.li <[email protected]>

Author: my-git9

content/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers.md

@@ -2152,289 +2152,10 @@ apiserver_admission_webhook_rejection_count{error_type="no_error",name="deny-unw
 -->
 ## 最佳实践和警告 {#best-practices-and-warnings}
 
-### 幂等性  {#idempotence}
-
-<!--
-An idempotent mutating admission webhook is able to successfully process an object it has already admitted
-and potentially modified. The admission can be applied multiple times without changing the result beyond
-the initial application.
--->
-幂等的变更性质的准入 Webhook 能够成功处理已经被它接纳甚或修改的对象。
-即使多次执行该准入测试，也不会产生与初次执行结果相异的结果。
-
-<!--
-#### Example of idempotent mutating admission webhooks:
-
-1. For a `CREATE` pod request, set the field `.spec.securityContext.runAsNonRoot` of the
-   pod to true, to enforce security best practices.
-
-2. For a `CREATE` pod request, if the field `.spec.containers[].resources.limits`
-   of a container is not set, set default resource limits.
-
-3. For a `CREATE` pod request, inject a sidecar container with name `foo-sidecar` if no container
-   with the name `foo-sidecar` already exists.
-
-In the cases above, the webhook can be safely reinvoked, or admit an object that already has the fields set.
--->
-#### 幂等 mutating admission Webhook 的示例： {#example-of-idempotent-mutating-admission-webhooks}
-
-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，或接受已经设置了字段的对象。
-
-<!--
-#### Example of non-idempotent mutating admission webhooks:
--->
-#### 非幂等 mutating admission Webhook 的示例： {#example-of-non-idempotent-mutating-admission-webhooks}
-
-<!--
-1. For a `CREATE` pod request, inject a sidecar container with name `foo-sidecar`
-   suffixed with the current timestamp (e.g. `foo-sidecar-19700101-000000`).
-
-2. For a `CREATE`/`UPDATE` pod request, reject if the pod has label `"env"` set,
-   otherwise add an `"env": "prod"` label to the pod.
-
-3. For a `CREATE` pod request, blindly append a sidecar container named
-   `foo-sidecar` without looking to see if there is already a `foo-sidecar`
-   container in the pod.
--->
-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
-with a different container name. Similarly the webhook can inject duplicated containers if the sidecar already exists in
-a user-provided pod.
-
-In the second case above, reinvoking the webhook will result in the webhook failing on its own output.
-
-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 可能导致同一个边车容器多次注入到
-Pod 中，而且每次使用不同的容器名称。
-类似地，如果 Sidecar 已存在于用户提供的 Pod 中，则 Webhook 可能注入重复的容器。
-
-在上述第二种情况下，重新调用 Webhook 将导致 Webhook 自身输出失败。
-
-在上述第三种情况下，重新调用 Webhook 将导致 Pod 规约中的容器重复，
-从而使请求无效并被 API 服务器拒绝。
-
-<!--
-### Intercepting all versions of an object
-
-It is recommended that admission webhooks should always intercept all versions of an object by setting `.webhooks[].matchPolicy`
-to `Equivalent`. It is also recommended that admission webhooks should prefer registering for stable versions of resources.
-Failure to intercept all versions of an object can result in admission policies not being enforced for requests in certain
-versions. See [Matching requests: matchPolicy](#matching-requests-matchpolicy) for examples.
--->
-### 拦截对象的所有版本 {#intercepting-all-versions-of-an-object}
-
-建议通过将 `.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 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 performance benefits. If a webhook is running within the cluster,
-you can run multiple webhook backends behind a service to leverage the load-balancing that service
-supports.
--->
-### 可用性   {#availability}
-
-建议准入 Webhook 尽快完成执行（时长通常是毫秒级），因为它们会增加 API 请求的延迟。
-建议对 Webhook 使用较小的超时值。有关更多详细信息，请参见[超时](#timeouts)。
-
-建议准入 Webhook 应该采用某种形式的负载均衡机制，以提供高可用性和高性能。
-如果集群中正在运行 Webhook，则可以在服务后面运行多个 Webhook 后端，以利用该服务支持的负载均衡。
-
-<!--
-### Guaranteeing the final state of the object is seen
-
-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.
-
-For example, a mutating admission webhook is configured to inject a sidecar container with name
-"foo-sidecar" on every `CREATE` pod request. If the sidecar *must* be present, a validating
-admisson webhook should also be configured to intercept `CREATE` pod requests, and validate that a
-container with name "foo-sidecar" with the expected configuration exists in the to-be-created
-object.
--->
-### 确保看到对象的最终状态 {#guaranteeing-the-final-state-of-the-object-is-seen}
-
-如果某准入 Webhook 需要保证自己能够看到对象的最终状态以实施策略，
-则应该使用一个验证性质的 Webhook，
-因为可以通过变更性质的 Webhook 看到对象后对其进行修改。
-
-例如，一个变更性质的准入 Webhook 被配置为在每个 `CREATE` Pod
-请求中注入一个名称为 "foo-sidecar" 的边车容器。
-
-如果**必须**存在边车容器，则还应配置一个验证性质的准入 Webhook 以拦截
-`CREATE` Pod 请求，并验证要创建的对象中是否存在具有预期配置的名称为
-"foo-sidecar" 的容器。
-
-<!--
-### Avoiding deadlocks in self-hosted webhooks
-
-There are several ways that webhooks can cause deadlocks, where the cluster cannot make progress in
-scheduling pods:
-
-* A webhook running inside the cluster might cause deadlocks for its own deployment if it is configured
-  to intercept resources required to start its own pods.
--->
-### 避免自托管的 Webhook 中出现死锁 {#avoiding-deadlocks-in-self-hosted-webhooks}
-
-有几种方式 Webhook 可能导致死锁，即集群无法在调度 Pod 时取得进展：
-
-* 如果集群内的 Webhook 配置能够拦截启动其自己的 Pod 所需的资源，
-  则该 Webhook 可能导致其自身部署时发生死锁。
-
-  <!--
-  For example, a mutating admission webhook is configured to admit **create** Pod requests only if a certain label is set in the
-  pod (such as `env: "prod"`). However, the webhook server runs as a Deployment that doesn't set the `env` label.
-  When a node that runs the webhook server pods
-  becomes unhealthy, the webhook deployment will try to reschedule the pods to another node. However the requests will
-  get rejected by the existing webhook server since the `env` label is unset, and the replacement Pod
-  cannot be created. Eventually, the entire Deployment for the webhook server may become unhealthy.
-  -->
-
-  例如，某变更性质的准入 Webhook 配置为仅当 Pod 中设置了某个标签
-  （例如 `"env": "prod"`）时，才接受 **create** Pod 请求。
-  Webhook 服务器在未设置 `"env"` 标签的 Deployment 中运行。
-  当运行 Webhook 服务器 Pod 的节点运行不正常时，Webhook 部署尝试将容器重新调度到另一个节点。
-  但是，由于未设置 `"env"` 标签，因此请求将被现有的 Webhook 服务器拒绝，并替换 Pod 不会被创建。
-  最终，Webhook 服务器的整个 Deployment 可能变成不健康。
-
-  <!--
-  If you use admission webhooks to check Pods, consider excluding the namespace where your webhook
-  listener is running, by specifying a
-  [namespaceSelector](#matching-requests-namespaceselector).
-  -->
-
-  如果你使用准入 Webhook 来检查 Pod，建议通过指定
-  [namespaceSelector](#matching-requests-namespaceselector) 来排除正在运行 Webhook 侦听器的名字空间。
-
-<!--
-* If the cluster has multiple webhooks configured (possibly from independent applications deployed on
-  the cluster), they can form a cycle.  Webhook A must be called to process startup of webhook B's
-  pods and vice versa. If both webhook A and webhook B ever become unavailable at the same time (for
-  example, due to a cluster-wide outage or a node failure where both pods run on the same node)
-  deadlock occurs because neither webhook pod can be recreated without the other already running.
--->
-* 如果集群中配置了多个 Webhook（可能来自集群上部署的独立应用），这些 Webhook 可能形成一个循环。
-  Webhook A 必须被调用以处理 Webhook B 的 Pod 启动，反之亦然。
-  如果 Webhook A 和 B 同时变得不可用
-  （例如，由于集群范围的停机故障或两个 Pod 运行在同一个节点上时出现节点故障），
-  将发生死锁，这是因为没有一个 Webhook Pod 可以在另一个已经运行之前被重新创建。
-
-  <!--
-  One way to prevent this is to exclude webhook A's pods from being acted on be webhook B. This
-  allows webhook A's pods to start, which in turn allows webhook B's pods to start. If you had a 
-  third webhook, webhook C, you'd need to exclude both webhook A and webhook B's pods from 
-  webhook C. This ensures that webhook A can _always_ start, which then allows webhook B's pods 
-  to start, which in turn allows webhook C's pods to start.
-  -->
-
-  防止这种情况的一种方法是排除 Webhook B 对 Webhook A 的 Pod 的作用。
-  这允许 Webhook A 的 Pod 启动，进而允许 Webhook B 的 Pod 启动。
-  如果有第三个 Webhook，即 Webhook C，你需要排除 Webhook C 对 Webhook A 和 B 的 Pod 的作用。
-  这确保了 Webhook A 可以始终启动，从而允许 Webhook B 的 Pod 启动，进而允许 Webhook C 的 Pod 启动。
-
-  <!--
-  If you want to ensure protection that avoids these risks, [ValidatingAdmissionPolicies](/docs/reference/access-authn-authz/validating-admission-policy/)
-  can
-  provide many protection capabilities without introducing dependency cycles.
-  -->
-
-  如果你想确保避免这些风险，
-  [ValidatingAdmissionPolicies](/zh-cn/docs/reference/access-authn-authz/validating-admission-policy/)
-  可以提供许多保护能力，而不会引入依赖循环。
-
-<!--
-* Admission webhooks can intercept resources used by critical cluster add-ons, such as CoreDNS,
-  network plugins, or storage plugins. These add-ons may be required to schedule or successfully run the
-  pods for a particular admission webhook on the cluster. This can cause a deadlock if both the 
-  webhook and critical add-on is unavailable at the same time.
--->
-* 准入 Webhook 可以拦截关键集群附加组件所使用的资源，例如 CoreDNS、网络插件或存储插件。
-  这些附加组件可能是调度或成功运行集群上特定准入 Webhook 的 Pod 所必需的。
-  如果 Webhook 和关键附加组件同时不可用，就可能导致死锁。
-
-  <!--
-  You may wish to exclude cluster infrastructure namespaces from webhooks, or make sure that
-  the webhook does not depend on the particular add-on that it acts on.  For exmaple, running
-  a webhook as a host-networked pod ensures that it does not depend on a networking plugin.
-
-  If you want to ensure protection for a core add-on / or its namespace,
-  [ValidatingAdmissionPolicies](/docs/reference/access-authn-authz/validating-admission-policy/)
-  can
-  provide many protection capabilities without any dependency on worker nodes and Pods.
-  -->
-
-  你可能希望从 Webhook 中排除集群基础设施名字空间，或者确保 Webhook 不依赖于其作用的特定附加组件。
-  例如，作为主机网络 Pod 运行 Webhook 可以确保 Webhook 不依赖某个网络插件。
-
-  如果你想确保对核心附加组件或其名字空间的保护，
-  [ValidatingAdmissionPolicies](/zh-cn/docs/reference/access-authn-authz/validating-admission-policy/)
-  可以提供许多保护能力，而无需依赖于工作节点和 Pod。
-
-<!--
-### Side effects
-
-It is recommended that admission webhooks should avoid side effects if possible, which means the webhooks operate only on the
-content of the `AdmissionReview` sent to them, and do not make out-of-band changes. The `.webhooks[].sideEffects` field should
-be set to `None` if a webhook doesn't have any side effect.
-
-If side effects are required during the admission evaluation, they must be suppressed when processing an
-`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}
-
-建议准入 Webhook 应尽可能避免副作用，这意味着该准入 Webhook 仅对发送给他们的
-`AdmissionReview` 的内容起作用，并且不要进行额外更改。
-如果 Webhook 没有任何副作用，则 `.webhooks[].sideEffects` 字段应设置为
-`None`。
-
-如果在准入执行期间存在副作用，则应在处理 `dryRun` 为 `true` 的 `AdmissionReview`
-对象时避免产生副作用，并且其 `.webhooks[].sideEffects` 字段应设置为
-`NoneOnDryRun`。更多详细信息，请参见[副作用](#side-effects)。
-
-<!--
-### Avoiding operating on the kube-system namespace
--->
-### 避免对 kube-system 名字空间进行操作 {#avoiding-operating-on-the-kube-system-namespace}
-
 <!--
-The `kube-system` namespace contains objects created by the Kubernetes system,
-e.g. service accounts for the control plane components, pods like `kube-dns`.
-Accidentally mutating or rejecting requests in the `kube-system` namespace may
-cause the control plane components to stop functioning or introduce unknown behavior.
-If your admission webhooks don't intend to modify the behavior of the Kubernetes control
-plane, exclude the `kube-system` namespace from being intercepted using a
-[`namespaceSelector`](#matching-requests-namespaceselector).
+For recommendations and considerations when writing mutating admission webhooks,
+see
+[Admission Webhooks Good Practices](/docs/concepts/cluster-administration/admission-webhooks-good-practices).
 -->
-`kube-system` 名字空间包含由 Kubernetes 系统创建的对象，
-例如用于控制平面组件的服务账号，诸如 `kube-dns` 之类的 Pod 等。
-意外更改或拒绝 `kube-system`
-名字空间中的请求可能会导致控制平面组件停止运行或者导致未知行为发生。
-如果你的准入 Webhook 不想修改 Kubernetes 控制平面的行为，请使用
-[`namespaceSelector`](#matching-requests-namespaceselector)
-避免拦截 `kube-system` 名字空间。
+有关编写可变 Admission Webhook 时的建议和注意事项，请参阅
+[Admission Webhooks 良好实践](/zh-cn/docs/concepts/cluster-administration/admission-webhooks-good-practices)。