Kubernetes-Architektur: wie der Cluster wirklich funktioniert

Artikel-Übersicht

Kubernetes hat den Ruf, schwer zu sein, und dieser Ruf ist berechtigt — aber der Grund liegt nicht in der Menge der Komponenten. Er liegt darin, dass Kubernetes anders denkt als fast alles andere in der Werkzeugkette. Dieser Artikel beginnt deshalb beim Grundprinzip: Zielzustand statt Befehl, und ein Regelkreis, der beides dauerhaft angleicht. Wer das verstanden hat, liest Fehlermeldungen anders. Danach gehen wir die Steuerungsebene durch — jede Komponente mit der Frage, was bei ihrem Ausfall passiert —, dann die Knoten und die Objekte, mit denen man tatsächlich arbeitet. Ein eigener Abschnitt räumt die Verwirrung um Docker und Kubernetes auf, inklusive der Historie, die sie verursacht. Fünf Gründe erklären, warum sich das alles schwer anfühlt, und zum Schluss die ehrliche Frage, ob du Kubernetes überhaupt brauchst.

Das Grundprinzip: Zielzustand statt Befehl

Kubernetes nimmt keine Befehle entgegen, sondern Zielzustände — und versucht danach dauerhaft, den tatsächlichen Zustand daran anzugleichen.

Dieser eine Satz erklärt die Hälfte aller Überraschungen. Wenn du einen Pod löschst, der zu einem Deployment gehört, kommt er wieder. Das ist kein Fehler und kein Automatismus, den jemand eingeschaltet hat — es ist das Wesen des Systems. Du hast erklärt, dass drei Instanzen laufen sollen. Kubernetes stellt sicher, dass drei laufen.

Der Mechanismus dahinter heißt Regelkreis: Eine Kontrollschleife vergleicht laufend Soll und Ist und unternimmt Schritte, um die Differenz zu verkleinern. Für jede Objektart gibt es einen solchen Controller.

Der Unterschied zur gewohnten Denkweise:

	Imperativ	Deklarativ
Du sagst	„starte einen Container"	„drei Instanzen sollen laufen"
Bei Ausfall	nichts passiert	Ersatz wird gestartet
Wiederholte Ausführung	startet noch einen	ändert nichts
Fehler zeigt sich	sofort im Rückgabewert	später, in Ereignissen

Die letzte Zeile ist der praktische Kern: Der Befehl, mit dem du etwas anlegst, war erfolgreich, sobald der Wunsch angenommen wurde — nicht, wenn er erfüllt ist. Wer kubectl apply ausführt und ein „created" sieht, weiß noch nichts darüber, ob es läuft.

Die Steuerungsebene

Vier Komponenten, jeweils mit der Frage, was bei ihrem Ausfall passiert:

API-Server. Die einzige Tür ins System. Jeder Befehl, jeder Controller, jedes Werkzeug spricht ausschließlich mit ihm. Fällt er aus: Es kann nichts mehr geändert werden — laufende Anwendungen laufen aber weiter.

etcd. Der Speicher für den gesamten Clusterzustand. Fällt er aus: Der API-Server hat nichts mehr zu lesen und zu schreiben; der Cluster ist eingefroren. Deshalb ist die Sicherung von etcd die wichtigste Betriebsmaßnahme überhaupt.

Scheduler. Entscheidet, auf welchem Knoten ein neuer Pod laufen soll — nach verfügbaren Ressourcen, Regeln und Verteilungswünschen. Fällt er aus: Neue Pods bleiben im Zustand „ausstehend"; bestehende laufen weiter.

Controller Manager. Beherbergt die Regelkreise für die Standardobjekte. Fällt er aus: Nichts wird mehr nachgeregelt — ein ausgefallener Pod bekommt keinen Ersatz.

Das Muster ist bei allen vieren dasselbe: Ein Ausfall der Steuerungsebene stoppt Änderungen, nicht den Betrieb. Anwendungen, die laufen, laufen weiter. Das ist eine bewusste Entwurfsentscheidung und der Grund, warum ein Cluster einen Ausfall der Steuerungsebene überstehen kann.

Die Knoten

Auf jedem Arbeitsknoten laufen drei Dinge:

kubelet — der Vertreter der Steuerungsebene auf dem Knoten. Er fragt beim API-Server, was hier laufen soll, und sorgt dafür.

Container-Laufzeit — startet die Container tatsächlich. Und hier die Klarstellung, die vieles auflöst: Kubernetes startet keine Container selbst. Es beauftragt eine Laufzeitumgebung über eine standardisierte Schnittstelle.

kube-proxy — kümmert sich um die Netzwerkregeln, damit Dienste unter einer stabilen Adresse erreichbar sind, egal auf welchem Knoten der Pod gerade läuft.

Die Objekte, mit denen man wirklich arbeitet

