# Kubernetes Pods: Die fundamentalen Bausteine der Orchestrierung

TL;DR / Management Summary In Kubernetes (K8s) verwalten wir keine einzelnen Container, sondern Pods. Ein Pod ist die kleinste bereitstellbare Einheit und kann einen oder mehrere Container enthalten, die sich das gleiche Netzwerk und den gleichen Speicher teilen. Ein Senior Admin nutzt Pods, um eng gekoppelte Prozesse (z.B. eine App und ihr Logging-Agent) gemeinsam zu skalieren und zu verwalten. Wichtigste Regel: Pods sind vergänglich (ephemeral) – sie werden jederzeit gelöscht und durch neue Instanzen ersetzt.

# 1. Was ist ein Pod?

Der Container-Container.

Ein Pod ist ein logischer Host für Container.

• Netzwerk: Alle Container im Pod haben die gleiche IP und sprechen sich über localhost an.
• Storage: Container können gemeinsame Volumes mounten, um Daten in Echtzeit auszutauschen.
• Isolation: Ein Pod läuft immer auf genau einem Worker Node (Artikel 811).

# 2. Pod-Muster: Sidecars & Helper

Teamwork im Pod.

Obwohl 90% aller Pods nur einen Container haben, sind Multi-Container-Pods mächtig:

• Sidecar Pattern: Ein zweiter Container (z.B. Envoy Proxy) kümmert sich um die Verschlüsselung (TLS), während der Haupt-Container nur HTTP spricht.
• Adapter Pattern: Ein Container wandelt Logs in ein einheitliches Format um, bevor sie an den Logging-Server geschickt werden.

# 3. Deep Dive: Der Pod-Lifecycle

Von der Erstellung zum Terminieren.

1. Pending: Der Scheduler sucht einen passenden Host.
2. Running: Mindestens ein Container läuft stabil.
3. Succeeded / Failed: Der Pod hat seine Aufgabe beendet (z.B. ein Job).
4. Terminating: Der Pod wird gelöscht. K8s sendet SIGTERM an die Prozesse.

# 4. Day-2 Operations: Liveness & Readiness Probes

Den Status prüfen.

Damit K8s weiß, ob ein Pod gesund ist:

• Liveness Probe: “Läuft die App noch?”. Falls nein -> K8s startet den Container neu.
• Readiness Probe: “Ist die App bereit für User-Traffic?”. (Z.B. Datenbank-Verbindung fertig aufgebaut). Falls nein -> Der Loadbalancer schickt keinen Traffic an diesen Pod.

# 5. Troubleshooting & “War Stories”

Wenn der Pod nicht ‘aufwacht’.

# Top 3 Fehlerbilder

1. Symptom: CrashLoopBackOff.

   • Ursache: Der Prozess im Container stürzt sofort nach dem Start ab (z.B. falsche Config oder fehlende DB).
   • Lösung: kubectl logs <pod_name> prüfen.

2. Symptom: ImagePullBackOff.

   • Ursache: Registry-Credentials falsch oder das Image-Tag existiert nicht.
   • Lösung: Artikel 803 prüfen.

3. Symptom: Pod bleibt ewig in Pending.

   • Ursache: Ressourcen-Mangel im Cluster. Kein Node hat genug freien RAM für die Anforderung der VM.

# “War Story”: Der “Zombie” Pod

Ein Admin löschte eine VM in Proxmox, die als Kubernetes Worker Node diente. Das Ereignis: Er vergaß, den Knoten vorher im Kubernetes-Cluster zu “drainen”. Das Ergebnis: K8s dachte 5 Minuten lang, der Knoten sei noch da (Timeout). Die Pods darauf wurden als Running angezeigt, waren aber faktisch tot. User erhielten Timeouts. Lehre: Löschen Sie niemals die Infrastruktur (Proxmox), ohne die Applikations-Ebene (K8s) zu informieren. Nutzen Sie kubectl drain <node>, um Pods sicher auf andere Knoten zu evakuieren.

# 6. Monitoring & Reporting

Pod-Statistiken.

# Metrics Server

Nutzen Sie kubectl top pods.

• KPI: CPU/Memory Usage vs. Requests/Limits.
• Optimierung: Wenn ein Pod dauerhaft 10% seiner “Requests” nutzt, verkleinern Sie die Anforderungen, um mehr Pods auf die Hardware zu packen.

# 7. Fazit & Empfehlung

Pods sind die Atome von Kubernetes.

• Empfehlung: Nutzen Sie das Sidecar-Modell nur für infrastrukturelle Aufgaben (Logs, Proxy, Backup-Sync). Mischen Sie niemals zwei verschiedene Business-Apps in einen Pod.
• Wichtig: Sorgen Sie dafür, dass Applikationen im Pod auf SIGTERM reagieren und Verbindungen sauber schließen, um Datenverlust beim Skalieren (Artikel 813) zu vermeiden.

# Anhang: Cheatsheet (kubectl pod)

# Referenzen

• Kubernetes Docs: Pod Overview
• Patterns for Kubernetes (Sidecars)
• Cloud-Native Lifecycle Management