Was ist Kubernetes? Eine Einführung für Unternehmen

Container, Microservices und cloudnative Architekturen sind die „Markenzeichen“ einer modernen Unternehmens-IT. Der Schlüssel zu all diesen Komponenten: Kubernetes. Es automatisiert Container-Deployments und vereinfacht die Skalierung. Dieser Artikel erklärt, was Kubernetes ist und zeigt typische Einsatzszenarien. Außerdem vergleichen wir die Vor- und Nachteile von Eigenbetrieb vs. Managed Container Platforms.

Definition: Was ist Kubernetes?

Kubernetes (auch K8s) ist eine Open-Source-Plattform zur automatisierten Bereitstellung von Containern. Dabei übernimmt Kubernetes die Rolle eines Orchestrators: Es sorgt dafür, dass containerisierte Anwendungen zuverlässig laufen und sich bei Last automatisch anpassen (Container-Skalierung). Außerdem managt es Update-Prozesse.

Schnellüberblick Container: Anwendungen können in einem Container „verpackt“ werden. Der Container enthält alles, was die Anwendung braucht (Bibliotheken, Konfigurationen, Laufzeit). Dadurch kann die Anwendung überall ausgeführt werden, egal in welcher Umgebung (Rechenzentrum, Cloud) oder auf welchem Betriebssystem (Linux, Windows, macOS). Weil sich Container den Kernel des Hosts teilen, starten sie sehr schnell und verbrauchen weniger Ressourcen als virtuelle Maschinen. Wichtig: Kubernetes selbst baut keine Container-Images. Hierzu werden Tools wie Docker oder Buildah benötigt. (Siehe auch Blogartikel „Containerisierung erklärt: Der Leitfaden für IT-Teams„.)

Im Gegensatz zu klassischen Deployment-Tools verwendet Kubernetes eine deklarative Steuerung. Will heißen: Der User beschreibt gegenüber Kubernetes den gewünschten Zielzustand („desired state“) einer Anwendung. Ab dann sorgt die Plattform selbstständig dafür, dass dieser Zustand erreicht und gehalten wird. Das umfasst Funktionen wie:

• Self-Healing: Automatisches Ersetzen von Containern, falls es zu einem Ausfall kommt
• Scheduling: Automatisches Starten und Beenden von Workloads
• Ressourcenmanagement: Automatisches Zuteilen von Kernel-Ressourcen wie CPU oder RAM

Typische Use Cases für Kubernetes sind Microservices-Architekturen, Serverless-Workloads, GitOps und DevSecOps-Pipelines. Die Verbreitung ist extrem hoch: Laut einer Studie der Cloud Native Computing Foundation (CNCF) nutzten im Jahr 2024 überwältigende 93 Prozent der befragten Unternehmen Kubernetes, entweder in Produktionsumgebungen oder in Pilot- bzw. Evaluierungsprojekten. Damit ist Kubernetes der De-facto-Standard für cloudnative Anwendungen.

Es existiert ein großes Ökosystem von Erweiterungen und Tools, zum Beispiel Monitoring-Werkzeuge und Service-Meshes. Aufgrund der Open-Source-Architektur von Kubernetes ist es für Unternehmen sehr einfach, diese Module wie gewünscht zu kombinieren. Ein Vendor-Lock-in wird vermieden.

Allerdings geht Kubernetes mit einer gewissen Komplexität einher. Beispielsweise müssen Netzwerk- und Storage-Komponenten korrekt konfiguriert und Operatoren gepflegt werden. Daher kann der Betrieb schnell personalintensiv werden. Hinzu kommt die steile Lernkurve für Entwickler und Admins, falls sie nicht bereits über Kubernetes-Erfahrung verfügen.

Hier bietet sich der Bezug von Kubernetes als Managed Service an. Man spricht hier auch von Container-as-a-Service oder Managed Container Platforms. Dabei übernimmt ein externer Provider alle wichtigen Management-Aufgaben wie den Betrieb der Infrastruktur, Control-Plane-Updates und Patching. Unternehmen können sich somit voll auf die Entwicklung und den Betrieb der Anwendungen konzentrieren.

Die wichtigsten Kubernetes-Begriffe

Hier ein Überblick über die wichtigsten Kubernetes-Begriffe:

Kubectl

Kubectl ist das Kommandozeilenprogramm von Kubernetes. Damit kann ein Admin einem Kubernetes-Cluster sagen, was es tun soll. Typische Befehle in diesem Kontext sind kubectl get pods oder kubectl describe node.

