Was ist Kubernetes? Architektur und Einsatz erklärt

Kubernetes ist eine offene Plattform, die containerisierte Anwendungen über mehrere Rechner hinweg bereitstellt, überwacht und an einen gewünschten Zustand angleicht. Statt einzelne Container manuell zu starten, beschreiben Sie das Ziel. Die Steuerung verteilt Arbeitslasten, ersetzt ausgefallene Instanzen und hält Netzwerkzugänge trotz wechselnder Pods stabil.

Wofür Kubernetes da ist

Ein einzelner Container ist schnell gestartet. Der Betrieb wird anspruchsvoll, sobald eine Anwendung aus mehreren Diensten besteht, Änderungen kontrolliert ausgerollt werden sollen und ein ausgefallener Prozess ersetzt werden muss. Kubernetes koordiniert diese Aufgaben über einen Cluster aus physischen oder virtuellen Maschinen.

Kubernetes ist eine Regelmaschine für den Betrieb. Sie übergeben nicht für jeden Container eine Folge manueller Befehle. Sie beschreiben Objekte mit einem gewünschten Zustand. Controller vergleichen diesen Zustand fortlaufend mit der Realität und veranlassen Korrekturen, wenn beides auseinanderläuft.

Das System übernimmt dabei vor allem diese Aufgaben:

• Es weist Arbeitslasten geeigneten Rechnern im Cluster zu.
• Es hält die angeforderte Zahl funktionsfähiger Anwendungsinstanzen aufrecht.
• Es führt Änderungen kontrolliert aus und meldet den Stand des Rollouts.
• Es stellt wechselnden Pods einen stabilen Netzwerkzugang gegenüber.
• Es bindet Speicher, Konfiguration und Zugangsdaten an Arbeitslasten.

Das klingt nach vollständiger Automatisierung, ist aber nur die halbe Wahrheit. Kubernetes setzt Regeln um, die jemand entwerfen, testen und überwachen muss. Eine schlechte Bereitschaftsprüfung wird zuverlässig ausgeführt und liefert trotzdem ein falsches Bild. Betrieb schlägt Prospekt, auch bei Orchestrierung.

Wie ein Kubernetes-Cluster aufgebaut ist

Ein Cluster besteht aus einer Control Plane und mindestens einem Worker Node. Die Control Plane verwaltet den Zustand des Clusters. Worker Nodes stellen die Laufzeit für Pods bereit. Diese Trennung ist logisch: Eine produktive Installation kann die Komponenten auf mehrere Maschinen verteilen und gegen Ausfälle absichern.

Die Control Plane steuert, sie arbeitet nicht allein. Der API-Server nimmt Änderungen und Abfragen entgegen. Der Scheduler weist noch nicht platzierte Pods geeigneten Nodes zu. Controller treiben den tatsächlichen Zustand zum gewünschten Zustand. Die Zustandsdaten des Clusters liegen in einem konsistenten Schlüssel-Wert-Speicher.

Auf jedem Worker Node sorgt das Kubelet dafür, dass die vorgesehenen Pods laufen. Eine Container-Laufzeit startet deren Container. Netzwerkkomponenten setzen die Erreichbarkeit um. Diese Bausteine sind getrennt, arbeiten aber an demselben Modell, das über die Kubernetes-API beschrieben wird.

Die Skizze reduziert den Cluster bewusst auf die Betriebsbeziehung: oben die steuernde Control Plane, darunter die ausführenden Nodes mit Pods und davor der stabile Service-Zugang.

Pods, Deployments und Services auseinanderhalten

Ein Pod ist die kleinste von Kubernetes bereitgestellte Recheneinheit. Er enthält einen oder mehrere eng gekoppelte Container, die Netzwerk und gegebenenfalls Speicher gemeinsam nutzen. Im Normalfall behandeln Sie einen Pod als ersetzbar. Seine Identität ist nicht der dauerhafte Bezugspunkt einer Anwendung.

