Orchestrierung Kubernetes: Grundlagen & Praxis

Wer sich intensiver mit Docker beschäftigt, kommt früher oder später an einen Punkt, an dem einzelne Container nicht mehr ausreichen. Einen Webserver mit Docker zu starten, ist schnell erledigt. Aber was passiert, wenn eine Anwendung aus mehreren Containern besteht, auf unterschiedlichen Servern läuft und auch bei einem Ausfall verfügbar bleiben soll?

Genau hier wird das Thema Orchestrierung mit Kubernetes interessant.

Kubernetes übernimmt viele Aufgaben, die bei einer größeren Container-Infrastruktur sonst manuell erledigt werden müssten. Dazu gehören das Starten von Anwendungen, die Verteilung auf verschiedene Server, die Überwachung des gewünschten Zustands und das kontrollierte Ausrollen neuer Versionen.

Das klingt zunächst nach einer komfortablen Container-Verwaltung. Tatsächlich steckt aber deutlich mehr dahinter.

In diesem Artikel schauen wir uns an, wie die Container-Orchestrierung mit Kubernetes funktioniert, welche Komponenten dabei zusammenarbeiten und warum Kubernetes in vielen modernen IT-Umgebungen eingesetzt wird. Außerdem zeige ich dir an einem konkreten Beispiel, wie du eine Anwendung mit mehreren Instanzen bereitstellen kannst.

Was bedeutet Orchestrierung mit Kubernetes?

Der Begriff Orchestrierung beschreibt in der IT die koordinierte Verwaltung und Automatisierung mehrerer Komponenten.

Bei Containern bedeutet das, dass Anwendungen nicht mehr einzeln gestartet, überwacht und verwaltet werden müssen. Stattdessen übernimmt ein Orchestrierungssystem einen großen Teil dieser Aufgaben.

Kubernetes ist eine Open-Source-Plattform, die speziell für die Verwaltung containerisierter Anwendungen entwickelt wurde.

Dabei geht es nicht nur darum, Container zu starten. Kubernetes kümmert sich auch darum, wo eine Anwendung ausgeführt wird, wie viele Instanzen benötigt werden und was passiert, wenn ein Container oder ein kompletter Server ausfällt.

Ein wichtiger Unterschied zur klassischen Automatisierung ist der sogenannte deklarative Ansatz.

Du beschreibst nicht jeden einzelnen Arbeitsschritt, sondern legst fest, welcher Zustand am Ende vorhanden sein soll.

Ein Beispiel:

Du möchtest eine Webanwendung mit drei Instanzen betreiben. Statt drei Container manuell auf unterschiedlichen Servern zu starten, definierst du in Kubernetes, dass drei entsprechende Pods laufen sollen.

Kubernetes versucht anschließend kontinuierlich, diesen gewünschten Zustand herzustellen und beizubehalten.

Wenn ein Pod ausfällt, erkennt der zuständige Controller, dass der gewünschte Zustand nicht mehr erfüllt ist. Kubernetes sorgt dann dafür, dass eine Ersatzinstanz erstellt wird.

Genau dieses Prinzip ist der Kern der Kubernetes-Orchestrierung: Du definierst den Soll-Zustand, Kubernetes gleicht ihn kontinuierlich mit dem Ist-Zustand ab.

Warum reicht Docker alleine häufig nicht aus?

Docker ist ein hervorragendes Werkzeug, um Container zu erstellen und auszuführen.

Mit wenigen Befehlen lässt sich ein Webserver starten, ein Container-Netzwerk einrichten oder eine Datenbank bereitstellen.

Für kleinere Projekte ist das oft vollkommen ausreichend.

Stell dir aber vor, du betreibst eine Anwendung, die aus folgenden Komponenten besteht:

Drei Webservern für eingehende Anfragen
Zwei Backend-Instanzen für die eigentliche Anwendungslogik
Einem Redis-Cache
Einer Datenbank
Mehreren Hintergrundprozessen für die Verarbeitung von Aufgaben

Solange alles auf einem einzelnen Server läuft, lässt sich eine solche Umgebung beispielsweise mit Docker Compose noch relativ übersichtlich verwalten.

Schwieriger wird es, wenn mehrere Server beteiligt sind.

