Thomas.will: Die Seite wurde neu angelegt: „Dieser Artikel übersetzt eine bekannte Docker-Compose-Anwendung Schritt für Schritt nach Kubernetes. Als Beispiel dient eine einfache Web-Anwendung mit Daten…“

2026-08-09T08:11:13Z

Die Seite wurde neu angelegt: „Dieser Artikel übersetzt eine bekannte Docker-Compose-Anwendung Schritt für Schritt nach Kubernetes. Als Beispiel dient eine einfache Web-Anwendung mit Daten…“

Neue Seite

Dieser Artikel übersetzt eine bekannte Docker-Compose-Anwendung Schritt für Schritt nach Kubernetes. Als Beispiel dient eine einfache Web-Anwendung mit Datenbank – die gleiche Art von Setup, die in Compose aus einem <code>web</code>- und einem <code>db</code>-Service besteht.

==Ausgangspunkt: die Compose-Datei==

Als Referenz die Compose-Anwendung, die übersetzt wird:

<syntaxhighlight lang="yaml">
services:
web:
image: nginx:1.25
ports:
- "8080:80"
environment:
- APP_MODE=production
depends_on:
- db

db:
image: postgres:16
environment:
- POSTGRES_PASSWORD=geheim
- POSTGRES_DB=appdb
volumes:
- db_data:/var/lib/postgresql/data

volumes:
db_data:
</syntaxhighlight>

Diese Datei wird in den folgenden Abschnitten Stück für Stück in Kubernetes-Objekte übersetzt.

==Von Container zu Pod und Deployment==

; Der Pod
* Die kleinste ausführbare Einheit in Kubernetes ist der '''Pod''', kein einzelner Container. Ein Pod kann einen oder mehrere Container enthalten, die sich Netzwerk und Storage teilen. In den meisten Fällen – wie hier – enthält ein Pod genau einen Container.

; Warum nicht direkt Pods erstellen
* Ein einzeln erstellter Pod wird bei einem Absturz '''nicht''' automatisch neu gestartet. Dafür braucht es eine übergeordnete Instanz.

; Das Deployment
* Ein '''Deployment''' beschreibt den Zielzustand ("es sollen N Instanzen dieses Pods laufen") und sorgt dafür, dass er eingehalten wird – inklusive Neustart bei Absturz und kontrollierten Updates. Das Deployment entspricht am ehesten dem <code>web:</code>-Service aus der Compose-Datei, nur mit eingebauter Selbstheilung.

===Das web-Deployment===

<syntaxhighlight lang="yaml">
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 1
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.25
ports:
- containerPort: 80
env:
- name: APP_MODE
value: "production"
</syntaxhighlight>

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

; Status prüfen
* <code>kubectl get deployments</code>
* <code>kubectl get pods -o wide</code>

==Von ports zu Service==

Das <code>ports: "8080:80"</code> aus Compose hat in Kubernetes kein direktes Gegenstück auf Container-Ebene. Stattdessen übernimmt ein eigenes Objekt die Netzwerk-Erreichbarkeit.

; Der Service
* Ein '''Service''' gibt einer Gruppe von Pods (ausgewählt über Labels) eine stabile, gleichbleibende Adresse. Das ist notwendig, weil Pods jederzeit neu erstellt werden und dabei eine neue IP-Adresse bekommen – ein Service bleibt davon unberührt erreichbar.

; ClusterIP als Standard
* Ohne weitere Angabe ist ein Service nur '''innerhalb''' des Clusters erreichbar. Das entspricht noch nicht dem externen Zugriff aus der Compose-Datei, ist aber der erste, notwendige Schritt.

<syntaxhighlight lang="yaml">
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
ports:
- port: 80
targetPort: 80
</syntaxhighlight>

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

; Erreichbarkeit von innerhalb des Clusters testen
* <code>kubectl run test-curl --rm -it --image=curlimages/curl -- curl -s http://web</code>

; Erreichbarkeit von außen testen (ohne Ingress)
* Solange noch kein Ingress existiert, kann mit Port-Forwarding von außen zugegriffen werden – vergleichbar mit dem <code>8080:80</code> aus Compose, nur manuell für die Dauer der Sitzung.
* <code>kubectl port-forward service/web 8080:80</code>
* Anschließend ist die Anwendung unter <code>http://localhost:8080</code> erreichbar, solange der Befehl im Vordergrund läuft.

==Von environment zu ConfigMap und Secret==

In der Compose-Datei stehen <code>APP_MODE=production</code> (unkritisch) und <code>POSTGRES_PASSWORD=geheim</code> (sensibel) beide gleich als <code>environment:</code>. Kubernetes trennt das bewusst.

; ConfigMap für unkritische Werte
* Für Konfiguration ohne Geheimhaltungsbedarf.

<syntaxhighlight lang="yaml">
apiVersion: v1
kind: ConfigMap
metadata:
name: web-config
data:
APP_MODE: "production"
</syntaxhighlight>

; Secret für sensible Werte
* Inhalt wird base64-kodiert gespeichert – das ist '''keine''' Verschlüsselung, nur Verschleierung. Für echte Vertraulichkeit braucht ein Cluster zusätzliche Maßnahmen (Encryption at Rest, externe Secret-Stores), was über diesen Kurs hinausgeht.