Ingress

Ingress ist der „Eingang“ in ein Kubernetes-Cluster. Es nimmt HTTP-/HTTPS-Anfragen von außen an und leitet sie an die richtigen Services oder Pods weiter. Ein Beispiel wäre das Frontend einer Web-Anwendung. Die Useranfragen werden via Ingress verarbeitet.

Cluster

Ein Kubernetes-Cluster bezeichnet eine komplette Kubernetes-Umgebung. Ein Cluster besteht aus mindestens einer Control Plane und mehreren Worker Nodes darunter. Gemeinsam bilden sie die Umgebung, in der containerisierte Anwendungen ausgeführt werden.

Node

Ein Node (dt.: Knoten) ist ein physischer oder virtueller Server in einem Kubernetes-Cluster. Darauf laufen die Pods, die von Kubernetes verwaltet werden. Nodes werden häufig in Pools gruppiert (zum Beispiel GPU-Nodes für KI-Workloads oder kostengünstige Spot-Nodes).

Worker Node

Ein Worker Node ist ein Node, auf dem Anwendungen laufen. Er stellt die Rechenleistung bereit (CPU, RAM, Netzwerk, lokale Volumes). Jeder Worker Node ist somit ein Node, aber nicht jeder Node ist ein Worker Node.

Ein Worker Node enthält:

• Kubelet: Ist für die Ausführung von Pods verantwortlich und übernimmt die Kommunikation mit der Control Plane

• Container Runtime: Startet und beendet Container (zum Beispiel containerd oder CRI-O)

• Kube-proxy: Regelt die interne Kommunikation zwischen Pods und verteilt eingehende Anfragen (Service Load Balancing)

Pod

Ein Pod bildet die kleinste Ausführungseinheit in Kubernetes. Es enthält ein oder mehrere Container, die sich Ressourcen teilen (CPU, RAM, Storage, Namespaces). Jeder Pod hat eine eigene IP-Adresse, über die er angesteuert werden kann. Pods sind kurzlebig. Sollen Daten langfristig abgespeichert werden (zum Beispiel Datenbanken), muss dies über Persistent Volumes geschehen.

Control Plane

Wichtige Komponenten der Control Plane sind:

• API Server: Bildet die zentrale Schnittstelle. Alle Befehle und Abfragen an den Kubernetes-Cluster müssen den API-Server passieren.

• Scheduler: Entscheidet, auf welchem Node ein Pod laufen soll, zum Beispiel unter Berücksichtigung von verfügbaren Ressourcen (CPU, RAM).

• Controller Manager: Hält den gewünschten Zustand aufrecht (Ist-Zustand = Soll-Zustand). Das betrifft zum Beispiel die Anzahl der Pods für einen bestimmten Workload.

• etcd: Ist die zentrale Datenbank des Kubernetes-Clusters. etcd enthält Informationen zu Pods und Nodes, Konfigurationen, Wunschzustände („desired states“) usw.

Die Control Plane steuert das gesamte Cluster. Sie setzt den gewünschten Zielzustand des Administrators um und reagiert automatisch auf Ereignisse, etwa Container-Ausfälle.

Weitere relevante Begriffe in Bezug auf Kubernetes (nicht in Grafik oben inkludiert):

Deployment

Deployments organisieren Pods. Sie regeln, wie viele Pods laufen sollen, wie Updates ablaufen (Rolling Updates) und wie Änderungen rückgängig gemacht werden können (Rollbacks). All das geschieht unter Verwendung von YAML („Yet Another Markup Language“ oder „YAML Ain’t Markup Language“), einem Dateiformat zur Datenserialisierung.

ReplicaSet

ReplicaSets werden in Deployments genutzt. Sie sorgen dafür, dass die korrekte Anzahl identischer Pods aufrechterhalten wird. Zum Beispiel könnte definiert sein, dass ein bestimmter Frontend-Workload jederzeit dreimal existieren muss.

Service

Ein Service stellt eine feste, dauerhafte Zugriffsschicht auf eine Gruppe von Pods bereit. Selbst wenn Pods neu gestartet werden oder neue IPs erhalten, bleibt der Service unter derselben Adresse erreichbar.

ConfigMaps & Secrets

Hier können Konfigurationen und vertrauliche Informationen (Passwörter, Token) sicher abgelegt werden. Secrets lassen sich verschlüsseln und rotieren.

Namespaces

