Admission control modules come into play after Kubernetes verifies who makes requests and whether the requester has sufficient permission to perform them. Unlike authentication and authorization, admission control can see the content of the request, or even have the ability to validate or mutate it. If the request doesn't pass through one of admission controllers, the request will be rejected immediately. For turning on admission controllers in Kubernetes, simply pass --admission-control (version < 1.10) --enable-admission-plugins (version >= 1.10) parameters when starting the API server.

Different admission controllers are designed for different purposes. In the following recipe, we'll introduce some important admission controllers and those that Kubernetes officially recommends that users have. The recommended list for version >= 1.6.0 is as follows: NamespaceLifecycle, LimitRanger, ServiceAccount, PersistentVolumeLabel, DefaultStorageClass, DefaultTolerationSeconds, ResourceQuota.

Please note that the sequence of admission controllers matters since the requests pass one by one in sequence (this is true for versions before 1.10, using the --admission-control option; in v1.10, the parameter is replaced by --enable-admission-plugins and the sequence no longer matters). We don't want to have ResourceQuota checking first and finding out that the resource information is outdated after checking the long chain of admission controllers.

If the version is >= 1.9.0, MutatingAdmissionWebhook and ValidatingAdmissionWebhook will be added before ResourceQuota. For more information about MutatingAdmissionWebhook and ValidatingAdmissionWebhook, please refer to the There's more section in this recipe.