Kubernetes 中的准入控制

本页面提供了_准入控制器_的概览。

准入控制器是一段代码，它在资源持久化之前，但在请求经过身份验证和授权之后，拦截对 Kubernetes API 服务器的请求。

Kubernetes 的几个重要功能需要启用准入控制器才能正确支持这些功能。因此，没有正确配置相应准入控制器的 Kubernetes API 服务器是不完整的服务器，它将不支持你期望的所有功能。

它们是什么？

准入控制器是 Kubernetes API 服务器中的代码，用于检查修改资源请求中传入的数据。

准入控制器适用于创建、删除或修改对象的请求。准入控制器还可以阻止自定义动词，例如通过 API 服务器代理连接到 Pod 的请求。准入控制器_不会_（也无法）阻止读取（**get**、**watch** 或 **list**）对象的请求，因为读取绕过了准入控制层。

准入控制机制可以是_验证_、_修改_或两者兼有。修改型控制器可以修改正在修改资源的数据；验证型控制器则不能。

Kubernetes 1.34 中的准入控制器由以下列表组成，它们被编译到 `kube-apiserver` 二进制文件中，并且只能由集群管理员配置。

准入控制扩展点

在完整的列表中，有三个特殊的控制器：MutatingAdmissionWebhook、ValidatingAdmissionWebhook 和 ValidatingAdmissionPolicy。这两个 Webhook 控制器分别执行在 API 中配置的修改型和验证型准入控制 Webhook。ValidatingAdmissionPolicy 提供了一种在 API 中嵌入声明性验证代码的方法，而无需依赖任何外部 HTTP 调用。

你可以使用这三个准入控制器在准入时自定义集群行为。

准入控制阶段

准入控制过程分两个阶段进行。第一阶段运行修改型准入控制器。第二阶段运行验证型准入控制器。请再次注意，有些控制器两者兼有。

如果任何阶段中的任何控制器拒绝了请求，则整个请求将立即被拒绝，并向最终用户返回错误。

最后，除了有时会修改对象之外，准入控制器有时还可能产生副作用，即作为请求处理的一部分修改相关资源。增加配额使用量是说明这种必要性的典型例子。任何此类副作用都需要相应的回收或协调过程，因为给定的准入控制器不能确定给定请求将通过所有其他准入控制器。

这些调用的顺序如下所示。

为什么我需要它们？

Kubernetes 的几个重要功能需要启用准入控制器才能正确支持这些功能。因此，没有正确配置相应准入控制器的 Kubernetes API 服务器是不完整的服务器，它将不支持你期望的所有功能。

如何启用准入控制器？

Kubernetes API 服务器标志 `enable-admission-plugins` 接受一个逗号分隔的准入控制插件列表，以便在修改集群中的对象之前调用这些插件。例如，以下命令行启用了 `NamespaceLifecycle` 和 `LimitRanger` 准入控制插件。

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...

如何关闭准入控制器？

Kubernetes API 服务器标志 `disable-admission-plugins` 接受一个逗号分隔的准入控制插件列表，即使它们在默认启用的插件列表中，也会被禁用。

kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...

哪些插件默认启用？

要查看哪些准入插件已启用

kube-apiserver -h | grep enable-admission-plugins

在 Kubernetes 1.34 中，默认插件是

CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook

每个准入控制器有什么作用？

AlwaysAdmit

**类型**：验证型。

此准入控制器允许所有 Pod 进入集群。它已**弃用**，因为其行为与根本没有准入控制器相同。

AlwaysDeny

**类型**：验证型。

拒绝所有请求。AlwaysDeny 已**弃用**，因为它没有实际意义。

AlwaysPullImages

**类型**：修改型和验证型。

此准入控制器修改每个新的 Pod，强制其镜像拉取策略为 `Always`。这在多租户集群中很有用，这样用户就可以确保他们的私有镜像只能由拥有拉取凭据的人使用。如果没有此准入控制器，一旦镜像被拉取到节点上，任何用户创建的任何 Pod 都可以通过知道镜像名称（假设 Pod 被调度到正确的节点）来使用它，而无需对镜像进行任何授权检查。启用此准入控制器后，在启动容器之前总是会拉取镜像，这意味着需要有效的凭据。

CertificateApproval

**类型**：验证型。

此准入控制器观察批准 CertificateSigningRequest 资源的请求，并执行额外的授权检查，以确保批准用户拥有**批准** CertificateSigningRequest 资源上请求的 `spec.signerName` 证书请求的权限。

