Admission Controller sind Plugins im kube-apiserver, die API-Anfragen abfangen – nachdem Authentifizierung und Autorisierung erfolgreich waren und bevor das Objekt im Cluster-Speicher etcd persistiert wird. Sie sind die letzte Kontrollinstanz: Lehnt ein Admission Controller eine Anfrage ab, erreicht das Objekt etcd nie, der Client erhält einen Fehler.
Admission Controller laufen in zwei Phasen: Zuerst kommen die mutierenden Plugins (sie dürfen das Objekt verändern, etwa Defaults ergänzen), danach die validierenden (sie dürfen nur annehmen oder ablehnen). Abgelehnte Anfragen und veränderte Objekte sind im Audit-Log des API-Servers dokumentiert.
Eingebaute Admission Controller
- NamespaceLifecycle: lehnt Anfragen an unbekannte Namespaces ab und schützt
default,kube-systemundkube-publicvor dem Löschen. - LimitRanger: setzt Standardwerte für Requests und Limits, wenn ein Container keine eigenen Angaben macht.
- ResourceQuota: erzwingt die in einem Namespace definierten Ressourcen- und Objekt-Quoten.
- PodSecurity: setzt die Pod Security Standards (privileged, baseline, restricted) durch.
Die Liste der aktiven Plugins steuert der Administrator beim Start des API-Servers über --enable-admission-plugins und --disable-admission-plugins.
Dynamische Admission Controller
Mit MutatingWebhookConfiguration und ValidatingWebhookConfiguration (API-Gruppe admissionregistration.k8s.io) lassen sich eigene Webhooks registrieren: Der API-Server ruft bei passenden Objekten einen HTTPS-Endpunkt auf. Mutierende Webhooks laufen vor den validierenden; zwischen mehreren mutierenden Webhooks ist die Reihenfolge nicht garantiert. Die deklarative Alternative sind ValidatingAdmissionPolicies.
Requests und Limits, die Admission Controller wie der LimitRanger vergeben, bestimmen zusammen mit den Angaben im Manifest die QoS-Klasse des Pods.