Verteilter Anwendungsbetrieb

Was ist Container-Orchestrierung?

Container Orchestration

Container-Orchestrierung ist die automatische Verwaltung vieler Container über mehrere Rechner hinweg: Eine zentrale Steuerung verteilt sie auf die verfügbaren Knoten, startet ausgefallene Instanzen neu und hält den beschriebenen Soll-Zustand ohne Handarbeit aufrecht.

Sobald mehr als eine Handvoll Container auf mehreren Rechnern läuft, ist nicht mehr die Frage, wie du sie startest, sondern wer sie um drei Uhr nachts neu startet.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Arbeitet mit: Einem beschriebenen Soll-Zustand
De-facto-Standard: Kubernetes, dazu Distributionen wie OpenShift
Braucht: Grenzwerte für Speicher und Rechenzeit
Verwechselt mit: Container-Laufzeitumgebung

Der Soll-Zustand wird beschrieben, nicht gestartet

Statt einzelne Startbefehle abzusetzen, legst du in einer Datei fest, was gelten soll: drei Kopien dieses Dienstes, dieses Image, so viel Arbeitsspeicher, erreichbar unter diesem Namen. Die Steuerungsebene vergleicht diesen Wunschzustand laufend mit der Wirklichkeit und gleicht Abweichungen selbst aus. Löscht jemand versehentlich eine Instanz, ist sie Sekunden später wieder da.

Dieses ständige Nachregeln ist der eigentliche Unterschied zu einem Skript, das Container startet. Ein Skript läuft einmal, eine Orchestrierung läuft immer. Deshalb reicht es auch nicht, eine Anwendung einmal auszurollen: Sie muss selbst melden können, ob sie betriebsbereit ist, sonst weiß die Plattform nicht, was sie reparieren soll.

Verteilung, Selbstheilung und Skalierung im Betrieb

Der Scheduler sucht für jede neue Instanz einen Knoten, der genug freie Ressourcen hat und die geforderten Bedingungen erfüllt, etwa eine bestimmte Region oder ein Knoten mit Grafikkarte. Fällt ein Knoten aus, verteilt die Plattform die betroffenen Instanzen auf die übrigen. Bei Lastspitzen kommen zusätzliche Kopien hinzu und verschwinden wieder, wenn die Last sinkt.

Damit Anfragen die richtigen Instanzen finden, bekommen Dienste einen festen internen Namen, hinter dem sich wechselnde Adressen verbergen. Neue Versionen rollen schrittweise aus: Erst wird eine Instanz getauscht, geprüft, dann die nächste. Geht dabei etwas schief, stoppt der Vorgang, statt die ganze Anwendung mitzureißen.

Der Fehler, der fast jedem Cluster passiert

Anwendungen werden ohne Angaben zu benötigtem Arbeitsspeicher und benötigter CPU-Zeit ausgerollt. Der Scheduler arbeitet dann blind, packt zu viel auf einen Knoten, und der erste Lastanstieg reißt Dienste mit, die mit dem Auslöser nichts zu tun haben. Genauso häufig fehlt die Bereitschaftsprüfung, sodass Anfragen auf Instanzen laufen, die noch gar nicht antworten können.

Beides ist schnell nachgeholt und ändert das Verhalten unter Last grundlegend. Wer neu einsteigt, sollte diese beiden Angaben deshalb vor jeder weiteren Optimierung setzen.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Container-Orchestrierung und was oft damit gleichgesetzt wird

Container-Orchestrierung gegen Container-Laufzeitumgebung

Die Laufzeitumgebung startet einen einzelnen Container auf einem einzelnen Rechner. Die Orchestrierung entscheidet, welcher Container auf welchem Rechner läuft, wie viele Kopien es gibt und was bei Ausfall passiert.

Container-Orchestrierung gegen Virtualisierung

Eine virtuelle Maschine bringt ein eigenes Betriebssystem mit, ein Container teilt sich den Kernel des Hosts. Orchestrierung setzt meist auf virtuellen Maschinen auf, ersetzt sie aber nicht.

Container-Orchestrierung gegen CI/CD-Pipeline

Die Pipeline baut und testet dein Artefakt und übergibt es an die Plattform. Was danach im laufenden Betrieb damit geschieht, regelt die Orchestrierung.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Der Verbund tut, was in den Dateien steht, nicht was gemeint war

Ohne angegebenen Bedarf und ohne Obergrenze kann die Verteilung nicht planen. Ein Dienst mit einem Speicherleck zieht dann den ganzen Knoten leer, das Betriebssystem beendet Prozesse nach eigenem Ermessen, und es trifft ausgerechnet den Nachbarn, der nichts falsch gemacht hat. Danach wandert die Störung von Knoten zu Knoten, weil die verschobenen Container den Fehler mitnehmen. Realistische Angaben zu Bedarf und Grenze sind deshalb keine Feinjustierung, sondern die Voraussetzung dafür, dass Ausfälle lokal bleiben.

Zustandsbehaftete Dienste sind der zweite wunde Punkt. Eine Datenbank im Verbund braucht Speicher, der ihr folgt, wenn sie auf einem anderen Knoten neu gestartet wird. Hängt der Speicher lokal am Blech oder erlaubt er nur einen schreibenden Zugriff, steht der Dienst nach dem Verschieben ohne seine Daten da. Das fällt im Testbetrieb mit kleinen Datenmengen nie auf.

Am meisten Schaden richten falsch gesetzte Prüfungen an, mit denen der Verbund feststellt, ob ein Dienst bereit und ob er noch am Leben ist. Ist die Frist zu knapp für eine Anwendung, die beim Start eine Minute braucht, startet der Verbund sie unermüdlich neu, und der Fehler sieht aus wie ein Absturz. Miss die tatsächliche Startzeit, bevor du die Werte setzt.

Container-Orchestrierung lernen

Wie du einen Cluster aufbaust, absicherst und im Störungsfall wieder einfängst, üben die Zertifizierungen der Linux Foundation an eigenen Umgebungen.

Ob ein Cluster wirklich gesund ist, siehst du erst mit passender Messtechnik, dafür gibt es eigene Kurse zur Überwachung verteilter Systeme .

Wissen prüfen

Sitzt Container-Orchestrierung schon?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Wissenstest Docker & Container Grundlagen QuizTeste dein Wissen zu Docker-Architektur, Dockerfiles, Volumes, Networking und Compose. Quiz starten Wissenstest Kubernetes Grundlagen QuizTeste dein Wissen zu Pods, Deployments, Services, ConfigMaps, kubectl und der Cluster-Architektur. Quiz starten

Kurse, die Container-Orchestrierung behandeln

Häufige Fragen

Brauche ich Kubernetes, wenn ich nur drei Container betreibe?

Meistens nicht. Der Aufwand für Betrieb, Netzwerk und Rechteverwaltung lohnt sich erst, wenn mehrere Teams unabhängig ausrollen, wenn Ausfälle automatisch aufgefangen werden müssen oder wenn die Last stark schwankt. Für eine Handvoll stabiler Dienste reicht oft ein einfacher Compose-Aufbau auf zwei Maschinen.

Was passiert mit meinen Daten, wenn eine Instanz neu gestartet wird?

Alles, was im Container selbst liegt, ist weg. Daten, die überleben sollen, gehören in ein eingebundenes Volume oder in eine Datenbank außerhalb des Clusters. Das ist der häufigste Grund, warum eine Anwendung im Test funktioniert und im Cluster plötzlich Dateien verliert.

Wie viele Knoten braucht ein produktiver Cluster?

Für die Steuerungsebene sind drei Knoten üblich, damit bei einem Ausfall noch eine Mehrheit für Entscheidungen zusammenkommt. Die Anzahl der Arbeitsknoten richtet sich nach der Last, zwei sind das Minimum, damit Wartung ohne Ausfall möglich bleibt.

Persönlich für dich da