Objekt	Wofür	Wer erzeugt es	Häufigster Fehler
Pod	eine oder mehrere Container, die zusammengehören	fast nie von Hand	direkt anlegen statt über ein Deployment
Deployment	gewünschte Anzahl Pods, Rollout, Rückrollung	du	Ressourcengrenzen vergessen
Service	stabile Adresse für eine Menge von Pods	du	falsche Selektoren — findet keine Pods
Ingress	HTTP-Zugang von außen	du	fehlender Ingress-Controller
ConfigMap	Konfiguration	du	Änderung wirkt nicht ohne Neustart
Secret	Zugangsdaten	du	nur base64-kodiert, nicht verschlüsselt
PersistentVolumeClaim	dauerhafter Speicher	du	Speicherklasse passt nicht zum Knoten
Namespace	Trennung von Bereichen	einmalig	Ressourcengrenzen nicht gesetzt

Zwei Punkte, die Einsteiger regelmäßig kosten:

Man erzeugt fast nie Pods direkt. Ein einzelner Pod wird bei Ausfall nicht ersetzt — dafür braucht es ein Deployment. Wer zum Ausprobieren einen Pod anlegt und sich wundert, dass er nach einem Knotenneustart verschwunden ist, hat genau das erlebt.

Secrets sind nicht verschlüsselt. Sie sind base64-kodiert, was Lesbarkeit verhindert, aber keine Sicherheit bietet. Verschlüsselung im Ruhezustand ist eine Clusterkonfiguration, die man aktiv einschalten muss.

Kubernetes und Docker

Die Verwirrung ist historisch begründet und lohnt eine saubere Auflösung.

Docker ist eine Werkzeugkette: Es baut Images, verwaltet sie und startet Container auf einer Maschine. Kubernetes plant und überwacht Container über viele Maschinen hinweg. Die beiden lösen verschiedene Probleme.

Was für Verwirrung sorgt: In den Anfangsjahren nutzte Kubernetes Docker direkt als Laufzeitumgebung. Später wurde eine standardisierte Schnittstelle eingeführt, und die Unterstützung für Docker als Laufzeit wurde entfernt — Kubernetes spricht heute mit schlankeren Laufzeiten, die diese Schnittstelle direkt bedienen.

Für die Praxis ändert das nichts: Images, die mit Docker gebaut wurden, laufen in Kubernetes unverändert. Das Bildformat ist standardisiert; nur die Komponente, die den Container startet, ist eine andere. Wer damals die Meldungen über das Ende der Docker-Unterstützung gelesen und sich Sorgen gemacht hat, hat sich umsonst gesorgt.

Wie man Images baut, worauf beim Build Context zu achten ist und wie eine Compose-Datei aussieht, steht in Docker Build Context, .dockerignore und Compose.

Warum es sich schwer anfühlt

Fünf Gründe, jeder mit einem Gegenmittel:

1. Deklarativ statt imperativ. Wer imperativ denkt, versteht die Rückmeldungen nicht. Gegenmittel: Bei jedem Problem zuerst fragen — was ist der Sollzustand, was ist der Istzustand, und warum kommt der Controller nicht dorthin?

2. Jede Abstraktion hat eine darunter, die durchschlägt. Besonders das Netzwerk: Solange es funktioniert, muss man es nicht verstehen; sobald es nicht funktioniert, muss man alles darunter verstehen. Gegenmittel: Das Netzwerkmodell früh lernen, nicht erst im Vorfall.

3. YAML ohne Typsicherheit. Ein falsch eingerückter Block erzeugt keine Fehlermeldung, sondern ein Objekt, das etwas anderes bedeutet. Gegenmittel: Schemaprüfung im Editor und im Bauvorgang.

4. Fehler sind asynchron. Der Befehl war erfolgreich, das Ergebnis erscheint Sekunden später — und zwar in den Ereignissen, nicht im Rückgabewert. Gegenmittel: kubectl describe und die Ereignisse eines Objekts sind der erste Blick, nicht der letzte.

5. Der Erweiterungsraum ist unbegrenzt. Jeder Cluster hat eigene Operatoren, eigene Ressourcentypen, eigene Regeln. Wissen aus einem Cluster überträgt sich nur teilweise. Gegenmittel: Die Kernobjekte beherrschen, den Rest im konkreten Cluster nachschlagen.

Brauchst du Kubernetes?

Die ehrliche Antwort für die meisten Projekte lautet: nein, noch nicht.

Kubernetes löst Probleme, die man ab einer bestimmten Größe hat: viele Dienste, die unabhängig ausgerollt werden; automatischer Ersatz ausgefallener Instanzen; Skalierung nach Last; einheitliche Verwaltung über mehrere Umgebungen. Wer diese Probleme nicht hat, zahlt Komplexität ohne Gegenwert.

Die Schwelle, an der es kippt:

Lage	Empfehlung
Ein bis drei Dienste, ein Server	Container mit Compose, fertig
Wenige Dienste, aber Ausfallsicherheit gefordert	verwaltete Container-Plattform
Viele Dienste, mehrere Teams, wechselnde Last	Kubernetes
Kein Betriebsteam, aber Kubernetes gefordert	verwaltetes Angebot, keinesfalls selbst betreiben

Die letzte Zeile ist wichtig: Einen Cluster selbst zu betreiben ist eine eigene Disziplin. Wer Kubernetes nutzen will, aber kein Team dafür hat, nimmt ein verwaltetes Angebot — für den DACH-Raum gibt es solche mit Rechenzentren in der EU und der Schweiz, was bei Datenschutzanforderungen den Ausschlag gibt. Mehr zu dieser Abwägung in Cloud-Architektur und KI.

Ob die Zerlegung in viele Dienste überhaupt die richtige Entscheidung war, ist die vorgelagerte Frage — behandelt in Microservices oder Monolith.

Was man zuerst lernt

Eine Reihenfolge, die sich bewährt hat:

1. Pod-Lebenszyklus. Welche Zustände es gibt und was sie bedeuten.
2. Deployment und Rollout. Wie eine neue Version ausgerollt und zurückgenommen wird.
3. Service und Namensauflösung. Wie Dienste einander finden.
4. Ressourcengrenzen. Anforderungen und Obergrenzen — der häufigste Grund für unerklärliche Neustarts.
5. Ereignisse und Protokolle lesen. describe, logs, events. Damit löst man achtzig Prozent aller Probleme.

Später kommen Speicher, Netzwerkrichtlinien, Operatoren und Paketierung. Aber erst später — die fünf oben tragen die ersten Monate.

Für den Betrieb gehört Beobachtbarkeit von Anfang an dazu; womit man dabei anfängt, steht in Monitoring und Observability.

Häufige Fragen

Wie ist Kubernetes aufgebaut? Aus einer Steuerungsebene mit API-Server, etcd, Scheduler und Controller Manager sowie Arbeitsknoten mit kubelet, Container-Laufzeit und kube-proxy.

Warum ist Kubernetes so schwer? Weil es deklarativ arbeitet, Fehler asynchron auftreten, YAML keine Typsicherheit bietet, jede Abstraktion durchschlagen kann und der Erweiterungsraum unbegrenzt ist.

Ist Kubernetes schwerer als Docker? Ja, deutlich — sie lösen aber verschiedene Probleme. Docker baut und startet Container auf einer Maschine, Kubernetes plant und überwacht sie über viele.

In welcher Sprache ist Kubernetes geschrieben? In Go — wie ein großer Teil der Infrastrukturwerkzeuge dieser Generation.

Lohnt es sich noch, Kubernetes zu lernen? Als Betriebsplattform ist es der De-facto-Standard. Für Entwickler lohnt sich das Verständnis der Kernobjekte; die Betriebstiefe braucht nur, wer den Cluster selbst verantwortet.

Braucht man Kubernetes überhaupt? Unter drei Diensten und ohne Ausfallsicherheitsanforderung meist nicht. Ohne eigenes Betriebsteam nur als verwaltetes Angebot.

Zusammenfassung und praktische Tipps

Kubernetes ist ein Regelkreissystem, kein Werkzeugkasten — und das ist der Schlüssel zu allem Weiteren. Die wichtigsten Punkte:

• Zielzustand statt Befehl. Ein gelöschter Pod kommt wieder, weil du erklärt hast, dass er laufen soll.
• Ein Ausfall der Steuerungsebene stoppt Änderungen, nicht den Betrieb.
• etcd sichern ist die wichtigste Betriebsmaßnahme.
• Pods legt man nicht direkt an, Secrets sind nicht verschlüsselt — zwei Einsteigerfallen.
• Docker-Images laufen unverändert, auch seit Docker nicht mehr die Laufzeit ist.
• describe und Ereignisse sind der erste Blick, nicht der letzte.
• Ohne Betriebsteam nur verwaltet — einen Cluster selbst zu betreiben ist eine eigene Disziplin.

Mein Rat für den Einstieg: Lösch als Erstes bewusst einen Pod, der zu einem Deployment gehört, und sieh zu, wie er wiederkommt. Dieser eine Versuch vermittelt das deklarative Modell besser als jedes Kapitel — und ab da liest du Fehlermeldungen als Frage danach, warum der Regelkreis sein Ziel nicht erreicht, statt als Meldung über einen fehlgeschlagenen Befehl.

Ressourcen

• Kubernetes – Konzepte – die offizielle Dokumentation, teilweise auf Deutsch
• Kubernetes – Komponenten – Steuerungsebene und Knoten im Detail
• Don't Panic: Kubernetes and Docker – die offizielle Klarstellung zur Laufzeitfrage
• kubectl – Spickzettel – die Befehle für den Alltag