有关执行 CertificateSigningRequest 资源上的不同操作所需的权限的更多信息，请参阅证书签名请求。

CertificateSigning

**类型**：验证型。

此准入控制器观察对 CertificateSigningRequest 资源的 `status.certificate` 字段的更新，并执行额外的授权检查，以确保签名用户拥有**签名** CertificateSigningRequest 资源上请求的 `spec.signerName` 证书请求的权限。

有关执行 CertificateSigningRequest 资源上的不同操作所需的权限的更多信息，请参阅证书签名请求。

CertificateSubjectRestriction

**类型**：验证型。

此准入控制器观察创建 `spec.signerName` 为 `kubernetes.io/kube-apiserver-client` 的 CertificateSigningRequest 资源。它拒绝任何指定 `system:masters` '组'（或'组织属性'）的请求。

DefaultIngressClass

**类型**：修改型。

此准入控制器观察不请求任何特定 Ingress 类的 `Ingress` 对象的创建，并自动为其添加默认 Ingress 类。这样，不请求任何特殊 Ingress 类的用户无需关心它们，他们将获得默认的 Ingress 类。

当没有配置默认 Ingress 类时，此准入控制器不执行任何操作。当有多个 Ingress 类被标记为默认时，它会拒绝任何 `Ingress` 的创建并返回错误，管理员必须重新检查其 `IngressClass` 对象，并只将一个标记为默认（使用注解 "ingressclass.kubernetes.io/is-default-class"）。此准入控制器忽略任何 `Ingress` 更新；它仅在创建时起作用。

有关 Ingress 类以及如何将一个标记为默认的更多信息，请参阅Ingress 文档。

DefaultStorageClass

**类型**：修改型。

此准入控制器观察不请求任何特定存储类的 `PersistentVolumeClaim` 对象的创建，并自动为其添加默认存储类。这样，不请求任何特殊存储类的用户无需关心它们，他们将获得默认的存储类。

当不存在默认 `StorageClass` 时，此准入控制器不执行任何操作。当有多个存储类被标记为默认时，并且你创建一个没有设置 `storageClassName` 的 `PersistentVolumeClaim`，Kubernetes 会使用最近创建的默认 `StorageClass`。当创建一个指定了 `volumeName` 的 `PersistentVolumeClaim` 时，如果静态卷的 `storageClassName` 与应用了任何默认 StorageClass 后的 `PersistentVolumeClaim` 上的 `storageClassName` 不匹配，它将保持挂起状态。此准入控制器忽略任何 `PersistentVolumeClaim` 更新；它仅在创建时起作用。

有关持久卷声明和存储类以及如何将存储类标记为默认的更多信息，请参阅持久卷文档。

DefaultTolerationSeconds

**类型**：修改型。

如果 Pod 尚未对 `node.kubernetes.io/not-ready:NoExecute` 或 `node.kubernetes.io/unreachable:NoExecute` 污点设置容忍，此准入控制器根据 k8s-apiserver 输入参数 `default-not-ready-toleration-seconds` 和 `default-unreachable-toleration-seconds` 为 Pod 设置默认宽恕容忍，以容忍 `notready:NoExecute` 和 `unreachable:NoExecute` 污点。`default-not-ready-toleration-seconds` 和 `default-unreachable-toleration-seconds` 的默认值为 5 分钟。

DenyServiceExternalIPs

**类型**：验证型。

此准入控制器拒绝所有新增的 `Service` 字段 `externalIPs` 的使用。此功能非常强大（允许网络流量拦截），并且没有得到很好的策略控制。启用后，集群用户不得创建使用 `externalIPs` 的新 Service，也不得向现有 `Service` 对象上的 `externalIPs` 添加新值。现有 `externalIPs` 的使用不受影响，用户可以从现有 `Service` 对象上的 `externalIPs` 中删除值。

大多数用户根本不需要此功能，集群管理员应考虑禁用它。确实需要使用此功能的集群应考虑使用一些自定义策略来管理其使用。

此准入控制器默认禁用。

EventRateLimit

**类型**：验证型。

此准入控制器可缓解 API 服务器被大量存储新事件的请求淹没的问题。集群管理员可以通过以下方式指定事件速率限制：

• 启用 `EventRateLimit` 准入控制器；
• 从提供给 API 服务器命令行标志 `---admission-control-config-file` 的文件中引用 `EventRateLimit` 配置文件

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: EventRateLimit
    path: eventconfig.yaml
