Kubernetes 中的准入控制

本页概述了 准入控制器。

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

Kubernetes 的一些重要功能需要启用准入控制器才能正常工作。因此，如果 Kubernetes API 服务器未正确配置适当的准入控制器集，它将是一个不完整的服务器，无法支持你期望的所有功能。

它们是什么？

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

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

准入控制机制可以是**验证性的**（validating）、**变更性的**（mutating），或两者兼有。变更性控制器可以修改正在修改的资源的数据；验证性控制器则不能。

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

准入控制扩展点

在完整的列表中，有三个特殊的控制器：MutatingAdmissionWebhook、ValidatingAdmissionWebhook 和 ValidatingAdmissionPolicy。这两个 Webhook 控制器分别执行在 API 中配置的变更性（mutating）和验证性（validating）的准入控制 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.33 中，默认启用的插件是：

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

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

AlwaysAdmit

类型：验证性（Validating）。

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

AlwaysDeny

类型：验证性（Validating）。

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

AlwaysPullImages

类型：变更性（Mutating）和验证性（Validating）。

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

CertificateApproval

类型：验证性（Validating）。

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

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

CertificateSigning

类型：验证性（Validating）。

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

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

CertificateSubjectRestriction

类型：验证性（Validating）。

此准入控制器观察具有 spec.signerName 为 kubernetes.io/kube-apiserver-client 的 CertificateSigningRequest 资源的创建。它拒绝任何指定了 system:masters 'group'（或 'organization attribute'）的请求。

DefaultIngressClass

类型：变更性（Mutating）。

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

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

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

DefaultStorageClass

类型：变更性（Mutating）。

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

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

有关 PersistentVolumeClaim 和 Storage Class 以及如何将 Storage Class 标记为默认的更多信息，请参阅持久卷文档。

DefaultTolerationSeconds

类型：变更性（Mutating）。

此准入控制器根据 k8s-apiserver 输入参数 default-not-ready-toleration-seconds 和 default-unreachable-toleration-seconds，为 Pod 设置默认的宽恕容忍度（forgiveness toleration），使其能够容忍 notready: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 分钟。

DenyServiceExternalIPs

类型：验证性（Validating）。

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

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

此准入控制器默认是禁用的。

EventRateLimit

类型：验证性（Validating）。

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

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

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

可以在配置中指定的限速类型有四种：

• Server：API 服务器接收到的所有 Event 请求（创建或修改）共享一个单独的桶。
• Namespace：每个 Namespace 都有一个专用的桶。
• User：为每个用户分配一个桶。
• SourceAndObject：根据 Event 的 source 和 involved object 的每种组合分配一个桶。

下面是此类配置的示例 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 配置 API (v1alpha1)。

此准入控制器默认是禁用的。

ExtendedResourceToleration

类型：变更性（Mutating）。

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

此准入控制器默认是禁用的。

ImagePolicyWebhook

类型：验证性（Validating）。

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。发送注解允许了解镜像策略后端的用户向其发送额外信息，并且不同的后端实现可以接受不同的信息。

你可以在此处放入的信息示例包括：

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

在任何情况下，这些注解都由用户提供，Kubernetes 不会对其进行任何验证。

LimitPodHardAntiAffinityTopology

类型：验证性（Validating）。

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

此准入控制器默认是禁用的。

LimitRanger

类型：变更性（Mutating）和验证性（Validating）。

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

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

MutatingAdmissionWebhook

类型：变更性（Mutating）。

此准入控制器调用与请求匹配的任何变更性 Webhook。匹配的 Webhook 按顺序调用；每个都可以根据需要修改对象。

此准入控制器（顾名思义）只在变更阶段运行。

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

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

编写和安装变更性 Webhook 时请谨慎

• 用户可能会对其尝试创建的对象与实际返回的对象不同感到困惑。
• 内建的控制回路（control loops）在读回其尝试创建的对象时发现不同，可能会导致故障。
  • 设置最初未设置的字段比覆盖原始请求中已设置的字段更不可能导致问题。请避免后者。
• 对内建资源或第三方资源的控制回路的未来变更可能会破坏今天工作正常的 Webhook。即使 Webhook 安装 API 最终确定，也不能保证所有可能的 Webhook 行为都会得到无限期的支持。