Was passiert, wenn einer dieser Server nicht mehr erreichbar ist? Wie wird die Last verteilt? Wie stellst du sicher, dass neue Container genügend Ressourcen bekommen? Und wie aktualisierst du die Anwendung, ohne alle Instanzen gleichzeitig zu stoppen?

Natürlich lassen sich viele dieser Aufgaben auch mit Skripten und zusätzlichen Werkzeugen lösen.

Allerdings entsteht dadurch schnell eine eigene Verwaltungsplattform, die ebenfalls gepflegt, überwacht und weiterentwickelt werden muss.

Kubernetes bietet für diese Aufgaben eine standardisierte Grundlage.

Das bedeutet nicht, dass Docker Compose grundsätzlich ungeeignet ist. Für lokale Entwicklungsumgebungen oder kleinere Projekte ist es häufig sogar die einfachere Lösung.

Eine Kubernetes-Orchestrierung lohnt sich vor allem dann, wenn die Anforderungen an Verfügbarkeit, Skalierung und automatisierten Betrieb entsprechend hoch sind.

Wie ist ein Kubernetes-Cluster aufgebaut?

Um die Orchestrierung mit Kubernetes zu verstehen, solltest du zunächst den Aufbau eines Kubernetes-Clusters kennen.

Ein Cluster besteht im Wesentlichen aus zwei Bereichen:

Control Plane: Verwaltet und steuert den Cluster.
Worker Nodes: Führen die eigentlichen Anwendungen aus.

Beide Bereiche arbeiten eng zusammen, haben aber unterschiedliche Aufgaben.

Die Control Plane – die Steuerzentrale von Kubernetes

Die Control Plane ist für die Verwaltung des Clusters verantwortlich.

Hier laufen die zentralen Komponenten, die Entscheidungen treffen, Konfigurationen verarbeiten und den Zustand der Ressourcen überwachen.

Zu den wichtigsten Komponenten gehören:

kube-apiserver: Stellt die Kubernetes-API bereit und ist die zentrale Schnittstelle für die Kommunikation mit dem Cluster.
etcd: Speichert die Konfigurations- und Zustandsdaten des Kubernetes-Clusters.
kube-scheduler: Entscheidet, auf welchem geeigneten Node ein neuer Pod ausgeführt werden soll.
kube-controller-manager: Führt verschiedene Controller aus, die den gewünschten Zustand der Ressourcen überwachen und entsprechende Änderungen veranlassen.
cloud-controller-manager: Integriert bei entsprechenden Installationen Funktionen eines Cloud-Anbieters.

Gerade das Zusammenspiel zwischen API Server, Scheduler und Controllern ist entscheidend.

Ein Deployment wird beispielsweise nicht einfach direkt auf einem beliebigen Server gestartet.

Stattdessen wird zunächst seine Konfiguration über die Kubernetes-API verarbeitet. Die zuständigen Controller erstellen die benötigten Ressourcen. Anschließend weist der Scheduler noch nicht zugewiesene Pods geeigneten Nodes zu.

Erst auf dem ausgewählten Node werden die Container gestartet.

Worker Nodes – hier laufen die Anwendungen

Die Worker Nodes stellen die Ressourcen für deine Anwendungen bereit.

Auf ihnen befinden sich unter anderem folgende Komponenten:

kubelet: Überwacht die dem Node zugewiesenen Pods und sorgt über die Container Runtime dafür, dass deren Container ausgeführt werden.
Container Runtime: Führt die eigentlichen Container aus. Häufig werden containerd oder CRI-O eingesetzt.
Netzwerkkomponenten: Stellen die notwendige Kommunikation zwischen Pods, Services und anderen Netzwerkteilnehmern bereit.

Je nach Kubernetes-Installation kommt zusätzlich kube-proxy zum Einsatz. Manche Netzwerkimplementierungen können dessen Aufgaben auch anders umsetzen.

Wichtig ist: Ein Worker Node entscheidet normalerweise nicht selbst, welche Anwendung er betreiben soll.

Die Zuweisung erfolgt über die Kubernetes-Steuerungsebene. Das kubelet auf dem jeweiligen Node kümmert sich anschließend um die Ausführung.

Pods, Deployments und Services: Die wichtigsten Grundlagen

Wenn du Kubernetes zum ersten Mal verwendest, wirken die vielen Ressourcen und Begriffe schnell unübersichtlich.

Besonders wichtig sind am Anfang drei Objekte: Pods, Deployments und Services.

