深入理解 Kubernetes 准入控制器（Admission Controller）：从插件清单到生产级配置实践

深入理解 Kubernetes 准入控制器Admission Controller从插件清单到生产级配置实践【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook导读准入控制器Admission Controller是 Kubernetes API Server 请求链路中位于对象持久化之前的最后一道拦截关卡负责在请求通过认证与授权之后、写入 etcd 之前对资源对象执行强制校验或就地修改。它是实现资源配额、安全策略、默认值注入、Webhook 扩展等能力的基础设施。本文以 concepts/admission-controller.md 为骨架结合本仓库中真实的 kube-apiserver 配置etc/kubernetes/apiserver与部署实践practice/master-installation.md完整梳理准入控制器的类型划分、全部内置插件清单、不同版本下的推荐配置以及 PodPreset、RBAC、Istio Sidecar 注入等典型应用场景帮助你在集群规划与安全加固时做出正确取舍。一、准入控制器是什么准入控制器位于 API Server 内部在对象被持久化之前拦截对 API Server 的请求。它的拦截时机处于整个请求处理链的末端请求先经过 TLS 认证Authentication与 RBAC 授权Authorization随后才进入准入阶段最后才会被写入 etcd 完成持久化。准入控制器通常用来做两类事情身份验证和授权即验证“谁在请求”认证与“允许做什么”授权——不过认证与授权通常由独立的认证器与授权器完成准入控制器更多承担其后的策略校验与对象改写对象变更与校验在资源真正落地前修改或拒绝不合规的请求。用一句话概括其定位准入控制器是 Kubernetes 对 API 请求进行最后把关的可插拔策略层。一旦你修改了准入控制器集合就等于修改了整个集群对 API 请求的接受标准。两种类型变更Mutating与验证Validating准入控制器分为以下两种变更Mutating准入控制修改请求的对象。典型代表如ServiceAccount自动填充 serviceAccountName、DefaultStorageClass自动补充存储类、MutatingAdmissionWebhook验证Validating准入控制验证请求的对象。典型代表如ResourceQuota校验配额是否超限、LimitRanger校验资源请求是否在 LimitRange 范围内、ValidatingAdmissionWebhook。需要注意一个准入控制器可能属于以上两种中的一种也可能两者都属于例如ServiceAccount既会填充字段也会校验引用是否存在。当请求到达 API Server 时执行顺序是固定的首先执行所有**变更Mutating**准入控制然后再执行所有**验证Validating**准入控制。之所以先变更后验证是因为验证阶段需要基于变更后的最终对象形态做检查——例如ResourceQuota只有在MutatingAdmissionWebhook完成默认值注入、DefaultStorageClass完成存储类填充之后执行才能正确计算资源总量。二、准入控制器的配置方式准入控制器是在API Server 的启动参数中配置的。历史上经历了两个阶段的参数演进参数适用版本说明--admission-controlKubernetes 1.9 及更早版本旧参数顺序敏感按给定顺序依次执行--enable-admission-pluginsKubernetes 1.10 及以上新参数顺序无关插件按固定逻辑顺序执行注意--admission-control在 Kubernetes 1.10 中已弃用被替换为--enable-admission-plugins。仓库中的真实配置样例本仓库的 kube-apiserver 配置文件中给出了一个实际可用的准入控制器组合etc/kubernetes/apiserver## default admission control policies KUBE_ADMISSION_CONTROL--admission-controlServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota对应的部署实践文档 practice/master-installation.md 也做了相同的强调默认准入控制策略配置在KUBE_ADMISSION_CONTROL环境变量中并特别指出--admission-control值必须包含ServiceAccount——因为 Kubernetes 的 Pod 运行离不开 ServiceAccount 的自动化注入。在将该环境变量传入kube-apiserver的 systemd 单元systemd/kube-apiserver.service中通过EnvironmentFile-/etc/kubernetes/apiserver加载最终由ExecStart中的$KUBE_ADMISSION_CONTROL展开为完整的启动参数。重要提示不要随意去掉准入控制器。我们在部署 Kubernetes 集群的时候都会默认开启一系列准入控制器如果没有设置这些准入控制器的话可以说你的 Kubernetes 集群就是在裸奔。准入控制器集合只应该由集群管理员修改普通用户无权变更。三、Kubernetes 支持的准入控制器全景清单以下是 Kubernetes 目前支持的准入控制器及其作用基于 concepts/admission-controller.md 完整整理按字母序准入控制器类型核心作用AlwaysPullImages变更修改每个 Pod 时强制重新拉取镜像imagePullPolicy: Always防止节点上缓存旧镜像被复用DefaultStorageClass变更观察创建PersistentVolumeClaim时未请求任何特定存储类的对象自动为其添加默认存储类用户无需感知即可获得默认存储类DefaultTolerationSeconds变更将 Pod 对notready:NoExecute和unreachable:NoExecute的容忍时间默认设置为 5 分钟DenyEscalatingExec验证拒绝exec和附加命令到以允许访问宿主机的升级权限运行的 PodEventRateLimit (alpha)验证缓解 API Server 被事件请求淹没的问题限制事件写入的时间速率ExtendedResourceToleration变更有助于创建具有扩展资源的专用节点自动为使用扩展资源的 Pod 添加容忍ImagePolicyWebhook验证允许后端Webhook 服务判断镜像拉取策略例如基于镜像仓库的密钥/白名单做决策Initializers (alpha)变更Pod 初始化的准入控制器Kubernetes 早期“动态准入控制”的一部分后逐步被 admission webhook 取代LimitPodHardAntiAffinityTopology验证拒绝任何在requiredDuringSchedulingRequiredDuringExecution的AntiAffinity字段中定义除kubernetes.io/hostname之外拓扑关键字的 PodLimitRanger验证确保所有资源请求request/limit不会超过 namespace 的LimitRange对象所定义的约束MutatingAdmissionWebhook1.9 版本中为 beta变更调用与请求匹配的任何变更 Webhook。匹配的 Webhook串行调用如果需要每个 Webhook 都可以修改对象NamespaceAutoProvision变更检查命名空间资源上的所有传入请求若引用的命名空间不存在则自动创建一个命名空间NamespaceExists验证检查除Namespace自身之外的所有命名空间资源上的请求若请求引用的命名空间不存在则拒绝该请求NamespaceLifecycle验证强制执行正在终止的命名空间中不能创建新对象确保拒绝引用不存在命名空间的请求防止删除三个系统保留命名空间default、kube-system、kube-publicNodeRestriction验证限制 kubelet 可以修改的Node和Pod对象防止 kubelet 越权详见下文 RBAC 小节OwnerReferencesPermissionEnforcement验证保护对metadata.ownerReferences对象的访问只有对该对象具有“删除”权限的用户才能更改其 owner 引用PodNodeSelector验证通过读取命名空间注释和全局配置限制命名空间内可使用的节点选择器PodPreset变更向匹配 PodPreset 的 Pod 注入 secret、volume、volume mount 和环境变量等字段PodSecurityPolicy验证对创建和修改 Pod 的请求根据请求的安全上下文与可用的 Pod 安全策略判断是否允许执行PodTolerationRestriction验证验证容器的容忍度与其命名空间的容忍度之间是否存在冲突存在冲突时拒绝该容器请求Priority变更使用priorityClassName字段并填充优先级的整数值如果找不到对应的优先级类则拒绝 PodResourceQuota验证观察传入请求确保它不违反命名空间ResourceQuota对象中列举的任何约束SecurityContextDeny验证拒绝任何试图设置某些升级权限的SecurityContext字段的 Pod被 PodSecurityPolicy 取代ServiceAccount两者兼具实现 ServiceAccount 的自动化默认填充defaultServiceAccount、校验 serviceAccountName 引用StorageObjectInUseProtection变更将kubernetes.io/pvc-protection或kubernetes.io/pv-protection终结器添加到新创建的 PVC 或 PV用户删除 PVC/PV 时对象不会被移除直到保护控制器移除终结器存储对象使用中保护ValidatingAdmissionWebhook1.8 版本中为 alpha1.9 版本中为 beta验证调用与请求匹配的任何验证 Webhook。匹配的 Webhook并行调用如果其中任何一个拒绝请求则整个请求失败从源码与文档佐证几个关键插件1. NodeRestriction 与 RBAC 的配合。在 concepts/rbac.md 中提到自 Kubernetes 1.7 开始相比直接授予 kubelet 访问权限更推荐使用 Node authorizer 与NodeRestrictionadmission plugin 的组合允许根据调度运行在节点上的 Pod 授予 kubelet 的 API 访问权限当启用Node授权模式时对system:nodes用户组的绑定将不会被自动创建。这说明 NodeRestriction 是“最小权限”安全模型的关键一环。2. PodPreset 的完整工作流。在 concepts/pod-preset.md 中可以看到 PodPreset 准入控制器的详细执行流程检索所有可用的PodPresets检查 PodPreset 标签选择器是否匹配正在创建的 Pod 上的标签尝试将由 PodPreset 定义的各种资源合并到正在创建的 Pod 中出现错误时在该 Pod 上引发记录合并错误的事件PodPreset不会注入任何资源到创建的 Pod 中注释刚生成的修改过的 Pod spec格式为podpreset.admission.kubernetes.io/podpreset-pod-preset name: resource version。启用 PodPreset 需要同时满足三个条件启用settings.k8s.io/v1alpha1/podpresetAPI 类型在 API Server 的--runtime-config中加settings.k8s.io/v1alpha1true、启用PodPreset准入控制器、在目标命名空间创建PodPreset对象。这一示例直观展示了准入控制器 集群级默认值注入钩子的典型用法。3. MutatingAdmissionWebhook 在生产中的典型落地——Istio Sidecar 注入。准入 Webhook 是动态准入控制的核心。本仓库中 Istio 相关实践文档usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md明确指出基于 Kubernetes 的 mutating webhook 准入控制器的自动 sidecar 注入方式是 Istio 服务网格向业务 Pod 注入 Envoy sidecar 的标准机制。同时 practice/openkruise.md 也印证了 OpenKruise 的SidecarSet同样利用了 mutating webhook 准入控制器在 Pod 创建时自动注入 sidecar 容器与 Istio 做法一致。而 Kubernetes 1.7 变更日志appendix/kubernetes-1.7-changelog.md则记录了外部准入控制器extensible admission controllers从 Alpha 引入的历史它提供了两个选项用于向 API Server 添加自定义业务逻辑以便在创建对象和验证策略时对其进行修改。四、各版本推荐配置准入控制器的启用集合与集群版本强相关。以下推荐配置完整继承自 concepts/admission-controller.md 的推荐配置章节。Kubernetes 1.10推荐对于 Kubernetes 1.10 及更高版本建议使用--enable-admission-plugins标志运行以下一组准入控制器顺序无关紧要--enable-admission-pluginsNamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuotaKubernetes 1.9顺序敏感对于 Kubernetes 1.9 及更早版本建议使用--admission-control标志顺序有关运行以下一组准入控制器--admission-controlNamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota值得重申的是在 1.9 中这些控制器分布在变更阶段和验证阶段。例如ResourceQuota在验证阶段运行因此是运行的最后一个准入控制器MutatingAdmissionWebhook在此列表中出现在它之前因为它在变更阶段运行。更早版本1.6 - 1.8对于更早期版本没有验证准入控制器和变更准入控制器的概念准入控制器以指定的确切顺序运行--admission-controlNamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds推荐配置的核心含义NamespaceLifecycle守住命名空间生命周期底线防止在终止中的命名空间建对象、防止删除系统保留命名空间LimitRanger ResourceQuota一内一外两道资源防线——LimitRange 约束单 Pod 的资源范围ResourceQuota 约束命名空间整体配额ServiceAccountPod 运行的基本前提缺失则 Pod 无法正常获取身份DefaultStorageClass DefaultTolerationSeconds提供开箱即用的默认值注入降低用户心智负担MutatingAdmissionWebhook ValidatingAdmissionWebhook打开动态准入扩展能力供 Istio、OpenKruise 等生态组件挂载自定义逻辑。对比本仓库 etc/kubernetes/apiserver 中的实际生产配置ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota可以看到该示例集群因版本较早仍使用--admission-control参数且未开启两个 Webhook 插件但ServiceAccount、NamespaceLifecycle、LimitRanger、ResourceQuota这些基础防线被完整保留——这也印证了官方推荐配置中安全底线插件不可缺失的设计思想。五、使用准入控制器时的实践要点配置入口唯一所有准入控制器只能通过 kube-apiserver 启动参数修改且修改后需要重启 kube-apiserver 生效。多 master 高可用部署如 practice/master-ha.md 所述时务必保证各 apiserver 节点的准入配置一致。区分版本语义1.10 之前--admission-control是顺序敏感的插件的排列顺序会直接影响执行结果1.10 之后改用--enable-admission-plugins插件按固定逻辑顺序执行列表顺序无关紧要。向老集群迁移时要注意这一语义差异。Webhook 是扩展的主力如果需要在集群中注入自定义策略镜像白名单、标签强制、sidecar 注入等优先使用MutatingAdmissionWebhook与ValidatingAdmissionWebhook组合前者串行调用可修改对象后者并行调用只要一个拒绝则请求失败。两者结合即可实现先改写、后校验的完整动态准入链路。安全插件宁多勿少PodSecurityPolicy、NodeRestriction、SecurityContextDeny、DenyEscalatingExec等安全类插件直接影响集群的攻击面。结合 guide/cluster-security-management.md 与 practice/security-policy.md 中的安全实践建议在多租户或生产环境中按需启用而不是维持最小集合。关注保留命名空间NamespaceLifecycle防止default、kube-system、kube-public被删除NamespaceExists用于拒绝引用不存在命名空间的请求。这两者在多团队共享集群时是避免误删/错引的基础保障。结语准入控制器是 Kubernetes 安全与策略体系中被低估的核心组件它决定了集群接受什么、拒绝什么、改写什么。本文以仓库文档 concepts/admission-controller.md 为主线完整覆盖了全部内置准入控制器的职责、变更/验证两阶段执行模型、1.6 至 1.10 的推荐配置演变并结合 etc/kubernetes/apiserver 的真实配置与 practice/master-installation.md 的部署实践进行了佐证同时延伸到 PodPreset、RBAC NodeRestriction、Istio/OpenKruise Webhook 注入等上下游生态。理解并善用准入控制器是走向生产级 Kubernetes 集群治理的第一步。参考本仓库 concepts/admission-controller.md、concepts/pod-preset.md、concepts/rbac.md、etc/kubernetes/apiserver、practice/master-installation.md、usecases/understand-sidecar-injection-and-traffic-hijack-in-istio-service-mesh.md、practice/openkruise.md。【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考