Namespaces sorgen für die logische Segmentierung innerhalb des Clusters, zum Beispiel nach Projekt oder Team. Das erleichtert die Governance, aber auch die Ressourcenkontrolle.

CRDs & Operatoren

CRDs (Custom Resource Definitions) erweitern Kubernetes um neue Objekttypen. Operatoren automatisieren komplexe Lifecycle-Aufgaben, wie Datenbank-Backups oder Cluster-Upgrades.

Use Cases

Kubernetes bietet verschiedene Einsatzszenarien:

1. Microservices-Architekturen

Kubernetes eignet sich ideal für Microservices-Architekturen, also für verteilte Anwendungen, die aus vielen kleinen Diensten bestehen. Die Plattform sorgt für automatisches Load Balancing, ersetzt defekte Container (Self-Healing) und führt Rolling Updates durch.

2. Cloudnative CI/CD und GitOps

Viele Unternehmen setzen Tools auf Kubernetes-Basis ein: Tekton oder Jenkins X für CI/CD sowie Argo CD oder Flux für GitOps. Diese Tools nutzen Kubernetes-APIs, um Deployments automatisiert auszuführen. Damit bildet Kubernetes heute den De-facto-Standard für automatisierte Softwarebereitstellung.

3. Data- und KI-Workloads

Moderne ML-Frameworks (TensorFlow, PyTorch, Spark Operator) laufen zunehmend containerisiert. Kubernetes unterstützt hier durch fein steuerbare Ressourcenvergabe (GPU-/CPU-Pools) sowie Batch-Verarbeitung. So lassen sich beispielsweise Trainingsjobs für LLMs orchestrieren.

4. Multi-Cloud- und Hybrid-Cloud-Strategien

Ob Bare Metal, Cloud oder On-Prem-Server, Kubernetes funktioniert überall gleich. Deshalb nutzen es Unternehmen als einheitliche Abstraktionsschicht für Multi-Cloud-Architekturen. In Kombination mit modularen IaaS-Services wird so ein Höchstmaß an Flexibilität erzielt.

5. Legacy-Modernisierung

Aktuell spielt sich in vielen Unternehmen ein Modernisierungsprozess ab, bei dem monolithische Anwendungen schrittweise containerisiert werden. Man bezeichnet dies auch als „Strangler Pattern“. Kubernetes hilft beim kontrollierten Herauslösen einzelner Funktionalitäten.

Vorteile von Kubernetes

Kubernetes bietet Unternehmen verschiedene Vorteile:

Automatische Skalierung

Kubernetes passt Anwendungen dynamisch an die Last an, indem es bei Bedarf zusätzliche Pods startet. Dadurch bleiben Services auch unter Lastspitzen stabil.

Hohe Ausfallsicherheit

Self-Healing-Mechanismen erkennen fehlerhafte Container und ersetzen sie automatisch durch neue Instanzen. Das reduziert Ausfallzeiten.

Hohe Portabilität

Kubernetes läuft identisch auf Bare Metal, On-Prem-Servern, in Clouds und in hybriden Umgebungen. So lassen sich Anwendungen flexibel verschieben, ohne Codeänderungen.

Effiziente Ressourcennutzung

Kubernetes verteilt Workloads automatisch auf geeignete Nodes, um Ressourcen optimal zu nutzen. Das verhindert Überprovisionierung und senkt Infrastrukturkosten.

Starkes Ökosystem

Es existiert eine große Auswahl an Erweiterungen und Integrationen für Kubernetes. Gleichzeitig werden durch das Open-Source-Fundament Herstellerabhängigkeiten vermieden.

Was ist eine Managed-Container-Plattform (Container-as-a-Service)?

Eine Managed-Container-Plattform, oft auch Container-as-a-Service (CaaS), bezeichnet eine extern verwaltete Container-Umgebung. Der komplette Betrieb und die Wartung erfolgen durch einen Provider. Unternehmen können sich voll auf die Anwendungen konzentrieren.

Aufgaben, die vom CaaS-Provider übernommen werden, sind:

• Netzwerkdesign
• Cluster-Management (zum Beispiel Image-Verwaltung)
• Troubleshooting
• Security-Patching
• Governance (zum Beispiel einheitliche Namespaces oder Deployment-Vorgaben)
• Monitoring
• Security (zum Beispiel Zugriffskontrollen)
• Support