Wer deren Zusammenspiel verstanden hat, kann bereits einen großen Teil der grundlegenden Kubernetes-Orchestrierung nachvollziehen.

Pods – die kleinste ausführbare Einheit

Ein Pod ist die kleinste bereitstellbare Einheit in Kubernetes.

Er enthält einen oder mehrere Container, die sich bestimmte Ressourcen teilen. Dazu gehören insbesondere Netzwerk-Namespace und Pod-IP-Adresse.

In vielen Fällen enthält ein Pod genau einen Anwendungscontainer.

Es gibt aber auch Situationen, in denen mehrere Container innerhalb eines Pods sinnvoll sind, beispielsweise wenn ein zusätzlicher Container eine unterstützende Funktion übernimmt.

Ein wichtiges Detail: Pods sind grundsätzlich keine dauerhaft unveränderlichen Objekte.

Sie können beendet, gelöscht und durch neue Pods ersetzt werden. Dabei kann sich auch ihre IP-Adresse ändern.

Genau deshalb solltest du Anwendungen in Kubernetes normalerweise nicht über die feste IP-Adresse eines einzelnen Pods ansprechen.

Deployments – Anwendungen kontrolliert verwalten

Ein Deployment beschreibt, wie eine Anwendung ausgeführt werden soll.

Unter anderem kannst du festlegen:

Welches Container-Image verwendet wird
Wie viele Pod-Instanzen laufen sollen
Welche Ressourcen benötigt werden
Welche Labels die Pods erhalten
Wie Änderungen ausgerollt werden

Das Deployment verwaltet dafür ReplicaSets, die wiederum die gewünschte Anzahl an Pods sicherstellen.

Wenn du beispielsweise drei Replikate definierst, versucht Kubernetes, drei entsprechende Pods bereitzustellen.

Wird einer dieser Pods gelöscht, erstellt der zuständige Controller normalerweise eine Ersatzinstanz.

Ein Deployment eignet sich besonders für zustandslose Anwendungen wie Webserver oder API-Dienste.

Services – stabile Erreichbarkeit für Anwendungen

Ein Kubernetes Service stellt eine stabile Möglichkeit bereit, eine Gruppe von Pods über das Netzwerk zu erreichen.

Warum ist das wichtig?

Weil einzelne Pods ersetzt werden können und ihre IP-Adressen nicht dauerhaft gleich bleiben müssen.

Ein Service verwendet normalerweise Labels und Selektoren, um die passenden Pods zu identifizieren.

Die zugehörigen Endpoints werden entsprechend aktualisiert, wenn neue Pods hinzukommen oder vorhandene Pods verschwinden.

Damit müssen andere Anwendungen nicht wissen, auf welchem Node ein bestimmter Container gerade ausgeführt wird.

Für die Kommunikation innerhalb des Clusters wird häufig der Service-Typ ClusterIP verwendet.

Sollen Anwendungen von außerhalb erreichbar sein, kommen beispielsweise LoadBalancer-Services oder eine passende Gateway- beziehungsweise Ingress-Lösung infrage.

Praxisbeispiel: Eine Anwendung mit Kubernetes orchestrieren

Schauen wir uns jetzt an, wie das Ganze in der Praxis aussieht.

Wir möchten einen Nginx-Webserver bereitstellen und dabei sicherstellen, dass drei Instanzen der Anwendung laufen.

Voraussetzung ist ein funktionierender Kubernetes-Cluster sowie eine konfigurierte kubectl-Verbindung.

Für unser Beispiel erstellen wir eine Datei mit dem Namen nginx-deployment.yaml.

Schritt 1: Deployment erstellen

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-webserver
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-webserver
  template:
    metadata:
      labels:
        app: nginx-webserver
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "64Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

Was passiert hier genau?

Mit kind: Deployment legen wir fest, dass Kubernetes ein Deployment erstellen soll.

Der Eintrag replicas: 3 definiert, dass drei Pod-Instanzen vorhanden sein sollen.

Über selector und die passenden Labels wird bestimmt, welche Pods zum Deployment gehören.

Im Bereich containers definieren wir das Nginx-Image und den verwendeten Container-Port.

Zusätzlich haben wir Ressourcenanforderungen und Limits angegeben.

Die Requests helfen dem Scheduler bei der Auswahl geeigneter Nodes. Die Limits begrenzen die Ressourcen, die ein Container verwenden darf.

