Der Mythos vom „fertigen Kubernetes"

“Wir haben jetzt Kubernetes.”

Kaum ein Satz wird in IT-Projekten so häufig ausgesprochen – und gleichzeitig so unterschiedlich verstanden.

Für die einen bedeutet er, dass die technische Grundlage für eine moderne Anwendungsplattform geschaffen wurde. Für andere ist er gleichbedeutend mit der Annahme, man habe den schwierigsten Teil der Transformation bereits hinter sich. Nicht selten schwingt sogar die Erwartung mit, dass Themen wie Hochverfügbarkeit, Skalierbarkeit, Sicherheit oder Ausfallsicherheit mit der Einführung von Kubernetes weitgehend gelöst seien.

Diese Erwartung ist nachvollziehbar.

Schließlich vermitteln nahezu alle großen Cloud-Anbieter genau dieses Bild.

Innerhalb weniger Minuten lässt sich bei Amazon Web Services ein EKS-Cluster erstellen. Microsoft verspricht mit Azure Kubernetes Service (AKS) einen vollständig verwalteten Kubernetes-Dienst. Google, dessen Ingenieure Kubernetes ursprünglich maßgeblich entwickelt haben, bietet mit Google Kubernetes Engine (GKE) ebenfalls eine Plattform an, auf der ein produktionsbereiter Cluster mit wenigen Klicks bereitsteht.

Auch zahlreiche Hosting-Anbieter werben mit ähnlich einfachen Versprechen. Kubernetes erscheint dort als Dienstleistung, die sich ähnlich unkompliziert buchen lässt wie früher eine virtuelle Maschine.

Die Botschaft ist stets dieselbe:

Der Cluster ist schnell erstellt.

Und genau das stimmt.

Ein Kubernetes-Cluster lässt sich heute tatsächlich innerhalb weniger Minuten bereitstellen. Was vor wenigen Jahren noch tiefgehende Kenntnisse über verteilte Systeme, Zertifikatsinfrastrukturen und Netzwerkkonzepte erforderte, übernimmt heute weitgehend eine Automatisierung. Der API-Server wird eingerichtet, etcd initialisiert, Worker Nodes werden registriert und die grundlegenden Komponenten des Control Plane starten ohne manuelle Eingriffe.

Aus Sicht der Infrastruktur ist das ein bemerkenswerter Fortschritt.

Aus Sicht des späteren Betriebs ist es jedoch lediglich der Anfang.

Die Verwechslung von Bereitstellung und Betrieb

Genau an dieser Stelle beginnt der Denkfehler, der sich durch erstaunlich viele Kubernetes-Projekte zieht.

Unternehmen verwechseln die Bereitstellung einer Plattform mit deren Betrieb.

Diese Unterscheidung wirkt auf den ersten Blick wie sprachliche Spitzfindigkeit. Tatsächlich beschreibt sie jedoch zwei völlig unterschiedliche Disziplinen.

Die Bereitstellung beantwortet eine vergleichsweise einfache Frage:

“Kann ich Kubernetes starten?”

Der Betrieb beantwortet eine wesentlich komplexere:

“Kann ich mit Kubernetes über Jahre hinweg zuverlässig geschäftskritische Anwendungen betreiben?”

Zwischen beiden Fragen liegen Welten.

Ein Cluster kann innerhalb weniger Minuten entstehen.

Eine belastbare Betriebsplattform entsteht häufig erst nach Monaten – und entwickelt sich anschließend kontinuierlich weiter.

Diese Differenz wird in vielen Projekten unterschätzt, weil sich der sichtbare Erfolg sehr früh einstellt.

Bereits nach kurzer Zeit lässt sich die erste Anwendung deployen. Pods starten. Services werden angelegt. Ein Ingress veröffentlicht die Anwendung nach außen. Die ersten Lasttests verlaufen erfolgreich. Das Projekt wirkt abgeschlossen.

Tatsächlich befindet sich die Plattform zu diesem Zeitpunkt noch in ihrer einfachsten Ausbaustufe.

Viele der eigentlichen Herausforderungen treten erst dann auf, wenn aus einer Demonstration ein produktives System wird.

Der Unterschied zwischen einer Demo und einer Produktionsplattform

Nahezu jede Kubernetes-Demonstration folgt demselben Muster.

Ein Entwickler erstellt einen Cluster.

Anschließend wird eine Anwendung deployt.

Nach wenigen Minuten ist sie über einen Browser erreichbar.

Die Präsentation endet meist mit einer automatischen Skalierung oder einem Rollout einer neuen Version.

Beeindruckend ist das durchaus.

Es vermittelt jedoch ein Bild, das mit dem späteren Alltag nur wenig gemeinsam hat.

Denn produktive Systeme bestehen selten aus einer einzelnen Anwendung.

Ein mittelständisches Softwareunternehmen betreibt häufig Dutzende Microservices. Hinzu kommen Datenbanken, Messaging-Systeme, Caches, Suchindizes, Monitoring-Komponenten, Authentifizierungsdienste, CI/CD-Systeme sowie zahlreiche interne Werkzeuge.

Jede dieser Komponenten besitzt eigene Anforderungen hinsichtlich Verfügbarkeit, Datensicherheit, Performance und Wartbarkeit.

Mit jedem zusätzlichen Dienst steigt die Anzahl möglicher Wechselwirkungen.

Ein Fehler in der Netzwerkkonfiguration kann plötzlich mehrere Anwendungen gleichzeitig betreffen.

Eine fehlerhafte DNS-Konfiguration verhindert möglicherweise die Kommunikation zwischen internen Services.

Ein falsch konfigurierter Admission Controller blockiert sämtliche Deployments.

Ein übersehener Zertifikatsablauf führt dazu, dass externe Clients keine Verbindung mehr herstellen können.

Nichts davon ist ein Kubernetes-Problem.

Und genau das macht diese Situationen so anspruchsvoll.

Kubernetes löst genau das Problem, für das es entwickelt wurde

Ein weiterer Grund für die verbreitete Fehleinschätzung liegt in der öffentlichen Wahrnehmung von Kubernetes selbst.

Über Kubernetes wird häufig gesprochen, als handele es sich um eine universelle Plattform für den Betrieb moderner Software.

Tatsächlich verfolgt Kubernetes ein wesentlich enger definiertes Ziel.

Das Projekt entstand bei Google aus den Erfahrungen mit Borg – einem internen System, das über viele Jahre hinweg Millionen von Containern koordinierte. Die zentrale Fragestellung lautete dabei nicht, wie Anwendungen entwickelt werden sollten, sondern wie sich eine große Anzahl voneinander unabhängiger Workloads zuverlässig über tausende Server hinweg orchestrieren lässt.

Kubernetes wurde deshalb als Container-Orchestrator entwickelt.

Nicht als Monitoring-System.

Nicht als Sicherheitsplattform.

Nicht als Backup-Lösung.

Nicht als CI/CD-System.

Nicht als Identity-Provider.

Nicht als Plattform zur Einhaltung regulatorischer Anforderungen.

Diese bewusste Fokussierung gehört zu den größten Stärken des Projekts.

Sie führt allerdings dazu, dass Unternehmen häufig Fähigkeiten erwarten, die Kubernetes niemals bereitstellen sollte.

Ein Orchestrator beantwortet eine klar umrissene Fragestellung:

Welche Container sollen mit welcher Konfiguration auf welchen Ressourcen laufen – und wie lässt sich dieser gewünschte Zustand dauerhaft sicherstellen?

Mehr nicht.

Alles andere entsteht außerhalb von Kubernetes.

Der Einfluss des Cloud-Marketings

Warum wird dieser Unterschied dennoch so häufig übersehen?

Ein wesentlicher Grund liegt im Marketing der vergangenen Jahre.

Kaum eine Technologie wurde so intensiv beworben wie Kubernetes.

Cloud-Anbieter präsentierten Kubernetes als Fundament moderner Softwareentwicklung. Beratungsunternehmen bezeichneten Kubernetes als unverzichtbaren Baustein jeder Digitalisierungsstrategie. Stellenanzeigen verlangten Kubernetes-Kenntnisse nahezu unabhängig von der tatsächlichen Aufgabe.

Damit entstand ein bemerkenswerter Effekt.

Nicht selten fiel die Entscheidung für Kubernetes bereits, bevor überhaupt klar war, welches Problem gelöst werden sollte.

Die Frage lautete nicht mehr:

“Welche Anforderungen haben unsere Anwendungen?”

Sondern:

“Wie setzen wir diese Anforderungen mit Kubernetes um?”

Technologisch ist das ein entscheidender Unterschied.

Architektur sollte stets aus den fachlichen Anforderungen entstehen.

Nicht aus der Popularität einer bestimmten Technologie.

Kubernetes ist ein hervorragendes Werkzeug.

Aber wie jedes Werkzeug entfaltet es seinen Nutzen nur dann vollständig, wenn es für die richtige Aufgabe eingesetzt wird.

Die eigentliche Herausforderung beginnt nach dem Go-live

Wer ein Kubernetes-Projekt erfolgreich in Produktion gebracht hat, erlebt häufig einen kurzen Moment der Erleichterung.

Die Anwendung läuft.

Die Deployments funktionieren.

Das Monitoring liefert erste Metriken.

Der Cluster wirkt stabil.

Aus Projektsicht scheint das Ziel erreicht.

Aus Betriebssicht beginnt jetzt erst die eigentliche Arbeit.

Denn produktive Plattformen altern.

Nicht schlagartig, sondern kontinuierlich.

Neue Sicherheitslücken werden veröffentlicht.

APIs werden als veraltet markiert.

Container-Images müssen aktualisiert werden.

Abhängigkeiten verändern sich.

Compliance-Anforderungen wachsen.

Neue Anwendungen stellen neue Anforderungen an Netzwerk, Storage oder Identitätsmanagement.

Mit jedem Monat nimmt die Zahl technischer Entscheidungen zu, die bewusst getroffen, dokumentiert und regelmäßig überprüft werden müssen.

Genau dieser fortlaufende Veränderungsprozess wird häufig unterschätzt.

Kubernetes ist kein Projekt mit einem definierten Endpunkt.

Kubernetes ist eine Betriebsentscheidung.

Und genau darin liegt der fundamentale Unterschied.

Während klassische Infrastrukturprojekte häufig mit der erfolgreichen Inbetriebnahme abgeschlossen werden konnten, beginnt bei Kubernetes nach der Inbetriebnahme erst die eigentliche Verantwortung.

Wer diese Verantwortung von Anfang an realistisch bewertet, schafft die Grundlage für eine belastbare Plattform.

Wer sie unterschätzt, wird früher oder später feststellen, dass nicht der Cluster zum Problem geworden ist, sondern die Vielzahl der betrieblichen Aufgaben, die sich rund um ihn entwickelt haben.

Im nächsten Kapitel betrachten wir deshalb genauer, was Kubernetes technisch tatsächlich leistet – und warum gerade seine Architektur erklärt, weshalb der Betrieb moderner Plattformen weit über das eigentliche Orchestrieren von Containern hinausgeht.

Was Kubernetes eigentlich ist – und warum genau darin seine größte Stärke liegt

Bevor wir darüber sprechen können, warum der Betrieb einer Kubernetes-Plattform so aufwendig ist, müssen wir zunächst verstehen, welche Aufgabe Kubernetes überhaupt erfüllt.

Denn ein bemerkenswerter Widerspruch zieht sich bis heute durch viele Projekte.

