Virtualisierung
Kubernetes
Kubernetes (K8s) ist der quelloffene Orchestrator, der Container über viele Server deklarativ ausrollt, skaliert und selbstheilend betreibt.
- Offen, CNCF (Apache 2.0)
- Deklarativ und selbstheilend
- Container-Orchestrierung
- CRDs und Operators
- RBAC, NetworkPolicies
Kubernetes (kurz K8s) ist ein Orchestrator für containerisierte Anwendungen. Statt Container von Hand auf Servern zu starten und zu überwachen, beschreibt man den gewünschten Zustand, und Kubernetes sorgt dafür, dass dieser über einen ganzen Cluster hinweg erreicht und gehalten wird: Es startet ausgefallene Container neu, verteilt Last und skaliert nach Bedarf. Es entstand aus Googles internem System Borg und wird heute von der Cloud Native Computing Foundation getragen.
Dieser Artikel erklärt die Bestandteile der Steuerebene und der Worker-Knoten, die wichtigsten API-Objekte vom Pod bis zum Service, das deklarative Modell mit seiner Reconciliation-Schleife, Netzwerk und Speicher über CNI und CSI, die Erweiterung per Operators sowie die Sicherheitsthemen und die ehrliche Einordnung der Betriebskomplexität.
1. Was Kubernetes löst
Container sind leicht zu starten, aber im Dutzend und über viele Server hinweg schwer von Hand zu betreiben: Wer startet einen abgestürzten Container neu, verteilt Last, rollt eine neue Version ohne Ausfall aus? Genau das übernimmt Kubernetes. Sein Kernprinzip ist deklarativ: Man beschreibt den Sollzustand (welche Anwendung, wie viele Instanzen, welche Ressourcen), und das System gleicht den Ist-Zustand kontinuierlich daran an.
Daraus folgt Selbstheilung: Fällt ein Container oder ein ganzer Knoten aus, erkennt Kubernetes die Abweichung vom Soll und erzeugt Ersatz, ohne dass jemand eingreift.
2. Steuerebene und Worker-Knoten
Ein Cluster besteht aus einer Control Plane und mehreren Worker Nodes. Die Steuerebene umfasst den kube-apiserver (zentraler Eingang für alle Anfragen), etcd (konsistenter Schlüssel-Wert-Speicher und einzige Quelle der Wahrheit), den Scheduler (platziert Pods auf Knoten) und den Controller-Manager (führt die Reconciliation-Schleifen aus).
Auf jedem Worker laufen der kubelet (startet und überwacht die Container nach Vorgabe), kube-proxy (setzt die Netzwerkregeln für Services um) und eine Container-Runtime über das CRI, in der Praxis containerd oder CRI-O. Der direkte Docker-Anschluss wurde mit Version 1.24 entfernt; Docker-Images laufen aber weiterhin, da sie dem offenen OCI-Format folgen.
3. Die wichtigsten Objekte
Kubernetes verwaltet alles als API-Objekte. Die zentralen:
Minimal-Deployment (YAML) und ein Blick in den Cluster
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels: { app: web }
template:
metadata:
labels: { app: web }
spec:
containers:
- name: web
image: nginx:1.27
---
# kubectl get pods -A # alle Pods anzeigen
# kubectl apply -f web.yaml # Sollzustand anwenden| Objekt | Aufgabe |
|---|---|
| Pod | kleinste Einheit, ein oder mehrere Container, die sich Netz und Speicher teilen |
| Deployment | verwaltet zustandslose Pods, Rolling Updates und Rollbacks |
| StatefulSet | für zustandsbehaftete Dienste mit stabiler Identität und eigenem Speicher |
| DaemonSet | eine Pod-Instanz je Knoten (etwa Monitoring- oder Log-Agenten) |
| Service | stabiler Endpunkt für eine Gruppe von Pods (ClusterIP, NodePort, LoadBalancer) |
| ConfigMap / Secret | Konfiguration bzw. sensible Daten (Secret nur base64-kodiert) |
| Namespace | logische Trennung für Teams, Umgebungen oder Mandanten |
| PersistentVolume / PVC | persistenter Speicher unabhängig vom Pod-Lebenszyklus |
4. Deklaratives Modell und Reconciliation
Der Anwender schreibt Manifeste (YAML), die den Sollzustand beschreiben; der API-Server speichert sie in etcd. Controller beobachten fortlaufend den tatsächlichen Zustand und handeln, sobald er vom Soll abweicht. Diese Reconciliation-Schleife ist das Herz von Kubernetes: Infrastruktur wird zu versionierbarem Code, und das System korrigiert sich selbst, statt auf manuelle Eingriffe zu warten.
Der eigentliche Bruch mit klassischem Serverbetrieb ist das deklarative Modell: Nicht „mach diese Schritte“, sondern „dieser Zustand soll gelten“. Den Weg dorthin und das Halten übernimmt der Cluster.
5. Netzwerk und Speicher: CNI und CSI
Kubernetes gibt nur ein Netzwerkmodell vor (jeder Pod hat eine eigene IP, alle Pods erreichen sich ohne NAT), die Umsetzung liefern austauschbare CNI-Plugins wie Calico oder Cilium. Wichtig für die Sicherheit: NetworkPolicies sind nur Spezifikationen; sie wirken erst, wenn das CNI-Plugin sie umsetzt. Speicher binden Pods über CSI ein, die standardisierte Schnittstelle, über die Storage-Systeme von Ceph bis Cloud-Volumes als PersistentVolumes bereitstehen.
6. Erweiterung: CRDs und Operators
Kubernetes lässt sich erweitern, ohne den Kern zu ändern. Custom Resource Definitions (CRDs) fügen eigene Objekttypen hinzu, und ein Operator ist ein darauf zugeschnittener Controller, der Betriebswissen in Code gießt: etwa eine Datenbank, die ihre Backups, Failover und Updates selbst verwaltet. Operators laufen als normale Pods und folgen demselben Reconciliation-Prinzip wie die eingebauten Controller. Genau dieses Muster macht aus Kubernetes eine Plattform für ganze Ökosysteme.
7. Sicherheit
Kubernetes ist nicht von Haus aus sicher, sondern muss bewusst gehärtet werden:
- RBAC regelt, wer was darf. Wildcard-Rechte und zu weite Cluster-Bindungen sind die häufigsten Fehler; das Prinzip ist minimale Rechtevergabe.
- Secrets sind nicht verschlüsselt sie werden nur base64-kodiert und liegen ohne Zutun im Klartext in etcd. Verschlüsselung der Daten im Ruhezustand (Encryption at Rest), idealerweise über ein KMS, muss aktiv eingerichtet werden.
- NetworkPolicies schränken den Pod-zu-Pod-Verkehr ein, wirken aber nur mit einem CNI, das sie durchsetzt.
- Pod Security Standards verhindern überprivilegierte Pods (kein Root, keine Host-Zugriffe) und lösen die alten PodSecurityPolicies ab.
etcd ist das Kronjuwel
Wer Zugriff auf etcd hat, hat den ganzen Cluster, inklusive aller Secrets im Klartext, wenn keine Verschlüsselung aktiv ist. Der etcd-Zugang gehört streng abgesichert und gesichert (Backup).
8. Release-Takt und Betriebsaufwand
Kubernetes erscheint rund dreimal im Jahr, jede Version wird etwa 14 Monate gepflegt. Cluster, die länger nicht aktualisiert werden, verlieren den Patch-Support, Upgrade-Management ist also Pflicht. Vor allem aber ist der Betrieb anspruchsvoll: Netzwerk, Speicher, Sicherheit und Linux-Grundlagen müssen zusammenpassen. Vieles, was schiefgeht, geht nicht an der Technik, sondern an der Komplexität schief.
Kubernetes ist mächtig, aber kein Selbstzweck. Für eine einzelne Anwendung oder ein kleines Team ist es oft zu viel; der Gewinn entsteht erst, wenn Skalierung, Ausfallsicherheit und Automatisierung über viele Dienste den Aufwand rechtfertigen.
9. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Selbstheilung und automatische Skalierung | hohe Komplexität, steile Lernkurve |
| Deklaratives Modell: Infrastruktur als versionierbarer Code | anspruchsvoller Betrieb (Netz, Storage, Sicherheit) |
| Erweiterbar über CRDs und Operators | für kleine Anwendungen oft überdimensioniert |
| Läuft on-premises, in jeder Cloud und auf Bare Metal | zustandsbehaftete Dienste erfordern sorgfältige Planung |
| Großes offenes Ökosystem (CNCF) | regelmäßige Upgrades zwingend (rund 14 Monate Support) |
Häufige Fragen zu Kubernetes
Standardmäßig nein. Ein Secret ist lediglich base64-kodiert, was sich ohne Schlüssel umkehren lässt, und liegt im Klartext in etcd. Verschlüsselung der Daten im Ruhezustand (Encryption at Rest), idealerweise über einen KMS-Anbieter, muss am API-Server aktiv konfiguriert werden. Wer Secrets ernst nimmt, aktiviert das und schützt den etcd-Zugang streng.
Meist nicht. Kubernetes lohnt sich, wenn viele Dienste skaliert, ausfallsicher und automatisiert betrieben werden müssen und das Betriebs-Know-how vorhanden ist. Für eine einzelne Anwendung oder ein kleines Team überwiegt oft die Komplexität; eine schlanke Container-Laufzeit oder klassische Virtualisierung ist dann die ehrlichere Wahl.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Kubernetes im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.