9.1.1 概述
最后更新于
最后更新于
每个针对Kubernetes资源对象的操作请求，都要经过kube-apiserver的层层审查才会被放行。对于读操作而言，需要经过认证（是否是合法用户）和鉴权（是否拥有权限）；而对于写操作而言，除了要经过认证和鉴权外，还要检查请求是合乎要求，只有顺利通过这些审查才会被持久化到etcd存储中。
准入控制器（Admission Controller）是用于审查请求的组件，它会劫持发往kube-apiserver的请求，对请求进行审查（必要时也会修改请求内容），它是kube-apiserver审查链中重要的一环，不合理的请求会被拒绝。
kube-apiserver支持配置多个准入控制器，准入控制器分为修改型（Mutating）控制器和校验型（Validating）控制器。修改型控制器会自动根据指定的策略对请求进行修改，而校验型控制器则只是单纯地检查请求是否合乎要求，充当“看门狗”的角色。
多个准入控制器以插件（Webhook Plugin）的形式被组织起来，kube-apiserver在审查请求时会先把请求交给修改型控制器对请求进行必要的修改，然后再将请求交给校验型控制器进行审查。下图展示了请求的审查完整路径，以及准入控制器所在的位置：
API请求到达kube-apiserver后会先进行认证（Authentication）和鉴权（Authorization），然后把请求交给修改型准入控制器进行必要的修改（多个修改型准入控制器串行执行），当所有修改型准入控制器执行完毕后，再使用OpenAPI 校验功能进行初步的语法校验，接着再把请求交给校验型准入控制器进行语法或语义的校验（多个修改型准入控制器并行执行），最后再写入etcd。上面中的任何一个审查环节、任何一个准入控制器返回失败，都会造成请求被拒绝。
准入控制器根据其部署形式可分为内置控制器和动态控制器两种。内置控制器集成在kube-apiserver中，以插件的形式提供，每个插件都可以通过参数控制启用或禁止；而动态控制器则是按一定标准实现的服务。关于动态控制器的更多内容将会在后续章节中展开介绍，本节主要介绍内置控制器的配置方法。
kube-apiserver提供了数十个准入控制器插件，其中一些是默认开启的，也可以通过参数显式地控制启用或禁用的插件。
通过kube-apiserver的--enable-admission-plugins参数可以设置除默认启用的控制器插件以外需要额外启用的插件，多个插件名字以逗号分隔，例如以下参数开启NodeRestriction和ResourceQuota两个插件。
该参数主要在需要启用默认禁用的插件时使用。
通过kube-apiserver的--disable-admission-plugins参数可以设置禁用的控制器插件，同样多个插件名字以逗号分隔，例如以下参数关闭PodNodeSelector和AlwaysDeny两个插件。
该参数主要在需要禁用默认启用的插件时使用。
《Using Admission Controllers》 https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers
《A Guide to Kubernetes Admission Controllers》https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers
