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

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

什么是准入控制器

每个针对Kubernetes资源对象的操作请求,都要经过kube-apiserver的层层审查才会被放行。对于读操作而言,需要经过认证(是否是合法用户)和鉴权(是否拥有权限);而对于写操作而言,除了要经过认证和鉴权外,还要检查请求是合乎要求,只有顺利通过这些审查才会被持久化到etcd存储中。

准入控制器(Admission Controller)是用于审查请求的组件,它会劫持发往kube-apiserver的请求,对请求进行审查(必要时也会修改请求内容),它是kube-apiserver审查链中重要的一环,不合理的请求会被拒绝。

kube-apiserver支持配置多个准入控制器,准入控制器分为修改型(Mutating)控制器和校验型(Validating)控制器。修改型控制器会自动根据指定的策略对请求进行修改,而校验型控制器则只是单纯地检查请求是否合乎要求,充当“看门狗”的角色。

多个准入控制器以插件(Webhook Plugin)的形式被组织起来,kube-apiserver在审查请求时会先把请求交给修改型控制器对请求进行必要的修改,然后再将请求交给校验型控制器进行审查。下图展示了请求的审查完整路径,以及准入控制器所在的位置:

如何进行Kubernetes中准入控制器的分析  kubernetes 第1张

API请求到达kube-apiserver后会先进行认证(Authentication)和鉴权(Authorization),然后把请求交给修改型准入控制器进行必要的修改(多个修改型准入控制器串行执行),当所有修改型准入控制器执行完毕后,再使用OpenAPI 校验功能进行初步的语法校验,接着再把请求交给校验型准入控制器进行语法或语义的校验(多个修改型准入控制器并行执行),最后再写入etcd。上面中的任何一个审查环节、任何一个准入控制器返回失败,都会造成请求被拒绝。

准入控制器配置

准入控制器根据其部署形式可分为内置控制器和动态控制器两种。内置控制器集成在kube-apiserver中,以插件的形式提供,每个插件都可以通过参数控制启用或禁止;而动态控制器则是按一定标准实现的服务。关于动态控制器的更多内容将会在后续章节中展开介绍,本节主要介绍内置控制器的配置方法。

kube-apiserver提供了数十个准入控制器插件,其中一些是默认开启的,也可以通过参数显式地控制启用或禁用的插件。

开启控制器插件

通过kube-apiserver--enable-admission-plugins参数可以设置除默认启用的控制器插件以外需要额外启用的插件,多个插件名字以逗号分隔,例如以下参数开启NodeRestrictionResourceQuota两个插件。

--enable-admission-plugins=NodeRestriction,ResourceQuota

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

关闭控制插件

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

--disable-admission-plugins=PodNodeSelector,AlwaysDeny

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

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

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:niceseo99@gmail.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

评论

有免费节点资源,我们会通知你!加入纸飞机订阅群

×
天气预报查看日历分享网页手机扫码留言评论电报频道链接