NamespaceAutoProvision

类型：变更性（Mutating）。

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

NamespaceExists

类型：验证性（Validating）。

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

NamespaceLifecycle

类型：验证性（Validating）。

此准入控制器强制执行以下规定：正在终止的 Namespace 中不能创建新对象，并确保拒绝对不存在的 Namespace 的请求。此准入控制器还阻止删除三个系统保留的命名空间：default、kube-system、kube-public。

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

NodeRestriction

类型：验证性（Validating）。

此准入控制器限制 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

类型：验证性（Validating）。

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

PersistentVolumeClaimResize

类型：验证性（Validating）。

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

建议启用 PersistentVolumeClaimResize 准入控制器。此准入控制器默认阻止所有 PersistentVolumeClaim 的扩容，除非 PersistentVolumeClaim 的 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

有关 PersistentVolumeClaim 的更多信息，请参阅PersistentVolumeClaims。

PodNodeSelector

类型：验证性（Validating）。

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

此准入控制器默认是禁用的。

配置文件格式

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

类型：验证性（Validating）。

PodSecurity 准入控制器在新的 Pod 被准入之前对其进行检查，并根据所请求的安全上下文以及 Pod 所在名字空间上允许的 Pod 安全标准的限制来决定是否应准入该 Pod。

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

PodSecurity 取代了旧的名为 PodSecurityPolicy 的准入控制器。

PodTolerationRestriction

类型：变更性（Mutating）和验证性（Validating）。

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

类型: 变更（Mutating）

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

{{ }} 如果任何变更准入 Webhook 添加或修改了 pods/binding 子资源的标签，这些更改将通过此控制器传播到 Pod 标签，覆盖具有冲突键的标签。 {{}}

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

Priority

类型：变更性（Mutating）和验证性（Validating）。

Priority 准入控制器使用 priorityClassName 字段并填充优先级整数值。如果找不到优先级类（priority class），则 Pod 被拒绝。

ResourceQuota

类型：验证性（Validating）。

此准入控制器会观察传入的请求，并确保它不违反名字空间中的 ResourceQuota 对象中列出的任何约束。如果在 Kubernetes 部署中使用了 ResourceQuota 对象，则必须使用此准入控制器来强制执行配额约束。

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

RuntimeClass

类型：变更性（Mutating）和验证性（Validating）。

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

另请参阅 Pod 开销以了解更多信息。

ServiceAccount

类型：变更性（Mutating）和验证性（Validating）。

此准入控制器实现了服务账号（ServiceAccount）的自动化。Kubernetes 项目强烈建议启用此准入控制器。如果您打算使用任何 Kubernetes 的 ServiceAccount 对象，则应该启用此准入控制器。

为了增强 Secret 相关的安全措施，使用独立的名字空间来隔离对挂载的 Secret 的访问。

StorageObjectInUseProtection

类型：变更性（Mutating）。

StorageObjectInUseProtection 插件会向新创建的持久卷申领（Persistent Volume Claims, PVCs）或持久卷（Persistent Volumes, PVs）添加 kubernetes.io/pvc-protection 或 kubernetes.io/pv-protection finalizers。如果用户删除 PVC 或 PV，除非 PVC 或 PV 保护控制器从 PVC 或 PV 中移除 finalizer，否则 PVC 或 PV 不会被删除。有关更详细的信息，请参阅使用中的存储对象保护。

TaintNodesByCondition

类型：变更性（Mutating）。

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

ValidatingAdmissionPolicy

类型：验证性（Validating）。

此准入控制器实现了对匹配的传入请求进行 CEL 校验。当同时启用特性门 validatingadmissionpolicy 和 API 组/版本 admissionregistration.k8s.io/v1alpha1 时，此控制器被启用。如果任何 ValidatingAdmissionPolicy 校验失败，则请求失败。

ValidatingAdmissionWebhook

类型：验证性（Validating）。

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

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

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

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

是的。推荐的准入控制器默认启用（此处列出），因此您无需显式指定它们。可以使用 --enable-admission-plugins 标志启用默认集合之外的其他准入控制器（顺序不重要）。