Kubernetes hat die Orchestrierung von Containern beherrschbar gemacht. Die Bedienung der Open-Source-Plattform ist allerdings keinesfalls trivial. Die hohe Komplexität verführt im praktischen Einsatz selbst Experten zu Fehlern. Die Folgen können gravierend sein – sind aber vermeidbar. [...]
Kaum ein Administrator kommt heute noch ohne Kubernetes (K8s) aus, um Container zu verwalten. Der große Funktionsumfang der Orchestrierungs-Plattform ist allerdings Fluch und Segen: Einerseits lässt sie praktisch keinen Wunsch im Hinblick auf das Erstellen, Betreiben und Managen von Containern offen. Andererseits verleitet das hohe Komplexitätslevel auch versierte K8s-Administratoren zu Fehlern. Zu den beliebtesten gehören die unbedachte Containerisierung von Applikationen, die Zurückhaltung bei festen Vorgaben hinsichtlich Requests und Limits sowie die mangelnde Abstimmung der Probes auf die Applikationen. Die folgende detaillierte Analyse dieser Fehler soll Administratoren helfen, sie zu erkennen und zu vermeiden.
Chaotische Containerisierung
Der Hype um Container ist ungebrochen. Viele Unternehmen möchten mit ihnen ihre Anwendungen modernisieren. Doch nicht alle Apps eignen sich für den Container-Betrieb. Monolithische Legacy-Anwendungen sind das beste Beispiel dafür, denn sie sind zu groß, zu ressourcenhungrig, schlecht skalierbar und zu unflexibel. Auch Apps, die eine lange Laufzeit erwarten und mit einem unerwarteten Abbruch Probleme haben, sind nicht ideal: Container sind unveränderlich und müssen daher bei Änderungen neu gestartet werden. Um Datenverlust, eingeschränkter Verfügbarkeit und schlechter Performance vorzubeugen, sollten Administratoren nur Anwendungen in Containern ausrollen, die für den Betrieb in einer solchen Umgebung geeignet sind. Feste Vorschriften gibt es nicht, aber grundsätzlich sind Twelve-Factor-Apps ein guter Kompass. Sie umfassen eine Reihe von Regeln und Standards für moderne Applikationen, die auf den Cloud-nativen und verteilten Betrieb in K8s ausgelegt sind. In den meisten Fällen werden Entwickler nicht um ein Redesign herumkommen, denn Kubernetes spielt seine größten Stärken in Verbindung mit Microservices aus.
Besonderes Augenmerk müssen Entwickler zudem auf das Logging legen, das im Zusammenhang mit Containern einige Besonderheiten aufweist. Normalerweise schreiben Applikationen ihre Logs in Dateien. In einer Container-Umgebung geht das allerdings nicht, denn deren Dateisystem ist in der Regel nicht beschreibbar. In den seltenen Fällen, wo es das ist, gehen die Logs aber beim Container-Restart verloren. Aus diesem Grund sollten Entwickler die Standard-Datenströme stdout (Standard Out) und stderr (Standard Error) verwenden, um ihre Logs an die Container-Runtime weiterzuleiten. Sie kann die Logs verarbeiten und falls nötig an einen zentralen Log-Speicher wie ElasticSearch, Loki oder Splunk transferieren.
Renitente Ressourcenplanung
Auch eine unzulängliche Ressourcenplanung bereitet beim Betrieb von Containern große Probleme. In Kubernetes steuern Administratoren deren Verteilung über Requests und Limits. Requests entsprechen den benötigten Ressourcen, die das Orchestrierungs-Tool für die einwandfreie Ausführung eines Containers bereitstellen muss. Limits hingegen stellen Grenzwerte dar, bei deren Erreichen Kubernetes einem Container keine zusätzlichen Ressourcen mehr zuteilt. Jedoch setzt K8s auf die freiwillige Einschränkung, so sind standardmäßig weder Requests noch Limits aktiviert, das heißt jeder Container kann sämtliche Ressourcen eines Cluster-Knotens nutzen.
Verlassen sich Administratoren auf diese Methode, ist keine sinnvolle Ressourcenplanung möglich. Daher ist es Pflicht, diese Einstellungen zu forcieren. Doch auch unter dieser Voraussetzung ist Vorsicht geboten: Durch zu hohe Request-Werte droht eine ineffiziente Ressourcen-Nutzung und es können horrende Kosten entstehen, wenn die Container in einer Cloud-Umgebung laufen. Legen Administratoren sie zu niedrig an, startet die Applikation eventuell erst gar nicht oder läuft zu langsam, weil zu viele andere Container um die Ressourcen konkurrieren (Noisy-Neighbor-Effekt). Auch zu niedrige Limits bergen Gefahren, etwa Performance-Einbußen. Im schlimmsten Fall beendet die Plattform Container, obwohl die nötigen Ressourcen eigentlich vorhanden wären. Zu hohe Limits bergen das Risiko von Speicher- oder CPU-Engpässen, falls mehr Ressourcen angefordert werden, als real zur Verfügung stehen. Dies kann ebenfalls zur negativen Beeinflussung von Applikationen untereinander führen. Im Extremfall verdrängt ein Container den anderen.
Administratoren brauchen für das Feintuning der Ressourcenverteilung also etwas Geschick und Hilfe, etwa von Monitoring-Tools wie Prometheus und Policy-Engines wie OPA-Gatekeeper oder Kyverno. Es ist auf jeden Fall sinnvoll, dass jede Anwendung (oder jeder Container) maximal die Ressourcen erhält, die sie für einen funktionalen Betrieb benötigt.
Problematische Probes
Probes sind konfigurierbare Sensoren, mit denen Administratoren die Funktionsfähigkeit von Containern und den darin enthaltenen Anwendungen oder Microservices prüfen. Kubernetes bietet derer drei: Startup Probes, Readiness Probes und Liveness Probes. Mit ihnen können Administratoren zudem bestimmte Verhaltensmuster für Kubernetes definieren, die das Orchestrierungs-Tool durchsetzt, wenn eine festgelegte Situation eintritt. Der Klassiker ist etwa ein Container-Neustart, wenn eine Applikation nicht mehr korrekt funktioniert. Administratoren müssen die Konfiguration von Probes auf jede Anwendung individuell zuschneiden, daher kommt es oft zu Fehlern.
Startup Probes prüfen, ob ein Container läuft und die Prüfung durch eine weitere Probe überhaupt möglich ist. Ob der Service innerhalb eines Containers betriebsbereit ist, finden Administratoren mit Readiness Probes heraus. Über sie können sie zudem dessen Erreichbarkeit manipulieren. Lässt der Service Interaktionen mit Benutzern oder anderen Services zu, sollten Administratoren diese Probes auf jeden Fall einsetzen. Jedoch sollten sie vorsichtig sein, denn falsche Einstellungen führen an dieser Stelle dazu, dass der Service beispielsweise fehlerfrei läuft, für User aber trotzdem nicht erreichbar ist. Liveness Probes prüfen, ob die Container-Anwendung insgesamt noch korrekt funktioniert. Administratoren müssen dafür allerdings passende Indikatoren bestimmen, sonst drohen unnötige Neustarts des Containers.
*Armin Kunaschik ist Senior DevOps Engineer bei Consol.
Be the first to comment