diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md index dab7bff34d..e879b6e497 100644 --- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md @@ -21,14 +21,14 @@ weight: 30 -此页面概述了准入控制器。 +此页面提供准入控制器（Admission Controllers）的概述。 -## 什么是准入控制插件？ +## 什么是准入控制插件？ {#what-are-they} 准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成， -并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。 +并编译进 `kube-apiserver` 可执行文件，并且只能由集群管理员配置。 在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。 它们根据 API 中的配置，分别执行变更和验证 [准入控制 webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 @@ -64,14 +64,14 @@ If any of the controllers in either phase reject the request, the entire request is rejected immediately and an error is returned to the end-user. --> 准入控制器可以执行 “验证（Validating）” 和/或 “变更（Mutating）” 操作。 -变更（mutating）控制器可以根据被其接受的请求修改相关对象；验证（validating）控制器则不行。 +变更（mutating）控制器可以根据被其接受的请求更改相关对象；验证（validating）控制器则不行。 准入控制器限制创建、删除、修改对象或连接到代理的请求，不限制读取对象的请求。 准入控制过程分为两个阶段。第一阶段，运行变更准入控制器。第二阶段，运行验证准入控制器。 再次提醒，某些控制器既是变更准入控制器又是验证准入控制器。 -如果任何一个阶段的任何控制器拒绝了该请求，则整个请求将立即被拒绝，并向终端用户返回一个错误。 +如果两个阶段之一的任何一个控制器拒绝了某请求，则整个请求将立即被拒绝，并向最终用户返回错误。 -最后，除了对对象进行变更外，准入控制器还可以有其它作用：将相关资源作为请求处理的一部分进行变更。 -增加使用配额就是一个典型的示例，说明了这样做的必要性。 +最后，除了对对象进行变更外，准入控制器还可能有其它副作用：将相关资源作为请求处理的一部分进行变更。 +增加配额用量就是一个典型的示例，说明了这样做的必要性。 此类用法都需要相应的回收或回调过程，因为任一准入控制器都无法确定某个请求能否通过所有其它准入控制器。 -## 为什么需要准入控制器？ +## 为什么需要准入控制器？ {#why-do-i-need-them} Kubernetes 的许多高级功能都要求启用一个准入控制器，以便正确地支持该特性。 -因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持你期望的所有特性。 +因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持你所期望的所有特性。 -## 如何启用一个准入控制器？ +## 如何启用一个准入控制器？ {how-do-i-turn-on-an-admission-controller} -Kubernetes API 服务器的 `enable-admission-plugins` 标志接受一个用于在集群修改对象之前 -调用的（以逗号分隔的）准入控制插件顺序列表。 +Kubernetes API 服务器的 `enable-admission-plugins` 标志接受一个（以逗号分隔的）准入控制插件列表， +这些插件会在集群修改对象之前被调用。 -例如，下面的命令就启用了 `NamespaceLifecycle` 和 `LimitRanger` 准入控制插件： +例如，下面的命令启用 `NamespaceLifecycle` 和 `LimitRanger` 准入控制插件： ```shell kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ... @@ -128,7 +128,7 @@ have to modify the systemd unit file if the API server is deployed as a systemd service, you may modify the manifest file for the API server if Kubernetes is deployed in a self-hosted way. --> -根据你 Kubernetes 集群的部署方式以及 API 服务器的启动方式的不同，你可能需要以不同的方式应用设置。 +根据你 Kubernetes 集群的部署方式以及 API 服务器的启动方式，你可能需要以不同的方式应用设置。 例如，如果将 API 服务器部署为 systemd 服务，你可能需要修改 systemd 单元文件； 如果以自托管方式部署 Kubernetes，你可能需要修改 API 服务器的清单文件。 {{< /note >}} @@ -138,7 +138,7 @@ in a self-hosted way. The Kubernetes API server flag `disable-admission-plugins` takes a comma-delimited list of admission control plugins to be disabled, even if they are in the list of plugins enabled by default. --> -## 怎么关闭准入控制器？ +## 怎么关闭准入控制器？ {#how-do-i-turn-off-an-admission-controller} Kubernetes API 服务器的 `disable-admission-plugins` 标志，会将传入的（以逗号分隔的） 准入控制插件列表禁用，即使是默认启用的插件也会被禁用。 @@ -152,9 +152,9 @@ kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ... To see which admission plugins are enabled: --> -## 哪些插件是默认启用的？ +## 哪些插件是默认启用的？ {#which-plugins-are-enabled-by-default} -下面的命令可以查看哪些插件是默认启用的： +要查看哪些插件是被启用的： ```shell kube-apiserver -h | grep enable-admission-plugins @@ -164,16 +164,16 @@ kube-apiserver -h | grep enable-admission-plugins In the current version, the default ones are: --> -在目前版本中，它们是： +在目前版本中，默认启用的插件有： -```shell +``` CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook ``` -## 每个准入控制器的作用是什么？ +## 每个准入控制器的作用是什么？ {#what-does-each-admission-controller-do} ### AlwaysAdmit {#alwaysadmit} @@ -182,7 +182,7 @@ CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultI -该准入控制器会允许所有的 pod 接入集群。已废弃，因为它的行为根本就和没有准入控制器一样。 +该准入控制器允许所有的 Pod 进入集群。此插件已被弃用，因其行为与没有准入控制器一样。 ### AlwaysDeny {#alwaysdeny} @@ -191,7 +191,7 @@ This admission controller allows all pods into the cluster. It is deprecated bec -拒绝所有的请求。由于它没有实际意义，已废弃。 +拒绝所有的请求。由于它没有实际意义，已被弃用。 ### AlwaysPullImages {#alwayspullimages} @@ -204,47 +204,47 @@ scheduled onto the right node), without any authorization check against the imag is enabled, images are always pulled prior to starting containers, which means valid credentials are required. --> -该准入控制器会修改每一个新创建的 Pod 的镜像拉取策略为 Always 。 +该准入控制器会修改每个新创建的 Pod，将其镜像拉取策略设置为 Always。 这在多租户集群中是有用的，这样用户就可以放心，他们的私有镜像只能被那些有凭证的人使用。 -如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 Pod 都可以通过已了解到的镜像 -的名称（假设 Pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何授权检查。 -当启用这个准入控制器时，总是在启动容器之前拉取镜像，这意味着需要有效的凭证。 +如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 Pod 都可以通过已了解到的镜像的名称 +（假设 Pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何鉴权检查。 +启用这个准入控制器之后，启动容器之前必须拉取镜像，这意味着需要有效的凭证。 -### CertificateApproval +### CertificateApproval {#certificateapproval} - -此准入控制器获取“审批” CertificateSigningRequest 资源的请求并执行额外的授权检查， -以确保审批请求的用户有权限审批 `spec.signerName` 请求 CertificateSigningRequest 资源的证书请求。 +此准入控制器获取“审批” CertificateSigningRequest 资源的请求并执行额外的鉴权检查， +以确保针对设置了 `spec.signerName` 的 CertificateSigningRequest 资源而言， +审批请求的用户有权限对证书请求执行 `approve` 操作。 +有关对 CertificateSigningRequest 资源执行不同操作所需权限的详细信息， +请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)。 -有关对证书签名请求资源执行不同操作所需权限的详细信息， -请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) - -### CertificateSigning +### CertificateSigning {#certificatesigning} -此准入控制器获取 CertificateSigningRequest 资源的 `status.certificate` 字段更新请求并执行额外的授权检查， -以确保签发证书的用户有权限为 `spec.signerName` 请求 CertificateSigningRequest 资源的证书请求`签发`证书。 +此准入控制器监视对 CertificateSigningRequest 资源的 `status.certificate` 字段的更新请求， +并执行额外的鉴权检查，以确保针对设置了 `spec.signerName` 的 CertificateSigningRequest 资源而言， +签发证书的用户有权限对证书请求执行 `sign` 操作。 -有关对证书签名请求资源执行不同操作所需权限的详细信息， -请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) +有关对 CertificateSigningRequest 资源执行不同操作所需权限的详细信息， +请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)。 ### CertificateSubjectRestrictions {#certificatesubjectrestrictions} @@ -253,9 +253,9 @@ This admission controller observes creation of CertificateSigningRequest resourc of `kubernetes.io/kube-apiserver-client`. It rejects any request that specifies a 'group' (or 'organization attribute') of `system:masters`. --> -此准入控制器获取具有 `kubernetes.io/kube-apiserver-client` 的 `spec.signerName` 的 -CertificateSigningRequest 资源创建请求， -它拒绝任何包含了 `system:masters` 一个“组”（或者“组织”）的请求。 +此准入控制器监视 `spec.signerName` 被设置为 `kubernetes.io/kube-apiserver-client` 的 +CertificateSigningRequest 资源创建请求，并拒绝所有将 “group”（或 “organization attribute”） +设置为 `system:masters` 的请求。 ### DefaultIngressClass {#defaultingressclass} @@ -265,8 +265,8 @@ ingress class and automatically adds a default ingress class to them. This way, request any special ingress class do not need to care about them at all and they will get the default one. --> -该准入控制器监测没有请求任何特定 Ingress 类的 `Ingress` 对象的创建，并自动向其添加默认 Ingress 类。 -这样，没有任何特殊 Ingress 类需求的用户根本不需要关心它们，它们将获得默认 Ingress 类。 +该准入控制器监测没有请求任何特定 Ingress 类的 `Ingress` 对象创建请求，并自动向其添加默认 Ingress 类。 +这样，没有任何特殊 Ingress 类需求的用户根本不需要关心它们，他们将被设置为默认 Ingress 类。 -当未配置默认 Ingress 类时，此准入控制器不执行任何操作。如果将多个 Ingress 类标记为默认 Ingress 类， -它将拒绝任何创建 `Ingress` 的操作，并显示错误。 -要修复此错误，管理员必须重新检查其 `IngressClass` 对象，并仅将其中一个标记为默认（通过注解 -"ingressclass.kubernetes.io/is-default-class"）。 -此准入控制器会忽略所有 `Ingress` 更新操作，仅响应创建操作。 +当未配置默认 Ingress 类时，此准入控制器不执行任何操作。如果有多个 Ingress 类被标记为默认 Ingress 类， +此控制器将拒绝所有创建 `Ingress` 的操作，并返回错误信息。 +要修复此错误，管理员必须重新检查其 `IngressClass` 对象，并仅将其中一个标记为默认 +（通过注解 "ingressclass.kubernetes.io/is-default-class"）。 +此准入控制器会忽略所有 `Ingress` 更新操作，仅处理创建操作。 关于 Ingress 类以及如何将 Ingress 类标记为默认的更多信息，请参见 -[ingress](/zh/docs/concepts/services-networking/ingress/)。 +[Ingress](/zh/docs/concepts/services-networking/ingress/) 页面。 ### DefaultStorageClass {#defaultstorageclass} @@ -296,9 +296,9 @@ and automatically adds a default storage class to them. This way, users that do not request any special storage class do not need to care about them at all and they will get the default one. --> -该准入控制器监测没有请求任何特定存储类的 `PersistentVolumeClaim` 对象的创建， +此准入控制器监测没有请求任何特定存储类的 `PersistentVolumeClaim` 对象的创建请求， 并自动向其添加默认存储类。 -这样，没有任何特殊存储类需求的用户根本不需要关心它们，它们将获得默认存储类。 +这样，没有任何特殊存储类需求的用户根本不需要关心它们，它们将被设置为使用默认存储类。 当未配置默认存储类时，此准入控制器不执行任何操作。如果将多个存储类标记为默认存储类， -它将拒绝任何创建 `PersistentVolumeClaim` 的操作，并显示错误。 -要修复此错误，管理员必须重新访问其 `StorageClass` 对象，并仅将其中一个标记为默认。 -此准入控制器会忽略所有 `PersistentVolumeClaim` 更新操作，仅响应创建操作。 +此控制器将拒绝所有创建 `PersistentVolumeClaim` 的请求，并返回错误信息。 +要修复此错误，管理员必须重新检查其 `StorageClass` 对象，并仅将其中一个标记为默认。 +此准入控制器会忽略所有 `PersistentVolumeClaim` 更新操作，仅处理创建操作。 -关于持久化卷和存储类，以及如何将存储类标记为默认，请参见 -[持久化卷](/zh/docs/concepts/storage/persistent-volumes/)。 +关于持久卷申领和存储类，以及如何将存储类标记为默认，请参见[持久卷](/zh/docs/concepts/storage/persistent-volumes/)页面。 ### DefaultTolerationSeconds {#defaulttolerationseconds} @@ -328,12 +327,13 @@ have toleration for taints `node.kubernetes.io/not-ready:NoExecute` or `node.kubernetes.io/unreachable:NoExecute`. The default value for `default-not-ready-toleration-seconds` and `default-unreachable-toleration-seconds` is 5 minutes. --> -该准入控制器基于 k8s-apiserver 输入参数 `default-not-ready-toleration-seconds` 和 +此准入控制器基于 k8s-apiserver 的输入参数 `default-not-ready-toleration-seconds` 和 `default-unreachable-toleration-seconds` 为 Pod 设置默认的容忍度，以容忍 `notready:NoExecute` 和 -`unreachable:NoExecute` 污点。 +`unreachable:NoExecute` 污点 （如果 Pod 尚未容忍 `node.kubernetes.io/not-ready：NoExecute` 和 -`node.kubernetes.io/unreachable：NoExecute` 污点的话） -`default-not-ready-toleration-seconds` 和 `default-unreachable-toleration-seconds` 的默认值是 5 分钟。 +`node.kubernetes.io/unreachable：NoExecute` 污点的话）。 +`default-not-ready-toleration-seconds` 和 `default-unreachable-toleration-seconds` +的默认值是 5 分钟。 ### DenyEscalatingExec {#denyescalatingexec} @@ -344,9 +344,9 @@ This admission controller will deny exec and attach commands to pods that run wi allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and have access to the host PID namespace. --> -该准入控制器将拒绝在由于拥有升级特权，而具备访问宿主机能力的 Pod 中执行 exec 和 -attach 命令。这包括在特权模式运行的 Pod，可以访问主机 IPC 名字空间的 Pod， -和访问主机 PID 名字空间的 Pod 。 +此准入控制器将拒绝在由于拥有提级特权而具备访问宿主机能力的 Pod 中执行 exec 和 +attach 命令。这类 Pod 包括在特权模式运行的 Pod、可以访问主机 IPC 名字空间的 Pod、 +和访问主机 PID 名字空间的 Pod。 -DenyExecOnPrivileged 准入插件已被废弃。 +DenyEscalatingExec 准入插件已被弃用。 建议使用基于策略的准入插件（例如 [PodSecurityPolicy](#podsecuritypolicy) 和自定义准入插件）， -该插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 +这类插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 ### DenyExecOnPrivileged {#denyexeconprivileged} @@ -367,14 +367,14 @@ DenyExecOnPrivileged 准入插件已被废弃。 -如果一个 pod 拥有一个特权容器，该准入控制器将拦截所有在该 pod 中执行 exec 命令的请求。 +如果一个 Pod 中存在特权容器，该准入控制器将拦截所有在该 Pod 中执行 exec 命令的请求。 此功能已合并至 [DenyEscalatingExec](#denyescalatingexec)。 -而 DenyExecOnPrivileged 准入插件已被废弃。 +而 DenyExecOnPrivileged 准入插件已被弃用。 建议使用基于策略的准入插件（例如 [PodSecurityPolicy](#podsecuritypolicy) 和自定义准入插件）， -该插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 +这类插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 -### DenyServiceExternalIPs +### DenyServiceExternalIPs {#denyserviceexternalips} -该准入控制器拒绝 `Service` 字段 `externalIPs` 的所有新规使用。 此功能非常强大（允许网络流量拦截）， -并且无法很好地受策略控制。 启用后，群集用户将无法创建使用 `externalIPs` 的新服务，也无法在现有 -`Service` 对象上向 `externalIPs` 添加新值。 `externalIPs` 的现有使用不受影响，用户可以从现有 -`Service` 对象上的 `externalIPs` 中删除值。 +此准入控制器拒绝新的 `Service` 中使用字段 `externalIPs`。 +此功能非常强大（允许网络流量拦截），并且无法很好地受策略控制。 +启用后，集群用户将无法创建使用 `externalIPs` 的新 `Service`，也无法在现有 +`Service` 对象上为 `externalIPs` 添加新值。 +`externalIPs` 的现有使用不受影响，用户可以在现有 `Service` 对象上从 +`externalIPs` 中删除值。 -大多数用户根本不需要此功能，集群管理员应考虑将其禁用。 -确实需要使用此功能的集群应考虑使用一些自定义策略来管理其的使用。 +大多数用户根本不需要此特性，集群管理员应考虑将其禁用。 +确实需要使用此特性的集群应考虑使用一些自定义策略来管理 `externalIPs` 的使用。 ### EventRateLimit {#eventratelimit} @@ -415,7 +417,7 @@ of it. This admission controller mitigates the problem where the API server gets flooded by event requests. The cluster admin can specify event rate limits by: --> -该准入控制器缓解了事件请求淹没 API 服务器的问题。集群管理员可以通过以下方式指定事件速率限制： +此准入控制器缓解了事件请求淹没 API 服务器的问题。集群管理员可以通过以下方式指定事件速率限制： * 启用 `EventRateLimit` 准入控制器； -* 从文件中引用 `EventRateLimit` 配置文件，并提供给 API 服务器命令的 - `--admission-control-config-file` 标志： +* 在通过 API 服务器的命令行标志 `--admission-control-config-file` 设置的文件中， + 引用 `EventRateLimit` 配置文件： -```yaml -apiVersion: apiserver.config.k8s.io/v1 -kind: AdmissionConfiguration -plugins: -- name: EventRateLimit - path: eventconfig.yaml -... -``` + ```yaml + apiVersion: apiserver.config.k8s.io/v1 + kind: AdmissionConfiguration + plugins: + - name: EventRateLimit + path: eventconfig.yaml + ... + ``` -可以在配置中指定四种类型的限制： +可以在配置中指定的限制有四种类型： * `Server`: API 服务器收到的所有事件请求共享一个桶。 -* `Namespace`: 每个名字空间都有一个专用的桶。 -* `User`: 给每个用户都分配一个桶。 -* `SourceAndObject`: 根据事件的源和涉及对象的每种组合分配桶。 +* `Namespace`: 每个名字空间都对应一个专用的桶。 +* `User`: 为每个用户分配一个桶。 +* `SourceAndObject`: 根据事件的来源和涉及对象的各种组合分配桶。 -下面是一个配置示例 `eventconfig.yaml`： +下面是一个针对此配置的 `eventconfig.yaml` 示例： ```yaml apiVersion: eventratelimit.admission.k8s.io/v1alpha1 kind: Configuration limits: -- type: Namespace - qps: 50 - burst: 100 - cacheSize: 2000 -- type: User - qps: 10 - burst: 50 + - type: Namespace + qps: 50 + burst: 100 + cacheSize: 2000 + - type: User + qps: 10 + burst: 50 ``` 详情请参见 -[EventRateLimit 配置文档（v1alpha1）](/zh/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)。 +[EventRateLimit 配置 API 文档（v1alpha1）](/zh/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)。 ### ExtendedResourceToleration {#extendedresourcetoleration} @@ -487,30 +489,29 @@ name as the key. This admission controller, if enabled, automatically adds tolerations for such taints to pods requesting extended resources, so users don't have to manually add these tolerations. --> -该插件有助于创建可扩展资源的专用节点。 -如果运营商想创建可扩展资源的专用节点（如 GPU、FPGA 等）， -那他们应该以扩展资源名称作为键名， +此插件有助于创建带有扩展资源的专用节点。 +如果运维人员想要创建带有扩展资源（如 GPU、FPGA 等）的专用节点，他们应该以扩展资源名称作为键名， [为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 -如果启用了该准入控制器，会将此类污点的容忍自动添加到请求扩展资源的 Pod 中， -用户不必再手动添加这些容忍。 +如果启用了此准入控制器，会将此类污点的容忍度自动添加到请求扩展资源的 Pod 中， +用户不必再手动添加这些容忍度。 ### ImagePolicyWebhook {#imagepolicywebhook} -ImagePolicyWebhook 准入控制器允许使用一个后端的 webhook 做出准入决策。 +ImagePolicyWebhook 准入控制器允许使用后端 Webhook 做出准入决策。 -#### 配置文件格式 +#### 配置文件格式 {#configuration-file-format} -ImagePolicyWebhook 使用配置文件来为后端行为设置配置选项。该文件可以是 JSON 或 YAML， +ImagePolicyWebhook 使用配置文件来为后端行为设置选项。该文件可以是 JSON 或 YAML， 并具有以下格式: ```yaml @@ -529,8 +530,8 @@ imagePolicy: -从文件中引用 ImagePolicyWebhook 的配置文件，并将其提供给 API 服务器命令标志 -`--admission-control-config-file`： +在通过命令行标志 `--admission-control-config-file` 为 API 服务器提供的文件中， +引用 ImagePolicyWebhook 配置文件： ```yaml apiVersion: apiserver.config.k8s.io/v1 @@ -544,7 +545,7 @@ plugins: -或者，你也可以直接将配置嵌入到文件中： +或者，你也可以直接将配置嵌入到该文件中： ```yaml apiVersion: apiserver.config.k8s.io/v1 @@ -568,14 +569,13 @@ It is required that the backend communicate over TLS. --> ImagePolicyWebhook 的配置文件必须引用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) -格式的文件；该文件设置了到后端的连接参数。 -要求后端使用 TLS 进行通信。 +格式的文件；该文件用来设置与后端的连接。要求后端使用 TLS 进行通信。 -kubeconfig 文件的 `cluster` 字段需要指向远端服务，user 字段需要包含已返回的授权者。 +kubeconfig 文件的 `clusters` 字段需要指向远端服务，`users` 字段需要包含已返回的授权者。 当面对一个准入决策时，API 服务器发送一个描述操作的 JSON 序列化的 `imagepolicy.k8s.io/v1alpha1` `ImageReview` 对象。 -该对象包含描述被审核容器的字段，以及所有匹配 `*.image-policy.k8s.io/*` 的 -Pod 注解。 +该对象包含描述被准入容器的字段，以及与 `*.image-policy.k8s.io/*` 匹配的所有 Pod 注解。 +{{ note }} -{{ note }} 注意，Webhook API 对象与其他 Kubernetes API 对象一样受制于相同的版本控制兼容性规则。 -实现者应该知道对 alpha 对象的更宽松的兼容性，并检查请求的 "apiVersion" 字段， +实现者应该知道对 alpha 对象兼容性是相对宽松的，并检查请求的 "apiVersion" 字段， 以确保正确的反序列化。 此外，API 服务器必须启用 `imagepolicy.k8s.io/v1alpha1` API 扩展组 （`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`）。 @@ -683,7 +682,7 @@ respond to either allow or disallow access. The response body's `spec` field is may be omitted. A permissive response would return: --> 远程服务将填充请求的 `ImageReviewStatus` 字段，并返回允许或不允许访问的响应。 -响应体的 `spec` 字段会被忽略，并且可以省略。一个允许访问应答会返回： +响应体的 `spec` 字段会被忽略，并且可以被省略。一个允许访问应答会返回： ```json { @@ -720,7 +719,7 @@ For further documentation refer to the -#### 使用注解进行扩展 +#### 使用注解进行扩展 {#extending-with-annotations} 一个 Pod 中匹配 `*.image-policy.k8s.io/*` 的注解都会被发送给 Webhook。 -这样做使得了解后端镜像策略的用户可以向它发送额外的信息，并为不同的后端实现 -接收不同的信息。 +这样做使得了解后端镜像策略的用户可以向它发送额外的信息， +并让不同的后端实现接收不同的信息。 -* 在紧急情况下，请求 "break glass" 覆盖一个策略。 -* 从一个记录了 break-glass 的请求的 ticket 系统得到的一个 ticket 号码。 -* 向策略服务器提供一个提示，用于提供镜像的 imageID，以方便它进行查找。 +* 在紧急情况下，请求破例覆盖某个策略。 +* 从一个记录了破例的请求的工单（Ticket）系统得到的一个工单号码。 +* 向策略服务器提供提示信息，用于提供镜像的 imageID，以方便它进行查找。 在任何情况下，注解都是由用户提供的，并不会被 Kubernetes 以任何方式进行验证。 -### LimitPodHardAntiAffinityTopology {#limitpodhardantiaffinitytopology} +### LimitPodHardAntiAffinityTopology {#limitpodhardantiaffinitytopology} -该准入控制器拒绝（定义了 `AntiAffinity` 拓扑键的）任何 Pod -（`requiredDuringSchedulingRequiredDuringExecution` 中的 -`kubernetes.io/hostname` 除外）。 +此准入控制器拒绝定义了 `AntiAffinity` 拓扑键的任何 Pod +（`requiredDuringSchedulingRequiredDuringExecution` 中的 `kubernetes.io/hostname` 除外）。 ### LimitRanger {#limitranger} @@ -771,13 +769,10 @@ enforce those constraints. LimitRanger can also be used to apply default resourc that don't specify any; currently, the default LimitRanger applies a 0.1 CPU requirement to all Pods in the `default` namespace. --> -该准入控制器会观察传入的请求，并确保它不会违反 `Namespace` 中 `LimitRange` -对象枚举的任何约束。 -如果你在 Kubernetes 部署中使用了 `LimitRange` 对象，则必须使用此准入控制器来 -执行这些约束。 -LimitRanger 还可以用于将默认资源请求应用到没有指定任何内容的 Pod； -当前，默认的 LimitRanger 对 `default` 名字空间中的所有 Pod 都应用了 -0.1 CPU 的需求。 +此准入控制器会监测传入的请求，并确保请求不会违反 `Namespace` 中 `LimitRange` 对象所设置的任何约束。 +如果你在 Kubernetes 部署中使用了 `LimitRange` 对象，则必须使用此准入控制器来执行这些约束。 +LimitRanger 还可以用于将默认资源请求应用到没有设定资源约束的 Pod； +当前，默认的 LimitRanger 对 `default` 名字空间中的所有 Pod 都设置 0.1 CPU 的需求。 请查看 -[limitRange 设计文档](/zh/docs/reference/kubernetes-api/policy-resources/limit-range-v1/) -和 [LimitRange 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -以了解更多细节。 +[limitRange API 文档](/zh/docs/reference/kubernetes-api/policy-resources/limit-range-v1/)和 +[LimitRange 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)以了解更多细节。 ### MutatingAdmissionWebhook {#mutatingadmissionwebhook} @@ -797,8 +791,8 @@ webhooks are called in serial; each one may modify the object if it desires. This admission controller (as implied by the name) only runs in the mutating phase. --> -该准入控制器调用任何与请求匹配的变更 Webhook。匹配的 Webhook 将被串行调用。 -每一个 Webhook 都可以根据需要修改对象。 +此准入控制器调用任何与请求匹配的变更（Mutating） Webhook。匹配的 Webhook 将被顺序调用。 +每一个 Webhook 都可以自由修改对象。 `MutatingAdmissionWebhook`，顾名思义，仅在变更阶段运行。 @@ -807,8 +801,8 @@ If a webhook called by this has side effects (for example, decrementing quota) i *must* have a reconciliation system, as it is not guaranteed that subsequent webhooks or validating admission controllers will permit the request to finish. --> -如果由此准入控制器调用的 Webhook 有副作用（如降低配额）， -则它 *必须* 具有协调系统，因为不能保证后续的 Webhook 和验证准入控制器都会允许完成请求。 +如果由此准入控制器调用的 Webhook 有副作用（如：减少配额）， +则它 **必须** 具有协调系统，因为不能保证后续的 Webhook 和验证准入控制器都会允许完成请求。 如果你禁用了 MutatingAdmissionWebhook，那么还必须使用 `--runtime-config` 标志禁止 `admissionregistration.k8s.io/v1` 组/版本中的 `MutatingWebhookConfiguration`， -这两个对象都是默认启用的。 +二者都是默认启用的。 -#### 谨慎编写和安装变更 webhook +#### 谨慎编写和安装变更 webhook {#use-caution-when-authoring-and-installing-mutating-webhooks} * 当用户尝试创建的对象与返回的对象不同时，用户可能会感到困惑。 -* 当它们回读的对象与尝试创建的对象不同，内建的控制环可能会出问题。 +* 当他们读回的对象与尝试创建的对象不同，内建的控制回路可能会出问题。 * 与覆盖原始请求中设置的字段相比，使用原始请求未设置的字段会引起问题的可能性较小。 - 应尽量避免前面那种方式。 -* 内建资源和第三方资源的控制回路未来可能会受到破坏性的更改，使现在运行良好的 Webhook - 无法再正常运行。即使完成了 Webhook API 安装，也不代表会为该 webhook 提供无限期的支持。 + 应尽量避免覆盖原始请求中的字段设置。 +* 内建资源和第三方资源的控制回路未来可能会出现破坏性的变更，使现在运行良好的 Webhook + 无法再正常运行。即使完成了 Webhook API 安装，也不代表该 Webhook 会被提供无限期的支持。 ### NamespaceAutoProvision {#namespaceautoprovision} @@ -852,9 +846,9 @@ It creates a namespace if it cannot be found. This admission controller is useful in deployments that do not want to restrict creation of a namespace prior to its usage. --> -该准入控制器会检查名字空间资源上的所有传入请求，并检查所引用的名字空间是否确实存在。 -如果找不到，它将创建一个名字空间。 -此准入控制器对于不想要求名字空间必须先创建后使用的集群部署中很有用。 +此准入控制器会检查针对名字空间域资源的所有传入请求，并检查所引用的名字空间是否确实存在。 +如果找不到所引用的名字空间，控制器将创建一个名字空间。 +此准入控制器对于不想要求名字空间必须先创建后使用的集群部署很有用。 ### NamespaceExists {#namespaceexists} @@ -862,7 +856,7 @@ a namespace prior to its usage. This admission controller checks all requests on namespaced resources other than `Namespace` itself. If the namespace referenced from a request doesn't exist, the request is rejected. --> -该准入控制器检查除 `Namespace` 以外的名字空间作用域资源上的所有请求。 +此准入控制器检查针对名字空间作用域的资源（除 `Namespace` 自身）的所有请求。 如果请求引用的名字空间不存在，则拒绝该请求。 ### NamespaceLifecycle {#namespacelifecycle} @@ -873,8 +867,8 @@ new objects created in it, and ensures that requests in a non-existent `Namespac This admission controller also prevents deletion of three system reserved namespaces `default`, `kube-system`, `kube-public`. --> -该准入控制器禁止在一个正在被终止的 `Namespace` 中创建新对象，并确保 -使用不存在的 `Namespace` 的请求被拒绝。 +该准入控制器禁止在一个正在被终止的 `Namespace` 中创建新对象，并确保针对不存在的 +`Namespace` 的请求被拒绝。 该准入控制器还会禁止删除三个系统保留的名字空间，即 `default`、 `kube-system` 和 `kube-public`。 @@ -883,7 +877,7 @@ A `Namespace` deletion kicks off a sequence of operations that remove all object etc.) in that namespace. In order to enforce integrity of that process, we strongly recommend running this admission controller. --> -删除 `Namespace` 会触发删除该名字空间中所有对象（Pod、Service 等）的一系列操作。 +`Namespace` 的删除操作会触发一系列删除该名字空间中所有对象（Pod、Service 等）的操作。 为了确保这个过程的完整性，我们强烈建议启用这个准入控制器。 ### NodeRestriction {#noderestriction} @@ -893,10 +887,10 @@ This admission controller limits the `Node` and `Pod` objects a kubelet can modi kubelets must use credentials in the `system:nodes` group, with a username in the form `system:node:`. Such kubelets will only be allowed to modify their own `Node` API object, and only modify `Pod` API objects that are bound to their node. --> -该准入控制器限制了 kubelet 可以修改的 `Node` 和 `Pod` 对象。 +该准入控制器限制了某 kubelet 可以修改的 `Node` 和 `Pod` 对象。 为了受到这个准入控制器的限制，kubelet 必须使用在 `system:nodes` 组中的凭证， 并使用 `system:node:` 形式的用户名。 -这样，kubelet 只可修改自己的 `Node` API 对象，只能修改绑定到节点本身的 Pod 对象。 +这样，kubelet 只可修改自己的 `Node` API 对象，只能修改绑定到自身节点的 Pod 对象。 -不允许 kubelet 在 `Node` API 对象上更新或删除污点。 +不允许 kubelet 更新或删除 `Node` API 对象的污点。 -`NodeRestriction` 准入插件可防止 kubelet 删除`Node` API 对象， -并对 `kubernetes.io/` 或 `k8s.io/` 前缀标签的 kubelet 强制进行如下修改： +`NodeRestriction` 准入插件可防止 kubelet 删除其 `Node` API 对象， +并对前缀为 `kubernetes.io/` 或 `k8s.io/` 的标签的修改对 kubelet 作如下限制： -* **防止** kubelet 添加/删除/更新带有 `node-restriction.kubernetes.io/` 前缀的标签。 - 保留此前缀的标签，供管理员用来标记 Node 对象以隔离工作负载，并且不允许 kubelet +* **禁止** kubelet 添加、删除或更新前缀为 `node-restriction.kubernetes.io/` 的标签。 + 这类前缀的标签时保留给管理员的，用以为 `Node` 对象设置标签以隔离工作负载，而不允许 kubelet 修改带有该前缀的标签。 -* **允许** kubelet 添加/删除/更新这些和这些前缀的标签： +* **允许** kubelet 添加、删除、更新以下标签： * `kubernetes.io/hostname` * `kubernetes.io/arch` * `kubernetes.io/os` * `beta.kubernetes.io/instance-type` * `node.kubernetes.io/instance-type` * `failure-domain.beta.kubernetes.io/region` （已弃用） - * `failure-domain.beta.kubernetes.io/zone` (已弃用） + * `failure-domain.beta.kubernetes.io/zone` （已弃用） * `topology.kubernetes.io/region` * `topology.kubernetes.io/zone` - * `kubelet.kubernetes.io/`-prefixed labels - * `node.kubernetes.io/`-prefixed labels + * `kubelet.kubernetes.io/` 为前缀的标签 + * `node.kubernetes.io/` 为前缀的标签 -kubelet 保留 `kubernetes.io` 或 `k8s.io` 前缀的所有标签，并且将来可能会被 +以 `kubernetes.io` 或 `k8s.io` 为前缀的所有其他标签都限制 kubelet 使用，并且将来可能会被 `NodeRestriction` 准入插件允许或禁止。 将来的版本可能会增加其他限制，以确保 kubelet 具有正常运行所需的最小权限集。 @@ -951,10 +946,10 @@ This admission controller also protects the access to `metadata.ownerReferences[ of an object, so that only users with "update" permission to the `finalizers` subresource of the referenced *owner* can change it. --> -该准入控制器保护对 `metadata.ownerReferences` 对象的访问，以便只有对该对象具有 -“删除” 权限的用户才能对其进行更改。 +此准入控制器保护对对象的 `metadata.ownerReferences` 的访问，以便只有对该对象具有 +“delete” 权限的用户才能对其进行更改。 该准入控制器还保护对 `metadata.ownerReferences[x].blockOwnerDeletion` 对象的访问， -以便只有对所引用的 **属主（owner）** 的 `finalizers` 子资源具有 “更新” +以便只有对所引用的 **属主（owner）** 的 `finalizers` 子资源具有 “update” 权限的用户才能对其进行更改。 ### PersistentVolumeClaimResize {#persistentvolumeclaimresize} @@ -965,7 +960,7 @@ subresource of the referenced *owner* can change it. This admission controller implements additional validations for checking incoming `PersistentVolumeClaim` resize requests. --> -该准入控制器检查传入的 `PersistentVolumeClaim` 调整大小请求，对其执行额外的验证操作。 +此准入控制器检查传入的 `PersistentVolumeClaim` 调整大小请求，对其执行额外的验证检查操作。 -建议启用 `PersistentVolumeClaimResize` 准入控制器。除非 PVC 的 `StorageClass` 明确地将 `allowVolumeExpansion` 设置为 -`true` 来显式启用调整大小。否则，默认情况下该准入控制器会阻止所有对 PVC 大小的调整。 +建议启用 `PersistentVolumeClaimResize` 准入控制器。除非 PVC 的 `StorageClass` 明确地将 +`allowVolumeExpansion` 设置为 `true` 来显式启用调整大小。 +否则，默认情况下该准入控制器会阻止所有对 PVC 大小的调整。 例如：由以下 `StorageClass` 创建的所有 `PersistentVolumeClaim` 都支持卷容量扩充： @@ -997,7 +993,7 @@ allowVolumeExpansion: true For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). --> 关于持久化卷申领的更多信息，请参见 -[PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 +[PersistentVolumeClaim](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 ### PersistentVolumeLabel {#persistentvolumelabel} @@ -1014,11 +1010,11 @@ a different zone. PersistentVolumeLabel is DEPRECATED and labeling persistent vo the {{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}. Starting from 1.11, this admission controller is disabled by default. --> -该准入控制器会自动将区（region）或区域（zone）标签附加到由云提供商（如 GCE、AWS） -定义的 PersistentVolume。这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。 +此准入控制器会自动将由云提供商（如 GCE、AWS）定义的区（region）或区域（zone） +标签附加到 PersistentVolume 上。这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。 如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签， 以防止 Pod 挂载其他区域的卷。 -PersistentVolumeLabel 已被废弃，标记持久卷已由 +PersistentVolumeLabel 已被弃用，为持久卷添加标签的操作已由 {{< glossary_tooltip text="云管理控制器" term_id="cloud-controller-manager" >}}接管。 从 1.11 开始，默认情况下禁用此准入控制器。 @@ -1030,8 +1026,7 @@ PersistentVolumeLabel 已被废弃，标记持久卷已由 This admission controller defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration. --> -该准入控制器通过读取名字空间注解和全局配置，来为名字空间中可以使用的节点选择器 -设置默认值并实施限制。 +此准入控制器通过读取名字空间注解和全局配置，来为名字空间中可以使用的节点选择器设置默认值并实施限制。 -#### 配置文件格式 +#### 配置文件格式 {#configuration-file-format-podnodeselector} -`PodNodeSelector` 使用配置文件来设置后端行为的选项。 -请注意，配置文件格式将在将来某个版本中改为版本化文件。 +`PodNodeSelector` 使用配置文件来设置后端行为的选项。请注意，配置文件格式将在将来某个版本中改为版本化文件。 该文件可以是 JSON 或 YAML，格式如下： ```yaml podNodeSelectorPluginConfig: - clusterDefaultNodeSelector: name-of-node-selector - namespace1: name-of-node-selector - namespace2: name-of-node-selector + clusterDefaultNodeSelector: name-of-node-selector + namespace1: name-of-node-selector + namespace2: name-of-node-selector ``` -基于提供给 API 服务器命令行标志 `--admission-control-config-file` 的文件名， -从文件中引用 `PodNodeSelector` 配置文件： +通过 API 服务器命令行标志 `--admission-control-config-file` 为 API 服务器提供的文件中， +需要引用 `PodNodeSelector` 配置文件： ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration plugins: -- name: PodNodeSelector - path: podnodeselector.yaml + - name: PodNodeSelector + path: podnodeselector.yaml ... ``` @@ -1075,10 +1069,10 @@ plugins: `PodNodeSelector` uses the annotation key `scheduler.alpha.kubernetes.io/node-selector` to assign node selectors to namespaces. --> -#### 配置注解格式 +#### 配置注解格式 {#configuration-annotation-format} -`PodNodeSelector` 使用键为 `scheduler.alpha.kubernetes.io/node-selector` 的注解 -为名字空间设置节点选择算符。 +`PodNodeSelector` 使用键为 `scheduler.alpha.kubernetes.io/node-selector` +的注解为名字空间设置节点选择算符。 ```yaml apiVersion: v1 @@ -1091,11 +1085,12 @@ metadata: -#### 内部行为 +#### 内部行为 {#internal-behavior} -该准入控制器行为如下： +此准入控制器行为如下： -这是下节已被废弃的 [PodSecurityPolicy](#podsecuritypolicy) 准入控制器的替代品。 -此准入控制器负责在创建和修改 Pod 时根据请求的安全上下文和 +这是下节所讨论的已被废弃的 [PodSecurityPolicy](#podsecuritypolicy) 准入控制器的替代品。 +此准入控制器负责在创建和修改 Pod 时，根据请求的安全上下文和 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) 来确定是否可以执行请求。 @@ -1160,7 +1155,7 @@ See also the [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) d for more information. --> 查看 [Pod 安全策略文档](/zh/docs/concepts/security/pod-security-policy/) -了解更多细节。 +进一步了解其间细节。 ### PodTolerationRestriction {#podtolerationrestriction} @@ -1174,18 +1169,19 @@ It then merges the tolerations annotated on the namespace into the tolerations o The resulting tolerations are checked against a list of allowed tolerations annotated to the namespace. If the check succeeds, the pod request is admitted otherwise it is rejected. --> -准入控制器 PodTolerationRestriction 检查 Pod 的容忍度与其名字空间的容忍度之间 -是否存在冲突。如果存在冲突，则拒绝 Pod 请求。 -然后，它将名字空间的容忍度合并到 Pod 的容忍度中，之后根据名字空间的容忍度 -白名单检查所得到的容忍度结果。如果检查成功，则将接受 Pod 请求，否则拒绝该请求。 +准入控制器 PodTolerationRestriction 检查 Pod 的容忍度与其名字空间的容忍度之间是否存在冲突。 +如果存在冲突，则拒绝 Pod 请求。 +控制器接下来会将名字空间的容忍度合并到 Pod 的容忍度中， +根据名字空间的容忍度白名单检查所得到的容忍度结果。 +如果检查成功，则将接受 Pod 请求，否则拒绝该请求。 -如果 Pod 的名字空间没有任何关联的默认容忍度或容忍度白名单，则使用集群级别的 -默认容忍度或容忍度白名单（如果有的话）。 +如果 Pod 的名字空间没有任何关联的默认容忍度或容忍度白名单， +则使用集群级别的默认容忍度或容忍度白名单（如果有的话）。 -名字空间的容忍度通过注解健 `scheduler.alpha.kubernetes.io/defaultTolerations` +名字空间的容忍度通过注解键 `scheduler.alpha.kubernetes.io/defaultTolerations` 来设置。可接受的容忍度可以通过 `scheduler.alpha.kubernetes.io/tolerationsWhitelist` 注解键来添加。 @@ -1229,16 +1225,15 @@ any of the constraints enumerated in the `ResourceQuota` object in a `Namespace` using `ResourceQuota` objects in your Kubernetes deployment, you MUST use this admission controller to enforce quota constraints. --> -该准入控制器会监测传入的请求，并确保它不违反任何一个 `Namespace` 中的 `ResourceQuota` -对象中枚举出来的约束。 -如果你在 Kubernetes 部署中使用了 `ResourceQuota`，你必须使用这个准入控制器来强制 -执行配额限制。 +此准入控制器会监测传入的请求，并确保它不违反任何一个 `Namespace` 中的 `ResourceQuota` +对象中列举的约束。如果你在 Kubernetes 部署中使用了 `ResourceQuota`， +则必须使用这个准入控制器来强制执行配额限制。 -请查看 +请参阅 [resourceQuota API 参考](/zh/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) 和 [Resource Quota 例子](/zh/docs/concepts/policy/resource-quotas/)了解更多细节。 @@ -1261,11 +1256,10 @@ for more information. --> ### RuntimeClass {#runtimeclass} -+{{< feature-state for_k8s_version="v1.20" state="stable" >}} +{{< feature-state for_k8s_version="v1.20" state="stable" >}} -如果你通过 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) -配置来定义一个 RuntimeClass，这个准入控制器会检查新的 Pod。 -当启用的时候，这个准入控制器会拒绝任何 overhead 字段已经设置的 Pod。 +如果你所定义的 RuntimeClass 包含 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)， +这个准入控制器会检查新的 Pod。被启用后，此准入控制器会拒绝所有已经设置了 overhead 字段的 Pod 创建请求。 对于配置了 RuntimeClass 并在其 `.spec` 中选定 RuntimeClass 的 Pod， 此准入控制器会根据相应 RuntimeClass 中定义的值为 Pod 设置 `.spec.overhead`。 @@ -1286,14 +1280,13 @@ then you could use this admission controller to restrict the set of values a sec See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for more context on restricting pod privileges. --> -该准入控制器将拒绝任何试图设置特定提升 +此准入控制器将拒绝任何试图设置特定提升 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) -字段的 Pod，正如任务 -[为 Pod 或 Container 配置安全上下文](/zh/docs/tasks/configure-pod-container/security-context/) -中所展示的那样。 -如果集群没有使用 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)、 -[PodSecurityPolicies](/zh/docs/concepts/security/pod-security-policy/)， -也没有任何外部执行机制，那么你可以使用此准入控制器来限制安全上下文所能获取的值集。 +中某些字段的 Pod，正如任务[为 Pod 或 Container 配置安全上下文](/zh/docs/tasks/configure-pod-container/security-context/) +中所展示的那样。如果集群没有使用 +[Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)、 +[PodSecurityPolicy](/zh/docs/concepts/security/pod-security-policy/)， +也没有任何外部强制机制，那么你可以使用此准入控制器来限制安全上下文所能获取的值集。 有关限制 Pod 权限的更多内容，请参阅 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)。 @@ -1311,7 +1304,7 @@ We strongly recommend using this admission controller if you intend to make use 的自动化。 如果你打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议你使用这个准入控制器。 -### StorageObjectInUseProtection +### StorageObjectInUseProtection {#storageobjectinuseprotection} `StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 -`kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC） -或持久化卷（PV）中。 -如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 -PVC/PV 不会被删除。 -有关更多详细信息，请参考 +`kubernetes.io/pv-protection` finalizers 添加到新创建的持久卷申领（PVC） +或持久卷（PV）中。如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers， +否则 PVC/PV 不会被删除。有关更多详细信息，请参考 [保护使用中的存储对象](/zh/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。 ### TaintNodesByCondition {#taintnodesbycondition} @@ -1340,10 +1331,9 @@ Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that to be scheduled on new Nodes before their taints were updated to accurately reflect their reported conditions. --> -该准入控制器为新创建的节点添加 `NotReady` 和 `NoSchedule` -{{< glossary_tooltip text="污点" term_id="taint" >}}。 -这些污点能够避免一些竞态条件的发生，这类静态条件可能导致 Pod 在更新节点污点以准确 -反映其所报告状况之前，就被调度到新节点上。 +该准入控制器为新创建的节点添加 `NotReady` 和 `NoSchedule` {{< glossary_tooltip text="污点" term_id="taint" >}}。 +这些污点能够避免一些竞态条件的发生，而这类竞态条件可能导致 Pod +在更新节点污点以准确反映其所报告状况之前，就被调度到新节点上。 ### ValidatingAdmissionWebhook {#validatingadmissionwebhook} @@ -1353,18 +1343,18 @@ webhooks are called in parallel; if any of them rejects the request, the request fails. This admission controller only runs in the validation phase; the webhooks it calls may not mutate the object, as opposed to the webhooks called by the `MutatingAdmissionWebhook` admission controller. --> -该准入控制器调用与请求匹配的所有验证 Webhook。 +此准入控制器调用与请求匹配的所有验证性 Webhook。 匹配的 Webhook 将被并行调用。如果其中任何一个拒绝请求，则整个请求将失败。 -该准入控制器仅在验证（Validating）阶段运行；与 `MutatingAdmissionWebhook` 准入控制器 -所调用的 Webhook 相反，它调用的 Webhook 应该不会使对象出现变更。 +该准入控制器仅在验证（Validating）阶段运行；与 `MutatingAdmissionWebhook` +准入控制器所调用的 Webhook 相反，它调用的 Webhook 不可以变更对象。 -如果以此方式调用的 Webhook 有其它作用（如，降低配额），则它必须具有协调机制。 -这是因为无法保证后续的 Webhook 或其他有效的准入控制器都允许请求完成。 +如果以此方式调用的 Webhook 有其它副作用（如：减少配额），则它必须具有协调机制。 +这是因为无法保证后续的 Webhook 或其他验证性准入控制器都允许请求完成。 如果你禁用了 ValidatingAdmissionWebhook，还必须通过 `--runtime-config` 标志来禁用 -`admissionregistration.k8s.io/v1` 组/版本中的 `ValidatingWebhookConfiguration` -对象（默认情况下在 1.9 版和更高版本中均处于启用状态）。 - +`admissionregistration.k8s.io/v1` 组/版本中的 `ValidatingWebhookConfiguration` +对象（默认情况下在 v1.9 和更高版本中均处于启用状态）。