Admission Controllers

当我们调用kubectl来创建POD时，会经过认证环节。它使用~/.kube/config中配置的证书来完成认证：

在该认证过程中，它识别哪个用户发送了该请求，并确保该用户是有效的。

然后就进入到了授权环节，此时检查用户是否具有操作某个资源的权限：

我们知道这个过程是基于RABC来完成的。此时如果该用户被授予了特定的Role，允许该用户执行list、get、delete等操作POD的权限，则通过授权，否则拒绝该操作。

如：下面我们通过该角色限制用户只能创建特定名称的POD

然而有些时候，我们想要实现更复杂的功能，这就需要使用到准入控制（Admision Controllers）
如：下面想要实现这些要求，通过RABC是无法完成的

● 我们限制镜像只能从特定的内部仓库拉取，不能从共有镜像库中拉取镜像；
● 限制container以root身份运行；
● 只允许特定的负载；
● 指定metadata中，需要包含label标签

准入控制帮助我们更好实现的安全措施，对于如何使用集群；除了简单的验证之外，准入控制能够完成更多功能，如：请求自身或者在创建POD之前执行其他操作。
准入控制器具有很多种：

● AlwaysPullImages：确保每次创建POD时，都会进行拉取镜像；
● DefaultStorageClass：监视PVC的创建，并若default storage class不存在，则自动添加；
● EventRateLimt：设置API-Server每次能够接受请求的速率，防止洪泛请求；
● NameSpaceExists：检查namespace是否存在，存在则通过，否则决绝；

如：指定了NamespaceExists后，我们创建一个名为blue的pod，若namespace不存在，则不通过

而另外一些控制器默认未启用，如：NamespaceAutoProvision，若namespace不存在，它会自动创建namespace。

如果想要查看，启用了哪些准入控制器，可以通过如下方式：

如果你是基于Kubeadm方式安装的kubernetes，使用下面的命令：

如果想要启用或关闭准入控制器。针对于不同的kubernetes安装方式，可以采用如下做法（左边二进制方式，右边kubeadm方式）：

当我们启用了NamespaceAutoProvision控制器后，在创建POD时，若对应的namespace不存在，则会自动创建：

通过上面的例子，我们能够看到，它不仅可以验证和拒绝用户，还能够在后端执行操作或修改请求本身。
只不过目前，NameSpaceExists和NamespaceAutoProvision，已经被NamespaceLifecycle所取代；
NamespaceLifecycle控制器，将拒绝不存在对应命名空间的请求，并且对于默认的命名空间，如：defalut、kube-system，将不能被删除。