如何进行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中准入控制器的分析的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注亿速云行业资讯频道,感谢各位的阅读!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。