Je populärer Kubernetes geworden ist, desto diffuser ist häufig das Verständnis seiner eigentlichen Funktion.

Für die einen ist Kubernetes eine Cloud.

Für andere eine Virtualisierungstechnologie.

Manche verstehen darunter eine Entwicklungsplattform, andere wiederum ein Deployment-Werkzeug oder ein Betriebssystem für Container.

Nichts davon trifft den Kern.

Kubernetes ist weder Betriebssystem noch Cloud-Plattform. Es ist auch keine Software, die Anwendungen “ausführt”. Kubernetes trifft überhaupt keine fachlichen Entscheidungen. Es kennt weder den Zweck einer Anwendung noch deren geschäftliche Bedeutung. Ob ein Pod einen Webshop, ein Krankenhausinformationssystem oder einen Minecraft-Server bereitstellt, spielt für Kubernetes keine Rolle.

Diese strikte Gleichgültigkeit gegenüber der Fachlichkeit ist kein Mangel.

Sie ist der Grund dafür, dass Kubernetes überhaupt in der Lage ist, nahezu jede Art von Anwendung zu orchestrieren.

Vom imperativen zum deklarativen Betrieb

Um diesen Gedanken zu verstehen, lohnt sich ein kurzer Blick auf die Art und Weise, wie Infrastruktur früher betrieben wurde.

Über Jahrzehnte dominierte ein imperatives Betriebsmodell.

Ein Administrator meldete sich auf einem Server an und führte konkrete Befehle aus.

Er installierte Pakete.

Er startete Prozesse.

Er änderte Konfigurationsdateien.

Er öffnete Firewall-Regeln.

Er passte Speichergrenzen an.

Jeder dieser Schritte veränderte den Zustand des Systems unmittelbar.

Das Problem bestand allerdings darin, dass der tatsächliche Zustand eines Servers nach einigen Monaten kaum noch nachvollziehbar war.

Warum existierte diese Konfiguration?

Wann wurde sie geändert?

Von wem?

War dieselbe Änderung auch auf allen anderen Servern erfolgt?

Mit zunehmender Anzahl von Systemen wurde diese Vorgehensweise praktisch unbeherrschbar.

Infrastructure as Code war die erste Antwort auf dieses Problem.

Kubernetes geht einen entscheidenden Schritt weiter.

Anstatt einzelne Befehle auszuführen, beschreibt der Betreiber lediglich den gewünschten Endzustand.

Nicht:

Starte diesen Container.

Sondern:

Es sollen jederzeit fünf Instanzen dieser Anwendung verfügbar sein.

Nicht:

Öffne Port 443.

Sondern:

Diese Anwendung soll über HTTPS erreichbar sein.

Nicht:

Starte den Container erneut.

Sondern:

Diese Anwendung darf niemals weniger als fünf funktionierende Instanzen besitzen.

Dieser Unterschied wirkt zunächst sprachlich.

Tatsächlich verändert er die gesamte Philosophie des Plattformbetriebs.

Kubernetes arbeitet mit einem gewünschten Zustand

Das Herzstück von Kubernetes ist ein Konzept, das sich Desired State Management nennt.

Nahezu jede Ressource innerhalb eines Clusters folgt demselben Prinzip.

Der Betreiber beschreibt den gewünschten Zustand.

Kubernetes versucht anschließend kontinuierlich, genau diesen Zustand herzustellen.

Und zwar unabhängig davon, warum er momentan nicht existiert.

Fällt ein Worker Node aus, startet Kubernetes die betroffenen Pods auf einem anderen Node.

Wird ein Container versehentlich gelöscht, erzeugt Kubernetes automatisch einen neuen.

Skaliert eine Anwendung aufgrund steigender Last von fünf auf zehn Replikate, sorgt Kubernetes dafür, dass diese zusätzlichen Instanzen tatsächlich entstehen.

Entscheidend dabei ist, dass Kubernetes nicht auf einzelne Ereignisse reagiert.

Es überprüft kontinuierlich, ob Realität und Sollzustand übereinstimmen.

In der Literatur spricht man deshalb häufig vom Reconciliation Pattern.

Das System befindet sich in einer permanenten Korrekturschleife.

Es vergleicht.

Es erkennt Abweichungen.

Es versucht, sie zu beseitigen.

Immer wieder.

Diese Architektur unterscheidet Kubernetes fundamental von klassischen Administrationswerkzeugen.

Der API-Server ist das eigentliche Herz des Systems

Viele Administratoren glauben zunächst, Kubernetes bestehe hauptsächlich aus Containern und Worker Nodes.

Technisch betrachtet ist das jedoch nur die sichtbare Oberfläche.

Die eigentliche Wahrheit über den Zustand eines Clusters befindet sich an einer völlig anderen Stelle.

Im Kubernetes API Server.

Nahezu jede Interaktion mit Kubernetes erfolgt über diese zentrale API.

Ob ein Entwickler ein Deployment erstellt, ob Argo CD eine neue Version ausrollt, ob der Horizontal Pod Autoscaler zusätzliche Pods anfordert oder ob ein Controller neue Ressourcen erzeugt – sämtliche Änderungen laufen über den API-Server.

Er ist die einzige autoritative Instanz.

Es existiert kein anderer Ort innerhalb des Clusters, an dem entschieden wird, wie das System aussehen soll.

Das ist ein bemerkenswert eleganter Architekturansatz.

Denn dadurch spielt es letztlich keine Rolle, welches Werkzeug Änderungen erzeugt.

Ob kubectl, Terraform, Helm, Argo CD oder ein eigener Operator – am Ende sprechen alle dieselbe Sprache.

Die API.

Diese konsequente Trennung zwischen Beschreibung und Ausführung bildet die Grundlage des gesamten Kubernetes-Ökosystems.

etcd – die unscheinbarste und zugleich wichtigste Komponente