...

配置中可以指定四种类型的限制

• `Server`：API 服务器收到的所有事件请求（创建或修改）共享一个桶。
• `Namespace`：每个命名空间有一个专用的桶。
• `User`：每个用户分配一个桶。
• `SourceAndObject`：根据事件的来源和涉及对象的每个组合分配一个桶。

下面是一个此类配置的示例 `eventconfig.yaml`

apiVersion: eventratelimit.admission.k8s.io/v1alpha1
kind: Configuration
limits:
  - type: Namespace
    qps: 50
    burst: 100
    cacheSize: 2000
  - type: User
    qps: 10
    burst: 50

有关更多详细信息，请参阅EventRateLimit Config API (v1alpha1)。

此准入控制器默认禁用。

ExtendedResourceToleration

**类型**：修改型。

此插件有助于创建带有扩展资源的专用节点。如果操作员希望创建带有扩展资源（如 GPU、FPGA 等）的专用节点，他们应该将扩展资源名称作为键污点节点。如果启用此准入控制器，它会自动为请求扩展资源的 Pod 添加此类污点的容忍度，因此用户不必手动添加这些容忍度。

此准入控制器默认禁用。

ImagePolicyWebhook

**类型**：验证型。

ImagePolicyWebhook 准入控制器允许后端 Webhook 做出准入决策。

此准入控制器默认禁用。

配置文件格式

ImagePolicyWebhook 使用配置文件来设置后端行为的选项。此文件可以是 json 或 yaml 格式，具有以下结构：

imagePolicy:
  kubeConfigFile: /path/to/kubeconfig/for/backend
  # time in s to cache approval
  allowTTL: 50
  # time in s to cache denial
  denyTTL: 50
  # time in ms to wait between retries
  retryBackoff: 500
  # determines behavior if the webhook backend fails
  defaultAllow: true

从提供给 API 服务器命令行标志 `---admission-control-config-file` 的文件中引用 ImagePolicyWebhook 配置文件

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    path: imagepolicyconfig.yaml
...

或者，你可以直接将配置嵌入到文件中

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    configuration:
      imagePolicy:
        kubeConfigFile: <path-to-kubeconfig-file>
        allowTTL: 50
        denyTTL: 50
        retryBackoff: 500
        defaultAllow: true

ImagePolicyWebhook 配置文件必须引用一个kubeconfig 格式的文件，该文件用于设置与后端的连接。要求后端通过 TLS 进行通信。

kubeconfig 文件的 `cluster` 字段必须指向远程服务，`user` 字段必须包含返回的授权者。

# clusters refers to the remote service.
clusters:
  - name: name-of-remote-imagepolicy-service
    cluster:
      certificate-authority: /path/to/ca.pem    # CA for verifying the remote service.
      server: https://images.example.com/policy # URL of remote service to query. Must use 'https'.

# users refers to the API server's webhook configuration.
users:
  - name: name-of-api-server
    user:
      client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use
      client-key: /path/to/key.pem          # key matching the cert

有关其他 HTTP 配置，请参阅kubeconfig 文档。

请求负载

当面临准入决策时，API 服务器将 POST 一个 JSON 序列化的 `imagepolicy.k8s.io/v1alpha1` `ImageReview` 对象，描述该操作。此对象包含描述正在准入的容器以及匹配 `*.image-policy.k8s.io/*` 的任何 Pod 注解的字段。

一个示例请求正文

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "spec": {
    "containers": [
      {
        "image": "myrepo/myimage:v1"
      },
      {
        "image": "myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
      }
    ],
    "annotations": {
      "mycluster.image-policy.k8s.io/ticket-1234": "break-glass"
    },
    "namespace": "mynamespace"
  }
}

远程服务应填写请求的 `status` 字段并响应以允许或拒绝访问。响应正文的 `spec` 字段被忽略，可以省略。一个允许的响应将返回

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": true
  }
}

要拒绝访问，服务将返回

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": false,
    "reason": "image currently blacklisted"
  }
}

有关更多文档，请参阅`imagepolicy.v1alpha1` API。

使用注解进行扩展

Pod 上所有匹配 `*.image-policy.k8s.io/*` 的注解都将发送到 Webhook。发送注解允许了解镜像策略后端的用户向其发送额外信息，并允许不同的后端实现接受不同的信息。

你可能在此处放置的信息示例有

