Was ist Kubernetes?

Kubernetes soll Teil einer belastbaren Anwendungsplattform werden? WZ-IT plant, baut und betreibt Kubernetes auf Proxmox, Bare Metal und europäischen Cloud-Infrastrukturen - inklusive Netzwerk, GitOps, Monitoring und Backup. Kubernetes-Angebot ansehen

Kubernetes ist eine quelloffene Plattform zur Orchestrierung containerisierter Anwendungen. Sie verteilt Workloads über einen Cluster, hält deren gewünschten Zustand aufrecht und stellt ein gemeinsames API-Modell für Deployment, Netzwerk, Konfiguration und Betrieb bereit. Statt sich bei jedem Server einzeln darum zu kümmern, welcher Container wann gestartet wird, beschreibt ein Team deklarativ: Diese Anwendung soll in drei Instanzen laufen, über diesen Dienst erreichbar sein und bei einem Ausfall automatisch ersetzt werden.

Der entscheidende Punkt ist nicht, dass Kubernetes Container starten kann. Das kann Docker ebenfalls. Kubernetes schafft eine einheitliche Steuerungs- und Automatisierungsebene über mehrere Systeme, Anwendungen und Teams hinweg. Diese zusätzliche Ebene ist wertvoll, wenn die Komplexität des Betriebs sie rechtfertigt. Für eine einzelne Anwendung auf einem Server kann sie dagegen unnötiger Aufwand sein.

Inhaltsverzeichnis

• Welches Problem Kubernetes löst
• Wie ein Kubernetes-Cluster aufgebaut ist
• Die wichtigsten Kubernetes-Objekte
• Der Regelkreis: gewünschter und tatsächlicher Zustand
• Was Kubernetes nicht automatisch löst
• Kubernetes, Docker und Container-Runtimes
• Wo Kubernetes betrieben werden kann
• Wann Kubernetes sinnvoll ist
• Was produktionsreifer Betrieb bedeutet

Welches Problem Kubernetes löst

Eine containerisierte Anwendung besteht selten nur aus einem Prozess. Im Produktivbetrieb kommen Webanwendung, APIs, Hintergrundjobs, Datenbanken, Caches, Ingress, Zertifikate, Konfiguration, Secrets und Monitoring zusammen. Werden mehrere Anwendungen über mehrere Server verteilt, entstehen wiederkehrende Fragen:

• Auf welchem System soll welcher Workload laufen?
• Was passiert, wenn ein Prozess oder ein kompletter Node ausfällt?
• Wie werden neue Versionen ohne unnötige Unterbrechung ausgerollt?
• Wie finden sich Dienste untereinander, obwohl Pods ersetzt werden und ihre IP-Adressen wechseln?
• Wie werden Ressourcen, Zugriffsrechte und Konfigurationen standardisiert?
• Wie bleibt die Plattform über Entwicklung, Test und Produktion reproduzierbar?

Kubernetes beantwortet diese Fragen über eine deklarative API und laufende Controller. Es übernimmt unter anderem Scheduling, Service Discovery, Rolling Updates, horizontale Skalierung, Selbstheilung und die Verteilung von Konfiguration. Dadurch entsteht eine gemeinsame Plattform, auf der Anwendungen nach denselben Regeln ausgeliefert werden können.

Kubernetes ist dabei kein Hosting-Anbieter und keine fertige Unternehmensplattform. Es ist der orchestrierende Kern, um den Netzwerk, Storage, Identity, Delivery, Observability und Betriebsprozesse bewusst aufgebaut werden müssen.

Wie ein Kubernetes-Cluster aufgebaut ist

Ein Cluster besteht aus einer Control Plane und einem oder mehreren Worker Nodes. Die offizielle Komponentenübersicht von Kubernetes trennt deren Aufgaben klar.

Control Plane

• kube-apiserver stellt die Kubernetes-API bereit. Werkzeuge, Nutzer und Controller kommunizieren über diese zentrale Schnittstelle.
• etcd speichert den konsistenten Zustand des Clusters. Ein Verlust ohne verwertbares Backup kann den Cluster unbrauchbar machen.
• kube-scheduler entscheidet, auf welchem Worker ein neuer Pod laufen soll. Dabei berücksichtigt er Ressourcen, Regeln und Platzierungsanforderungen.
• kube-controller-manager führt verschiedene Regelkreise aus und gleicht gewünschten und tatsächlichen Zustand ab.

In einem hochverfügbaren Produktionssetup werden diese Komponenten nicht auf einen einzigen Ausfallpunkt konzentriert. Die Kubernetes-Dokumentation zu Produktionsumgebungen empfiehlt eine replizierte Control Plane und eine abgesicherte, lastverteilte API.

