Thomas.will: Die Seite wurde neu angelegt: „Dieser Artikel erklärt, warum der Schritt von Docker Compose zu Kubernetes notwendig wird, wie ein Kubernetes-Cluster aufgebaut ist, und baut anschließend ei…“

2026-08-09T08:10:36Z

Die Seite wurde neu angelegt: „Dieser Artikel erklärt, warum der Schritt von Docker Compose zu Kubernetes notwendig wird, wie ein Kubernetes-Cluster aufgebaut ist, und baut anschließend ei…“

Neue Seite

Dieser Artikel erklärt, warum der Schritt von Docker Compose zu Kubernetes notwendig wird, wie ein Kubernetes-Cluster aufgebaut ist, und baut anschließend einen eigenen Cluster mit '''k3s''' auf vier virtuellen Maschinen auf: einem Server-Node, zwei Agent-Nodes und einem separaten Client.

==Warum reicht Docker Compose nicht mehr==

Mit Docker Compose lässt sich eine Anwendung aus mehreren Containern zuverlässig auf '''einem''' Host beschreiben und starten. Für Entwicklung und kleine Tests ist das ausreichend. Sobald eine Anwendung produktiv läuft, tauchen aber Fragen auf, die Compose grundsätzlich nicht beantworten kann.

; Was passiert bei einem Host-Ausfall
* Fällt der Host aus, auf dem Compose läuft, ist die gesamte Anwendung nicht mehr erreichbar. Es gibt keinen zweiten Host, auf den automatisch ausgewichen wird.

; Wie wird über mehrere Maschinen skaliert
* <code>docker compose up --scale web=3</code> startet drei Instanzen – aber immer auf demselben Host. Reicht dessen CPU oder RAM nicht mehr aus, gibt es keinen Mechanismus, der auf eine zweite Maschine ausweicht.

; Was passiert, wenn ein Container abstürzt
* Compose kann einen abgestürzten Container auf demselben Host neu starten (<code>restart: always</code>). Es gibt aber keine Instanz, die aktiv überwacht, ob genügend Kapazität für einen Neustart überhaupt noch vorhanden ist.

; Wie läuft ein Update ohne Downtime
* Ein <code>docker compose up -d</code> nach einem Image-Wechsel ersetzt Container in der Regel abrupt. Ein kontrolliertes, schrittweises Update über mehrere Instanzen hinweg, bei dem immer genügend laufende Instanzen übrig bleiben, ist mit Compose nicht vorgesehen.

Der eigentliche Sprung ist konzeptioneller Natur: Bei Compose '''startet''' man Container. Bei Kubernetes '''beschreibt''' man einen gewünschten Zielzustand ("es sollen drei Instanzen dieser Anwendung laufen") – und ein fortlaufend aktiver Kontrollmechanismus sorgt dafür, dass dieser Zustand über beliebig viele Maschinen hinweg eingehalten wird, auch wenn einzelne Maschinen ausfallen.

Dieses Prinzip nennt sich '''Self-Healing''': Stirbt eine Instanz, wird sie automatisch neu gestartet – bei Bedarf auf einer anderen Maschine. Genau dieses Verhalten wird am Ende dieses Artikels in einer Übung selbst provoziert und beobachtet.

==Ziel dieses Kurses==

Am Ende versteht ihr, warum eine Compose-Anwendung bei Skalierung und Ausfallsicherheit an ihre Grenzen stößt, und könnt dieselbe Anwendung so beschreiben, dass ein Cluster sie selbstständig am Laufen hält – auch wenn Nodes ausfallen, Images wechseln oder die Last steigt. Es geht nicht darum, jeden Kubernetes-Befehl auswendig zu können, sondern zu verstehen, was im Cluster passiert, wenn ein Pod stirbt, ein neues Image ausgerollt wird oder Traffic hereinkommt.

==Architektur eines Kubernetes-Clusters==

Ein Kubernetes-Cluster besteht aus zwei Arten von Maschinen (Nodes) mit unterschiedlichen Aufgaben.

; Control Plane (Server-Node)
* Trifft alle Entscheidungen: Wo soll ein Container laufen, ist der gewünschte Zustand noch erfüllt, was passiert bei einem Ausfall. Der Server-Node führt selbst normalerweise keine Anwendungs-Container aus.

