Kubernetes 中的准入控制
此页面概述了*准入控制器*。
准入控制器是一段代码,它在资源持久化之前,但在请求被认证和授权之后,拦截对 Kubernetes API 服务器的请求。
Kubernetes 的几个重要特性需要启用准入控制器才能正确支持该特性。因此,一个没有配置正确的一组准入控制器的 Kubernetes API 服务器是不完整的服务器,它将不支持你期望的所有特性。
它们是什么?
准入控制器是 Kubernetes API 服务器中的代码,用于检查请求中到达的用于修改资源的数据。
准入控制器适用于创建、删除或修改对象的请求。准入控制器还可以阻止自定义谓词,例如通过 API 服务器代理连接到 Pod 的请求。准入控制器*不*(也不能)阻止读取(**get**、**watch** 或 **list**)对象的请求,因为读取会绕过准入控制层。
准入控制机制可以是*验证*、*修改*或两者兼而有之。修改控制器可能会修改正在修改的资源的数据;验证控制器则不能。
Kubernetes 1.32 中的准入控制器由下面列表组成,被编译到 kube-apiserver
二进制文件中,并且只能由集群管理员配置。
准入控制扩展点
在完整的列表中,有三个特殊的控制器:MutatingAdmissionWebhook、ValidatingAdmissionWebhook 和 ValidatingAdmissionPolicy。两个 webhook 控制器执行在 API 中配置的修改和验证(分别)准入控制 webhook。ValidatingAdmissionPolicy 提供了一种在 API 中嵌入声明式验证代码的方法,而无需依赖任何外部 HTTP 调用。
你可以使用这三个准入控制器在准入时自定义集群行为。
准入控制阶段
准入控制过程分两个阶段进行。在第一阶段,运行修改准入控制器。在第二阶段,运行验证准入控制器。再次注意,有些控制器两者兼而有之。
如果任何一个阶段的任何控制器拒绝请求,则整个请求将立即被拒绝,并将错误返回给最终用户。
最后,除了有时修改相关对象外,准入控制器有时可能会产生副作用,也就是说,在请求处理过程中修改相关资源。增加配额使用量是为什么必须这样做的规范示例。任何此类副作用都需要相应的回收或协调过程,因为给定的准入控制器不能确定给定的请求是否会通过所有其他准入控制器。
如何启用准入控制器?
Kubernetes API 服务器标志 enable-admission-plugins
接受一个逗号分隔的准入控制插件列表,在修改集群中的对象之前调用它们。例如,以下命令行启用 NamespaceLifecycle
和 LimitRanger
准入控制插件
kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...
注意
根据 Kubernetes 集群的部署方式和 API 服务器的启动方式,你可能需要以不同的方式应用这些设置。例如,如果 API 服务器作为 systemd 服务部署,你可能需要修改 systemd 单元文件,如果 Kubernetes 以自托管方式部署,你可能需要修改 API 服务器的清单文件。如何关闭准入控制器?
Kubernetes API 服务器标志 disable-admission-plugins
接受一个逗号分隔的要禁用的准入控制插件列表,即使它们在默认启用的插件列表中。
kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...
默认启用哪些插件?
要查看启用了哪些准入插件
kube-apiserver -h | grep enable-admission-plugins
在 Kubernetes 1.32 中,默认插件是
CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook
每个准入控制器做什么?
AlwaysAdmit
Kubernetes v1.13 [已弃用]
类型:验证。
此准入控制器允许所有 Pod 进入集群。它已被弃用,因为它的行为与根本没有准入控制器相同。
AlwaysDeny
Kubernetes v1.13 [已弃用]
类型:验证。
拒绝所有请求。AlwaysDeny 已被弃用,因为它没有实际意义。
AlwaysPullImages
类型:修改和验证。
此准入控制器修改每个新 Pod,以强制镜像拉取策略为 Always
。这在多租户集群中非常有用,这样用户可以确保他们的私有镜像只能由那些拥有拉取凭据的人使用。如果没有此准入控制器,一旦将镜像拉取到节点,任何用户的任何 Pod 都可以通过知道镜像的名称来使用它(假设 Pod 被调度到正确的节点上),而无需对镜像进行任何授权检查。启用此准入控制器后,始终在启动容器之前拉取镜像,这意味着需要有效的凭据。
CertificateApproval
类型:验证。
此准入控制器观察批准 CertificateSigningRequest 资源的请求,并执行额外的授权检查,以确保批准用户有权使用 CertificateSigningRequest 资源上请求的 spec.signerName
来批准证书请求。
有关对 CertificateSigningRequest 资源执行不同操作所需的权限的更多信息,请参阅证书签名请求。
CertificateSigning
类型:验证。
此准入控制器观察对 CertificateSigningRequest 资源的 status.certificate
字段的更新,并执行额外的授权检查,以确保签名用户有权使用 CertificateSigningRequest 资源上请求的 spec.signerName
来签名证书请求。
有关对 CertificateSigningRequest 资源执行不同操作所需的权限的更多信息,请参阅证书签名请求。
CertificateSubjectRestriction
类型:验证。
此准入控制器观察具有 kubernetes.io/kube-apiserver-client
的 spec.signerName
的 CertificateSigningRequest 资源的创建。它拒绝任何指定 system:masters
的“组”(或“组织属性”)的请求。
DefaultIngressClass
类型:修改。
此准入控制器观察创建的未请求任何特定入口类的 Ingress
对象,并自动将默认入口类添加到它们。这样,不请求任何特殊入口类的用户根本不需要关心它们,他们将获得默认的入口类。
当没有配置默认入口类时,此准入控制器不做任何事情。当多个入口类被标记为默认时,它会拒绝任何 Ingress
的创建并显示错误,并且管理员必须重新访问他们的 IngressClass
对象,并仅将一个标记为默认(使用注解 "ingressclass.kubernetes.io/is-default-class")。此准入控制器忽略任何 Ingress
更新;它仅在创建时起作用。
有关入口类以及如何将一个标记为默认的更多信息,请参阅入口文档。
DefaultStorageClass
类型:修改。
此准入控制器观察创建的未请求任何特定存储类的 PersistentVolumeClaim
对象,并自动将默认存储类添加到它们。这样,不请求任何特殊存储类的用户根本不需要关心它们,他们将获得默认的存储类。
当没有配置默认存储类时,此准入控制器不执行任何操作。当多个存储类被标记为默认时,它会拒绝创建任何 PersistentVolumeClaim
,并返回错误,管理员必须重新检查他们的 StorageClass
对象,并仅将其中一个标记为默认。此准入控制器忽略任何 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
Kubernetes v1.13 [alpha]
类型:验证。
此准入控制器缓解了 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 注释。
注意
Webhook API 对象与 Kubernetes 其他 API 对象一样,受相同的版本兼容性规则约束。实现者应注意 alpha 对象的宽松兼容性承诺,并检查请求的apiVersion
字段以确保正确的反序列化。此外,API 服务器必须启用 imagepolicy.k8s.io/v1alpha1
API 扩展组(--runtime-config=imagepolicy.k8s.io/v1alpha1=true
)。示例请求正文
{
"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
中定义 AntiAffinity
拓扑键(除了 kubernetes.io/hostname
之外)的 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、服务等)。为了强制执行该过程的完整性,我们强烈建议运行此准入控制器。
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
的访问,以便只有具有对象 delete 权限的用户才能更改它。 此准入控制器还保护对对象的 metadata.ownerReferences[x].blockOwnerDeletion
的访问,以便只有具有被引用所有者的 finalizers
子资源的 update 权限的用户才能更改它。
PersistentVolumeClaimResize
Kubernetes v1.24 [稳定版]
类型:验证。
此准入控制器实现了额外的验证,用于检查传入的 PersistentVolumeClaim
调整大小请求。
建议启用 PersistentVolumeClaimResize
准入控制器。 默认情况下,此准入控制器会阻止调整所有声明的大小,除非声明的 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
有关持久卷声明的更多信息,请参阅 持久卷声明。
PodNodeSelector
Kubernetes v1.5 [alpha]
类型:验证。
此准入控制器通过读取命名空间注释和全局配置来默认设置和限制命名空间内可以使用的节点选择器。
默认情况下,此准入控制器处于禁用状态。
配置文件格式
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
内部行为
此准入控制器具有以下行为
- 如果
Namespace
具有带有键scheduler.alpha.kubernetes.io/node-selector
的注释,则使用其值作为节点选择器。 - 如果命名空间缺少此类注释,则使用
PodNodeSelector
插件配置文件中定义的clusterDefaultNodeSelector
作为节点选择器。 - 针对命名空间节点选择器评估 Pod 的节点选择器是否存在冲突。冲突会导致拒绝。
- 针对插件配置文件中定义的特定于命名空间的允许选择器评估 Pod 的节点选择器。冲突会导致拒绝。
注意
PodNodeSelector
允许强制 Pod 在特定标记的节点上运行。另请参阅 PodTolerationRestriction
准入插件,该插件允许阻止 Pod 在特定污点的节点上运行。PodSecurity
Kubernetes v1.25 [稳定版]
类型:验证。
PodSecurity
准入控制器在允许新的 Pod 之前检查它们,根据请求的安全上下文以及 Pod 将要加入的命名空间的允许 Pod 安全标准的限制来确定是否应允许它。
有关更多信息,请参阅 Pod 安全准入文档。
PodSecurity
取代了名为 PodSecurityPolicy
的旧准入控制器。
PodTolerationRestriction
Kubernetes v1.7 [alpha]
类型:修改和验证。
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"}]'
默认情况下,此准入控制器处于禁用状态。
Priority
类型:修改和验证。
优先级准入控制器使用 priorityClassName
字段并填充优先级的整数值。如果找不到优先级类,则 Pod 将被拒绝。
ResourceQuota
类型:验证。
此准入控制器将观察传入的请求,并确保其不违反 Namespace
中 ResourceQuota
对象中列举的任何约束。如果在 Kubernetes 部署中使用 ResourceQuota
对象,则必须使用此准入控制器来强制执行配额约束。
有关更多详细信息,请参阅 ResourceQuota API 参考 和 资源配额示例。
RuntimeClass
类型:修改和验证。
如果使用 Pod 开销配置定义了 RuntimeClass
,则此准入控制器会检查传入的 Pod。启用后,此准入控制器将拒绝任何已设置开销的 Pod 创建请求。对于在其 .spec
中配置和选择了 RuntimeClass
的 Pod,此准入控制器将根据相应 RuntimeClass
中定义的值在 Pod 中设置 .spec.overhead
。
另请参阅 Pod 开销 以获取更多信息。
ServiceAccount
类型:修改和验证。
此准入控制器实现 serviceAccount 的自动化。Kubernetes 项目强烈建议启用此准入控制器。如果打算使用任何 Kubernetes ServiceAccount
对象,则应启用此准入控制器。
为了增强 Secret 周围的安全措施,请使用单独的命名空间来隔离对已挂载 Secret 的访问。
StorageObjectInUseProtection
类型:修改。
StorageObjectInUseProtection
插件将 kubernetes.io/pvc-protection
或 kubernetes.io/pv-protection
终结器添加到新创建的持久卷声明 (PVC) 或持久卷 (PV)。 如果用户删除 PVC 或 PV,则在 PVC 或 PV 保护控制器从 PVC 或 PV 中删除终结器之前,不会删除该 PVC 或 PV。 有关更详细的信息,请参阅 正在使用的存储对象保护。
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
标志启用默认集之外的其他准入控制器(顺序无关紧要)。