Chaos vermeiden: Namenskonventionen in Kubernetes-Clustern durchsetzen

Montag, 1.4.2019

Namenskonventionen

Arbeiten mehrere Teams gemeinsam auf einem Kubernetes-Cluster, bekommen eindeutige und einheitliche Ressourcenbezeichnungen eine große Bedeutung, damit sich alle Beteiligten schnell zurechtfinden. Eine automatische Durchsetzung von Konventionen mit eigener Logik ist da sehr zeitsparend.

Zur groben Gruppierung von Ressourcen bieten sich Namespaces an. So können beispielsweise verschiedene Entwicklungs- und Produktionsumgebungen voneinander getrennt werden. Damit man dem Namespace seine Kritikalität ansieht, sollen in unserem Cluster alle Namespaces auf -dev, -staging oder -prod enden, damit die Zuordnung direkt aus dem Namen ableitbar ist.
Nachdem eine solche Konvention beschlossen ist, muss sie auch kontrolliert und durchgesetzt werden - die Kubernetes-API bietet hier eine elegante Möglichkeit an, dies zu automatisieren.

Um Kubernetes-Ressourcen bei der Anlage zu validieren, kann man einen eigenen ValidatingAdmissionWebhook registrieren. Er wird bei der Anlage und Änderungen von Kubernetes-Ressourcen aufgerufen. Bei fehlgeschlagener Prüfung kann die Anlage bzw. Änderung mit einer Fehlermeldung verhindert werden. Der ValidatingAdmissionWebhook wird vom AdmissionController aufgerufen, der in einer Standardinstallation von Kubernetes vorhanden und aktiviert ist.

Der ValidatingAdmissionWebhook wird als Ressource angelegt (webhook.yml). Die folgenden Attribute legen fest, in welchen Namespaces und für welche Ressourcen der Webhook aufgerufen werden soll. Im Fall der Prüfung von Namespaces kann bei namespaceSelector einfach {} für „alle Namespaces“ angegeben werden. Unter rules wird dann definiert, welche Ressourcen (z.B. Namespace, Deployments, ConfigMaps, …) mit welcher Aktion (Anlage, Änderung, Löschen) dem Webhook zur Validierung übergeben werden. Der name des Webhooks muss ein FQDN (z.B. mein-name.meine-domain.de) sein, kann ansonsten aber frei gewählt werden.


Seminar/Schulung zum Thema


Sobald die Regel auf eine Aktion passt, wird der unter clientConfig registrierte Endpunkt aufgerufen. Dabei kann ein interner (Kubernetes-)Service oder eine externe URL konfiguriert werden. In beiden Fällen sind ausschließlich HTTPS-Endpunkte erlaubt. Zur Überprüfung des SSL-Zertifikats können die entsprechenden Root-Zertifikate der Zertifizierungsstelle angegeben werden.

 

Die Implementierung des Endpunkts bekommt ein JSON-Objekt (Beispiel in payload.json, nur ein Ausschnitt), mit der Ressource, die gerade bearbeitet werden soll. Bei einem HTTP-Returncode von 200 wird die Ressource vom AdmissionController freigegeben und ganz normal bearbeitet (answer-ok.json).

Wenn der Endpunkt einen Returncode > 400 liefert, wird die Bearbeitung abgebrochen und dem Benutzer eine Fehlermeldung angezeigt (z. B. bei kubectl). Die Fehlermeldung kann der Endpunkt als JSON-Objekt zurückgeben (answer-failed.json).

Falls der Endpunkt mal nicht erreichbar sein sollte, kann im ValidatingAdmissionWebhook mit der failurePolicy gesteuert werden, ob die Bearbeitung der Ressource abgebrochen wird oder nicht (ignore).

Wichtig ist, dass der Endpunkt in seiner Validierungslogik lediglich die Ressource-Definition überprüft, die er als Input-Parameter übergeben bekommt und keine Seiteneffekte erzeugt – es können nämlich durchaus mehrere ValidatingAdmissionWebhooks registriert werden. Diese werden dann alle parallel aufgerufen und sobald der erste Endpunkt mit einem Fehler antwortet, wird der Request des Benutzers abgelehnt. Da die hier diskutierten Webhooks lediglich in der Validation-Phase aufgerufen werden, sollten sie außerdem keine Veränderungen an der Ressource vornehmen. Hierfür gibt es MutatingAdmissionWebhook.

Fazit: Mit dem ValidatingAdmissionWebhook können beliebige Ressourcen sehr leichtgewichtig und entkoppelt validiert werden. Übrigens eignen sich auch Serverless-Functions (z. B. AWS Lambda, Google Cloud Functions) prima für eine solche Anwendung. So können Namenskonventionen automatisiert und mit sprechenden Fehlermeldungen ganz nach eigenen Vorstellungen durchgesetzt werden.


Sie sind Software-Entwickler, DevOps-Engineer oder IT-Architekt und möchten Kubernetes Hands-On kennenlernen?

Hier finden Sie weitere Informationen zu unserer Schulung:


Seminar/Schulung zum Thema

zurück zur Blogübersicht

Diese Beiträge könnten Sie ebenfalls interessieren

Keinen Beitrag verpassen – viadee Blog abonnieren

Jetzt Blog abonnieren!

Kommentare

Andreas Kruse

Andreas Kruse

Andreas Kruse verfügt über langjährige Erfahrungen in der Entwicklung von Java-basierten Enterprise-Anwendungen. Als IT-Architekt möchte er Cloud-Native-Technologien im passenden Kontext sinnvoll einsetzen. CI/CD und DevOps spielen dabei im Aufbau der Entwicklungsumgebung und Anwendungsarchitektur immer eine Rolle.