<syntaxhighlight lang="yaml">
apiVersion: v1
kind: Secret
metadata:
name: db-secret
type: Opaque
stringData:
POSTGRES_PASSWORD: geheim
</syntaxhighlight>

; Beide anwenden
* <code>kubectl apply -f web-config.yaml</code>
* <code>kubectl apply -f db-secret.yaml</code>

; Im Deployment referenzieren
* Der <code>env:</code>-Abschnitt im Deployment wird angepasst, um aus ConfigMap und Secret zu lesen statt den Wert direkt einzutragen.

<syntaxhighlight lang="yaml">
env:
- name: APP_MODE
valueFrom:
configMapKeyRef:
name: web-config
key: APP_MODE
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: POSTGRES_PASSWORD
</syntaxhighlight>

==Das db-Deployment und der Datenbank-Service==

Die Datenbank wird nach demselben Muster übersetzt wie <code>web</code>.

<syntaxhighlight lang="yaml">
apiVersion: apps/v1
kind: Deployment
metadata:
name: db
spec:
replicas: 1
selector:
matchLabels:
app: db
template:
metadata:
labels:
app: db
spec:
containers:
- name: db
image: postgres:16
ports:
- containerPort: 5432
env:
- name: POSTGRES_DB
value: "appdb"
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: POSTGRES_PASSWORD
---
apiVersion: v1
kind: Service
metadata:
name: db
spec:
selector:
app: db
ports:
- port: 5432
targetPort: 5432
</syntaxhighlight>

; Wichtig zum Namen des Service
* Der Service heißt <code>db</code>. Innerhalb des Clusters ist die Datenbank damit unter genau diesem Namen erreichbar – das entspricht exakt dem Verhalten von <code>depends_on: db</code> in Compose, wo der Service-Name ebenfalls als Hostname funktioniert. Der <code>web</code>-Container kann sich also mit <code>db:5432</code> verbinden, ohne dass eine IP-Adresse bekannt sein muss.

; Anwenden
* <code>kubectl apply -f db-deployment.yaml</code>

==depends_on gibt es nicht – was das bedeutet==

; Kein eingebautes Warten
* Kubernetes startet <code>web</code> und <code>db</code> unabhängig voneinander. Es gibt kein automatisches "warte, bis die Datenbank bereit ist" wie es <code>depends_on</code> in Compose suggeriert (selbst dort wartet es ohne Healthcheck-Angabe nur auf den Containerstart, nicht auf Bereitschaft).

; Die Kubernetes-Lösung: Probes
* Statt einer Startreihenfolge prüft Kubernetes fortlaufend, ob ein Container tatsächlich bereit ist, Traffic zu empfangen. Das wird im nächsten Artikel beim Thema Health-Checks und Rolling Updates vertieft.

==Alltagswerkzeuge zum Debuggen==

Diese Befehle ersetzen im Kubernetes-Alltag das, was <code>docker logs</code> und <code>docker exec</code> bei Compose waren.

; Logs eines Pods ansehen
* <code>kubectl logs <pod-name></code>

; Logs fortlaufend verfolgen
* <code>kubectl logs -f <pod-name></code>

; In einen laufenden Container wechseln
* <code>kubectl exec -it <pod-name> -- /bin/bash</code>

; Detaillierten Zustand und Ereignisse eines Pods ansehen
* Der wichtigste Befehl bei Problemen – zeigt unter anderem, warum ein Pod nicht startet.
* <code>kubectl describe pod <pod-name></code>

; Alle Ressourcen eines Namespace auf einen Blick
* <code>kubectl get all</code>

==Übung: Vollständige Übersetzung selbst durchführen==

# Legt für jedes der oben gezeigten Manifeste eine eigene YAML-Datei an und wendet sie in dieser Reihenfolge an: ConfigMap, Secret, db-Deployment inkl. Service, web-Deployment inkl. Service.
# Prüft mit <code>kubectl get pods</code>, dass beide Pods im Status <code>Running</code> sind.
# Wechselt mit <code>kubectl exec -it</code> in den <code>web</code>-Pod und prüft von dort mit <code>curl db:5432</code> (oder <code>nc -zv db 5432</code>), ob die Datenbank über den Service-Namen erreichbar ist.
# Löscht den <code>db</code>-Pod gezielt mit <code>kubectl delete pod</code> und beobachtet, ob der <code>web</code>-Pod danach noch funktioniert – vergleicht das Verhalten mit dem, was ihr in Compose erwarten würdet.
# Öffnet mit <code>kubectl port-forward service/web 8080:80</code> die Anwendung im Browser und bestätigt den Zugriff.

==Übung: Fehler bewusst provozieren==

# Ändert im <code>web</code>-Deployment den Image-Namen versehentlich auf <code>nginx:1.25.9999</code> (nicht existierendes Tag) und wendet es erneut an.
# Beobachtet mit <code>kubectl get pods</code>, welcher Status auftritt.
# Findet mit <code>kubectl describe pod <pod-name></code> im Abschnitt <code>Events</code> die genaue Fehlerursache.
# Korrigiert das Image wieder auf <code>nginx:1.25</code> und bestätigt, dass der Pod danach wieder normal startet.

Kubernetes Compose App Uebersetzen - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „Dieser Artikel übersetzt eine bekannte Docker-Compose-Anwendung Schritt für Schritt nach Kubernetes. Als Beispiel dient eine einfache Web-Anwendung mit Daten…“