; Worker-Nodes (Agent-Nodes)
* Hier laufen die eigentlichen Container. Ein Agent meldet sich beim Server-Node an, bekommt Arbeit zugewiesen und führt sie aus.

; Der Client
* <code>kubectl</code> ist das Kommandozeilenwerkzeug, mit dem der Cluster gesteuert wird. Es läuft bewusst '''nicht''' auf einem der Cluster-Nodes, sondern auf einem separaten Rechner (oder dem eigenen Laptop), der über das Netzwerk mit dem Server-Node spricht. Das ist ein wichtiger Unterschied zu einer Gewohnheit aus der Docker-Welt: Bei Docker meldet man sich häufig direkt auf dem Host an, um <code>docker</code>-Befehle auszuführen. Bei Kubernetes steuert man den Cluster von außen.

In diesem Kurs werden vier Maschinen aufgesetzt:

{| class="wikitable"
! Maschine !! Rolle !! Beschreibung
|-
| k8s-server || Control Plane || Server-Node, hier läuft k3s im Server-Modus
|-
| k8s-agent-1 || Worker || Erster Agent-Node
|-
| k8s-agent-2 || Worker || Zweiter Agent-Node
|-
| k8s-client || Client || Kein Cluster-Node, nur <code>kubectl</code> und die Kubeconfig
|}

==k3s als Kubernetes-Distribution==

Für den Cluster wird '''k3s''' verwendet, eine schlanke, aber vollständig zu Kubernetes kompatible Distribution.

; Ein einziges Binary
* Statt vieler einzelner Komponenten (<code>kube-apiserver</code>, <code>kube-scheduler</code>, <code>kube-controller-manager</code>, <code>etcd</code> …) steckt bei k3s alles in einem Go-Binary.

; SQLite statt etcd
* Als Standard-Datenspeicher nutzt k3s SQLite statt des ressourcenhungrigen etcd. Für ein Lab-Setup völlig ausreichend.

; Geringer Ressourcenbedarf
* k3s läuft mit deutlich weniger RAM pro Node als ein klassischer Kubeadm-Aufbau – ideal für VirtualBox-VMs mit begrenzten Ressourcen.

; Vollständig kompatible API
* Alle <code>kubectl</code>-Befehle, Manifeste und Konzepte funktionieren bei k3s exakt so wie bei jedem anderen Kubernetes-Cluster. Was in diesem Kurs gelernt wird, gilt uneingeschränkt auch für größere Cluster.

==Vorbereitung der virtuellen Maschinen==

; Empfohlene VM-Ausstattung
* 1 vCPU, 2 GB RAM, 10 GB Festplatte je Node reichen für dieses Lab aus.

; Basis-Image
* Ein minimales Debian oder Rocky Linux als Grundlage. Empfehlenswert: eine VM einmal vorbereiten (Betriebssystem installieren, <code>curl</code> und <code>open-vm-tools</code>/Gastadditionen einrichten) und anschließend dreimal klonen.

; Netzwerk-Konfiguration in VirtualBox
* Für die Kommunikation der Nodes untereinander wird ein '''Internal Network''' oder '''Host-only Adapter''' verwendet. Zusätzlich braucht jede VM einen zweiten Adapter im '''NAT'''-Modus, damit Pakete und Container-Images aus dem Internet geladen werden können.

; Feste IP-Adressen vergeben
* Damit sich die Nodes zuverlässig finden, sollten feste IP-Adressen im internen Netz vergeben werden, zum Beispiel <code>192.168.56.10</code> (Server), <code>192.168.56.11</code> und <code>192.168.56.12</code> (Agents), <code>192.168.56.20</code> (Client).

==Installation des Server-Node==

Auf der Maschine <code>k8s-server</code>:

; k3s im Server-Modus installieren
* <code>curl -sfL https://get.k3s.io | sh -</code>

; Installation prüfen
* <code>sudo k3s kubectl get nodes</code>

; Join-Token auslesen
* Das Token wird für den Beitritt der Agent-Nodes benötigt.
* <code>sudo cat /var/lib/rancher/k3s/server/node-token</code>

==Installation der Agent-Nodes==

Auf '''jeder''' der beiden Maschinen <code>k8s-agent-1</code> und <code>k8s-agent-2</code>:

; k3s im Agent-Modus installieren und dem Cluster beitreten
* <code><SERVER_IP></code> durch die IP-Adresse von <code>k8s-server</code> ersetzen, <code><NODE_TOKEN></code> durch das zuvor ausgelesene Token.
* <code>curl -sfL https://get.k3s.io | K3S_URL=https://<SERVER_IP>:6443 K3S_TOKEN=<NODE_TOKEN> sh -</code>

; Beitritt vom Server aus prüfen
* Nach kurzer Zeit sollten auf <code>k8s-server</code> beide Agents als <code>Ready</code> erscheinen.
* <code>sudo k3s kubectl get nodes</code>

==kubectl auf dem Client einrichten==

Auf der Maschine <code>k8s-client</code>, die '''nicht''' Teil des Clusters ist:

; kubectl installieren
* <code>curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"</code>
* <code>sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl</code>

; Kubeconfig vom Server-Node holen
* Die Datei enthält die Zugangsdaten für den Cluster. Sie wird vom Server-Node kopiert und angepasst.
* <code>scp k8s-server:/etc/rancher/k3s/k3s.yaml ~/.kube/config</code>

; Server-Adresse in der Kubeconfig anpassen
* Die kopierte Datei verweist standardmäßig auf <code>127.0.0.1</code>. Das muss auf die tatsächliche IP-Adresse von <code>k8s-server</code> geändert werden.
* In <code>~/.kube/config</code> die Zeile <code>server: https://127.0.0.1:6443</code> auf <code>server: https://<SERVER_IP>:6443</code> ändern.

; Verbindung testen
* <code>kubectl get nodes</code>
* Es sollten alle drei Nodes (Server und beide Agents) mit Status <code>Ready</code> erscheinen.

==Übung: Cluster verifizieren==

# Meldet euch auf <code>k8s-client</code> an und prüft mit <code>kubectl get nodes -o wide</code>, welche interne IP-Adresse jeder Node hat.
# Ermittelt mit <code>kubectl cluster-info</code>, unter welcher Adresse die Control Plane erreichbar ist.
# Prüft mit <code>kubectl get pods -A</code>, welche System-Pods bereits ohne euer Zutun im Cluster laufen (unter anderem CoreDNS und Traefik). Notiert euch, in welcher Namespace diese laufen.
# Führt <code>kubectl describe node k8s-agent-1</code> aus und sucht im Abschnitt <code>Allocatable</code> nach der verfügbaren CPU- und Speicherkapazität dieses Nodes.

==Übung: Self-Healing beobachten==

Diese Übung provoziert bewusst den zentralen Unterschied zu Docker Compose: Ein Pod stirbt, und der Cluster reagiert von selbst.

# Startet eine einfache Test-Anwendung: <code>kubectl create deployment webtest --image=nginx:1.25 --replicas=1</code>
# Prüft mit <code>kubectl get pods -o wide</code>, auf welchem Agent-Node der Pod gelandet ist.
# Löscht den Pod gezielt (nicht das Deployment): <code>kubectl delete pod <pod-name></code>
# Prüft sofort danach erneut mit <code>kubectl get pods -o wide</code> und beobachtet: Ein neuer Pod ist automatisch entstanden – möglicherweise sogar auf dem anderen Agent-Node.
# Überlegt gemeinsam: Was genau hat gemerkt, dass ein Pod fehlt, und wer hat entschieden, ihn neu zu starten? (Antwort wird im weiteren Kursverlauf beim Thema Deployments und Controller vertieft.)
# Räumt zum Abschluss auf: <code>kubectl delete deployment webtest</code>

==Übung: Grenzen von Compose selbst erleben==

# Simuliert einen Node-Ausfall, indem ihr <code>k8s-agent-1</code> in VirtualBox herunterfahrt, während dort Pods laufen.
# Beobachtet mit <code>kubectl get nodes</code>, wie lange es dauert, bis der Node als <code>NotReady</code> markiert wird.
# Beobachtet mit <code>kubectl get pods -o wide</code>, was mit den Pods passiert, die vorher auf <code>k8s-agent-1</code> liefen.
# Startet <code>k8s-agent-1</code> wieder und prüft, ob der Node wieder automatisch dem Cluster beitritt.

Kubernetes Grundlagen und Cluster Aufbau - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „Dieser Artikel erklärt, warum der Schritt von Docker Compose zu Kubernetes notwendig wird, wie ein Kubernetes-Cluster aufgebaut ist, und baut anschließend ei…“