Admission controllers are Kubernetes code that allows you to intercept a call to the Kubernetes API server after it has been authenticated and authorized. There are standard admission controllers that are included with the core Kubernetes system, and people also write their own. There are two controllers that are more important than the rest:

• The MutatingAdmissionWebhook is responsible for calling Webhooks that mutate, in serial, a given request. This controller only runs during the mutating phase of cluster operating. You can use a controller like this in order to build business logic into your cluster to customize admission logic with operations such as CREATE, DELETE, and UPDATE. You can also do things like automate the provisioning of storage with the StorageClass. Say that a deployment creates a PersistentVolumeClaim; a webhoook can automate the provisioning of the StorageClass in response. With the MutatingAdmissionWebhook, you can also do things such as injecting a sidecar into a container prior to it being built.
• The ValidatingAdmissionWebhook is what the admission controller runs in the validation phase, and calls any webhooks that will validate a given request. Here, webhooks are called in parallel, in contrast to the serial nature of the MutatingAdmissionWebhook. It is key to understand that none of the webhooks that it calls are allowed to mutate the original object. An example of a validating webhook such as this is incrementing a quota.

Admission controllers and their mutating and validating webhooks are very powerful, and importantly provide Kubernetes operators with additional control without having to recompile binaries such as the kube-apiserver.  The most powerful example is Istio, which uses webhooks to inject its Envoy sidecar in order to implement load balancing, circuit breaking, and deployment capabilities. You can also use webhooks to restrict namespaces that are created in multi-tenant systems.

You can think of mutation as a change and validation as a check in the Kubernetes system. As the associated ecosystem of software grows, it will become increasingly important from a security and validation standpoint to use these types of capabilities. You can use controllers, with their change and check capabilities to do things such as override image pull policies in order to enable or prevent certain images from being used on your cluster. 

These admission controllers are essentially part of the cluster control plane, and can only be run by cluster administrators. 

Here's a very simple example where we'll check that a namespace exists in the admission controller.

First, let's grab Minikube for our cluster and check which namespaces exist:

master $ kubectl get namespaces
 NAME STATUS AGE
 default Active 23m
 kube-public Active 23m
 kube-system Active 23m

Great! Now, let's try and create a simple deployment, where we put it into a namespace that doesn't exist. What do you think will happen?

master $ kubectl run nodejs --image nodej2 --namespace not-here
 Error from server (NotFound): namespaces "not-here" not found

So, why did that happen? If you guessed that our ValidatingAdmissionWebhook picked up on that request and blocked it, you'd be correct!