• 在紧急情况下，请求“打破常规”以覆盖策略。
• 记录“打破常规”请求的票务系统中的票号
• 向策略服务器提供关于所提供镜像的 imageID 的提示，以节省查找时间

在任何情况下，注解均由用户提供，Kubernetes 不会以任何方式验证。

LimitPodHardAntiAffinityTopology

**类型**：验证型。

此准入控制器拒绝在 `requiredDuringSchedulingRequiredDuringExecution` 中定义除 `kubernetes.io/hostname` 之外的 `AntiAffinity` 拓扑键的任何 Pod。

此准入控制器默认禁用。

LimitRanger

**类型**：修改型和验证型。

此准入控制器将观察传入请求，并确保其不违反 `Namespace` 中 `LimitRange` 对象枚举的任何约束。如果你在 Kubernetes 部署中使用 `LimitRange` 对象，则必须使用此准入控制器来强制执行这些约束。LimitRanger 还可以用于对未指定任何资源请求的 Pod 应用默认资源请求；目前，默认的 LimitRanger 将 0.1 CPU 要求应用于 `default` 命名空间中的所有 Pod。

有关更多详细信息，请参阅LimitRange API 参考和LimitRange 示例。

MutatingAdmissionWebhook

**类型**：修改型。

此准入控制器调用任何与请求匹配的修改型 Webhook。匹配的 Webhook 串行调用；每个 Webhook 都可以根据需要修改对象。

此准入控制器（顾名思义）仅在修改阶段运行。

如果此控制器调用的 Webhook 具有副作用（例如，减少配额），则它**必须**有一个协调系统，因为无法保证后续 Webhook 或验证准入控制器会允许请求完成。

如果你禁用 MutatingAdmissionWebhook，则还必须通过 `--runtime-config` 标志禁用 `admissionregistration.k8s.io/v1` 组/版本中的 `MutatingWebhookConfiguration` 对象，两者默认都是启用的。

编写和安装修改型 Webhook 时请谨慎

• 用户可能会对他们尝试创建的对象与实际获得的对象不同感到困惑。
• 内置控制循环可能会在他们尝试创建的对象在读回时发生变化时中断。
  • 设置最初未设置的字段比覆盖原始请求中设置的字段更不容易引起问题。避免后者。
• 未来对内置资源或第三方资源的控制循环的更改可能会破坏目前运行良好的 Webhook。即使 Webhook 安装 API 已最终确定，也并非所有可能的 Webhook 行为都能保证无限期地受到支持。

NamespaceAutoProvision

**类型**：修改型。

此准入控制器检查命名空间资源上的所有传入请求，并检查引用的命名空间是否存在。如果找不到，它将创建一个命名空间。此准入控制器在不希望在使用命名空间之前限制其创建的部署中很有用。

NamespaceExists

**类型**：验证型。

此准入控制器检查除 `Namespace` 本身之外的所有命名空间资源请求。如果请求中引用的命名空间不存在，则拒绝该请求。

NamespaceLifecycle

**类型**：验证型。

此准入控制器强制处于终止过程中的 `Namespace` 中不能创建新对象，并确保拒绝不存在 `Namespace` 的请求。此准入控制器还阻止删除三个系统保留的命名空间 `default`、`kube-system`、`kube-public`。

`Namespace` 删除会启动一系列操作，以删除该命名空间中的所有对象（Pod、Service 等）。为了强制执行此过程的完整性，我们强烈建议运行此准入控制器。

NodeRestriction

**类型**：验证型。

此准入控制器限制 kubelet 可以修改的 `Node` 和 `Pod` 对象。为了受此准入控制器限制，kubelet 必须使用 `system:nodes` 组中的凭据，用户名为 `system:node:<nodeName>` 形式。此类 kubelet 将只允许修改其自己的 `Node` API 对象，并且只修改绑定到其节点的 `Pod` API 对象。kubelet 不允许更新或删除其 `Node` API 对象中的污点。

`NodeRestriction` 准入插件阻止 kubelet 删除其 `Node` API 对象，并强制 kubelet 按如下方式修改 `kubernetes.io/` 或 `k8s.io/` 前缀下的标签：

• **阻止** kubelet 添加/删除/更新带有 `node-restriction.kubernetes.io/` 前缀的标签。此标签前缀保留给管理员用于对其 `Node` 对象进行工作负载隔离，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（已弃用）
  • topology.kubernetes.io/region
  • topology.kubernetes.io/zone
  • kubelet.kubernetes.io/ 前缀标签
  • node.kubernetes.io/ 前缀标签