Fragt man Administratoren nach den wichtigsten Bestandteilen eines Kubernetes-Clusters, werden meist Scheduler oder Control Plane genannt.

Dabei wird eine Komponente erstaunlich häufig unterschätzt.

etcd.

Dabei handelt es sich um eine verteilte Schlüssel-Wert-Datenbank.

Auf den ersten Blick klingt das wenig spektakulär.

Tatsächlich speichert etcd den vollständigen Zustand des gesamten Clusters.

Welche Deployments existieren?

Welche Pods laufen?

Welche Nodes sind registriert?

Welche Services wurden angelegt?

Welche ConfigMaps existieren?

Welche Secrets wurden gespeichert?

Welche Custom Resources wurden erstellt?

Nahezu jede Information über den Cluster landet letztlich in etcd.

Geht diese Datenbank verloren, verliert Kubernetes nicht unmittelbar die laufenden Container.

Es verliert jedoch das Wissen darüber, wie der Cluster eigentlich aussehen sollte.

Deshalb zählt etcd zu den kritischsten Komponenten einer Kubernetes-Infrastruktur.

Backups des Clusters sind in Wirklichkeit häufig nichts anderes als konsistente Sicherungen dieser Datenbank ergänzt um persistente Anwendungsdaten.

Wer diesen Zusammenhang versteht, erkennt schnell, warum Disaster Recovery in Kubernetes deutlich komplexer ist als das Kopieren einiger YAML-Dateien.

Controller statt Skripte

Ein weiteres Konzept macht Kubernetes außergewöhnlich.

Nahezu jede Funktion des Systems wird durch sogenannte Controller umgesetzt.

Ein Controller verfolgt immer dieselbe Aufgabe.

Er beobachtet den Zustand des Clusters.

Er erkennt Abweichungen.

Er versucht, diese Abweichungen zu korrigieren.

Der ReplicaSet Controller stellt sicher, dass genügend Pods existieren.

Der Deployment Controller organisiert Rollouts neuer Versionen.

Der Node Controller erkennt ausgefallene Worker Nodes.

Der Job Controller überwacht Batch-Prozesse.

Der Horizontal Pod Autoscaler reagiert auf Metriken und passt die Anzahl der Replikate an.

Bemerkenswert ist dabei weniger ihre Existenz als ihre Architektur.

Anstatt zentrale Logik in Kubernetes selbst einzubauen, wird nahezu jede Funktion als eigenständiger Controller implementiert.

Genau deshalb lassen sich eigene Controller entwickeln.

Operatoren wie Cert-Manager, ExternalDNS oder Prometheus funktionieren letztlich nach demselben Prinzip.

Sie erweitern Kubernetes nicht durch Änderungen am Kernsystem.

Sie nutzen dieselben Mechanismen wie Kubernetes selbst.

Dadurch entsteht ein erstaunlich konsistentes Ökosystem.

Gleichzeitig erklärt genau dieses Prinzip, weshalb Kubernetes heute aus tausenden voneinander unabhängigen Erweiterungen besteht.

Und damit beginnt bereits das nächste Problem.

Kubernetes kennt keine Anwendungen

Für viele Entscheider klingt der Begriff “Anwendungsplattform” selbstverständlich.

Technisch betrachtet ist er jedoch irreführend.

Kubernetes kennt keine Anwendungen.

Es kennt lediglich Ressourcen.

Pods.

Deployments.

ReplicaSets.

StatefulSets.

DaemonSets.

Services.

Ingresses.

Persistent Volume Claims.

ConfigMaps.

Secrets.

Aus Sicht von Kubernetes existiert keine “CRM-Anwendung”.

Es existiert lediglich eine Sammlung von Ressourcen, deren gewünschter Zustand beschrieben wurde.

Diese scheinbar kleine Unterscheidung besitzt enorme praktische Auswirkungen.

Denn Kubernetes erkennt beispielsweise nicht, ob ein Deployment fachlich erfolgreich war.

Ein Pod kann den Status Running besitzen und dennoch keinerlei sinnvolle Funktion erfüllen.

Eine REST-API kann auf Port 443 erreichbar sein und trotzdem jede Anfrage mit einem HTTP-500 beantworten.

Ein Microservice kann vollständig gesund erscheinen, obwohl seine Verbindung zur Datenbank seit Stunden unterbrochen ist.

Kubernetes bewertet ausschließlich infrastrukturelle Zustände.

Nicht fachliche Qualität.

Hier endet seine Verantwortung.

Warum genau diese Architektur so erfolgreich wurde

An diesem Punkt könnte man den Eindruck gewinnen, Kubernetes sei erstaunlich unvollständig.

Tatsächlich verhält es sich genau umgekehrt.

Gerade weil Kubernetes so wenige Annahmen über Anwendungen trifft, konnte sich ein außergewöhnlich großes Ökosystem entwickeln.

Nahezu jede moderne Plattformlösung baut heute auf denselben grundlegenden Mechanismen auf.

GitOps-Werkzeuge.

Service Meshes.

Policy Engines.

Backup-Lösungen.

Security Scanner.

Observability-Plattformen.

Sie alle nutzen dieselbe API.

Dieselbe deklarative Architektur.

Dasselbe Reconciliation-Prinzip.

Die Stärke von Kubernetes liegt deshalb nicht darin, möglichst viele Funktionen selbst bereitzustellen.

Seine Stärke besteht darin, ein universelles Kontrollsystem für Infrastruktur bereitzustellen, das sich nahezu beliebig erweitern lässt.

Genau daraus entsteht jedoch eine Konsequenz, die für Betreiber häufig unterschätzt wird.

Je offener ein System für Erweiterungen ist, desto größer wird zwangsläufig die Verantwortung für deren Auswahl, Integration, Wartung und Zusammenspiel.

Mit anderen Worten:

Die Architektur, die Kubernetes so erfolgreich gemacht hat, ist gleichzeitig der Grund dafür, weshalb der Betrieb produktiver Plattformen erheblich komplexer ist, als es die Bereitstellung eines Clusters zunächst vermuten lässt.

Im nächsten Kapitel betrachten wir deshalb genau diese Konsequenz. Denn Kubernetes löst viele Probleme bewusst nicht – und genau dort entstehen später die Aufgaben, die in den meisten Projektplänen nur unzureichend berücksichtigt werden.

Warum Kubernetes viele Probleme bewusst nicht löst

Nachdem wir verstanden haben, was Kubernetes eigentlich ist, drängt sich zwangsläufig eine weitere Frage auf:

Wenn Kubernetes so leistungsfähig ist – warum benötigt man dann überhaupt noch so viele zusätzliche Komponenten?

Die Antwort darauf liegt nicht in einer technischen Einschränkung, sondern in einer bewussten Architekturentscheidung.

Kubernetes wurde niemals mit dem Ziel entwickelt, sämtliche Anforderungen moderner IT-Plattformen abzudecken. Im Gegenteil: Die Entwickler haben über viele Jahre hinweg sehr konsequent darauf geachtet, den Funktionsumfang des eigentlichen Kerns möglichst klein zu halten.

Diese Entscheidung wirkt zunächst kontraintuitiv.

Schließlich wäre es naheliegend gewesen, Monitoring, Logging, Backup oder Zertifikatsmanagement direkt in Kubernetes zu integrieren.

Genau das ist jedoch nie geschehen.

Und das aus gutem Grund.

Das Unix-Prinzip – neu gedacht für verteilte Systeme

Bereits in den frühen 1970er-Jahren formulierten die Entwickler des Unix-Betriebssystems einen Grundsatz, der bis heute als einer der wichtigsten Entwurfsprinzipien der Informatik gilt:

“Do one thing and do it well.”

Software sollte möglichst genau eine Aufgabe erfüllen – diese dafür aber zuverlässig.

Anstatt eine riesige Anwendung mit hunderten Funktionen zu entwickeln, kombiniert man spezialisierte Werkzeuge miteinander.

Dieses Prinzip findet sich heute nahezu überall wieder.

Linux selbst besteht aus hunderten einzelner Programme.

Git konzentriert sich ausschließlich auf Versionsverwaltung.

PostgreSQL ist eine Datenbank und kein Webserver.

NGINX ist ein Webserver und keine Datenbank.

OpenTelemetry sammelt Telemetriedaten, betreibt aber kein Dashboard.

Auch Kubernetes folgt exakt diesem Gedanken.

Seine Aufgabe besteht darin, den gewünschten Zustand einer Infrastruktur sicherzustellen.

Nicht mehr.

Nicht weniger.

Alles andere würde den Kern unnötig aufblähen.

Warum Kubernetes keine Backup-Lösung besitzt

Ein gutes Beispiel ist das Thema Datensicherung.

Nahezu jedes Unternehmen benötigt Backups.

Warum besitzt Kubernetes also keine eingebaute Backup-Funktion?

Die Antwort lautet:

Weil Kubernetes gar nicht wissen kann, was überhaupt gesichert werden soll.

Betrachten wir eine PostgreSQL-Datenbank.

Die eigentlichen Daten liegen auf einem Persistent Volume.

Gleichzeitig existieren Konfigurationsdateien innerhalb des Clusters.

Zusätzlich laufen möglicherweise Replikationsprozesse, Datenbanktransaktionen oder Write-Ahead-Logs.

Ein einfaches Kopieren des Dateisystems genügt häufig nicht, um eine konsistente Sicherung zu erzeugen.

Je nach Datenbank unterscheiden sich die Anforderungen erheblich.

Oracle arbeitet anders als PostgreSQL.

MongoDB anders als MySQL.

Redis besitzt wiederum völlig andere Anforderungen.

Kubernetes könnte unmöglich für jede dieser Technologien eine optimale Backup-Strategie implementieren.

Stattdessen stellt Kubernetes lediglich die Infrastruktur bereit, auf der spezialisierte Backup-Werkzeuge arbeiten können.

Velero ist dafür ein bekanntes Beispiel.

Andere Unternehmen setzen auf Snapshot-Mechanismen ihrer Storage-Systeme oder integrieren professionelle Enterprise-Backup-Lösungen.

Kubernetes trifft hier bewusst keine Entscheidung.

Das gleiche Problem existiert beim Netzwerk

Noch deutlicher wird dieses Prinzip beim Thema Netzwerk.

Viele Administratoren gehen davon aus, dass Kubernetes automatisch sämtliche Netzwerkkommunikation organisiert.

Tatsächlich definiert Kubernetes lediglich ein Netzwerkmodell.

Jeder Pod soll eine eigene IP-Adresse erhalten.

Pods sollen unabhängig vom Host miteinander kommunizieren können.

Network Policies sollen den Datenverkehr einschränken können.

Wie diese Anforderungen technisch umgesetzt werden, schreibt Kubernetes jedoch nicht vor.

Genau hier kommen sogenannte Container Network Interfaces (CNI) ins Spiel.

Calico.

Cilium.

Flannel.

Weave Net.

OVN-Kubernetes.

Alle erfüllen dieselbe grundlegende Aufgabe.

Ihre interne Architektur unterscheidet sich jedoch erheblich.

Cilium beispielsweise nutzt eBPF und verlagert viele Netzwerkfunktionen direkt in den Linux-Kernel. Dadurch lassen sich Firewall-Regeln, Load Balancing oder Observability deutlich effizienter umsetzen als mit klassischen iptables-basierten Ansätzen.

Calico verfolgt dagegen einen anderen Schwerpunkt und ist insbesondere im Enterprise-Umfeld weit verbreitet.