Für eine produktive Umgebung solltest du außerdem eine konkret freigegebene Image-Version oder einen Image-Digest verwenden. Ein beweglicher Tag wie nginx:stable eignet sich für ein einfaches Beispiel, garantiert aber nicht dauerhaft dasselbe Image.

Schritt 2: Deployment im Cluster erstellen

Nachdem wir die YAML-Datei gespeichert haben, können wir sie mit folgendem Befehl anwenden:

kubectl apply -f nginx-deployment.yaml

Kubernetes verarbeitet nun die Konfiguration und erstellt das Deployment.

Mit folgendem Befehl überprüfen wir den Zustand:

kubectl get deployments

Die verfügbaren Pods kannst du dir ebenfalls anzeigen lassen:

kubectl get pods -o wide

Bei einem funktionierenden Cluster sollten nach erfolgreichem Start drei entsprechende Pods vorhanden sein.

Mit der Option -o wide erhältst du zusätzliche Informationen, beispielsweise darüber, auf welchem Node ein Pod ausgeführt wird.

Schritt 3: Einen Kubernetes Service erstellen

Damit unsere Anwendung über einen stabilen Endpunkt innerhalb des Clusters erreichbar ist, erstellen wir einen Service.

Speichere folgende Konfiguration als nginx-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP
  selector:
    app: nginx-webserver
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Anschließend wenden wir die Datei an:

kubectl apply -f nginx-service.yaml

Der Service identifiziert anhand des Labels app: nginx-webserver die zugehörigen Pods.

Andere Anwendungen innerhalb des Clusters können den Service bei funktionierender Cluster-DNS-Konfiguration über seinen Namen erreichen.

Zum Testen auf deinem lokalen Rechner kannst du eine Portweiterleitung einrichten:

kubectl port-forward service/nginx-service 8080:80

Danach lässt sich der Webserver über http://localhost:8080 aufrufen.

Der Port-Forward-Befehl ist insbesondere für Tests und Fehlersuche geeignet. Er ersetzt keine produktive Veröffentlichung über einen geeigneten Netzwerkzugang.

Schritt 4: Kubernetes-Selbstheilung testen

Jetzt kommt ein interessanter Teil.

Wir löschen absichtlich einen der drei Pods und beobachten, wie Kubernetes darauf reagiert.

Zeige zunächst alle Pods an:

kubectl get pods

Wähle anschließend einen der angezeigten Pod-Namen aus und lösche ihn:

kubectl delete pod POD-NAME

Ersetze POD-NAME durch den tatsächlichen Namen.

Nun kannst du die Pods kontinuierlich beobachten:

kubectl get pods -w

Normalerweise wirst du sehen, dass ein neuer Pod erstellt wird.

Der Grund dafür ist nicht, dass Kubernetes den alten Container einfach wieder einschaltet.

Stattdessen stellt der zuständige Controller fest, dass weniger Pods vorhanden sind als im Deployment definiert.

Daraufhin wird eine neue Instanz erstellt, um den gewünschten Zustand wiederherzustellen.

Wichtig: Diese Selbstheilung funktioniert nur innerhalb der verfügbaren Ressourcen und Möglichkeiten des Clusters. Wenn beispielsweise kein geeigneter Node vorhanden ist, kann Kubernetes einen Ersatz-Pod zwar erstellen, aber nicht erfolgreich starten.

Wie entscheidet Kubernetes, auf welchem Node ein Pod läuft?

Eine besonders interessante Aufgabe innerhalb der Orchestrierung übernimmt der Kubernetes Scheduler.

Er entscheidet, welchem Node ein noch nicht zugewiesener Pod zugeordnet wird.

Dabei wird nicht einfach irgendein freier Server ausgewählt.

Der Scheduler berücksichtigt verschiedene Kriterien, unter anderem:

Verfügbare und bereits angeforderte Ressourcen
CPU- und Arbeitsspeicher-Requests
Node Labels und Node Selector
Node Affinity und Pod Affinity
Taints und Tolerations
Topologie- und Verteilungsregeln
Weitere Scheduling-Einschränkungen

Ein typisches Beispiel ist eine Anwendung, die besonders viel Arbeitsspeicher benötigt.

Wenn ein Pod 4 GiB RAM anfordert, muss ein geeigneter Node entsprechend genügend nicht bereits reservierte Kapazität besitzen.

