Kubernetes einfach erklärt: was ist das?

Kubernetes ist ein Open-Source-System, das Container auf vielen Servern automatisch verteilt, überwacht und bei Ausfällen neu startet. In Kubernetes beschreibst du, was das Cluster laufen lassen soll, zum Beispiel drei Kopien deines Webshops, und das System kümmert sich darum, dass genau dieser Zustand entsteht und erhalten bleibt. Das ist der Kern. Alles andere, von Skalierung bis Rollout ohne Ausfall, folgt aus diesem Prinzip.

Ich arbeite seit 2017 mit Kubernetes, habe in einem Operations-Team mehrere Cluster betrieben und 2024 bei Rheinwerk das Buch „Kubernetes: Das Praxisbuch für Entwickler und DevOps-Teams" veröffentlicht. Heute betreibe ich produktionsreife Cluster für mittelständische Unternehmen und für meine eigene Website, die selbst als Container in Kubernetes läuft. Alle meine Beiträge zum Thema findest du gesammelt auf der Seite Kubernetes.

Dieser Beitrag ist der Einstieg: die Grundlagen, ein erstes Deployment zum Mitmachen und eine ehrliche Einordnung, für wen Kubernetes sich lohnt und für wen nicht.

Kubernetes: was ist das und welches Problem löst es?

Um Kubernetes zu verstehen, hilft ein Blick darauf, woher es kommt. Google betreibt containerisierte Workloads laut kubernetes.io schon seit über einem Jahrzehnt in Produktion und hat dafür ein eigenes Verwaltungssystem gebaut: Borg. Es hat Container auf Server verteilt, gestartet, überwacht, neu gestartet und die Hardware so dicht gepackt, dass möglichst wenig Rechenleistung brachlag. Kubernetes ist die Neuentwicklung dieser Ideen als Open-Source-Projekt. Der erste öffentliche Commit stammt aus dem Juni 2014, und mit Version 1.0 hat Google das Projekt an die Cloud Native Computing Foundation übergeben. Die Geschichte dazu erzählt der Beitrag über Borg als Vorgänger von Kubernetes auf kubernetes.io.

Warum braucht es so ein System überhaupt? Weil Container zwar leichtgewichtig und portabel sind, aber niemand dir sagt, auf welchem Server sie laufen sollen. Solange du eine Anwendung auf einem Server hast, reicht Docker. Sobald du zwanzig Services in je drei Kopien auf fünf Servern betreibst, brauchst du eine Antwort auf Fragen wie: Wo ist noch Platz? Wer startet den Container neu, wenn er abstürzt? Wie findet der Webserver die Datenbank, wenn sie gerade auf einen anderen Server umgezogen ist? Was passiert nachts um drei, wenn ein Server stirbt?

Genau das ist Container-Orchestrierung, und Kubernetes ist das Werkzeug, das sich dafür durchgesetzt hat. In meinen ersten Kubernetes-Jahren, in einem Unternehmen, das jede Anwendung in die Cloud migrieren wollte, habe ich erlebt, wie sich dadurch die Arbeit im Betrieb verändert: Vorher brauchte eine Lastspitze zur Weihnachtsaktion wochenlange Kapazitätsplanung, danach war es ein Eintrag in einer Datei.

Deklarativ: du beschreibst den Zustand, Kubernetes stellt ihn her

Das wichtigste Konzept in Kubernetes ist der gewünschte Zustand. Du sagst nicht „starte Container A auf Server 3", sondern „von Anwendung A sollen drei Kopien laufen". Kubernetes vergleicht dann laufend den Ist-Zustand mit dem Soll-Zustand und gleicht Abweichungen aus. Stirbt ein Server, laufen die drei Kopien nach kurzer Zeit auf den übrigen Servern. Löscht jemand versehentlich einen Container, steht wenige Sekunden später ein neuer da.