Worker Nodes

• kubelet sorgt auf jedem Node dafür, dass die für ihn vorgesehenen Pods ausgeführt werden.
• Eine Container-Runtime wie containerd startet und verwaltet die Container.
• Eine Netzwerkkomponente setzt die Service- und Weiterleitungslogik um. Das eigentliche Pod-Netz liefert üblicherweise ein CNI-Plugin wie Cilium oder Calico.

Diese Trennung erlaubt, Anwendungen unabhängig von einem einzelnen Server zu beschreiben. Sie beseitigt aber nicht die physische Realität: Liegen alle virtuellen Nodes auf demselben Hypervisor, derselben Stromversorgung oder demselben Storage, bleibt genau dort ein gemeinsamer Ausfallpunkt.

Die wichtigsten Kubernetes-Objekte

Kubernetes bildet Plattformzustand in API-Objekten ab. Die wichtigsten Bausteine sind:

Die Objekte lassen sich als YAML deklarieren und über kubectl, Helm, Kustomize oder ein GitOps-System anwenden. Für produktive Plattformen ist entscheidend, dass diese Definitionen versioniert, geprüft und reproduzierbar ausgeliefert werden, statt Änderungen nur manuell im Cluster vorzunehmen.

Der Regelkreis: gewünschter und tatsächlicher Zustand

Das zentrale Funktionsprinzip heißt Reconciliation. Ein Deployment sagt beispielsweise: Von Version X sollen drei Replikate laufen. Controller beobachten kontinuierlich den tatsächlichen Zustand. Fällt ein Pod aus oder verschwindet ein Node, versucht Kubernetes, die fehlende Instanz an anderer Stelle neu zu erstellen.

Das ist die oft genannte Selbstheilung. Sie ist wertvoll, aber präzise zu verstehen:

• Kubernetes kann einen abgestürzten Container oder Pod ersetzen.
• Es kann einen Workload nach einem Node-Ausfall neu einplanen, wenn andere Nodes und benötigte Daten verfügbar sind.
• Es kann nicht automatisch eine logisch beschädigte Datenbank reparieren.
• Es erkennt ohne geeignete Health Checks nicht zuverlässig, ob eine Anwendung fachlich korrekt funktioniert.
• Es ersetzt kein Disaster-Recovery-Konzept, wenn Cluster, Storage oder Standort insgesamt verloren gehen.

Was Kubernetes nicht automatisch löst

Kubernetes liefert Bausteine, aber keine vollständige Betriebsorganisation. Folgende Aufgaben bleiben bestehen:

• Backups und Restore-Tests: etcd, persistente Daten und Anwendungssicherungen brauchen getrennte Verfahren und geprüfte Wiederanlaufpläne.
• Monitoring und Logging: Metriken, Logs, Traces und fachliche Health Checks müssen erfasst, gespeichert und alarmiert werden.
• Security: RBAC, Admission Policies, NetworkPolicies, Image-Prüfung, Secrets und Patch-Prozesse sind zu konfigurieren und zu pflegen.
• Storage: Ein PersistentVolume ist noch keine Backup- oder Hochverfügbarkeitsstrategie.
• Anwendungsarchitektur: Eine fehlerhafte oder nicht horizontal skalierbare Anwendung wird durch Kubernetes nicht automatisch cloud-native.
• Kapazitätsplanung: Cluster-Autoscaling kann helfen, braucht aber verfügbare Infrastruktur, definierte Ressourcenanforderungen und Kostenkontrolle.

Darum behandeln wir Kubernetes als Teil eines Betriebsmodells, nicht als isoliertes Installationsprojekt.

Kubernetes, Docker und Container-Runtimes

Kubernetes ist kein Ersatz für Container. Es verwendet Container-Images nach dem OCI-Standard und führt sie über eine Runtime aus. Docker als Entwicklerwerkzeug kann weiterhin Images bauen und lokal ausführen; Kubernetes selbst nutzt heute typischerweise containerd oder CRI-O über das Container Runtime Interface.

Der Unterschied liegt in der Ebene:

• Docker Compose beschreibt und startet mehrere zusammengehörige Container typischerweise auf einem Docker-System.
• Coolify ergänzt eine selbst gehostete Bedien- und Deployment-Ebene für Docker-basierte Anwendungen.
• Kubernetes stellt eine verteilte Orchestrierungs-API für Cluster, Plattformteams und komplexere Betriebsanforderungen bereit.

Eine ausführliche Entscheidungshilfe bietet unser Vergleich Kubernetes vs. Docker Compose vs. Coolify.

Wo Kubernetes betrieben werden kann

