Thomas.will: Die Seite wurde neu angelegt: „Dieser Artikel baut auf dem vorherigen Deployment aus Compose-App nach Kubernetes übersetzen auf und ergänzt das, was…“

2026-08-09T08:11:40Z

Die Seite wurde neu angelegt: „Dieser Artikel baut auf dem vorherigen Deployment aus Compose-App nach Kubernetes übersetzen auf und ergänzt das, was…“

Neue Seite

Dieser Artikel baut auf dem vorherigen Deployment aus [[Kubernetes-Compose-App-Uebersetzen|Compose-App nach Kubernetes übersetzen]] auf und ergänzt das, was mit Docker Compose gar nicht möglich war: externer Zugriff über Ingress, kontrollierte Updates ohne Downtime, Skalierung und persistente Daten.

==Externer Zugriff mit Ingress==

Port-Forwarding aus dem vorherigen Artikel funktioniert nur temporär und nur für eine Person gleichzeitig. Für dauerhaften externen Zugriff wird ein '''Ingress''' verwendet.

; Was ein Ingress macht
* Ein Ingress ist ein Regelwerk, das eingehenden HTTP(S)-Traffic anhand von Hostname oder Pfad an den passenden internen Service weiterleitet – vergleichbar mit einem Reverse Proxy wie Traefik oder Nginx, den man aus der Compose-Welt kennt.

; Ingress-Controller bei k3s
* k3s bringt Traefik als Ingress-Controller bereits vorinstalliert mit. Es muss nichts zusätzlich installiert werden.

<syntaxhighlight lang="yaml">
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
spec:
rules:
- host: web.lab.local
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web
port:
number: 80
</syntaxhighlight>

; Anwenden
* <code>kubectl apply -f web-ingress.yaml</code>

; Hostnamen lokal auflösen
* Da <code>web.lab.local</code> keine echte Domain ist, muss der Hostname auf dem Client in <code>/etc/hosts</code> eingetragen werden, zeigend auf die IP-Adresse von <code>k8s-server</code>.
* <code>echo "<SERVER_IP> web.lab.local" | sudo tee -a /etc/hosts</code>

; Zugriff testen
* <code>curl http://web.lab.local</code>

==Health-Checks: Probes==

Im vorherigen Artikel wurde festgestellt, dass es kein Äquivalent zu <code>depends_on</code> gibt. Die Kubernetes-Antwort darauf sind '''Probes''' – fortlaufende Prüfungen, ob ein Container tatsächlich funktioniert.

; Liveness Probe
* Prüft, ob der Container noch lebt. Schlägt sie fehl, wird der Container neu gestartet.

; Readiness Probe
* Prüft, ob der Container bereit ist, Traffic zu empfangen. Schlägt sie fehl, wird der Pod aus dem Service entfernt, aber '''nicht''' neu gestartet – er bekommt einfach so lange keinen Traffic, bis die Probe wieder erfolgreich ist.

<syntaxhighlight lang="yaml">
containers:
- name: web
image: nginx:1.25
ports:
- containerPort: 80
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 15
periodSeconds: 20
</syntaxhighlight>

; Warum das die depends_on-Lücke schließt
* Ein Service leitet Traffic nur an Pods weiter, deren Readiness Probe erfolgreich ist. Damit landet Traffic nie bei einer Instanz, die noch nicht bereit ist – unabhängig von der Startreihenfolge.

==Rolling Updates==

; Was bei einem Compose-Update passiert
* <code>docker compose up -d</code> nach einem Image-Wechsel ersetzt Container ohne eingebaute Kontrolle darüber, wie viele gleichzeitig offline sind.

; Was ein Deployment stattdessen tut
* Standardmäßig verwendet ein Deployment die Update-Strategie <code>RollingUpdate</code>: Es werden schrittweise neue Pods mit dem neuen Image gestartet und alte erst entfernt, wenn genügend neue bereit sind (erkennbar über die Readiness Probe).