Ein Deployment verwaltet eine Menge von Pods für eine meist zustandslose Arbeitslast. Sie beschreiben ein Pod-Muster und den gewünschten Zustand. Der zugehörige Controller erzeugt oder ersetzt Pods und führt Aktualisierungen kontrolliert aus. Die Anwendung muss dennoch mit Unterbrechungen einzelner Instanzen umgehen können.

Ein Service entkoppelt Clients von den wechselnden Pod-Endpunkten. Er wählt passende Pods über Labels aus und bietet dafür einen beständigeren Netzwerkzugang. Ein Service bedeutet nicht automatisch Internetzugriff. Ob ein Zugang nur im Cluster oder extern verfügbar ist, hängt von Typ und Netzarchitektur ab.

Labels sind die Kupplung zwischen Objekten. Stimmen Selektoren und Labels nicht überein, findet ein Service keine passenden Pods oder ein Controller verwaltet die falsche Menge. Prüfen Sie deshalb nicht nur, ob Objekte existieren, sondern ob ihre Beziehungen tatsächlich aufgelöst werden.

Gewünschter Zustand statt Startskript

Der zentrale Unterschied zu einer einfachen Container-Liste liegt in der Regelung. Sie erklären beispielsweise, welche Arbeitslast laufen und wie sie erreichbar sein soll. Kubernetes beobachtet den Ist-Zustand und reagiert auf Abweichungen. Dieses Prinzip wird als Reconciliation bezeichnet.

Fällt ein Container aus, kann ihn das Kubelet entsprechend der Neustartregel erneut starten. Geht ein Pod eines verwalteten Workloads verloren, kann der Controller einen Ersatz anlegen. Wird ein Node nicht mehr verfügbar, können geeignete Arbeitslasten auf anderen Nodes neu eingeplant werden.

Das System weiß jedoch nur, was seine Messpunkte erkennen. Eine Liveness-Prüfung beantwortet, ob ein Prozess neu gestartet werden soll. Eine Readiness-Prüfung entscheidet, ob eine Instanz Verkehr erhalten darf. Eine Startup-Prüfung schützt langsam startende Anwendungen vor vorschnellen Neustarts.

Selbstheilung ist kein Fehlerverständnis. Kubernetes kann einen abgestürzten Container ersetzen. Es repariert keinen Programmfehler, keine falsche Datenmigration und keinen unerreichbaren externen Dienst. Auch ein beschädigter oder nicht verfügbarer Speicher verlangt einen eigenen Wiederherstellungsweg.

Speicher und Zustand bleiben die harte Stelle

Zustandslose Webdienste lassen sich leichter ersetzen, weil ihre wichtigen Daten außerhalb des Pods liegen. Datenbanken, Warteschlangen und andere zustandsbehaftete Dienste benötigen dauerhaften Speicher, klare Identitäten und geordnete Abläufe. Kubernetes stellt dafür Objekte bereit, nimmt Ihnen die Speicherkonstruktion aber nicht ab.

Ein Persistent Volume beschreibt Speicher, der den Lebenszyklus eines Pods überdauern kann. Ein Claim fordert passenden Speicher für eine Arbeitslast an. Ob der Speicher bei einem Node-Ausfall tatsächlich an anderer Stelle verfügbar wird, entscheidet die zugrunde liegende Speichertechnik und ihre Einbindung.

Ein Volume ist noch keine Sicherung. Ein Snapshot im selben Fehlerbereich hilft wenig, wenn Zugang, Konto oder Standort ausfallen. Für wichtige Daten brauchen Sie eine getrennte Sicherung, einen dokumentierten Rückweg und einen Wiederherstellungstest außerhalb des laufenden Clusters.

Fragen Sie nach dem Ausfallpfad: Was geschieht, wenn ein Node verschwindet, die Control Plane nicht erreichbar ist oder der Speicher keine Schreibzugriffe mehr annimmt? Die Antworten bestimmen, ob Kubernetes Ihre Verfügbarkeit verbessert oder nur mehr bewegliche Teile erzeugt.

Was Kubernetes nicht automatisch liefert