Reichen die verfügbaren Ressourcen nicht aus, kann der Pod im Status Pending bleiben.

Das lässt sich beispielsweise mit folgendem Befehl untersuchen:

kubectl describe pod POD-NAME

Im Bereich Events findest du häufig Hinweise, warum ein Pod nicht eingeplant werden konnte.

Gerade bei Scheduling-Problemen lohnt es sich, zuerst die Events zu prüfen, bevor du wahllos Konfigurationen änderst.

Skalierung: Wie Kubernetes auf steigende Last reagiert

Ein großer Vorteil der Kubernetes-Orchestrierung ist die Möglichkeit, Anwendungen flexibel zu skalieren.

Grundsätzlich gibt es zwei wichtige Ansätze:

Horizontale Skalierung

Bei der horizontalen Skalierung wird die Anzahl der Anwendungsinstanzen erhöht oder verringert.

Wenn deine Webanwendung mehr Anfragen verarbeiten muss, kannst du beispielsweise aus drei Pods sechs machen.

Manuell funktioniert das mit folgendem Befehl:

kubectl scale deployment nginx-webserver --replicas=6

Kubernetes versucht danach, sechs Pods für das Deployment bereitzustellen.

Das funktioniert allerdings nur, wenn genügend Cluster-Ressourcen verfügbar sind.

Horizontal Pod Autoscaler (HPA)

Mit einem Horizontal Pod Autoscaler lässt sich die Anzahl der Pods anhand bestimmter Metriken automatisch anpassen.

Ein häufig verwendetes Beispiel ist die durchschnittliche CPU-Auslastung relativ zu den definierten CPU-Requests.

Ein HPA könnte so erstellt werden:

kubectl autoscale deployment nginx-webserver \
  --cpu-percent=70 \
  --min=3 \
  --max=10

Damit wird ein Autoscaler eingerichtet, der bei entsprechenden Messwerten die Replikazahl innerhalb des definierten Bereichs anpassen kann.

Voraussetzung ist, dass die benötigten CPU-Metriken im Cluster bereitgestellt werden, beispielsweise über einen korrekt eingerichteten Metrics Server.

Ein häufiger Irrtum ist, dass Kubernetes automatisch zusätzliche Server erstellt, sobald mehr Pods benötigt werden.

Das ist nicht grundsätzlich der Fall.

Der HPA skaliert zunächst die Anzahl der Pods. Sollen bei fehlender Kapazität auch zusätzliche Nodes bereitgestellt werden, wird eine passende Node-Autoscaling-Lösung benötigt.

Rolling Updates: Anwendungen ohne geplanten Komplettausfall aktualisieren

In produktiven Umgebungen gehören regelmäßige Updates zum Alltag.

Neue Container-Images müssen bereitgestellt, Sicherheitsupdates eingespielt und Fehler korrigiert werden.

Wenn eine Anwendung nur aus einem einzelnen Container besteht, kann ein Update zu einer Unterbrechung führen.

Bei mehreren Instanzen ermöglicht Kubernetes sogenannte Rolling Updates.

Dabei werden alte Pods schrittweise durch neue ersetzt.

Wie viele Pods gleichzeitig ersetzt werden dürfen, lässt sich über die Deployment-Strategie beeinflussen.

Ein Update des Container-Images könnte beispielsweise so aussehen:

kubectl set image deployment/nginx-webserver \
  nginx=nginx:1.28

Anschließend kannst du den Fortschritt beobachten:

kubectl rollout status deployment/nginx-webserver

Sollte eine neue Version Probleme verursachen, lässt sich unter geeigneten Voraussetzungen ein Rollback auf die vorherige Deployment-Revision durchführen:

kubectl rollout undo deployment/nginx-webserver

Allerdings solltest du Rolling Updates nicht automatisch mit vollständiger Ausfallsicherheit gleichsetzen.

Entscheidend ist unter anderem, ob die Anwendung korrekt auf Beendigungs- und Startsignale reagiert und ob Readiness Probes sinnvoll konfiguriert wurden.

Erst wenn neue Pods tatsächlich bereit sind, sollten sie regulären Anwendungstraffic erhalten.

Readiness und Liveness Probes richtig verstehen

Ein Container kann technisch laufen, obwohl die darin enthaltene Anwendung nicht richtig funktioniert.