All das reduziert den internen Aufwand und steigert die Verfügbarkeit. So lassen sich beispielsweise DevOps-Prozesse schneller etablieren, als wenn die Kubernetes-Plattform in Eigenregie aufgebaut werden müsste. Außerdem skaliert die Plattform dynamisch, wichtig bei plötzlich auftretenden Lastspitzen.

Bereich	Eigenbetrieb	CaaS
Aufwand	Hoch; Unternehmen müssen Hardware, Cluster-Architektur und Security selbst planen	Niedrig; Architektur ist vorkonfiguriert und sofort einsatzbereit
Standardisierung	Gefahr von Plattform-Divergenzen zwischen Teams (unterschiedliche Manifeste und Policies)	Einheitliche Vorgaben für Deployments, Namespaces und Netzwerkrichtlinien
Sicherheit	Security-Standards müssen selbst definiert und laufend durchgesetzt werden	Provider liefert zertifizierte Sicherheitsrichtlinien und übernimmt die Implementierung
Updates & Patching	Verantwortung liegt beim internen Team; wird häufig aufgeschoben	Provider führt Updates und Patches zeitnah durch, um Sicherheitslücken vorzubeugen
Fehlerbehebung	Troubleshooting liegt vollständig beim Unternehmen	Provider unterstützt beim Incident Response, inklusive Ursachenanalyse
Kontrolle	Maximale Kontrolle über Architektur und Betriebsprozesse; vorteilhaft bei strengen Compliance-Vorgaben	Ein Teil der Kontrolle wird abgegeben; nicht für jede Compliance-Strategie geeignet

Wie gestaltet man die Zusammenarbeit?

Ein CaaS-Modell entfaltet seinen vollen Nutzen nur, wenn Unternehmen und Provider sinnvolle Prozesse etablieren. Hier einige Best Practices:

1. Verantwortlichkeiten definieren

Es muss im Vorfeld klar geregelt werden, welche Aufgaben der Provider übernimmt (zum Beispiel Control Plane, Security-Patching) und welche Aufgaben im Unternehmen verbleiben (zum Beispiel CI/CD-Einbindung). Eine RACI-Matrix verhindert Missverständnisse.

2. Monitoring zentralisieren

Ein gemeinsames Dashboard (zum Beispiel Grafana oder LogicMonitor) sorgt dafür, dass alle Beteiligten dieselbe Sicht auf den Zustand der Anwendung haben.

3. Klare Prozesse aufsetzen

Prozesse sollten schriftlich im SLA definiert werden. Fragen, die hier zu beantworten sind:

• Wie werden Incidents gemeldet?
• Welche Response-Zeiten gelten?
• Wie laufen Wartungsfenster ab?

4. Security-Maßnahmen abstimmen

Legen Sie gemeinsam mit dem Provider Kubernetes-Security-Best-Practices fest:

• Definieren Sie Netzwerk-Policies (zum Beispiel mit Calico oder Cilium) für Pod-zu-Pod-Traffic-Kontrolle
• Implementieren Sie RBAC für granulares Access-Management
• Führen Sie regelmäßige Vulnerability-Scans von Images durch (zum Beispiel mit Trivy oder Clair)
• Betreiben Sie Audit-Logging

Implementieren Sie Kubernetes – mit Proact!

Sie möchten Kubernetes für Ihr Unternehmen nutzen? Dann sollten Sie die Proact Managed Container Platform (PMCP) kennenlernen, eine vollständig gemanagte, CNCF-zertifizierte Kubernetes-Umgebung.

Die Plattform bietet strukturierte Namespaces, klare Sicherheitsrichtlinien, automatisierte Updates und eine hochverfügbare Infrastruktur. So können Sie sich komplett auf die Entwicklung und den Betrieb Ihrer Anwendungen konzentrieren. Weil die PMCP auf Open-Source-Standards basiert, werden Herstellerabhängigkeiten vermieden.

Während des Onboardings unterstützt Sie ein Proact-Ansprechpartner, beispielsweise bei der Image-Verwaltung oder der Einbindung Ihrer CI/CD-Pipeline. Dabei achten wir darauf, den laufenden Betrieb so wenig wie möglich zu beeinträchtigen. Auch nach der erfolgreichen Einführung lassen wir Sie nicht alleine: Wir betreiben Monitoring, führen Optimierungen durch und beantworten zeitnah Ihre Supportanfragen.

Das klingt interessant? Dann kontaktieren Sie uns jetzt für ein kostenloses Beratungsgespräch. Wir freuen uns schon, von Ihnen zu hören!