Drei Fehler bei der Kubernetes-Nutzung

Kubernetes ist bei Administratoren beliebter denn je, um den Aufwand des Container-Managements beherrschbar zu machen. Doch auch wenn Googles Orchestrierungs-Plattform inzwischen das Maß aller Dinge ist, ist deren Bedienung ob der Komplexität der Plattform selbst nicht trivial. So kommt es immer wieder vor, dass sich Fehler in der Bedienung einschleichen.

Fehler 1: Container für jede Anwendung nutzen

Nicht jede Anwendung eignet sich für die Ausführung in einem Container. Es gibt Apps, die Entwickler entsprechend modifizieren können, um sie für den Container-Betrieb lauffähig zu machen – etwa große Legacy-Monolithen. Nach einem Redesign und heruntergebrochen in Microservices können Administratoren sie problemlos in Container packen. Andere Anwendungen sind allerdings völlig ungeeignet. Zum Beispiel jene, die extreme Ressourcen-Anforderungen haben, schlecht mit häufigen Restarts oder mehreren Instanzen ihrer selbst umgehen können. Da Kubernetes ein verteiltes System ist, bringen geteilte Ressourcen auch andere Anforderungen an die Apps mit, deren Missachtung zu Abstürzen und Datenverlust führen kann.

Die klare Empfehlung ist daher, nicht einfach jede Anwendung in Container zu verpacken und in Kubernetes zu stecken. IT-Teams sollten bei jeder App evaluieren, ob ein Redesign für einen unkomplizierten Container-Betrieb notwendig ist oder die App sich überhaupt für den Einsatz auf einem solchen System eignet. Wer nur sogenannte Twelve-Factor-Apps deployt, ist auf der sicheren Seite: Die Twelve-Factor-Methode ist eine Sammlung von Regeln für das Erstellen moderner Apps und in der IT-Welt weit verbreitet.

Fehler 2: Requests und Limits nicht forcieren

Die Ressourcenplanung in Kubernetes findet über den Scheduler der Plattform via Requests und Limits statt. Mit Requests legen Administratoren die vom Container benötigten Ressourcen fest, die Kubernetes ihnen für die einwandfreie Ausführung garantieren muss. Limits sind Grenzwerte, bei deren Erreichen Kubernetes den Container bremst und ihm keine weiteren Ressourcen zuteilt. Leider forciert das Orchestrierungs-Tool diese Angaben nicht standardmäßig, weshalb Administratoren diese Anforderung manuell aktivieren sollten.

Damit ist die Arbeit allerdings noch nicht getan, denn sie brauchen auch die „richtigen“ Werte für ihre Requests und Limits: Zu hohe Request-Werte führen etwa zur ineffizienten Ressourcenverteilung und unnötig hohen Kosten. Andererseits führen zu niedrige Limits dazu, dass Kubernetes Applikationen ausbremst oder sogar beendet, obwohl noch Ressourcen vorhanden sind. Die richtigen Werte zu finden, ist für Administratoren ein Balanceakt. Die klare Handlungsempfehlung ist, immer für jegliche Requests und Limits Werte zu setzen. Monitoring-Tools wie Prometheus helfen dabei, sie zu finden, während Policy-Engines wie OPA-Gatekeeper oder Kyverno sich zum Forcieren vernünftiger Standardwerte eignen.

Fehler 3: Probes nicht auf die Anwendung abstimmen

Kubernetes bietet die Möglichkeit, Startup Probes, Readiness Probes und Liveness Probes zu setzen. Diese konfigurierbaren Sensoren prüfen die Funktionsfähigkeit von Containern beziehungsweise den darin enthaltenen Anwendungen oder Microservices. Stimmt etwas nicht, können Administratoren ein bestimmtes Verhaltensmuster definieren, das die Plattform dann durchsetzt, etwa ein Neustart des Containers. Startup Probes sind unkompliziert: Sie bestimmen lediglich, ob der Container läuft und die Prüfung über eine der anderen beiden Arten von Probes überhaupt Sinn ergibt.

Readiness Probes erkennen, ob die Anwendung in einem Container gerade korrekt funktioniert, und regeln die Erreichbarkeit des Service. Administratoren sollten daher diese Probes in jedem Fall verwenden, wenn der im Container enthaltene Service Interaktionen zulässt – hat die Anwendung keine Interaktion mit Benutzern oder anderen Anwendungen, ist eine Probe an dieser Stelle unnötig. Doch Vorsicht: Falsch konfigurierte Probes können im schlimmsten Fall dafür sorgen, dass Services für User nicht erreichbar sind, obwohl der Container läuft. Liveness Probes prüfen, ob die Container-Anwendung noch korrekt läuft. Um unnötige Restarts der Applikation zu vermeiden, benötigen Administratoren passende Indikatoren für eine Fehlfunktion. Die klare Handlungsempfehlung ist, Probes sehr genau auf den individuellen Anwendungsfall abzustimmen.

Armin Kunaschik

Senior Devops Engineer bei Consol