Diese Arbeitsweise verändert den Umgang mit Servern. In der Welt der klassischen Anwendungen sind Server wie Haustiere: Sie haben Namen, werden gepflegt und dürfen auf keinen Fall sterben. In Kubernetes sind Server Nutztiere mit Nummern: Fällt einer aus, übernimmt ein anderer, und niemand trauert. Der Fachbegriff dafür ist Pets versus Cattle, und er gilt auch für die Container selbst. Die Frage, die du dir bei jeder Anwendung stellen solltest, lautet: Würde ein Nutzer merken, wenn genau dieser Container jetzt verschwindet? Wenn ja, ist die Anwendung noch nicht bereit für Kubernetes.

Wichtig für die Erwartung: Das Self-Healing von Kubernetes ist am Ende ein sehr zuverlässiges Aus- und Einschalten. Ein Container, der wegen eines Programmierfehlers abstürzt, wird neu gestartet und stürzt wieder ab. Kubernetes hält das System am Leben, aber es repariert deinen Code nicht.

Die Kubernetes-Grundlagen: Cluster, Control Plane, Node, Pod

Ein Kubernetes-Cluster besteht aus zwei Arten von Maschinen. Die Control Plane ist das Gehirn: Sie nimmt deine Beschreibungen entgegen, speichert sie und entscheidet, welcher Container wo laufen soll. Die Worker Nodes sind die Muskeln: Auf ihnen laufen die eigentlichen Container. In meinen Clustern auf Hetzner laufen drei Control-Plane-Nodes in drei verschiedenen Rechenzentren, damit der Ausfall eines Rechenzentrums das Cluster nicht lahmlegt. Für den Einstieg reicht auch eine einzige Maschine, die beides gleichzeitig ist.

Darauf aufbauend gibt es eine Handvoll Objekte, die du am Anfang wirklich brauchst:

Objekt	Wofür	Ein Satz zum Merken
Pod	Kleinste Einheit, ein oder mehrere Container mit gemeinsamer IP	Kubernetes plant und rollt Pods aus, nicht einzelne Container
Deployment	Hält eine gewünschte Anzahl gleicher Pods am Leben und rollt neue Versionen aus	Das Objekt, das du zu 90 Prozent selbst schreibst
Service	Stabile Adresse und Lastverteilung vor wechselnden Pods	Die Telefonnummer, die gleich bleibt, egal wer abnimmt
Ingress	Leitet HTTP-Anfragen von außen an Services weiter	Der Empfang mit der Ausschilderung
ConfigMap und Secret	Konfiguration und Zugangsdaten getrennt vom Image	Nie Passwörter ins Image backen

Pods erzeugst du in der Praxis nicht direkt, sondern über ein Deployment. Der Grund: Ein einzelner Pod wird nach einem Node-Ausfall nicht ersetzt, ein Deployment sorgt dafür. Wie die Komponenten der Control Plane im Detail zusammenspielen, vom API-Server bis zum Scheduler, steht in Kubernetes-Architektur: die Komponenten.

Ein erstes Deployment in 19 Zeilen

Theorie ist gut, ein Manifest ist besser. Das folgende Deployment beschreibt drei Kopien eines Nginx-Webservers. Speichere es als webshop.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webshop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webshop
  template:
    metadata:
      labels:
        app: webshop
    spec:
      containers:
        - name: webshop
          image: nginx:stable
          ports:
            - containerPort: 80

Lies das Manifest von oben nach unten: kind sagt, welches Objekt du beschreibst. replicas: 3 ist der gewünschte Zustand. Der selector sagt dem Deployment, welche Pods zu ihm gehören, und das template ist die Bauanleitung für jeden einzelnen Pod, hier ein Container mit dem Image nginx:stable auf Port 80. Der Selector und die Labels im Template müssen zusammenpassen, sonst lehnt Kubernetes das Manifest ab.

Ins Cluster bringst du die Datei mit kubectl apply. Danach siehst du innerhalb weniger Sekunden drei Pods:

$ kubectl apply -f webshop.yaml
deployment.apps/webshop created

$ kubectl get pods
NAME                       READY   STATUS    RESTARTS   AGE
webshop-7c9f6d5b8d-2xk4q   1/1     Running   0          12s
webshop-7c9f6d5b8d-hs7pl   1/1     Running   0          12s
webshop-7c9f6d5b8d-vq2mn   1/1     Running   0          12s

Jetzt der Moment, an dem Kubernetes bei mir zum ersten Mal Klick gemacht hat. Lösche einen der Pods und schau sofort wieder nach:

$ kubectl delete pod webshop-7c9f6d5b8d-2xk4q
pod "webshop-7c9f6d5b8d-2xk4q" deleted

$ kubectl get pods
NAME                       READY   STATUS    RESTARTS   AGE
webshop-7c9f6d5b8d-hs7pl   1/1     Running   0          2m
webshop-7c9f6d5b8d-9tqvw   1/1     Running   0          3s
webshop-7c9f6d5b8d-vq2mn   1/1     Running   0          2m

Der gelöschte Pod ist weg, ein neuer mit anderem Namen ist da, und es sind wieder drei. Du hast nichts nachgestartet. Das Deployment hat den Soll-Zustand mit dem Ist-Zustand verglichen und die Lücke geschlossen. Genauso funktioniert ein Update: Du änderst das Image im Manifest, führst kubectl apply erneut aus, und Kubernetes tauscht die Pods nacheinander aus, ohne dass der Dienst ausfällt. Die Details zu Strategien und Rollbacks stehen in der Dokumentation zu Deployments.

Kubernetes vs. Docker in drei Sätzen

Docker baut und startet Container auf einem einzelnen Rechner, Kubernetes betreibt Container auf vielen Rechnern. Die beiden sind keine Konkurrenten: Mit Docker baust du das Image, Kubernetes startet daraus Pods, wobei es dafür heute eine schlankere Container-Runtime wie containerd nutzt und Docker selbst nicht mehr im Cluster braucht. Für die Entwicklung auf dem Laptop bleibt Docker das Werkzeug der Wahl, für den Betrieb in Produktion übernimmt Kubernetes.

Wenn du gerade mit Docker Compose arbeitest und überlegst, ob ein Cluster der nächste Schritt ist, habe ich die Abgrenzung mit Beispielen in Kubernetes vs Docker: der Unterschied ausführlich beschrieben.

Wann Kubernetes sinnvoll ist und wann nicht

Die erste Frage, die ich Kunden stelle, die Kubernetes einführen wollen, lautet: „Welches Ziel wollt ihr damit erreichen?" Kubernetes ist ein Werkzeug, kein Ziel. In meiner Erfahrung lohnt es sich, wenn mindestens zwei der folgenden Punkte zutreffen, und es ist Ballast, wenn keiner zutrifft.

Kubernetes lohnt sich, wenn	Kubernetes ist zu viel, wenn
Deine Anwendung aus mehreren Services besteht, die unabhängig skalieren sollen	Du eine klassische Drei-Schichten-Anwendung mit wenigen Nutzern betreibst
Ausfälle einzelner Server für Nutzer unsichtbar bleiben müssen	Ein Ausfall von einer Stunde niemandem weh tut
Du mehrmals pro Woche ohne Ausfall ausrollen willst	Releases alle paar Monate über ein Wartungsfenster laufen
Mehrere Teams oder Kunden je einen eigenen Stack bekommen	Es ein Team und eine Anwendung gibt
Du Cloud, eigenes Rechenzentrum oder beides gleichzeitig brauchst	Die Anwendung eine feste IP oder andere Server-Eigenheiten braucht

