Ein typisches Szenario in einem deutschen Mittelstandsunternehmen sieht so aus: Das Entwicklungsteam betreibt erst wenige Container auf einzelnen VMs, dann kommen neue Services, strengere Sicherheitsvorgaben und der Wunsch nach planbaren Releases dazu. Spätestens dann stellt sich nicht die Frage, ob Container laufen, sondern wer ihren Betrieb zuverlässig koordiniert. Genau dafür ist Kubernetes gedacht.

Wer den Begriff noch einordnen möchte, findet den größeren Rahmen in einer Einführung in Cloud-native Grundlagen. Für die Architektur eines Clusters hilft ein einfaches Bild: Kubernetes arbeitet wie eine Werkleitung mit Leitstand und Produktionsflächen. Der Leitstand entscheidet, was laufen soll. Die Produktionsflächen führen es aus.

Der Leitstand ist der Control Plane. Hier liegen die Komponenten, die den gewünschten Soll-Zustand des Clusters verwalten. Der wichtigste Einstiegspunkt ist der kube-apiserver. Er nimmt Befehle entgegen, etwa aus kubectl, aus der CI/CD-Pipeline oder aus einem GitOps-Prozess. Wenn Sie ein Deployment anwenden, landet diese Definition zuerst beim API-Server.

etcd speichert den Zustand des Clusters. Dort steht zum Beispiel, welche Deployments, Pods oder Services es gibt. Deshalb ist etcd besonders schützenswert. Wer in Deutschland regulierte Daten verarbeitet, sollte hier früh über Zugriffskontrolle, Backup, Verschlüsselung und Netzsegmentierung nachdenken. Das passt auch zu BSI-Anforderungen rund um Härtung, Rollenmodelle, Protokollierung und abgesicherte Administrationszugänge.

Der kube-scheduler entscheidet, auf welchem Worker Node ein neuer Pod läuft. Er prüft freie Ressourcen, Regeln für Affinität oder Anti-Affinität und mögliche Einschränkungen wie Taints und Tolerations. Der kube-controller-manager überwacht, ob der Ist-Zustand noch zum Soll-Zustand passt. Fällt ein Pod aus, sorgt der Controller dafür, dass ein neuer gestartet wird.

Die eigentliche Arbeit passiert auf den Worker Nodes. Auf jedem Node läuft der kubelet. Er spricht mit dem API-Server und stellt sicher, dass die zugewiesenen Pods wirklich gestartet werden. kube-proxy kümmert sich um Netzregeln innerhalb des Clusters, damit Services Anfragen an die passenden Pods weiterleiten können. In neueren Setups übernehmen Teile dieser Netzlogik auch CNI-Erweiterungen, aber für den Einstieg reicht dieses Modell.

Pods sind die kleinste deploybare Einheit in Kubernetes. Ein Pod enthält einen oder mehrere Container, die sich Netzwerk und Storage teilen. In der Praxis läuft in einem Pod oft genau ein Anwendungscontainer. Mehrere Container in einem Pod sind sinnvoll, wenn sie eng zusammengehören, etwa eine App und ein Sidecar für Logs oder Zertifikate.

Ein einfacher Pod für eine interne Webanwendung sieht so aus:

apiVersion: v1kind: Podmetadata:name: web-demospec:containers:- name: webimage: nginx:1.27ports:- containerPort: 80

Für produktive Systeme wird ein einzelner Pod fast nie direkt verwaltet. Wichtiger ist ein ReplicaSet, meist indirekt über ein Deployment. Ein ReplicaSet sorgt dafür, dass eine festgelegte Anzahl identischer Pods läuft. Das ist der erste Schritt zu Ausfallsicherheit. Wenn ein Node ausfällt oder ein Container crasht, erstellt Kubernetes automatisch Ersatz.

apiVersion: apps/v1kind: Deploymentmetadata:name: web-demospec:replicas: 3selector:matchLabels:app: web-demotemplate:metadata:labels:app: web-demospec:containers:- name: webimage: nginx:1.27ports:- containerPort: 80

Hier laufen drei identische Pods. Für viele KMU ist genau das der Punkt, an dem Kubernetes erstmals echten Nutzen bringt: nicht wegen technischer Eleganz, sondern weil Updates, Neustarts und Lastspitzen kontrollierbarer werden. Wenn Sie nur eine einzelne interne Anwendung mit wenigen Releases pro Jahr betreiben, ist dieser Aufwand oft noch nicht nötig. Wenn mehrere Services, getrennte Teams, Compliance-Vorgaben und Hochverfügbarkeit zusammenkommen, kippt die Rechnung schnell zugunsten von Kubernetes.

Ein Service löst ein weiteres Grundproblem. Pods sind austauschbar und ihre IP-Adressen ändern sich. Andere Anwendungen brauchen trotzdem eine stabile Adresse. Ein Service bildet deshalb eine feste Netzwerkadresse vor einer Gruppe passender Pods.

apiVersion: v1kind: Servicemetadata:name: web-demospec:selector:app: web-demoports:- port: 80targetPort: 80

Der Service leitet Anfragen an alle Pods mit dem Label app: web-demo weiter. Intern funktioniert das wie ein fester Empfangsschalter, obwohl im Hintergrund verschiedene Mitarbeiter Dienst haben können. Diese Entkopplung ist eine der wichtigsten Ideen in Kubernetes.

Für den ersten produktiven Rollout lohnt sich ein nüchterner Ansatz. Starten Sie nicht mit einem hochkomplexen Multi-Cluster-Design, sondern mit einem kleinen, klar abgesicherten Cluster, sauberem Namespace-Konzept, Rollen über RBAC, Image-Scanning, Secret-Management und nachvollziehbarem Logging. Das spart Aufwand, senkt das Fehlerrisiko und erfüllt viele Anforderungen, die CTOs und IT-Verantwortliche in deutschen SMEs vor einer Freigabe zu Recht stellen.