Die Plattform ist noch kein Produktivbetrieb. Viele notwendige Fähigkeiten kommen aus ergänzenden Komponenten oder aus der Betriebsumgebung. Dazu gehören ein passendes Pod-Netz, DNS, ein Zugang von außen, Zertifikate, Protokollsammlung, Metriken, Alarmierung, Sicherungen und eine belastbare Identitätsverwaltung.

Die Grenzen sind nüchtern und betriebsrelevant:

• Kubernetes baut keine fehlerfreie Anwendung aus fehlerhaftem Code.
• Es garantiert ohne passende Topologie keine Hochverfügbarkeit.
• Es ersetzt weder Datenbanksicherung noch Wiederherstellungstest.
• Es entscheidet nicht selbst über angemessene Ressourcen und Grenzwerte.
• Es aktualisiert Cluster und Erweiterungen nicht ohne Betriebsrisiko.

Jede Erweiterung hat einen Lebenszyklus. Netz- und Speicherplugins, Ingress- oder Gateway-Komponenten sowie Überwachungssysteme müssen mit der Cluster-Version zusammenpassen. Bei einer Aktualisierung prüfen Sie deshalb nicht nur Kubernetes selbst, sondern die vollständige Abhängigkeitskette.

Eigener Cluster oder verwalteter Dienst

Bei einem selbst betriebenen Cluster besitzen Sie mehr Kontrolle über Netz, Speicher und Aktualisierungszeitpunkt. Sie tragen dafür die Verantwortung für Control Plane, Sicherung, Zertifikate, Aktualisierungen und Störungsanalyse. Auf gemieteten Servern etwa von Hetzner oder OVHcloud bleibt auch die Architektur oberhalb der Maschinen Ihre Aufgabe.

Ein verwalteter Kubernetes-Dienst nimmt typischerweise Teile des Control-Plane-Betriebs ab. Er löst jedoch nicht automatisch die Fragen Ihrer Arbeitslast: Ressourcenplanung, sichere Images, Zugriffsrechte, Netzwerkregeln, Datenhaltung, Observability und Kostenkontrolle bleiben beim Betreiber der Anwendung.

Vergleichen Sie beide Wege nicht nur über den Maschinenpreis. Rechnen Sie Bereitschaft, Aktualisierungen, Überwachung, Sicherungen und den Rückweg aus einer Störung mit ein. Reaktionszeit zählt in Minuten, aber die dafür nötige Betriebsbereitschaft kostet auch außerhalb eines Ausfalls Zeit.

Wann Kubernetes passt und wann nicht

Kubernetes passt, wenn mehrere containerisierte Dienste konsistent ausgerollt werden müssen, wechselnde Last oder viele Instanzen zu koordinieren sind und ein Team die Plattform dauerhaft betreiben kann. Es ist besonders nützlich, wenn deklarative Abläufe und standardisierte Schnittstellen wichtiger sind als eine möglichst kleine Systemoberfläche.

Für eine kleine Anwendung auf einem einzelnen Server kann Kubernetes unnötige Komplexität schaffen. Docker Compose, ein Systemdienst oder ein einfacher Plattformdienst sind dann oft leichter zu verstehen, zu sichern und wiederherzustellen. Die richtige Frage lautet nicht, ob Kubernetes modern wirkt, sondern ob seine Regelung einen realen Betriebsengpass beseitigt.

Meiden Sie Kubernetes vorerst, wenn niemand für Cluster-Aktualisierungen zuständig ist, Sicherung und Wiederherstellung ungeklärt sind oder die Anwendung ihre Zustände nicht sauber trennt. Ein Orchestrator ordnet vorhandene Betriebsdisziplin. Er erzeugt sie nicht.

Kubernetes lohnt sich, wenn seine Regelkreise echte Betriebsarbeit vereinheitlichen und ein Team die zusätzliche Plattform beherrscht. Prüfen Sie zuerst Fehlerbereiche, Datenpfad und Aktualisierung. Wenn ein kleineres Werkzeug denselben Dienst transparenter wiederherstellbar macht, ist das die bessere Architektur.