Kubernetes bringt neben Vorteilen auch Pflichten mit: Fachwissen, das du aufbauen oder einkaufen musst, laufende Kosten für die Control Plane, die selbst Rechenleistung braucht, und eine veränderte Arbeitsweise im Betrieb. Für ein Startup mit Frontend, Backend und Datenbank und einer Handvoll Kunden ist ein einzelner Server mit Docker Compose oder ein Container-Dienst des Cloud-Anbieters meist die bessere Wahl. Das sage ich als jemand, der mit Kubernetes sein Geld verdient.

Und wenn Kubernetes passt, bleibt die Frage nach dem Betriebsmodell. Die großen Cloud-Anbieter bieten Managed Kubernetes an: Sie betreiben die Control Plane, du kümmerst dich um deine Anwendungen. Für kleine Teams ohne eigene Betriebserfahrung ist das in der Regel der richtige Weg. Ich betreibe meine Cluster selbst, mit k3s auf Hetzner in deutschen Rechenzentren, weil meine Kunden Datenhoheit und kalkulierbare Kosten wichtiger sind als ein Klick-Setup. Das ist eine bewusste Entscheidung mit Aufwand dahinter, nicht die Standardempfehlung.

Häufige Fragen

Was heißt K8s?

K8s ist die Kurzform von Kubernetes: K, dann acht Buchstaben, dann s. Das Wort selbst kommt aus dem Griechischen und bedeutet Steuermann, deshalb ist das Logo ein Steuerrad. Beide Schreibweisen meinen exakt dasselbe System.

Ist Kubernetes nur für große Unternehmen?

Nein, aber es ist für Unternehmen mit mehreren Services und dem Anspruch auf Ausfallsicherheit. Die Größe der Firma ist weniger entscheidend als die Struktur der Anwendungen. Ein Mittelständler mit zehn Services und drei Kunden-Stacks profitiert mehr als ein Konzern mit einer einzigen monolithischen Anwendung.

Brauche ich Docker noch, wenn ich Kubernetes nutze?

Auf deinem Entwicklungsrechner ja, zum Bauen und Testen von Images. Im Cluster nicht: Kubernetes nutzt eine eigene Container-Runtime wie containerd, die Docker-Images ohne Docker ausführt. Das Image-Format ist ein offener Standard, deshalb passt beides zusammen.

Was kostet Kubernetes?

Die Software ist kostenlos und Open Source. Kosten entstehen durch die Server, auf denen das Cluster läuft, durch die Control Plane, die selbst Ressourcen braucht, und vor allem durch Menschen, die es aufbauen und betreiben. Bei Managed Kubernetes kommt eine Gebühr des Cloud-Anbieters für die Control Plane dazu, dafür entfällt ein großer Teil des Betriebsaufwands.

Ersetzt Kubernetes einen Server?

Nein, Kubernetes braucht Server. Es liegt als Schicht über mehreren Maschinen und verteilt Container darauf. Der Unterschied zum klassischen Server ist, dass dir egal sein kann, auf welcher Maschine deine Anwendung gerade läuft.

Wie du weitermachst

Wenn du das Deployment von oben in einem eigenen Cluster ausprobieren willst, ist der schnellste Weg ein lokales Cluster auf deinem Rechner. Wie du das Lernen strukturiert angehst, von der ersten Installation bis zur Zertifizierung, steht in Kubernetes lernen. Für das Verständnis, was beim kubectl apply im Hintergrund passiert, empfehle ich als Nächstes Kubernetes-Architektur: die Komponenten. Und wer noch zwischen Compose und Cluster schwankt, findet in Kubernetes vs Docker die Entscheidungshilfe.

Ausführlich mit allen Beispielen, von der Entstehung bei Google über Stateless und Stateful bis zur Frage, für welche Unternehmen Kubernetes passt, steht das in Kapitel 2 meines Buchs „Kubernetes: Das Praxisbuch für Entwickler und DevOps-Teams" (Rheinwerk). Alle Informationen zum Buch findest du auf meiner Kubernetes-Seite.