; Image aktualisieren
* <code>kubectl set image deployment/web web=nginx:1.26</code>

; Rollout beobachten
* <code>kubectl rollout status deployment/web</code>

; Rollout-Historie ansehen
* <code>kubectl rollout history deployment/web</code>

; Bei Problemen zurückrollen
* <code>kubectl rollout undo deployment/web</code>

==Skalierung==

; Deployment skalieren
* <code>kubectl scale deployment/web --replicas=3</code>

; Verteilung über die Nodes prüfen
* <code>kubectl get pods -o wide</code>
* Die drei Instanzen verteilen sich in der Regel automatisch über die verfügbaren Agent-Nodes.

; Warum die Datenbank nicht einfach genauso skaliert wird
* Würde <code>db</code> ebenfalls auf drei Replicas skaliert, entstünden drei unabhängige PostgreSQL-Instanzen ohne gemeinsamen Datenbestand – das produziert Dateninkonsistenz, keine Hochverfügbarkeit. Zustandsbehaftete Anwendungen wie Datenbanken benötigen einen anderen Ansatz (<code>StatefulSet</code>), der über den Rahmen dieses Kurses hinausgeht, aber als Begriff hier bewusst fällt.

==Persistente Daten: PersistentVolumeClaim==

In der ursprünglichen Compose-Datei sorgte <code>volumes: db_data:/var/lib/postgresql/data</code> dafür, dass die Datenbank einen Container-Neustart übersteht. Das Kubernetes-Äquivalent ist ein '''PersistentVolumeClaim''' (PVC).

<syntaxhighlight lang="yaml">
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: db-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
</syntaxhighlight>

; Im db-Deployment einbinden
* Der Claim wird als Volume in den Pod eingehängt und im Container an den passenden Pfad gemountet.

<syntaxhighlight lang="yaml">
spec:
containers:
- name: db
image: postgres:16
volumeMounts:
- name: data
mountPath: /var/lib/postgresql/data
volumes:
- name: data
persistentVolumeClaim:
claimName: db-data
</syntaxhighlight>

; Anwenden und prüfen
* <code>kubectl apply -f db-pvc.yaml</code>
* <code>kubectl get pvc</code>

==Übung: Rolling Update ohne Downtime beobachten==

# Skaliert <code>web</code> zunächst auf 3 Replicas.
# Öffnet ein zweites Terminal und lasst dort fortlaufend Anfragen laufen, zum Beispiel mit <code>watch curl -s http://web.lab.local</code>.
# Startet im ersten Terminal ein Rolling Update auf ein anderes Image (<code>nginx:1.26</code>) und beobachtet parallel im zweiten Terminal, ob Anfragen fehlschlagen.
# Prüft mit <code>kubectl rollout status deployment/web</code>, wann der Rollout abgeschlossen ist.

==Übung: Rollback im Fehlerfall==

# Führt absichtlich ein Update auf ein nicht existierendes Image durch (<code>nginx:kaputt</code>).
# Beobachtet mit <code>kubectl rollout status deployment/web</code>, dass der Rollout hängen bleibt.
# Macht das Update mit <code>kubectl rollout undo deployment/web</code> rückgängig und bestätigt mit <code>kubectl get pods</code>, dass wieder die alte, funktionierende Version läuft.

==Übung: Persistenz der Datenbank prüfen==

# Bindet den PVC wie oben gezeigt ins <code>db</code>-Deployment ein und wendet die Änderung an.
# Legt über <code>kubectl exec -it</code> in den <code>db</code>-Pod eine Testtabelle oder einen Testeintrag in der Datenbank an.
# Löscht den <code>db</code>-Pod gezielt mit <code>kubectl delete pod</code>.
# Prüft nach dem automatischen Neustart, ob der zuvor angelegte Datenbestand noch vorhanden ist.

Kubernetes Ingress Updates Skalierung - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „Dieser Artikel baut auf dem vorherigen Deployment aus Compose-App nach Kubernetes übersetzen auf und ergänzt das, was…“