Admission controllers are a powerful Kubernetes-native feature that helps you define and customize what is allowed to run on your cluster.
As watchdogs, they can control what’s going into your cluster. They can manage deployments requesting too many resources, enforce pod security policy admission controller, and even block vulnerable images from being deployed.
Image Source: Google
An admission controller intercepts and processes requests to the Kubernetes API prior to the persistence of the object, but after the request is authenticated and authorized.
These controllers are compiled and shipped into the kube-apiserver binary, and can only be legalized and composed by the cluster administrator using the enable-admission-plugins and admission-control-config-file flags.
The power of Kubernetes admission controllers can answer existential questions in the life of a DevOps:
1)Is the pod requesting too many resources?
2)Are the base images used to spawn the microservice pods secure?
They can block pods from running if the cluster is out of resources or if the images are not secure. And, as we saw earlier, they can even mutate the request to tweak the resources request from a pod.
You are probably already running several Kubernetes admission controllers that come pre-configured out-of-the-box with your standard deployment. Some aspects of Kubernetes that you may consider built-in are actually enforced by these controllers, for example:
LimitRanger: Manages resource limits and requests, as mentioned before.
PodSecurityPolicy: Acts on creation and modification of the pod and determines if it should be admitted based on the requested security context and the available Pod Security Policies.