Welches System die bessere Wahl darstellt, hängt von den Anforderungen ab.

Benötigt ein Unternehmen WireGuard?

IPv6?

BGP-Routing?

Network Encryption?

Service Mesh Integration?

Clusterübergreifende Kommunikation?

Es gibt keine universell richtige Antwort.

Deshalb enthält Kubernetes bewusst keine eigene Implementierung.

Storage ist niemals “nur Storage”

Ähnlich verhält es sich bei persistenten Daten.

Container selbst sind grundsätzlich flüchtig.

Wird ein Pod gelöscht, verschwinden sämtliche lokal gespeicherten Daten.

Für zustandslose Anwendungen wie Webserver ist das unproblematisch.

Für Datenbanken wäre es eine Katastrophe.

Kubernetes löst dieses Problem über sogenannte Persistent Volumes.

Doch auch hier fällt auf:

Kubernetes stellt lediglich die Abstraktion bereit.

Die eigentliche Speicherung erfolgt außerhalb des Clusters.

Je nach Infrastruktur können dabei völlig unterschiedliche Technologien zum Einsatz kommen.

Lokale NVMe-SSDs.

Ceph.

NetApp.

Longhorn.

AWS EBS.

Azure Managed Disks.

Google Persistent Disks.

NFS.

SAN-Systeme.

Alle unterscheiden sich hinsichtlich Latenz, Replikation, Snapshots, Ausfallsicherheit und Performance.

Ein Datenbankcluster reagiert äußerst sensibel auf diese Unterschiede.

Ein Storage-System mit hoher Latenz kann selbst leistungsfähige Anwendungen massiv ausbremsen.

Ein fehlendes Multi-Attach-Feature verhindert bestimmte Architekturen.

Unzureichende Snapshot-Funktionen erschweren Disaster-Recovery-Szenarien.

Kubernetes kennt diese Unterschiede nicht.

Es abstrahiert sie lediglich.

Die Verantwortung für die richtige Architektur verbleibt beim Betreiber.

Kubernetes besitzt kein Sicherheitskonzept für Unternehmen

Kaum ein Bereich wird häufiger missverstanden.

Natürlich verfügt Kubernetes über umfangreiche Sicherheitsmechanismen.

Role Based Access Control (RBAC).

Pod Security Standards.

Admission Controller.

Network Policies.

Secrets.

Security Contexts.

All diese Funktionen existieren.

Sie bilden jedoch lediglich Werkzeuge.

Ein Sicherheitskonzept entsteht dadurch noch lange nicht.

Ein Beispiel verdeutlicht den Unterschied.

Kubernetes erlaubt die Definition von Rollen.

Es entscheidet jedoch nicht, welche Rolle ein Entwickler erhalten sollte.

Kubernetes kann Network Policies durchsetzen.

Es analysiert jedoch nicht, welche Kommunikationsbeziehungen innerhalb einer Anwendung überhaupt zulässig sind.

Kubernetes kann Container isolieren.

Es prüft jedoch nicht automatisch, ob das verwendete Container-Image bekannte Sicherheitslücken enthält.

Auch Themen wie Image Signing, Software Supply Chain Security, SBOMs oder CVE-Management gehören nicht zum Kernsystem.

Sie werden durch spezialisierte Lösungen ergänzt.

Der Betreiber muss entscheiden, welche davon eingesetzt werden.

Die eigentliche Stärke liegt im Erweiterungsmodell

Bis hierhin könnte leicht der Eindruck entstehen, Kubernetes sei unvollständig.

Das Gegenteil ist der Fall.

Die eigentliche Innovation liegt gerade darin, dass Kubernetes nicht versucht, jedes Problem selbst zu lösen.

Stattdessen stellt es einen universellen Erweiterungsmechanismus bereit.

Die wichtigste Grundlage dafür bilden die Custom Resource Definitions (CRDs).

CRDs erlauben es, Kubernetes um vollständig neue Ressourcentypen zu erweitern.

Für Kubernetes spielt es letztlich keine Rolle, ob eine Ressource “Deployment”, “Pod” oder “Certificate” heißt.

Sobald eine Ressource über die API definiert wurde, können Controller ihren Zustand überwachen und verwalten.

Dieses Konzept hat das Kubernetes-Ökosystem grundlegend verändert.

Ein Zertifikat wird plötzlich zu einer Kubernetes-Ressource.

Eine Datenbank ebenfalls.

Ein DNS-Eintrag.

Ein Backup.

Ein Kafka-Cluster.

Selbst komplette Cloud-Ressourcen lassen sich heute deklarativ über Kubernetes verwalten.

Operatoren wie Crossplane oder ACK (AWS Controllers for Kubernetes) gehen sogar noch einen Schritt weiter.

Sie ermöglichen die Bereitstellung externer Cloud-Infrastruktur direkt über die Kubernetes-API.

Virtuelle Netzwerke.

Load Balancer.

Datenbanken.

Objektspeicher.

Alles erscheint plötzlich wie eine native Kubernetes-Ressource.

Architektonisch ist das ausgesprochen elegant.

Operativ erhöht es jedoch zwangsläufig die Komplexität.

Jede zusätzliche Komponente erzeugt neue Abhängigkeiten

Und genau hier beginnt das eigentliche Problem vieler Plattformen.

Ein Unternehmen entscheidet sich beispielsweise für Cert-Manager, um TLS-Zertifikate automatisch verwalten zu lassen.

Eine sinnvolle Entscheidung.

Kurz darauf wird ExternalDNS eingeführt, damit DNS-Einträge automatisch erzeugt werden.

Dann folgt Argo CD für GitOps.

Prometheus Operator für Monitoring.

Loki für Logaggregation.

Tempo für Distributed Tracing.

External Secrets zur Integration eines Secret Stores.

Kyverno oder Open Policy Agent für Richtlinien.

