kubernetes中的Admission Controllers

这是啥

准入控制admission controller本质上一段代码，在对kubernetes api的请求过程当中，顺序为 先通过 认证 & 受权，执行准入操做，在对目标对象进行操做。这个准入代码在apiserver中，并且必须被编译到二进制文件中才能被执行。

在对集群进行请求时，每一个准入控制代码都按照必定顺序执行。若是有一个准入控制拒绝了这次请求，那么整个请求的结果将会当即返回，并提示用户相应的error信息。

在某些状况下，为了适用于应用系统的配置，准入逻辑可能会改变目标对象。此外，准入逻辑也会改变请求操做的一部分相关资源。

为何须要？

在kubernetes中，一些高级特性正常运行的前提条件为，将一些准入模块处于enable状态。总结下，对于kubernetes apiserver，若是不适当的配置准入控制模块，他就不能称做是一个完整的server，某些功能也不会正常的生效。

如何开启一个准入模块

在kubernetes apiserver中有一个参数：admission_control，他的值为一串用逗号链接的 有序的 准入模块列表，设置后，就可在对象呗操做前执行必定顺序的准入模块调用。

每一个准入模块都干了啥

AlwaysAdmit

对全部请求开绿灯。

AlwaysDeny

对全部请求开红灯，多用于测试环境。

DenyExecOnPrivileged

它会拦截全部想在privileged container上执行命令的请求。
若是本身的集群支持privileged container，本身又但愿限制用户在这些privileged container上执行命令，那么强烈推荐使用它。

ServiceAccount

这个plug-in将 serviceAccounts实现了自动化，若是想要使用ServiceAccount 对象，那么强烈推荐使用它。
关于serviceAccount的描述以下：

一个serviceAccount为运行在pod内的进程添加了相应的认证信息。当准入模块中开启了此插件（默认开启），那么当pod建立或修改时他会作一下事情：

1. 若是pod没有serviceAccount属性，将这个pod的serviceAccount属性设为“default”；
   
   
   1. 确保pod使用de serviceAccount始终存在；
   2. 若是LimitSecretReferences 设置为true，当这个pod引用了Secret对象却没引用ServiceAccount对象，弃置这个pod；
   3. 若是这个pod没有包含任何ImagePullSecrets，则serviceAccount的ImagePullSecrets被添加给这个pod；
   4. 若是MountServiceAccountToken为true，则将pod中的container添加一个VolumeMount 。

SecurityContextDeny

这个插件将会将使用了 SecurityContext的pod中定义的选项所有失效。
关于 SecurityContext的描述：

SecurityContext 在container中定义了操做系统级别的安全设定（uid, gid, capabilities, SELinux等等）。

ResourceQuota

它会观察全部的请求，确保在namespace中ResourceQuota对象处列举的container没有任何异常。若是在kubernetes中使用了ResourceQuota对象，就必须使用这个插件来约束container。

推荐在admission control参数列表中，这个插件排最后一个。

LimitRanger

他会观察全部的请求，确保没有违反已经定义好的约束条件，这些条件定义在namespace中LimitRange对象中。若是在kubernetes中使用LimitRange对象，则必须使用这个插件。

NamespaceExists

它会观察全部的请求，若是请求尝试建立一个不存在的namespace，则这个请求被拒绝。

有推荐的插件顺序吗？

有！

--admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota