Kundenorientierte Anwendungen auf Kubernetes: Den Dienst verfügbar halten, nicht nur die Pods

Ein kundenorientierter Dienst kann gesunde Pods haben, während Nutzer trotzdem fehlgeschlagene Logins, langsame API-Antworten, defekte Sessions, Datenbank-Timeouts, Zertifikatsfehler oder unvollständige Releases erleben. Kubernetes kann Replikate, Netzwerk, Platzierung, Health-Signale und Scaling verwalten — es garantiert nicht automatisch korrektes Anwendungsverhalten, Datenbankverfügbarkeit, Resilienz externer Abhängigkeiten oder Notfallwiederherstellung.

Ein Produktionsdesign verbindet die Kontrollmechanismen von Kubernetes mit messbaren Nutzerergebnissen, nicht nur mit der Cluster-Gesundheit.

Eine übliche Architektur: Client → DNS → CDN/DDoS-Schutz → externer Load Balancer → Gateway oder Ingress → Kubernetes Service → Anwendungs-Pods → Datenbank/Cache/Objektspeicher/externe APIs. Jede Ebene kann zur eigentlichen Verfügbarkeitsgrenze werden — drei gesunde Anwendungsreplikate helfen nicht, wenn der einzige Load Balancer, die Datenbank oder der Identity Provider nicht verfügbar ist.

Ein einzelnes Replikat erzeugt einen Single Point of Failure auf Anwendungsebene. Mehrere Replikate verbessern die Verfügbarkeit nur, wenn sie auf unabhängigen Nodes laufen, Sessions portabel sind und bei einem Ausfall ausreichend Kapazität übrig bleibt. Topology Spread Constraints können Pods über Nodes und Zonen verteilen — eine strikte Spread-Regel kann Pods aber im Zustand Pending belassen, wenn die erforderlichen Ausfalldomänen oder die Kapazität nicht verfügbar sind.

Ein PodDisruptionBudget begrenzt gleichzeitige freiwillige Unterbrechungen und kann bei Node-Wartung helfen — es verhindert keine unfreiwilligen Ausfälle und schafft selbst keine Kapazität. Ein Cluster, der mit voll ausgeschöpfter angeforderter Kapazität läuft, kann weder ein ausgefallenes Replikat ersetzen noch Surge-Pods für ein Rollout erstellen.

Ein Rolling Update bedeutet nicht automatisch Zero Downtime — es erfordert außerdem mehrere gesunde Replikate, korrekte Readiness, Graceful Shutdown, abwärtskompatible APIs, kompatibles Datenbankschema und ausreichende Surge-Kapazität.

Datenbank-Schema-Änderungen zählen zu den größten Release-Risiken — nutzen Sie ein abwärtskompatibles Expand-and-Contract-Muster: kompatibles Schema hinzufügen, dual-kompatiblen Code ausrollen, Daten migrieren und veraltetes Schema erst in einem späteren Release entfernen.

Session-Modelle reichen von zustandslosen signierten Tokens über datenbank- oder Redis-gestützte Sessions bis zu Load-Balancer-Affinity. Sticky Sessions können einen Übergang unterstützen, machen lokalen Session-Zustand aber nicht dauerhaft — sie versagen, wenn der Pod verschwindet, sich die Client-IP ändert oder Traffic in eine andere Region wechselt.

API-Design

Der HorizontalPodAutoscaler kann die Replika-Anzahl anhand von Ressourcen-, Custom- oder externen Metriken anpassen. CPU kann geeignet sein, wenn sie mit der Last korreliert — sie ist schwach, wenn die Anwendung durch Datenbank, Queue, externe API oder Connection Pool begrenzt wird. Erwägen Sie stattdessen Requests pro Sekunde, Queue-Tiefe oder gleichzeitige Anfragen.

Node-Autoscaling kann Pods im Zustand Pending erzeugen, wenn kein Node über ausreichend Kapazität verfügt — verlassen Sie sich nicht auf die Notfall-Erstellung von Nodes bei Traffic-Spitzen, die kürzer sind als die Node-Startzeit. Skalieren Sie vor absehbarer Nachfrage wie Launches oder Marketingkampagnen bereits vorab.

Die Verfügbarkeit der Anwendung kann die Verfügbarkeit ihrer Datenbank nicht übersteigen, wenn jede Anfrage von ihr abhängt — eine Kubernetes-Anwendung mit zehn Replikaten und einer ungeschützten Datenbank bleibt ein Single-Point-Dienst. Erfassen Sie jede externe Abhängigkeit (Identität, Zahlung, E-Mail, Suche, CRM) mit Timeout-, Retry-, Rate-Limit- und Fallback-Verhalten.

Gesunde Infrastruktur belegt keinen gesunden Geschäftsdienst — verfolgen Sie die p95/p99-Tail-Latenz statt nur den Durchschnitt, da eine kleine Gruppe extrem langsamer Anfragen Ihre wertvollsten oder komplexesten Vorgänge darstellen kann.

Schützen Sie Kubernetes-Ressourcen, Anwendungskonfiguration, persistente Dateien, Datenbank, Objektspeicher, Secrets und Schlüssel, Container-Images sowie die Gateway-/DNS-Konfiguration. Ein Wiederherstellungs-Cluster benötigt möglicherweise eine Gateway-Implementierung, TLS-Zertifikate, Datenbankwiederherstellung, Objektspeicher-Zugriff, Secret-Rotation und eine DNS-Umschaltung — die Wiederherstellung ist erst abgeschlossen, wenn kritische Customer Journeys in der Wiederherstellungsumgebung erfolgreich sind, nicht schon, wenn Pods „Running" melden. Das umfassendere Planungs-Framework beschreibt der Leitfaden zum Notfallwiederherstellungsplan.