如何进行Kubernetes中准入控制器的分析

如何进行Kubernetes中准入控制器的分析，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

什么是准入控制器

每个针对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两个插件。

--enable-admission-plugins=NodeRestriction,ResourceQuota

该参数主要在需要启用默认禁用的插件时使用。

关闭控制插件

通过kube-apiserver的--disable-admission-plugins参数可以设置禁用的控制器插件，同样多个插件名字以逗号分隔，例如以下参数关闭PodNodeSelector和AlwaysDeny两个插件。

--disable-admission-plugins=PodNodeSelector,AlwaysDeny

该参数主要在需要禁用默认启用的插件时使用。

看完上述内容，你们掌握如何进行Kubernetes中准入控制器的分析的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注行业资讯频道，感谢各位的阅读！