Velero für Backups.

Harbor als Container Registry.

Innerhalb weniger Monate besteht die Plattform nicht mehr aus Kubernetes.

Sie besteht aus mehreren Dutzend voneinander abhängiger Open-Source-Projekte.

Jedes einzelne besitzt seinen eigenen Release-Zyklus.

Eigene Sicherheitsupdates.

Eigene Konfigurationsoptionen.

Eigene Deprecation-Strategien.

Eigene Dokumentation.

Eigene Community.

Eigene Fehlerbilder.

Genau diese Komplexität ist in der Anfangsphase kaum sichtbar.

Sie wächst schleichend.

Mit jeder weiteren Entscheidung steigt die Zahl möglicher Wechselwirkungen – nicht linear, sondern nahezu exponentiell. Denn jede neue Komponente interagiert nicht nur mit Kubernetes selbst, sondern potenziell auch mit allen bereits vorhandenen Komponenten.

Aus einem Container-Orchestrator wird dadurch schrittweise eine vollständige Plattform.

Und genau an diesem Punkt verändert sich auch die eigentliche Aufgabe des Betreibers.

Er betreibt längst nicht mehr Kubernetes.

Er betreibt ein komplexes, verteiltes Softwaresystem, dessen zentrale Eigenschaft nicht seine Größe ist, sondern die Vielzahl technischer Abhängigkeiten, die verstanden, dokumentiert, aktualisiert und kontinuierlich aufeinander abgestimmt werden müssen.

Diese Erkenntnis markiert den Übergang zum eigentlichen Kern dieses Artikels.

Denn bislang haben wir ausschließlich über Architektur gesprochen.

Ab dem nächsten Kapitel verlassen wir die Theorie und betrachten den Alltag einer produktiven Plattform. Dort zeigt sich, weshalb erfahrene Plattformingenieure kaum über den “Day-1”, also die Inbetriebnahme eines Clusters, sprechen – sondern fast ausschließlich über Day-2-Operations.

Denn genau dort entstehen der überwiegende Teil der Kosten, der Risiken und des personellen Aufwands, den Unternehmen bei der Einführung von Kubernetes systematisch unterschätzen.

Day-2-Operations: Warum der eigentliche Aufwand erst nach dem Go-live beginnt

In nahezu jedem Kubernetes-Projekt existiert ein Moment, der sich wie ein Meilenstein anfühlt.

Die erste Anwendung läuft.

Der Ingress beantwortet Anfragen.

Die CI/CD-Pipeline deployt erfolgreich in den Cluster.

Die Dashboards zeigen grüne Statusanzeigen.

Aus Sicht des Projekts scheint das Ziel erreicht.

Aus Sicht des Betriebs hat die eigentliche Arbeit gerade erst begonnen.

Diese Unterscheidung wird in vielen Organisationen unterschätzt, weil IT-Projekte traditionell einem linearen Muster folgen. Anforderungen werden definiert, Software wird entwickelt, Infrastruktur wird bereitgestellt und nach erfolgreicher Inbetriebnahme geht das Projekt in den Regelbetrieb über.

Kubernetes funktioniert anders.

Mit der Bereitstellung eines Clusters endet kein Projekt. Es beginnt vielmehr ein kontinuierlicher Prozess, dessen Aufwand sich nicht aus einzelnen Aufgaben, sondern aus der permanenten Veränderung eines komplexen Systems ergibt.

Genau deshalb unterscheiden erfahrene Plattformingenieure zwischen Day-1-Operations und Day-2-Operations.

Day 1 beschreibt alles, was notwendig ist, um eine Plattform erstmals produktiv zu nehmen.

Day 2 beschreibt alles, was danach passiert.

Und genau dort entstehen die Kosten, die in Business Cases, Projektplänen und Budgetkalkulationen regelmäßig unterschätzt werden.

Infrastruktur altert – auch wenn sie fehlerfrei funktioniert

Ein weit verbreiteter Irrtum besteht in der Annahme, eine funktionierende Plattform benötige lediglich gelegentliche Wartung.

Tatsächlich altert jede produktive Infrastruktur kontinuierlich.

Nicht, weil Hardware verschleißt.

Sondern weil Software niemals statisch ist.

Jede Woche erscheinen neue Sicherheitsmeldungen. Bibliotheken veröffentlichen Bugfixes. Container-Images werden aktualisiert. Linux-Kernel erhalten Patches. APIs werden erweitert oder als veraltet markiert. Neue Compliance-Anforderungen entstehen. Kryptographische Verfahren verändern sich. Zertifikate laufen ab.

Selbst wenn sich an der eigenen Anwendung kein einziges Byte verändert, verändert sich die Umgebung, in der sie betrieben wird.

Wer diese Veränderungen ignoriert, erhält keine stabile Plattform.

Er erhält eine Plattform, deren technischer Schuldenberg mit jedem Monat wächst.

Ein Kubernetes-Upgrade ist niemals nur ein Kubernetes-Upgrade

Besonders deutlich zeigt sich dieser Effekt bei Versionsupdates.

Wer bisher hauptsächlich klassische Server administriert hat, verbindet ein Upgrade häufig mit einem überschaubaren Vorgang.

Neue Version installieren.

Dienst neu starten.

Funktion testen.

Fertig.

Im Kubernetes-Umfeld ist diese Vorstellung kaum noch haltbar.

Nehmen wir an, ein Unternehmen möchte seinen Cluster von Kubernetes 1.31 auf Version 1.32 aktualisieren.

Der eigentliche Upgrade-Prozess ist dabei häufig die kleinste Herausforderung.

Die entscheidende Frage lautet vielmehr:

Welche Auswirkungen besitzt diese Änderung auf sämtliche Komponenten, die auf Kubernetes aufbauen?

Verwendet das Unternehmen den Prometheus Operator?

