Eine Anwendung läuft. Dann kommt ein Update, ein Server fällt aus oder mehrere Abteilungen brauchen gleichzeitig mehr Leistung. Kubernetes organisiert, wo Container laufen und wie der vereinbarte Betriebszustand wieder erreicht wird. Ob daraus eine verlässlichere Anwendung entsteht, entscheidet die gesamte Architektur.
Nehmen wir ein internes Auftragsportal: Mitarbeitende erfassen Bestellungen, eine Schnittstelle überträgt sie ins Warenwirtschaftssystem und ein Hintergrundprozess erstellt Dokumente. Für diese Aufgaben können getrennte Container eingesetzt werden. Wer sie einzeln startet, muss auch Updates, Neustarts und die Zuordnung zu Rechnern koordinieren. Genau hier setzt die Orchestrierung an.
Der gewünschte Zustand wird zur Arbeitsgrundlage
Bei Kubernetes wird beispielsweise festgelegt: Von der Webanwendung sollen zwei Instanzen mit einer bestimmten Softwareversion laufen. Die Plattform vergleicht diesen gewünschten Zustand laufend mit dem vorhandenen Zustand. Ein Deployment beschreibt die Bereitstellung einer Anwendung und lässt die zugehörigen Pods über einen ReplicaSet-Controller verwalten. Fehlt eine Instanz, versucht die Steuerung, Ersatz bereitzustellen.
Das ist auch für Updates interessant: Eine neue Version kann schrittweise ausgerollt werden. Dafür müssen unter anderem Ressourcen, Startverhalten und die gewählte Update-Strategie passen. Ein technisch erfolgreicher Rollout sagt allerdings noch nichts darüber aus, ob eine Bestellung fachlich korrekt verarbeitet wurde. Diese Prüfung bleibt Teil der Anwendung und ihrer Tests.
Die wichtigsten Begriffe am Auftragsportal erklärt
- Container-Image
- Die paketierte Grundlage einer Anwendung mit ihren benötigten Dateien und Laufzeitbestandteilen. Daraus werden ausführbare Container gestartet.
- Pod
- Die kleinste bereitstellbare Einheit in Kubernetes. Meist enthält sie einen Anwendungscontainer; eng zusammengehörende Container können sich einen Pod und damit unter anderem den Netzwerkraum teilen. Zwei Kopien der Webanwendung sind üblicherweise zwei Pods.
- Node
- Ein Rechner, auf dem Pods ausgeführt werden. Ein Node kann eine virtuelle Maschine oder ein physischer Server sein. Kubernetes ergänzt deshalb eine mögliche Virtualisierungsschicht, statt sie grundsätzlich zu ersetzen.
- Cluster und Control Plane
- Der Cluster verbindet die Steuerung mit den ausführenden Nodes. Zur Control Plane gehören unter anderem API-Server, Zustandsdatenbank, Scheduler und Controller. Auf den Nodes sorgen Kubelet und Container-Laufzeit für die Ausführung.
- Service
- Ein stabiler logischer Zugang zu einer Gruppe von Pods. Deren Adressen können sich beim Austausch ändern. Der Service entkoppelt den Zugriff von einzelnen kurzlebigen Instanzen.
Was beim Ausfall tatsächlich passiert
Fällt ein Node aus, können verwaltete Pods auf anderen geeigneten Nodes neu bereitgestellt werden. Dafür müssen Ausfall erkannt, ausreichend freie Kapazität vorhanden und die benötigten Daten erreichbar sein. Eine zweite Instanz auf demselben physischen Host schützt nicht vor dessen Ausfall. Auch mehrere Server im selben Strom- oder Netzwerkbereich können eine gemeinsame Fehlerquelle haben.
Für unser Auftragsportal heißt das: Die Weboberfläche lässt sich möglicherweise zügig ersetzen. Ein bereits gestarteter Dokumentenauftrag muss jedoch so gestaltet sein, dass eine Wiederholung keine doppelte Rechnung oder Bestellung erzeugt. Sitzungen dürfen beim Austausch einer Instanz nicht unkontrolliert verloren gehen. Diese Eigenschaften kommen aus der Softwarearchitektur und den angebundenen Systemen.
Eine Zahl von drei Servern allein ist daher noch kein Verfügbarkeitskonzept. Steuerung, Anwendung, Netzwerk, Speicher und verbleibende Leistung nach einem Ausfall müssen zusammen betrachtet werden. Gleiches gilt für den Betrieb in einer Cloud oder bei einem verwalteten Kubernetes-Angebot: Der konkrete Leistungsumfang entscheidet, welche Verantwortung beim Anbieter und welche beim Unternehmen liegt.
Persistente Daten brauchen einen eigenen Plan
Pods sind austauschbar. Geschäftsdaten dürfen deshalb nicht ausschließlich im beschreibbaren Dateisystem eines Containers liegen. Kubernetes kann dauerhaften Speicher über Persistent Volumes und entsprechende Anforderungen, die Persistent Volume Claims, einbinden. Eine StorageClass beschreibt, wie geeigneter Speicher bereitgestellt werden kann.
Diese Objekte machen den zugrunde liegenden Speicher nicht automatisch ausfallsicher. Eine lokale Festplatte bleibt an ihre Infrastruktur gebunden; ein externer Speicherdienst hat eigene Leistungs- und Ausfalleigenschaften. Auch eine Datenbank außerhalb des Clusters kann die passende Lösung sein. Entscheidend sind Anwendungssupport, Datenkonsistenz, Zugriffswege und die vereinbarte Wiederherstellung.
Für das Portal wird deshalb getrennt festgelegt, wie lange es ausfallen darf, welcher Datenverlust vertretbar wäre und wie ein Restore geprüft wird. Ein Cluster, der eine versehentliche Löschung zuverlässig an alle Instanzen weitergibt, ersetzt keine Sicherung. Mehr dazu bei Backup und Wiederherstellung.
Wann sich der zusätzliche Aufbau lohnt
Interessant wird Kubernetes, wenn mehrere Anwendungen regelmäßig aktualisiert werden, reproduzierbare Bereitstellung benötigt wird oder Last und verfügbare Rechner gezielt verteilt werden sollen. Zugleich entstehen Aufgaben für Updates der Plattform, Zugriffsverwaltung, Netzwerk, Speicher und Überwachung.
Bei einer einzelnen stabilen Anwendung kann ein sauber betreuter Server mit Docker Compose oder eine klassische virtuelle Maschine wirtschaftlich besser passen. Die Entscheidung sollte vom benötigten Betriebsverhalten ausgehen: Welche Unterbrechungen sind zulässig? Wie häufig gibt es Änderungen? Wer kann die Umgebung im Fehlerfall nachvollziehen und wiederherstellen?
Ein sinnvoller Pilot hat überprüfbare Ziele
- Ein repräsentativer Geschäftsablauf wird mit realistischen Datenmengen und ohne produktive Kundendaten getestet.
- Ein Update wird einschließlich einer vorgesehenen Rückkehrmöglichkeit durchgespielt. Änderungen am Datenbankschema werden dabei gesondert betrachtet.
- Der Ausfall einer Instanz und eines vorgesehenen Infrastrukturbausteins wird kontrolliert geprüft.
- Eine Sicherung wird in eine getrennte Testumgebung zurückgespielt und fachlich geöffnet.
- Für Meldungen, Plattformpflege und die Anwendung gibt es benannte Zuständigkeiten.
DAXS unterstützt bei der Bewertung der Anwendung, der passenden Infrastruktur sowie bei Umsetzung und vereinbartem Betrieb. Ein erster Schritt ist eine Bestandsaufnahme mit einem konkreten Anwendungsfall und nachvollziehbaren Abnahmekriterien.
Quellen: Kubernetes: Aufgaben und Grenzen der Plattform · Cluster-Komponenten · Pods und ihr Lebenszyklus · Deployments und Updates · Services · Persistente Speicher · Planung produktiver Umgebungen