Kubernetes verständlich erklärt.

Was Kubernetes eigentlich macht

Anwendungen werden heute häufig in Containern ausgeliefert. Ein Container packt eine Anwendung mit allem, was sie zum Laufen braucht, in eine abgeschlossene Einheit. Das macht sie gut übertragbar: Was auf dem Testrechner läuft, läuft auch auf dem Server.

Solange es nur wenige Container gibt, kann man sie von Hand starten. Sobald es viele werden, braucht es eine zentrale Instanz, die entscheidet, was wo läuft, und dafür sorgt, dass es weiterläuft. Diese Aufgabe übernimmt Kubernetes, ein 2014 veröffentlichtes Open-Source-System, das containerisierte Anwendungen automatisch bereitstellt, skaliert und verwaltet. Skalieren heißt: bei mehr Last mehr Kopien einer Anwendung starten und bei weniger Last wieder abbauen.

Kubernetes arbeitet deklarativ: Statt Schritt für Schritt vorzugeben, was zu tun ist, beschreibst Du den gewünschten Zustand, etwa „von dieser Anwendung sollen immer drei Kopien laufen“. Kubernetes vergleicht ständig Soll und Ist und gleicht Abweichungen selbstständig aus. Stürzt eine Kopie ab, startet es eine neue.

Control Plane und Worker Nodes

Kubernetes läuft auf einem Cluster, einem Verbund von Maschinen mit zwei Bereichen. Die Control Plane ist die Steuerzentrale, auf den Worker Nodes laufen die Anwendungen. Ein Node ist eine Maschine im Cluster, ob physisch oder virtuell.

Zur Control Plane gehören im Kern vier Bausteine:

• Der API-Server ist die zentrale Schnittstelle, über die alles läuft. API steht für Programmierschnittstelle, also einen festgelegten Weg, über den Programme und Menschen mit dem System sprechen.
• etcd ist ein verteilter Datenspeicher, in dem der gesamte Zustand des Clusters liegt, quasi das Gedächtnis.
• Der Scheduler entscheidet, auf welchem Node eine neue Anwendung startet.
• Der Controller-Manager überwacht laufend, ob der gewünschte Zustand erreicht ist, und greift ein, wenn nicht.

Auf jedem Worker Node läuft das kubelet, ein kleiner Agent. Es bekommt vom API-Server gesagt, welche Anwendungen es ausführen soll, und sorgt dafür, dass deren Container laufen. Gestartet werden die Container von einer Container Runtime; Kubernetes bündelt sie in sogenannten Pods (siehe unten).

Die wichtigsten Konzepte

Ein Pod ist die kleinste Einheit in Kubernetes und bündelt einen oder mehrere Container, die eng zusammengehören. Soll auf jedem Node genau eine Kopie eines Pods laufen, etwa ein Agent, der Protokolldateien einsammelt, nutzt man ein DaemonSet. Im Alltag begegnen Dir außerdem vor allem diese vier Begriffe:

RBAC kennt nur Erlaubnisse und keine Verbote: Was nicht ausdrücklich erlaubt ist, ist untersagt. Das funktioniert gut, solange Rechte knapp und bewusst vergeben werden, also jede Person und jede Anwendung nur die Rechte bekommt, die sie für ihre Aufgabe braucht.

Der API-Server als zentrale Schaltstelle

Jede Anfrage an den Cluster läuft über den API-Server, ob sie von einem Menschen, einer Anwendung oder einer internen Komponente kommt. Dort durchläuft sie vereinfacht gesagt zwei Prüfungen: Die Authentifizierung klärt, wer anfragt. Die Autorisierung entscheidet anhand der Rollen, was diese Identität darf.

Die Zugangsdaten für den Cluster liegen meist gebündelt in einer Konfigurationsdatei, der kubeconfig. Weil Kubernetes Rechte allein an die Identität knüpft, ist eine kubeconfig mit Administratorrechten der Generalschlüssel zum Cluster, egal, wer sie in der Hand hat. Solche Dateien gehören deshalb so sorgfältig verwahrt wie ein Hauptpasswort.

Weil alles über den API-Server läuft, kann er auch jede Anfrage protokollieren. Dieses Audit-Log ist die wichtigste Quelle, um nachzuvollziehen, was im Cluster passiert. Wie gut man Angriffe in so einer Umgebung erkennt, zeigt mein Praxistest mit Wazuh.

Wann sich Kubernetes lohnt

Kubernetes kostet Aufwand: Der Cluster will eingerichtet, aktualisiert und überwacht werden, und das Team braucht das Wissen dafür.

Ich starte so einfach wie möglich und wechsle erst auf Kubernetes, wenn es echte Gründe dafür gibt. Wer seine Anwendung von Anfang an in Containern ausliefert, kann die Container später in einen Cluster übernehmen, wenn das Vorhaben wächst.

Reproduzierbar aufbauen

Bei einem von Hand eingerichteten Cluster weiß nach ein paar Wochen niemand mehr genau, welcher Schalter wann umgelegt wurde. Deshalb beschreibe ich Infrastruktur als Code (Infrastructure as Code), zum Beispiel mit Terraform. Terraform arbeitet ähnlich deklarativ wie Kubernetes, gleicht aber nur bei jedem Lauf ab: Ich beschreibe den gewünschten Zielzustand (Maschinen, Netze, Konfiguration), und das Werkzeug stellt ihn her.

Jede Änderung steht im Code und bleibt damit nachvollziehbar. Weil der Code versioniert ist, lässt sich zeigen, wer wann was geändert hat. Außerdem kann ich die Umgebung jederzeit identisch neu aufbauen, etwa für eine Testumgebung oder nach einem Ausfall. Die Daten selbst sichern weiterhin Backups.

Was das für Dein Unternehmen heißt

Für eine gute Entscheidung musst Du nicht jedes Detail von Kubernetes kennen. Diese Grundregeln helfen:

1. Erst den Bedarf klären. Kubernetes lohnt sich erst bei mehreren Diensten mit eigenem Lastprofil. Für kleinere Anwendungen ist ein verwalteter Container-Dienst oft der bessere Start.
2. Infrastruktur als Code beschreiben. Test- und Vorabumgebungen entstehen auf Knopfdruck und sehen jedes Mal gleich aus. Änderungen bleiben nachvollziehbar.
3. Rechte knapp vergeben. Jede Person und jede Anwendung bekommt nur die Rechte, die sie wirklich braucht. Zugänge mit Administratorrechten gehören in wenige Hände.
4. Protokollierung von Anfang an mitplanen. Ist das Audit-Log nicht aktiviert, fehlen im Ernstfall die Spuren, denn nachträglich lässt sich nichts protokollieren.

Ein sauber dokumentierter Aufbau macht einen Cluster nicht unangreifbar, aber überprüfbar und jederzeit wiederherstellbar. Wenn Du wissen willst, ob Kubernetes für Dein Vorhaben passt oder ein einfacherer Weg reicht, findest Du hier meine Cloud-Lösungen.