Kubernetes ist infrastrukturell portabel. Gängige Modelle sind:

1. Auf eigener Virtualisierung: etwa Kubernetes auf Proxmox mit virtuellen Control-Plane- und Worker-Nodes.
2. Auf Bare Metal: direkte Installation auf physischen Servern, sinnvoll bei hoher Leistung, spezialisierten Netzwerk- oder GPU-Anforderungen.
3. Bei europäischen Cloud- und Bare-Metal-Anbietern: beispielsweise Hetzner oder OVHcloud, selbst verwaltet und mit kontrollierbarer Datenhaltung.
4. Als Managed Kubernetes: Amazon EKS, Azure AKS oder Google GKE übernehmen Teile der Control Plane, während Workloads, Berechtigungen, Netzwerk und Daten weiterhin verantwortet werden müssen.
5. Leichtgewichtig am Edge: Distributionen wie K3s reduzieren Ressourcenbedarf und Installationskomplexität für kleinere oder verteilte Umgebungen.

Die Plattform bleibt ähnlich, aber Verantwortung, Kostenmodell, Integrationen und Souveränität unterscheiden sich deutlich.

Wann Kubernetes sinnvoll ist

Kubernetes wird interessant, wenn mehrere dieser Bedingungen zusammenkommen:

• viele containerisierte Dienste oder mehrere Anwendungsteams,
• standardisierte Deployments über mehrere Umgebungen,
• hohe Änderungsfrequenz und automatisierte Rollouts,
• horizontale Skalierung oder dynamische Workloads,
• klare Anforderungen an Ausfallsicherheit und Wartung ohne längere Unterbrechung,
• hybride, souveräne oder Multi-Cluster-Infrastruktur,
• eine gemeinsame Plattform mit Policies, Self-Service und GitOps.

Es ist häufig überdimensioniert, wenn eine kleine Zahl stabiler Anwendungen auf einem Server läuft, kaum deployt wird und kein Team die zusätzliche Plattform dauerhaft betreuen kann. Der Artikel Brauchen wir Kubernetes? führt diese Entscheidung strukturiert durch.

Was produktionsreifer Betrieb bedeutet

Ein installiertes Cluster ist nur der Anfang. Für Produktion braucht es mindestens:

• dokumentierte Zielarchitektur und Ausfallziele,
• hochverfügbare Control Plane oder bewusst akzeptierten Single Point of Failure,
• getrennte Netzwerkzonen und kontrollierten API-Zugriff,
• Ingress/Gateway, DNS und Zertifikatsautomatisierung,
• belastbaren persistenten Storage,
• Git-basierte Delivery und reproduzierbare Konfiguration,
• Monitoring, Logging, Alerting und Kapazitätsgrenzen,
• Backup, Restore-Tests und Disaster Recovery,
• Upgrade- und Security-Prozesse für Cluster und Workloads.

Kubernetes veröffentlicht ungefähr drei Minor-Releases pro Jahr und pflegt eine Minor-Version laut offizieller Release- und Supportübersicht ungefähr ein Jahr. Wer Kubernetes betreibt, plant Upgrades deshalb als wiederkehrenden Prozess ein, nicht als seltenes Großprojekt.

Für interne APIs, Dashboards und Services muss zudem nicht alles öffentlich erreichbar sein. Mit NetBird als privater Zugriffsschicht lassen sich Cluster-Zugänge und interne Dienste identitätsbasiert bereitstellen.

Fazit

Kubernetes standardisiert den Betrieb containerisierter Anwendungen über mehrere Systeme hinweg. Seine Stärke liegt in der deklarativen API, den laufenden Regelkreisen und einem großen Ökosystem. Die Plattform passt, wenn Anforderungen an Deployment, Skalierung, Resilienz und gemeinsame Betriebsstandards den zusätzlichen Clusterbetrieb rechtfertigen. Für kleinere Systeme können Docker Compose, Coolify oder virtuelle Maschinen dieselben Anforderungen mit weniger Plattformkomponenten erfüllen.

WZ-IT ordnet deshalb zuerst Anwendung, Team, Infrastruktur und Betriebsziele ein. Wenn Kubernetes passt, bauen wir die vollständige Kette: von Proxmox, Bare Metal oder Cloud über Netzwerk und GitOps bis zu Monitoring, Backup und langfristigem Betrieb.

Quellen

• Kubernetes-Dokumentation: Konzepte
• Kubernetes-Dokumentation: Cluster-Komponenten
• Kubernetes-Dokumentation: Produktionsumgebungen
• Kubernetes-Dokumentation: Workloads
• Kubernetes: Releases und Support-Zeiträume