Warum Kubernetes plötzlich verständlich wird

Stell dir vor, du bist Betriebsleiter einer deutschlandweiten Supermarktkette.

Nicht einer Filiale.

Der ganzen Kette.

Jeden Morgen öffnen hunderte Standorte ihre Türen. Kassierer beginnen ihre Schicht. Lieferungen treffen ein. Kühlanlagen laufen. Manche Filialen werden renoviert, andere erweitert.

Und trotzdem erwarten die Kunden etwas ganz Einfaches:

Sie wollen einkaufen.

Sie interessieren sich nicht dafür, welche Kassiererin heute an Kasse 4 sitzt.

Sie interessieren sich nicht dafür, welches Kühlhaus gerade gewartet wird.

Sie wollen einfach nur, dass die Milch im Regal steht und die Kasse funktioniert.

Genau dieses Problem löst Kubernetes.

Kubernetes startet nicht einfach Container.

Kubernetes organisiert eine riesige verteilte Infrastruktur so, dass Anwendungen zuverlässig laufen – selbst wenn einzelne Maschinen ausfallen, Container verschwinden oder neue Versionen ausgerollt werden.

Als ich Kubernetes zum ersten Mal lernte, fühlte es sich an wie das Organigramm eines Unternehmens, dessen Gebäude ich noch nie betreten hatte.

API Server.

Scheduler.

Kubelet.

Deployment.

Ingress.

Jeder Begriff war verständlich.

Aber zusammen ergaben sie noch kein Bild.

Die folgende Analogie hat das für mich verändert:

Kubernetes ist eine deutschlandweite Supermarktkette.

Sobald dieses Bild sitzt, werden viele Kubernetes-Komponenten erstaunlich intuitiv.

Die gesamte Kette: Der Cluster

Ein Kubernetes-Cluster ist die komplette Supermarktkette.

Alle Filialen.

Alle Mitarbeiter.

Alle Lagerhäuser.

Alle Regeln.

Alle Prozesse.

Wenn jemand von einem Produktions-Cluster spricht, meint er nicht einen einzelnen Server.

Er meint die gesamte Betriebsumgebung.

Eine wichtige Denkweise für Einsteiger:

Wenn etwas nicht funktioniert, frage zuerst:

  • Ist das Problem in einer Filiale?
  • Ist das Problem in der Zentrale?
  • Oder ist die Verbindung zwischen beiden gestört?

Diese Frage löst erstaunlich viele Kubernetes-Probleme.

Die Unternehmenszentrale: Die Control Plane

Jede große Supermarktkette besitzt eine Zentrale.

Dort wird nicht kassiert.

Dort werden keine Regale eingeräumt.

Dort wird entschieden.

Die Zentrale bestimmt:

  • welche Filialen existieren
  • welche Regeln gelten
  • wer Änderungen durchführen darf
  • wie viele Mitarbeiter benötigt werden

Die Kubernetes-Control-Plane erfüllt genau diese Aufgabe.

Sie ist das Gehirn des Clusters.

Sie führt die Arbeit nicht selbst aus.

Sie entscheidet lediglich, wie die Arbeit aussehen soll.

Der API Server: Die zentrale Schaltstelle

Jede Nachricht in der Supermarktkette läuft über die Zentrale.

Filialen melden Probleme.

Manager melden Statusberichte.

Neue Anweisungen werden verteilt.

Genau das ist der API Server.

Er ist die wichtigste Kommunikationsschnittstelle des gesamten Clusters.

Wenn du einen Befehl ausführst:

kubectl get pods

sprichst du nicht direkt mit den Pods.

Du sprichst mit dem API Server.

Der API Server ist die gemeinsame Wahrheit des Clusters.

Fast jede Komponente kommuniziert über ihn.

etcd: Das Hauptbuch

Jede Unternehmenszentrale benötigt ein Hauptbuch.

Darin steht:

  • welche Filialen existieren
  • welche Regeln gelten
  • welche Teams eingesetzt werden sollen
  • welche Änderungen vorgenommen wurden

In Kubernetes heißt dieses Hauptbuch:

etcd

Wenn dort steht:

“Die Anwendung soll mit vier Instanzen laufen”

dann betrachten alle anderen Komponenten diese Information als Wahrheit.

Verlierst du etcd, verlierst du das Gedächtnis des Clusters.

Deshalb gilt:

Der API Server ist die Schaltstelle.

etcd ist das Gedächtnis.

Der Scheduler: Die Logistikabteilung

Stell dir vor, die Zentrale beschließt:

“Wir brauchen eine weitere Kasse.”

Die Frage lautet nun:

In welcher Filiale?

Die Logistik beginnt zu prüfen:

  • Wo ist noch Platz?
  • Wo gibt es genug Personal?
  • Welche Filiale besitzt die benötigte Ausstattung?
  • Welche Vorgaben müssen erfüllt werden?

Erst danach wird die neue Arbeit einer Filiale zugewiesen.

Genau das macht der Kubernetes Scheduler.

Er startet keine Container.

Er entscheidet lediglich:

“Dieser Pod soll auf diesem Node laufen.”

Nodes: Die Filialen

Ein Node ist eine einzelne Filiale.

Eine echte Betriebsstätte.

Mit Strom.

Mit Netzwerk.

Mit Ressourcen.

Mit Grenzen.

Eine Filiale kann nicht unendlich viele Kassen betreiben.

Genauso besitzt ein Node nur begrenzte CPU- und Memory-Kapazität.

Kubelet: Die Filialleitung

Jede Filiale benötigt jemanden, der die Anweisungen der Zentrale umsetzt.