kubelet 对 `kubernetes.io` 或 `k8s.io` 前缀下任何其他标签的使用均被保留，将来 `NodeRestriction` 准入插件可能会禁止或允许。

未来版本可能会增加额外的限制，以确保 kubelet 拥有正确操作所需的最小权限集。

OwnerReferencesPermissionEnforcement

**类型**：验证型。

此准入控制器保护对对象 `metadata.ownerReferences` 的访问，以便只有具有对象**删除**权限的用户才能更改它。此准入控制器还保护对对象 `metadata.ownerReferences[x].blockOwnerDeletion` 的访问，以便只有具有对引用**所有者**的 `finalizers` 子资源**更新**权限的用户才能更改它。

PersistentVolumeClaimResize

**类型**：验证型。

此准入控制器为检查传入的 `PersistentVolumeClaim` 扩容请求实现了额外的验证。

建议启用 `PersistentVolumeClaimResize` 准入控制器。默认情况下，此准入控制器会阻止所有 PVC 的扩容，除非 PVC 的 `StorageClass` 通过将 `allowVolumeExpansion` 设置为 `true` 显式启用扩容。

例如：从以下 `StorageClass` 创建的所有 `PersistentVolumeClaim` 都支持卷扩容

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-vol-default
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://192.168.10.100:8080"
  restuser: ""
  secretNamespace: ""
  secretName: ""
allowVolumeExpansion: true

有关持久卷声明的更多信息，请参阅PersistentVolumeClaims。

PodNodeSelector

**类型**：验证型。

此准入控制器通过读取命名空间注解和全局配置来默认并限制命名空间中可以使用哪些节点选择器。

此准入控制器默认禁用。

配置文件格式

`PodNodeSelector` 使用配置文件来设置后端行为的选项。请注意，配置文件格式将在未来版本中转换为版本化文件。此文件可以是 json 或 yaml 格式，具有以下结构：

podNodeSelectorPluginConfig:
  clusterDefaultNodeSelector: name-of-node-selector
  namespace1: name-of-node-selector
  namespace2: name-of-node-selector

从提供给 API 服务器命令行标志 `---admission-control-config-file` 的文件中引用 `PodNodeSelector` 配置文件

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodNodeSelector
  path: podnodeselector.yaml
...

配置注解格式

`PodNodeSelector` 使用注解键 `scheduler.alpha.kubernetes.io/node-selector` 为命名空间分配节点选择器。

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/node-selector: name-of-node-selector
  name: namespace3

内部行为

此准入控制器具有以下行为

1. 如果 `Namespace` 具有键为 `scheduler.alpha.kubernetes.io/node-selector` 的注解，则将其值用作节点选择器。
2. 如果命名空间缺少此类注解，则使用 `PodNodeSelector` 插件配置文件中定义的 `clusterDefaultNodeSelector` 作为节点选择器。
3. 评估 Pod 的节点选择器与命名空间节点选择器之间的冲突。冲突会导致拒绝。
4. 评估 Pod 的节点选择器与插件配置文件中定义的命名空间特定允许选择器之间的冲突。冲突会导致拒绝。

PodSecurity

**类型**：验证型。

PodSecurity 准入控制器在 Pod 被准入之前检查新 Pod，根据请求的安全上下文和 Pod 所在命名空间允许的Pod 安全标准限制来决定是否准入。

有关更多信息，请参阅Pod 安全准入文档。

PodSecurity 替换了旧的名为 PodSecurityPolicy 的准入控制器。

PodTolerationRestriction

**类型**：修改型和验证型。

PodTolerationRestriction 准入控制器验证 Pod 容忍度与其命名空间容忍度之间的任何冲突。如果存在冲突，则拒绝 Pod 请求。然后，它将命名空间上注解的容忍度合并到 Pod 的容忍度中。将结果容忍度与命名空间上注解的允许容忍度列表进行检查。如果检查成功，则准入 Pod 请求，否则拒绝。

如果 Pod 的命名空间没有关联的默认容忍度或允许的容忍度注解，则如果指定了集群级别的默认容忍度或集群级别的允许容忍度列表，则使用它们。

命名空间的容忍度通过 `scheduler.alpha.kubernetes.io/defaultTolerations` 注解键分配。允许的容忍度列表可以通过 `scheduler.alpha.kubernetes.io/tolerationsWhitelist` 注解键添加。

