Kubernetes (K8s) ist eine Open-Source-Container-Orchestrierungsplattform, die die Bereitstellung, Skalierung und Verwaltung containerisierter Anwendungen in einem Cluster von Maschinen automatisiert. Google veröffentlichte K8s 2014 als Open Source, und die Cloud Native Computing Foundation (CNCF) pflegt und betreut es bis heute.
Kubernetes ist eine Open-Source-Plattform zur Container-Orchestrierung, die die Bereitstellung, Skalierung und Verwaltung containerisierter Anwendungen automatisiert. Google veröffentlichte Kubernetes im Juni 2014 als Open Source, und die Cloud Native Computing Foundation (CNCF) pflegt es seit 2015. Kubernetes gruppiert Container in Pods, plant deren Ausführung auf einem Cluster von Maschinen und startet fehlgeschlagene Workloads automatisch neu.
Wichtige Erkenntnisse
- Kubernetes plant die Ausführung von Containern in einem Cluster, startet fehlgeschlagene Workloads neu und skaliert Anwendungen automatisch. Google veröffentlichte Kubernetes im Juni 2014 als Open Source, und Version 1.0 erschien am 21. Juli 2015, als das Projekt der neu gegründeten CNCF übergeben wurde.
- Ein Kubernetes-Cluster besteht aus zwei Teilen: einer Steuerungsebene (kube-apiserver, etcd, kube-scheduler und Controller-Manager), die Entscheidungen trifft, und Worker-Knoten (kubelet, Container-Runtime, kube-proxy), die die Workloads ausführen.
- Das Projekt veröffentlicht drei kleinere Versionen pro Jahr, die jeweils etwa 14 Monate lang unterstützt werden. Kubernetes v1.36, veröffentlicht am 22. April 2026, ist die aktuelle Version.
- Kubernetes-Secrets werden standardmäßig Base64-kodiert, nicht verschlüsselt. In Produktionsclustern sollte die Verschlüsselung ruhender Daten aktiviert werden; der KMS-v2-Provider ist seit Version 1.29 stabil.
- Der Ingress NGINX-Controller wurde im März 2026 eingestellt und erhält keine weiteren Sicherheitsupdates mehr. Die Gateway-API ist sein empfohlener Nachfolger.
So funktioniert Kubernetes
Kubernetes arbeitet mit einem deklarativen Modell: Sie beschreiben den gewünschten Zustand in YAML oder JSON, und die Controller gleichen den Cluster kontinuierlich auf diesen Zustand ab. Wenn Sie beispielsweise festlegen, dass eine Bereitstellung fünf Replikate eines Dienstes ausführen soll und eines davon ausfällt, erkennt Kubernetes die Lücke und startet automatisch einen Ersatz.
Stellen Sie sich ein Unternehmen vor, das ein ERP-System mit separaten Modulen für Lagerhaltung, Personalwesen und Finanzen betreibt. Mit steigender Nachfrage skaliert Kubernetes die Container hinter jedem Modul, verteilt den Datenverkehr auf die Server und startet ausgefallene Dienste neu. Zusätzlich führt es Liveness-Probes (Läuft die Anwendung noch?) und Readiness-Probes (Kann sie bereits Datenverkehr verarbeiten?) durch, sodass fehlerhafte Container neu gestartet oder außer Betrieb genommen werden, bevor es die Benutzer bemerken. Da die CNCF Kubernetes als herstellerneutrale Open-Source-Software pflegt, kann dieselbe Clusterdefinition lokal, in jeder gängigen Cloud oder in Hybridumgebungen ausgeführt werden.
Kubernetes vs. Docker Swarm
Docker Swarm ist der in Docker integrierte Clustering-Modus; er ist einfacher einzurichten als Kubernetes, deckt aber ein viel engeres Spektrum an Orchestrierungsanforderungen ab.
| Attribut | Hafenschwarm | Kubernetes |
| Einrichtung | In Docker integriert; in wenigen Minuten startbereit | Steilere Lernkurve; Managed Services (EKS, AKS, GKE) reduzieren die Belastung |
| Skalierung | Manuelle Service-Skalierung | Automatische horizontale Skalierung mit dem Horizontal Pod Autoscaler (HPA) |
| Selbstheilung | Neustarts fehlgeschlagener Container | Startet Pods neu, plant sie neu und ersetzt sie mithilfe von Liveness- und Readiness-Probes. |
| Rollouts | Laufende Updates, eingeschränkte Steuerungsmöglichkeiten | Laufende Updates plus automatisches Rollback bei fehlgeschlagenen Integritätsprüfungen |
| Ökosystem | Docker-Toolchain | CNCF-Ökosystem: Helm, Prometheus, cert-manager, Gateway-API-Implementierungen |
| Am besten geeignet, | Kleine Teams, einfache Arbeitslasten | Skalierbare Produktionssysteme, Microservices, Hybrid- und Multi-Cloud-Umgebungen |
Hauptmerkmale von Kubernetes
Kubernetes bündelt die operativen Aufgaben, die Teams früher manuell per Skript erledigten, in integrierte, deklarative Funktionen.
- Horizontale SkalierungDer horizontale Pod-Autoscaler fügt Pods basierend auf Metriken wie CPU- und Speicherauslastung hinzu oder entfernt sie. Ressourcenanforderungen und -limits ermöglichen es dem Scheduler, Container platzsparend auf Knoten zu verteilen, ohne einzelne Maschinen zu überlasten.
- Selbstheilung: Das kubelet startet Container neu, die bei den Liveness-Probes fehlschlagen, und blockiert den Datenverkehr von Pods, die bei den Readiness-Probes fehlschlagen.
- Diensterkennung und Lastverteilung: Jeder Dienst erhält einen DNS-Namen und eine stabile virtuelle IP-Adresse. ClusterIP stellt einen Dienst innerhalb des Clusters bereit, NodePort öffnet einen Port auf jedem Knoten, und LoadBalancer stellt einen Cloud-Load-Balancer für externen Datenverkehr bereit.
- Speicherorchestrierung: PersistentVolumes und PersistentVolumeClaims entkoppeln den Speicher von den Pods, und die Container Storage Interface (CSI) bindet Backends wie AWS EBS, Google Persistent Disk oder NFS mit dynamischer Bereitstellung über StorageClasses ein.
- Geheimnisse und Konfiguration: ConfigMaps enthalten Konfigurationen, während Secrets sensible Werte wie API-Schlüssel enthalten. Secrets werden standardmäßig Base64-kodiert, aber nicht verschlüsselt. Aktivieren Sie die Verschlüsselung ruhender Daten und verwenden Sie den KMS v2-Provider (stabil seit Version 1.29), um sie mit Schlüsseln zu schützen, die in einem externen Schlüsselverwaltungsdienst gespeichert sind.
- Automatisierte Rollouts und Rollbacks: Deployments aktualisieren Pods schrittweise, überwachen dabei die Integritätsprüfungen und greifen bei einem Update-Fehler auf die letzte stabile Version zurück.
- Batch-Workloads: Jobs führen Aufgaben bis zum Abschluss aus, und CronJobs führen sie nach einem Zeitplan aus, wie z. B. nächtliche Datensicherungen oder Analyseläufe.
- Dual-Stack-Netzwerk und Erweiterbarkeit: Pods und Services können sowohl IPv4- als auch IPv6-Adressen tragen, und Custom Resource Definitions erweitern die Kubernetes-API für Tools wie Prometheus-Operatoren oder cert-manager.
Kubernetes-Architektur
Ein Kubernetes-Cluster teilt die Verantwortlichkeiten zwischen einer Steuerungsebene, die globale Entscheidungen trifft, und Worker-Knoten auf, die Anwendungsworkloads ausführen.
Komponenten der Steuerebene
- kube-apiserver: Die Eingangstür des Clusters. Jeder kubectl-Befehl, jede Controller- und Knoteninteraktion läuft über den API-Server.
- etcd: Ein konsistenter Schlüsselwertspeicher, der den gesamten Clusterstatus und die Konfiguration enthält. Er ist die maßgebliche Datenquelle: Wenn eine Komponente der Steuerungsebene neu gestartet wird, stellt sie den aktuellen Zustand aus etcd wieder her.
- kube-scheduler: Weist neu erstellte Pods Knoten basierend auf Ressourcenanforderungen, Affinitätsregeln und Einschränkungen zu.
- kube-controller-manager: Führt die Abgleichschleifen aus, die dafür sorgen, dass der Ist-Zustand dem Soll-Zustand entspricht, z. B. durch Ersetzen von Pods, wenn ein Knoten ausfällt.
- Cloud-Controller-Manager: Integriert den Cluster mit den APIs eines Cloud-Anbieters für Load Balancer, Routen und den Lebenszyklus von Knoten.
Komponenten des Arbeitsknotens
- kubelet: Der Agent auf jedem Knoten, der sicherstellt, dass die in den Pod-Spezifikationen beschriebenen Container ausgeführt werden und fehlerfrei funktionieren.
- Container-Laufzeitumgebung: Die Software, die Container über die Container Runtime Interface (CRI) ausführt, typischerweise containerd oder CRI-O. Kubernetes hat die Docker-spezifische dockershim in Version 1.24 (Mai 2022) entfernt; mit Docker erstellte Images laufen weiterhin unverändert.
- kube-proxy: Verwaltet Netzwerkregeln auf jedem Knoten, damit der Service-Datenverkehr die richtigen Pods erreicht.
Kubernetes-Objekte
| Betreff | Was sie tut, | Beispielanwendungsfall |
| Schote | Kleinste einsetzbare Einheit; ein oder mehrere Container teilen sich Netzwerk und Speicher. | Eine Instanz eines Nginx-Webservers wird ausgeführt |
| Service | Stabiler Netzwerk-Endpunkt für eine Gruppe von Pods | Verbindung eines Frontends mit einer Backend-API |
| Einsatz | Verwaltet ReplicaSets, rollierende Updates und Rollbacks. | Veröffentlichung einer neuen Microservice-Version ohne Ausfallzeiten |
| Replikat-Set | Hält eine bestimmte Anzahl identischer Pods am Laufen | Für die Verfügbarkeit werden fünf Webserver-Replikate aufrechterhalten. |
| ConfigMap / Geheimnis | Konfiguration und sensible Werte speichern | Datenbankverbindungszeichenfolgen; API-Zugangsdaten |
| StatefulSet | Stabile Identität und Speicherung für zustandsbehaftete Anwendungen | MongoDB oder MySQL mit instanzspezifischen Volumes betreiben |
| Dämonenset | Führt auf jedem Knoten einen Pod aus. | Bereitstellung eines Protokollierungs- oder Überwachungsagenten im gesamten Cluster |
| Job / CronJob | Aufgaben einmalig oder nach einem Zeitplan ausführen | Nächtliche Datenbanksicherungen |
Netzwerk: Von der Eingangs- zur Gateway-API
Die Art und Weise, wie externer Datenverkehr in einen Kubernetes-Cluster gelangt, hat sich im Jahr 2026 wesentlich verändert, und jedes Team, das immer noch auf den Ingress NGINX-Controller als Standard setzt, muss handeln.
Die Ingress-API leitet externen HTTP- und HTTPS-Traffic an Services innerhalb des Clusters weiter und kann TLS beenden. Die API selbst ist weiterhin Teil von Kubernetes, ihre Funktionalität ist jedoch eingefroren. Ihre beliebteste Implementierung, der Ingress-NGINX-Controller, wurde vom Kubernetes-Projekt am 24. März 2026 nach einer Ankündigung vom 12. November 2025 eingestellt; das Repository ist schreibgeschützt und erhält keine weiteren Bugfixes oder CVE-Patches.
In einer Erklärung vom 29. Januar 2026 stellten die Kubernetes Steering Committee und Security Response Committee fest, dass etwa die Hälfte der Cloud-nativen Umgebungen Ingress NGINX verwenden, und forderten eine sofortige Migration.
Die Gateway-API, die seit Version 1.0 im Oktober 2023 allgemein verfügbar ist, ist der empfohlene Nachfolger. Sie trennt Infrastrukturaspekte (Gateways) von Anwendungsrouting (HTTPRoutes), unterstützt umfassendere Verkehrssteuerung und verhält sich konsistent über Implementierungen wie Envoy Gateway, Cilium und Cloud-Provider-Gateways hinweg.
Das Tool ingress2gateway, das im März 2026 Version 1.0 erreichte, wandelt bestehende Ingress-Ressourcen in Gateway-API-Äquivalente um. Teams, die weiterhin die Ingress-API nutzen möchten, können auf einen aktiv gewarteten Drittanbieter-Controller wie Traefik, HAProxy oder den kommerziellen F5 NGINX Ingress Controller umsteigen.
Kubernetes in DevOps und CI/CD
Kubernetes bietet DevOps-Teams ein einheitliches Bereitstellungsziel und ein einheitliches Betriebsmodell für jede Umgebung. Deshalb bildet es den Ankerpunkt der meisten modernen CI/CD-Pipelines.
Mit Jenkins, GitLab CI oder ähnlichen Tools erstellte Pipelines erstellen ein Container-Image, übertragen es an eine Registry und wenden ein aktualisiertes Manifest auf den Cluster an; Kubernetes führt dann das Rolling Update durch und rollt automatisch zurück, wenn die Integritätsprüfungen fehlschlagen.
In GitOps-Workflows überwachen Tools wie Argo CD und Flux ein Git-Repository und synchronisieren den Cluster damit, sodass jede Änderung versionskontrolliert und nachvollziehbar ist. Da Manifeste deklarativ sind, werden dieselben Definitionen in Entwicklung, Staging und Produktion identisch ausgeführt. Um mehr über die Funktionsweise von DevOps zu erfahren, lesen Sie bitte den entsprechenden Artikel.
PKI und TLS in Kubernetes
Jeder Kubernetes-Cluster ist eine funktionierende Public-Key-Infrastruktur: X.509-Zertifikate authentifizieren und verschlüsseln nahezu jede Verbindung zwischen den Komponenten, unabhängig davon, ob das Team, das den Cluster betreibt, über Zertifikate nachdenkt oder nicht.
Die Public-Key-Infrastruktur (PKI) ist das Framework aus Zertifizierungsstellen (CAs), Zertifikaten und Schlüsseln, das Vertrauen zwischen Systemen herstellt. In Kubernetes sichern TLS-Zertifikate (Transport Layer Security) den Endpunkt des API-Servers, die Verbindung des Kubelets zur Steuerungsebene, den Datenverkehr zwischen etcd-Peers und -Clients sowie alle über HTTPS bereitgestellten Dienste.
Clientzertifikate authentifizieren Benutzer und Komponenten gegenüber dem API-Server. Cluster, die mit kubeadm initialisiert wurden, generieren diese PKI automatisch. Ihre Clientzertifikate laufen standardmäßig nach einem Jahr ab, daher muss die Erneuerung überwacht oder automatisiert werden, um Ausfälle zu vermeiden.
Für Workload-Zertifikate automatisiert cert-manager die Ausstellung und Erneuerung innerhalb des Clusters und wurde am 12. November 2024 als CNCF-Projekt offiziell anerkannt, wodurch es den gleichen Reifegrad wie Kubernetes selbst erreicht hat. Zertifikate gelangen typischerweise als Kubernetes-Secrets in den Cluster, auf die Gateways oder Ingress-Ressourcen verweisen; die korrekte Generierung der zugrunde liegenden Zertifikatsignierungsanforderung (CSR) ist der erste Schritt in diesem Prozess.
Im Unternehmensmaßstab sollten Cluster- und Workload-Zertifikate dem gleichen Lebenszyklusmanagementprozess unterliegen wie der Rest der Infrastruktur, insbesondere da die maximale Gültigkeit öffentlicher TLS-Zertifikate gemäß dem Zeitplan des CA/Browser Forums bis März 2029 auf 47 Tage sinkt.
Kubernetes-Sicherheitsrisiken und Best Practices
Die meisten Sicherheitslücken in Kubernetes lassen sich auf eine kleine Anzahl wiederkehrender Schwachstellen zurückführen, die jeweils über gut verstandene Kontrollmechanismen verfügen.
| Risiko | Warum es wichtig ist | Best-Practice- |
| Fehlkonfigurierte Zugriffskontrolle | Schwache oder standardmäßige RBAC-Einstellungen ermöglichen es nicht autorisierten Benutzern, den Cluster zu manipulieren. | Setzen Sie das Prinzip der minimalen Berechtigungen (RBAC) durch, überprüfen Sie regelmäßig die Zugriffsrechte und wenden Sie Netzwerkrichtlinien an. |
| Anfällige Containerbilder | Veraltete oder nicht verifizierte Bilder übertragen bekannte CVEs in die Produktion. | Greifen Sie auf vertrauenswürdige Datenbanken zu und scannen Sie Bilder mit Tools wie Trivy. |
| Unverschlüsselte Geheimnisse | Base64-kodierte Geheimnisse sind für jeden mit etcd- oder API-Zugriff lesbar. | Aktivieren Sie die Verschlüsselung ruhender Daten mit KMS v2; beschränken Sie den Zugriff auf geheime Daten über RBAC. |
| Ungepatchte Eingangsschicht | Für veraltete Controller wie Ingress NGINX werden nach März 2026 keine CVE-Fixes mehr behoben. | Migration zu Gateway-API oder einem verwalteten Controller |
| Nicht unterzeichnete Lieferkette | Manipulierte Images und Abhängigkeiten gelangen unbemerkt in den Cluster. | Bilder mit Sigstore Cosign signieren und verifizieren; Zulassungsrichtlinien durchsetzen |
| Abgelaufene Zertifikate | kubeadm-Clientzertifikate laufen nach einem Jahr ab und führen zu Problemen bei der Clusterauthentifizierung. | Überwachung und Automatisierung der Zertifikatserneuerung in Clustern |
Für eine detailliertere Behandlung siehe die Leitfäden von EC zu Best Practices für die Kubernetes-Sicherheit , zur Absicherung von Containern und zu Maschinenidentitäten in Kubernetes im Zero-Trust-Modell.
Wie Verschlüsselungsberatung hilft
CertSecure Manager ist die Zertifikatslebenszyklusmanagement-Plattform von Encryption Consulting. Sie erkennt die in Ihren Kubernetes-Clustern und Ihrer gesamten IT-Infrastruktur verwendeten Zertifikate, automatisiert deren Ausstellung und Verlängerung durch Integrationen wie cert-manager und warnt Sie vor dem Ablauf von Zertifikaten, bevor es zu Ausfällen kommt. Die PKI-Services von Encryption Consulting entwerfen und betreiben anschließend die CA-Hierarchie, die das Vertrauen in Ihren Clustern sichert. Die Plattform basiert auf ISO/IEC 27001:2022- und SOC 2-zertifizierten Verfahren.
Häufig gestellte Fragen
Was ist Kubernetes in einfachen Worten?
Kubernetes ist eine Software, die containerisierte Anwendungen auf einer Gruppe von Maschinen, einem sogenannten Cluster, ausführt und verwaltet. Sie definieren den gewünschten Zustand, beispielsweise drei Instanzen eines Webservers, und Kubernetes startet die Container, verteilt sie auf die Maschinen, ersetzt ausgefallene Container und fügt bei steigendem Datenverkehr weitere hinzu.
Worin besteht der Unterschied zwischen Kubernetes und Docker?
Docker erstellt und führt einzelne Container auf einem einzelnen Rechner aus. Kubernetes orchestriert viele Container auf mehreren Rechnern und übernimmt dabei Planung, Skalierung, Netzwerkbetrieb und Wiederherstellung. Beide arbeiten zusammen: Mit Docker erstellte Container-Images laufen in Kubernetes-Pods. Seit Kubernetes v1.24 im Mai 2022 dockershim entfernt hat, führen Cluster diese Images über CRI-Laufzeitumgebungen wie containerd oder CRI-O aus.
Wie häufig wird Kubernetes veröffentlicht und welche Version ist die aktuelle?
Das Kubernetes-Projekt veröffentlicht drei kleinere Versionen pro Jahr, die jeweils etwa 14 Monate lang mit Patches versorgt werden. Es werden stets die drei aktuellsten Nebenversionen unterstützt. Kubernetes v1.36, veröffentlicht am 22. April 2026, ist die aktuelle Nebenversion; v1.37 ist für den 26. August 2026 geplant.
Sind Kubernetes-Secrets standardmäßig verschlüsselt?
Nein. Kubernetes-Secrets werden Base64-kodiert, was eine reversible Kodierung, aber keine Verschlüsselung ist. Jeder mit Zugriff auf etcd oder ausreichenden API-Berechtigungen kann sie lesen. In Produktionsclustern sollte die Verschlüsselung ruhender Daten über eine EncryptionConfiguration aktiviert werden, idealerweise mit dem KMS-v2-Provider, der in Kubernetes v1.29 stabil wurde und Secrets mit Schlüsseln verschlüsselt, die in einem externen Schlüsselverwaltungsdienst gespeichert sind.
Was hat Ingress NGINX in Kubernetes ersetzt?
Das Kubernetes-Projekt hat den Ingress NGINX-Controller im März 2026 eingestellt, und das Repository erhält keine Bugfixes oder Sicherheitspatches mehr. Die Ingress-API selbst existiert zwar noch, wird aber nicht mehr weiterentwickelt. Für neue Bereitstellungen wird die Gateway-API als Nachfolger empfohlen, und das Tool ingress2gateway konvertiert bestehende Ingress-Ressourcen während der Migration.
Warum benötigt Kubernetes PKI- und TLS-Zertifikate?
Jede Verbindung zwischen Kubernetes-Komponenten, einschließlich API-Server, etcd, Kubelets und Controllern, wird mit X.509-Zertifikaten von Cluster-Zertifizierungsstellen authentifiziert und verschlüsselt. Ohne diese Public-Key-Infrastruktur könnte jeder Prozess eine Cluster-Komponente imitieren. Von kubeadm ausgestellte Zertifikate laufen standardmäßig nach einem Jahr ab; daher muss die Erneuerung überwacht oder automatisiert werden.
Automatisieren Sie Zertifikatslebenszyklen in Ihren Clustern
Zertifikatsfehler führen unbemerkt zum Ausfall von Kubernetes-Clustern. Automatisieren Sie Zertifikatslebenszyklen mit CertSecure Manager oder generieren Sie Ihre nächste CSR in Sekundenschnelle mit dem kostenlosen CSR-Generator von EC.