Unterstützt die eingesetzte Version bereits die neue Kubernetes-Version?

Wie verhält sich Argo CD?

Sind sämtliche Custom Resource Definitions kompatibel?

Verwendet Cert-Manager APIs, die in der neuen Kubernetes-Version entfernt wurden?

Funktionieren Admission Webhooks weiterhin?

Arbeitet der CNI-Treiber mit dem aktualisierten Linux-Kernel zusammen?

Sind alle Helm-Charts kompatibel?

Existieren Breaking Changes in verwendeten Operatoren?

Kann die Storage-Lösung weiterhin Snapshots erzeugen?

Diese Fragen besitzen keine allgemeingültige Antwort.

Sie müssen für jede Plattform individuell beantwortet werden.

Mit zunehmender Anzahl integrierter Komponenten entsteht dadurch ein hochkomplexes Abhängigkeitsnetz, dessen Pflege weit über die eigentliche Aktualisierung von Kubernetes hinausgeht.

Komplexität wächst nicht linear

Ein häufiger Denkfehler besteht darin, die Größe einer Plattform anhand der Anzahl ihrer Anwendungen zu bewerten.

In Wirklichkeit bestimmt nicht die Anzahl der Anwendungen die Komplexität.

Entscheidend ist die Anzahl der Wechselwirkungen.

Eine einzelne Anwendung besitzt vergleichsweise wenige Abhängigkeiten.

Zwanzig Anwendungen teilen sich Netzwerk, Storage, Authentifizierung, Monitoring, Logging, Zertifikatsverwaltung, Container Registry, DNS, Backup-Systeme und Deployment-Pipelines.

Plötzlich beeinflusst eine scheinbar kleine Änderung zahlreiche andere Systeme gleichzeitig.

Ein neues Sicherheitsfeature im Ingress Controller verändert möglicherweise das Verhalten sämtlicher APIs.

Ein fehlerhaftes Zertifikats-Update betrifft plötzlich alle öffentlich erreichbaren Dienste.

Eine Anpassung der Network Policies kann unbemerkt interne Kommunikationspfade unterbrechen.

Komplexität entsteht deshalb nicht durch die Anzahl der Ressourcen.

Sie entsteht durch ihre gegenseitigen Abhängigkeiten.

Und genau diese Abhängigkeiten werden mit jeder zusätzlichen Komponente dichter.

Die eigentliche Herausforderung ist Unsicherheit

Interessanterweise verursachen bekannte Aufgaben selten größere Probleme.

Ein Administrator weiß, wie ein Zertifikat erneuert wird.

Ein Plattformteam weiß, wie ein Node ersetzt wird.

Schwieriger sind Situationen, in denen mehrere Systeme gleichzeitig beteiligt sind.

Ein Beispiel.

Eine Anwendung antwortet plötzlich deutlich langsamer als gewöhnlich.

Die CPU-Auslastung ist niedrig.

Auch der Arbeitsspeicher zeigt keine Auffälligkeiten.

Die Pods laufen stabil.

Ist die Datenbank verantwortlich?

Das Netzwerk?

Ein DNS-Problem?

Ein fehlerhaftes Deployment?

Eine geänderte Firewall-Regel?

Eine überlastete Storage-Anbindung?

Eine externe API?

Die Herausforderung besteht nun nicht darin, Kubernetes zu verstehen.

Die Herausforderung besteht darin, die Ursache innerhalb eines verteilten Systems zu identifizieren.

Und genau dafür benötigen moderne Plattformen weit mehr als einen funktionierenden Cluster.

Betrieb bedeutet Verantwortung

Mit jeder Plattform wächst nicht nur die technische Komplexität.

Es wächst auch die organisatorische Verantwortung.

Wer entscheidet über Wartungsfenster?

Wer bewertet Sicherheitsmeldungen?

Wer priorisiert kritische CVEs?

Wer dokumentiert Architekturänderungen?

Wer testet Disaster-Recovery-Szenarien?

Wer stellt sicher, dass Backups tatsächlich wiederhergestellt werden können?

Wer analysiert Incidents?

Wer aktualisiert Runbooks?

Wer überprüft, ob Monitoring-Regeln noch sinnvoll sind?

Diese Aufgaben erscheinen selten in Architekturdiagrammen.

Sie entscheiden jedoch darüber, ob eine Plattform über Jahre hinweg zuverlässig betrieben werden kann.

Genau deshalb sprechen erfahrene Site Reliability Engineers häufig davon, dass Plattformbetrieb weniger ein Infrastrukturproblem als ein Organisationsproblem sei.

Technologie lässt sich einkaufen.

Verantwortung nicht.

Day-2-Operations sind kein Ausnahmefall – sie sind der eigentliche Betrieb

Die vielleicht wichtigste Erkenntnis lautet daher:

Der produktive Betrieb einer Kubernetes-Plattform besteht nicht aus gelegentlichen Eingriffen zwischen zwei Releases.

Er besteht nahezu ausschließlich aus Day-2-Operations.

Updates.

Fehleranalysen.

Kapazitätsplanung.

Sicherheitsbewertungen.

Automatisierungen.

Dokumentation.

Tests.

Optimierungen.

Compliance.

Incident Response.

All diese Aufgaben begleiten eine Plattform während ihres gesamten Lebenszyklus.

Wer sie als Nebensache betrachtet, unterschätzt nicht Kubernetes.

Er unterschätzt den Betrieb moderner Softwareplattformen.

---

Im zweiten Teil dieses Beitrags verlassen wir die architektonische Perspektive und betrachten die konkreten Disziplinen, aus denen professioneller Plattformbetrieb tatsächlich besteht – von Observability über Security bis hin zu Disaster Recovery und der Frage, warum Managed Kubernetes den größten Teil dieser Verantwortung keineswegs übernimmt.