Ein Webserver-Prozess könnte beispielsweise gestartet sein, aber aufgrund eines internen Fehlers keine gültigen Antworten liefern.

Für solche Situationen stellt Kubernetes sogenannte Probes bereit.

Liveness Probe

Die Liveness Probe überprüft, ob ein Container neu gestartet werden sollte.

Schlägt diese Prüfung wiederholt fehl, kann das kubelet den betreffenden Container neu starten.

Readiness Probe

Die Readiness Probe prüft, ob ein Container bereit ist, regulären Netzwerkverkehr zu verarbeiten.

Wenn die Prüfung fehlschlägt, wird der entsprechende Pod normalerweise nicht als bereit für die Service-Endpunkte betrachtet.

Das ist besonders während eines Deployments wichtig.

Startup Probe

Zusätzlich gibt es die Startup Probe.

Sie eignet sich insbesondere für Anwendungen, die längere Zeit zum Starten benötigen.

Solange die Startup Probe noch nicht erfolgreich war, werden Liveness- und Readiness-Probes für den betreffenden Container nicht ausgeführt.

Eine sinnvolle Probe-Konfiguration kann verhindern, dass Anwendungen zu früh Anfragen erhalten oder bei einem langsamen Start unnötig neu gestartet werden.

Falsch konfigurierte Probes können allerdings selbst zur Ursache von Ausfällen werden.

Typische Probleme bei der Kubernetes-Orchestrierung

So leistungsfähig Kubernetes auch ist: Im Betrieb läuft nicht immer alles wie geplant.

Besonders bei den ersten Deployments begegnen einem bestimmte Fehlermeldungen regelmäßig.

Pods bleiben im Status Pending

Ein Pod im Status Pending konnte möglicherweise noch keinem geeigneten Node zugewiesen werden.

Häufige Ursachen sind fehlende Ressourcen, nicht passende Node-Selektoren oder Einschränkungen durch Taints.

Auch das Warten auf benötigte Volumes kann eine Rolle spielen.

Für die Fehlersuche ist kubectl describe pod meistens der erste sinnvolle Schritt.

CrashLoopBackOff

Bei CrashLoopBackOff startet ein Container wiederholt neu, wobei Kubernetes die Neustarts zunehmend verzögert.

Mögliche Ursachen sind:

Fehlerhafte Anwendungskonfiguration
Fehlende Umgebungsvariablen
Nicht erreichbare externe Abhängigkeiten
Probleme beim Anwendungsstart
Unpassende Liveness-Probes

Zur Analyse helfen unter anderem:

kubectl logs POD-NAME
kubectl logs POD-NAME --previous
kubectl describe pod POD-NAME

Mit --previous kannst du Logs der vorherigen Container-Instanz abrufen, sofern diese noch verfügbar sind.

ImagePullBackOff

Wenn Kubernetes ein Container-Image nicht herunterladen kann, erscheint häufig der Status ImagePullBackOff.

Überprüfe in diesem Fall den Imagenamen, den Tag, die Erreichbarkeit der Registry und gegebenenfalls benötigte Zugangsdaten.

Ein Service ist nicht erreichbar

Bei Netzwerkproblemen solltest du nicht sofort von einem Fehler des CNI-Plugins ausgehen.

Oft liegt die Ursache deutlich näher.

Kontrolliere zunächst, ob der Service die richtigen Labels verwendet und passende Endpoints vorhanden sind.

kubectl get service nginx-service
kubectl get endpointslices \
  -l kubernetes.io/service-name=nginx-service

Auch Readiness-Probes, NetworkPolicies und Anwendungsports sollten überprüft werden.

Sicherheit gehört zur Container-Orchestrierung dazu

Eine funktionierende Kubernetes-Umgebung ist nicht automatisch eine sichere Kubernetes-Umgebung.

Gerade wenn mehrere Teams und Anwendungen denselben Cluster verwenden, solltest du dich früh mit Sicherheitsmechanismen beschäftigen.

Wichtige Themen sind:

Role-Based Access Control (RBAC): Regelt, welche Benutzer und ServiceAccounts welche Aktionen ausführen dürfen.
NetworkPolicies: Beschränken Netzwerkverbindungen zwischen Pods, sofern das Netzwerk-Plugin diese unterstützt.
Pod Security Standards: Definieren Sicherheitsanforderungen an Pod-Konfigurationen.
Secrets: Stellen sensible Konfigurationswerte bereit, erfordern aber zusätzliche Schutzmaßnahmen für Speicherung und Zugriff.
Image Security: Umfasst die Prüfung und kontrollierte Verwendung von Container-Images.
Resource Limits: Helfen dabei, Auswirkungen übermäßiger Ressourcennutzung zu begrenzen.