Das ist das Kubelet.

Wenn die Zentrale sagt:

“Starte drei neue Kassen.”

dann sorgt das Kubelet dafür, dass genau das passiert.

Es überprüft:

  • laufen die Container?
  • sind sie gesund?
  • müssen sie neu gestartet werden?

Das Kubelet ist die lokale Filialleitung.

Pods: Die Kassenteams

Ein Pod entspricht einem Team, das an einer Kasse arbeitet.

Wichtig:

Kassenteams sind austauschbar.

Heute arbeitet Team A.

Morgen Team B.

Für den Kunden spielt das keine Rolle.

Genauso sind Pods vergänglich.

Pods kommen und gehen.

Kubernetes erwartet sogar, dass sie irgendwann ersetzt werden.

Deployments: Die Personalvorgabe

Ein Filialleiter möchte nicht jede Schicht manuell planen.

Er möchte sagen:

“Es sollen immer drei Kassen geöffnet sein.”

Das ist ein Deployment.

Ein Deployment beschreibt den gewünschten Zustand.

Zum Beispiel:

  • welches Container-Image laufen soll
  • wie viele Replikate existieren sollen
  • wie Updates durchgeführt werden

Merksatz:

  • Deployment = Personalvorgabe
  • ReplicaSet = Dienstplan
  • Pod = echtes Team auf der Fläche

Services: Die stabile Durchwahl

Ein Kunde möchte nicht wissen, welcher Mitarbeiter gerade arbeitet.

Er möchte einfach Kasse 4 finden.

Genau das macht ein Service.

Ein Service stellt einen stabilen Namen bereit.

Auch wenn dahinter ständig Pods ausgetauscht werden.

Für den Benutzer bleibt die Adresse gleich.

Für Kubernetes dürfen sich die Pods jederzeit ändern.

Ingress: Der Haupteingang

Der Service regelt den Verkehr innerhalb der Kette.

Der Ingress regelt Besucher von außen.

Er entscheidet beispielsweise:

  • shop.example.com → Webshop
  • api.example.com → API
  • admin.example.com → Admin-Bereich

Der Ingress ist das Eingangsschild des Einkaufszentrums.

ConfigMaps und Secrets

Nicht alles gehört in den Container.

Eine ConfigMap ist das schwarze Brett.

Dort hängen:

  • Öffnungszeiten
  • Konfigurationen
  • Feature Flags

Ein Secret ist der Tresor.

Dort liegen:

  • Passwörter
  • API Keys
  • Zertifikate

Ein schwarzes Brett ist kein Tresor.

Eine ConfigMap ist kein Secret.

Namespaces: Die Abteilungen

Große Unternehmen besitzen Abteilungen.

Produktion.

Marketing.

Buchhaltung.

Ähnlich funktionieren Namespaces.

Sie helfen dabei, Ressourcen logisch voneinander zu trennen.

Labels und Selectors: Die Namensschilder

Jeder Mitarbeiter trägt ein Namensschild.

Beispielsweise:

app: checkout
tier: frontend
env: production

Services und Deployments suchen anhand dieser Kennzeichnungen.

Viele Beziehungen in Kubernetes basieren auf Labels.

Nicht auf festen Namen.

Probes: Ist die Kasse wirklich einsatzbereit?

Eine Kasse kann eingeschaltet sein.

Und trotzdem nicht funktionieren.

Deshalb unterscheidet Kubernetes:

  • Startup Probe
  • Readiness Probe
  • Liveness Probe

Einfach gesagt:

  • Startup → Noch im Aufbau
  • Readiness → Bereit für Kunden
  • Liveness → Muss ersetzt werden?

Persistent Volumes: Das Lagerhaus

Mitarbeiter kommen und gehen.

Das Lager bleibt.

Pods verschwinden.

Daten sollen bleiben.

Persistent Volumes sind das Lagerhaus der Supermarktkette.

RBAC und Network Policies

RBAC beantwortet:

Wer darf welche Tür öffnen?

Network Policies beantworten:

Wer darf mit wem sprechen?

Das eine regelt Berechtigungen.

Das andere Netzwerkverkehr.

Events: Die Meldungen aus den Filialen

Wenn etwas schiefgeht, hinterlassen die Filialen Berichte.

In Kubernetes heißen diese Berichte:

Events.

Sehr oft liegt die erste brauchbare Fehlerursache genau dort.

Wo die Analogie endet

Jede Metapher hat Grenzen.

Pods sind deutlich kurzlebiger als echte Mitarbeiter.

Services sind keine Menschen.

Nodes können jederzeit ersetzt werden.

Und trotzdem erfüllt die Analogie ihren Zweck:

Sie liefert eine mentale Landkarte.

Abschluss

Kubernetes ist komplex, weil es ein komplexes Problem löst.

Viele Anwendungen.

Viele Maschinen.

Viele Ausfälle.

Viele Änderungen.

Die Supermarktkette ersetzt keine technische Expertise.

Aber sie gibt jedem Begriff einen Platz.

Die Zentrale.

Die Filiale.

Die Filialleitung.

Das Kassenteam.

Das schwarze Brett.

Der Tresor.

Der Haupteingang.

Sobald diese Bilder im Kopf existieren, werden die offiziellen Kubernetes-Begriffe deutlich leichter verständlich.

Dann fragt man nicht mehr:

“Was ist ein Kubelet?”

Sondern:

“Wer hätte dieses Problem in der Supermarktkette lösen sollen?”

Und genau dort beginnt echtes Kubernetes-Verständnis.