命名空间注解示例

apiVersion: v1
kind: Namespace
metadata:
  name: apps-that-need-nodes-exclusively
  annotations:
    scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'
    scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'

此准入控制器默认禁用。

PodTopologyLabels

**类型**：修改型

PodTopologyLabels 准入控制器会修改所有绑定到 Node 的 Pod 的 `pods/binding` 子资源，添加与绑定 Node 匹配的拓扑标签。这使得 Node 拓扑标签可以作为 Pod 标签提供，并通过Downward API 暴露给正在运行的容器。此控制器提供的标签是 topology.kubernetes.io/region 和 topology.kuberentes.io/zone 标签。

当启用 `PodTopologyLabelsAdmission` 特性门控时，此准入控制器被启用。

Priority

**类型**：修改型和验证型。

优先级准入控制器使用 `priorityClassName` 字段并填充优先级的整数值。如果未找到优先级类，则拒绝 Pod。

ResourceQuota

**类型**：验证型。

此准入控制器将观察传入请求，并确保其不违反 `Namespace` 中 `ResourceQuota` 对象枚举的任何约束。如果你在 Kubernetes 部署中使用 `ResourceQuota` 对象，则必须使用此准入控制器来强制执行配额约束。

有关更多详细信息，请参阅ResourceQuota API 参考和资源配额示例。

RuntimeClass

**类型**：修改型和验证型。

如果你定义了配置了Pod 开销的 RuntimeClass，此准入控制器将检查传入的 Pod。启用后，此准入控制器将拒绝任何已设置开销的 Pod 创建请求。对于在其 `.spec` 中配置并选择了 RuntimeClass 的 Pod，此准入控制器根据相应 RuntimeClass 中定义的值设置 Pod 中的 `.spec.overhead`。

另请参阅Pod 开销以获取更多信息。

ServiceAccount

**类型**：修改型和验证型。

此准入控制器实现了服务账户的自动化。Kubernetes 项目强烈建议启用此准入控制器。如果你打算使用 Kubernetes `ServiceAccount` 对象，则应启用此准入控制器。

为了增强 Secret 的安全措施，请使用单独的命名空间来隔离对挂载 Secret 的访问。

StorageObjectInUseProtection

**类型**：修改型。

`StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 `kubernetes.io/pv-protection` finalizers 添加到新创建的 Persistent Volume Claims (PVCs) 或 Persistent Volumes (PV)。如果用户删除了 PVC 或 PV，则在 PVC 或 PV 保护控制器从 PVC 或 PV 中移除 finalizer 之前，PVC 或 PV 不会被删除。有关详细信息，请参阅Storage Object in Use Protection。

TaintNodesByCondition

**类型**：修改型。

此准入控制器将新创建的节点污点为 `NotReady` 和 `NoSchedule`。这种污点避免了竞争条件，该条件可能导致 Pod 在其污点更新以准确反映其报告条件之前被调度到新节点上。

ValidatingAdmissionPolicy

**类型**：验证型。

此准入控制器为传入的匹配请求实现 CEL 验证。当特性门控 `validatingadmissionpolicy` 和 `admissionregistration.k8s.io/v1alpha1` 组/版本都启用时，它被启用。如果任何 ValidatingAdmissionPolicy 失败，则请求失败。

ValidatingAdmissionWebhook

**类型**：验证型。

此准入控制器调用任何与请求匹配的验证型 Webhook。匹配的 Webhook 并行调用；如果其中任何一个拒绝请求，则请求失败。此准入控制器仅在验证阶段运行；它调用的 Webhook 不能修改对象，这与 `MutatingAdmissionWebhook` 准入控制器调用的 Webhook 不同。

如果此控制器调用的 Webhook 具有副作用（例如，减少配额），则它**必须**有一个协调系统，因为无法保证后续 Webhook 或其他验证准入控制器会允许请求完成。

如果你禁用 ValidatingAdmissionWebhook，则还必须通过 `--runtime-config` 标志禁用 `admissionregistration.k8s.io/v1` 组/版本中的 `ValidatingWebhookConfiguration` 对象。

是否有推荐的准入控制器集？

是的。推荐的准入控制器默认启用（此处显示），因此你无需显式指定它们。你可以使用 `---enable-admission-plugins` 标志启用默认集之外的其他准入控制器（**顺序无关紧要**）。