Ein besonders wichtiger Punkt ist der Zugriff auf die Kubernetes-API.

Wer weitreichende Berechtigungen besitzt, kann unter Umständen nicht nur Anwendungen verändern, sondern auch auf sensible Cluster-Ressourcen zugreifen.

Deshalb sollte das Prinzip der minimal benötigten Berechtigungen von Anfang an berücksichtigt werden.

Monitoring und Logging im Kubernetes-Cluster

Bei wenigen Containern ist es noch relativ einfach, den Überblick zu behalten.

In einem größeren Cluster sieht das anders aus.

Pods können auf verschiedenen Nodes laufen, ersetzt werden oder nur für kurze Zeit existieren.

Deshalb reicht es nicht aus, gelegentlich kubectl get pods auszuführen.

Für einen zuverlässigen Betrieb benötigst du einen Überblick über Ressourcenverbrauch, Anwendungszustand und Fehlermeldungen.

In vielen Kubernetes-Umgebungen kommen dafür Werkzeuge wie Prometheus und Grafana zum Einsatz.

Prometheus kann Metriken sammeln und auswertbar machen. Grafana bietet Möglichkeiten, diese Daten in Dashboards darzustellen.

Für das zentrale Logging werden häufig Lösungen wie Loki in Kombination mit geeigneten Log-Sammlern eingesetzt.

Bei der Überwachung solltest du nicht nur CPU und Arbeitsspeicher im Blick behalten.

Auch folgende Informationen sind relevant:

Anzahl nicht verfügbarer Pods
Häufigkeit von Container-Neustarts
Fehlerquoten und Antwortzeiten
Auslastung der Nodes
Zustand der Persistent Volumes
Probleme bei Deployments
Verfügbarkeit der Control Plane

Wichtig ist außerdem, zwischen einer technischen Metrik und einem tatsächlichen Anwendungsproblem zu unterscheiden.

Ein Pod kann beispielsweise den Status Running besitzen, obwohl Nutzer bereits Fehler erhalten.

Gutes Monitoring sollte deshalb immer auch die Anwendung selbst berücksichtigen.

Wann ist Kubernetes-Orchestrierung wirklich sinnvoll?

Bei aller Begeisterung für Kubernetes sollte man sich auch eine andere Frage stellen: Brauche ich diese Komplexität überhaupt?

Nicht jede Webanwendung benötigt einen vollständigen Kubernetes-Cluster.

Wenn du einen einzelnen Webserver und eine kleine Datenbank betreibst, kann eine sauber konfigurierte Docker-Compose-Umgebung vollkommen ausreichend sein.

Kubernetes bringt schließlich eigene Herausforderungen mit.

Die Control Plane muss betrieben und aktualisiert werden. Netzwerk und Storage benötigen passende Lösungen. Zugriffsrechte müssen verwaltet werden. Zusätzlich kommen Monitoring, Backup und das Patchmanagement der Nodes hinzu.

Das verursacht Aufwand, den man nicht unterschätzen sollte.

Anders sieht es aus, wenn mehrere Anwendungen auf verschiedenen Servern laufen, regelmäßig aktualisiert werden und hohe Anforderungen an Skalierung oder Verfügbarkeit bestehen.

Dann kann Kubernetes viele wiederkehrende Betriebsaufgaben erheblich vereinfachen.

Besonders interessant wird die Plattform auch bei automatisierten Deployment-Prozessen, GitOps und standardisierten Entwicklungsumgebungen.

Die Entscheidung sollte deshalb immer von den tatsächlichen Anforderungen abhängen.

Kubernetes ist kein Selbstzweck. Die Plattform sollte ein vorhandenes Betriebsproblem lösen und nicht zusätzliche Probleme schaffen, die vorher gar nicht existiert haben.

Häufig gestellte Fragen zur Orchestrierung mit Kubernetes

Was ist Orchestrierung in Kubernetes?

Unter Orchestrierung mit Kubernetes versteht man die automatisierte Bereitstellung, Verwaltung, Skalierung und Überwachung containerisierter Anwendungen. Kubernetes nutzt dafür deklarative Konfigurationen und Controller, die den tatsächlichen Clusterzustand kontinuierlich mit dem gewünschten Zustand vergleichen.

Warum wird Kubernetes für die Container-Orchestrierung eingesetzt?

Kubernetes bietet standardisierte Möglichkeiten, um Anwendungen über mehrere Server hinweg zu betreiben. Dazu gehören Scheduling, die Verwaltung von Replikaten, Netzwerkabstraktionen, Rolling Updates und Mechanismen zur Wiederherstellung ausgefallener Workloads.

Was ist der Unterschied zwischen Docker und Kubernetes?

Docker bietet Werkzeuge zum Erstellen und Ausführen von Containern. Kubernetes übernimmt die Verwaltung und Orchestrierung containerisierter Anwendungen innerhalb eines Clusters. Moderne Kubernetes-Installationen verwenden dafür beispielsweise containerd oder CRI-O als Container Runtime.

Kann Kubernetes Container automatisch neu starten?

Ja. Das kubelet kann Container entsprechend ihrer Restart Policy neu starten. Darüber hinaus sorgen Controller dafür, dass ausgefallene oder gelöschte Pods bei Bedarf durch neue Pods ersetzt werden. Kubernetes kann allerdings keine erfolgreiche Wiederherstellung garantieren, wenn Ressourcen oder notwendige Abhängigkeiten fehlen.

Ist Kubernetes nur für große Unternehmen geeignet?

Nein. Kubernetes kann auch für kleinere Teams, private Homelabs und Lernumgebungen sinnvoll sein. Allerdings sollte der zusätzliche Verwaltungsaufwand berücksichtigt werden. Für einfache Anwendungen sind schlankere Lösungen häufig ausreichend.

Was ist der Unterschied zwischen einem Pod und einem Deployment?

Ein Pod ist eine ausführbare Einheit mit einem oder mehreren Containern. Ein Deployment beschreibt dagegen den gewünschten Zustand einer Anwendung und verwaltet über ReplicaSets die zugehörigen Pods. Dadurch werden Skalierung und kontrollierte Updates ermöglicht.

Fazit: Kubernetes-Orchestrierung verstehen statt nur YAML kopieren

Die Orchestrierung mit Kubernetes ist deutlich mehr als das automatisierte Starten von Containern.

Kubernetes verbindet verschiedene Mechanismen zu einer Plattform, mit der Anwendungen über mehrere Server hinweg verwaltet werden können.

Besonders wichtig sind dabei die deklarative Arbeitsweise und das Zusammenspiel zwischen API Server, Scheduler, Controllern und Worker Nodes.

Wenn du verstanden hast, wie Deployments, Pods und Services zusammenarbeiten, werden viele Abläufe im Cluster nachvollziehbarer.

Das gilt nicht nur für die normale Bereitstellung einer Anwendung, sondern auch für die Fehlersuche.

Ein Pod, der nicht startet, ist dann nicht einfach nur ein Fehlerzustand. Du kannst gezielt untersuchen, ob die Ursache beim Scheduling, beim Image, bei den Ressourcen oder innerhalb der Anwendung liegt.

Für den Einstieg würde ich deshalb nicht versuchen, möglichst viele Kubernetes-Werkzeuge gleichzeitig zu lernen.

Baue zunächst einen kleinen Cluster auf, erstelle ein Deployment, skaliere es und lösche testweise einen Pod. Beobachte anschließend, wie Kubernetes reagiert.

Beschäftige dich danach mit Services, Readiness-Probes und Rolling Updates. Erst wenn diese Grundlagen sitzen, lohnt sich der nächste Schritt zu Themen wie Helm, GitOps, Argo CD oder erweiterten Scheduling-Regeln.

Mein wichtigster Tipp: Lerne nicht nur die Kubernetes-Befehle auswendig. Versuche zu verstehen, warum Kubernetes eine bestimmte Entscheidung trifft.

Genau dieses Verständnis macht später den Unterschied zwischen einem Cluster, der irgendwie funktioniert, und einer Infrastruktur, die du gezielt betreiben und bei Problemen analysieren kannst.

Wenn du tiefer einsteigen möchtest, findest du in der offiziellen Kubernetes-Dokumentation weitere technische Hintergründe zu Pods, Deployments, Scheduling und den Komponenten des Clusters.