In Kubernetes-Tutorials wirkt alles elegant - YAML deployen, und die Magie geschieht. Aber in Produktion? Das ist eine andere Geschichte. Nach Jahren des Cluster-Betriebs für Unternehmenskunden haben wir die 15 Szenarien zusammengetragen, die Einsteiger tatsächlich von praxiserprobten Engineers trennen. Hier lesen Sie, womit Sie wirklich konfrontiert werden - und wie Sie es lösen.

Debugging-Albträume

1. Pod hängt in CrashLoopBackOff - ohne Logs

Das ist der stille Killer des Kubernetes-Debuggings. Ihr Pod startet immer wieder neu, aber in den Logs steht nichts. Hier sollten Sie nachsehen:

  • Logs des vorherigen Containers prüfen - der Container könnte abstürzen, bevor er überhaupt etwas schreibt
  • Init-Container ansehen - sie scheitern oft lautlos, noch bevor Ihr Haupt-Container startet
  • Auf OOMKilled prüfen - wegen Speichermangels beendete Container hinterlassen nicht immer Logs
  • Image lokal testen - manchmal beendet sich der Entrypoint sofort, weil Env-Variablen oder Configs fehlen
  • Debug-Container nutzen - hängen Sie einen Busybox-Sidecar an, um die Pod-Umgebung zu inspizieren

2. StatefulSet-Pod bindet seinen Storage nach Node-Ausfall nicht neu ein

Ihr Node ist ausgefallen, und der Pod hängt nun in der Warteschleife auf sein PVC. Die Daten sind sicher, aber Kubernetes bekommt die Verbindung nicht wiederhergestellt. Übliche Abhilfen:

  • Den hängenden Pod force-deleten - manchmal braucht Kubernetes einen Anstoß, um loszulassen
  • VolumeAttachment-Objekte prüfen - veraltete Attachments des toten Nodes können neue blockieren
  • Gesundheit des CSI-Treibers verifizieren - die Storage-Treiber-Pods in kube-system brauchen womöglich Aufmerksamkeit
  • Letzter Ausweg: das PV patchen - entfernen Sie die claimRef, um ein Rebinding zu ermöglichen

3. Pods in Pending, aber der Cluster Autoscaler skaliert nicht hoch

Sie haben wartende Pods und verfügbares Budget, aber keine neuen Nodes. Die Debugging-Checkliste:

  • Autoscaler-Logs prüfen - sie sagen Ihnen exakt, warum das Scale-up abgelehnt wurde
  • Node-Group-Limits verifizieren - Sie könnten unbemerkt die maximale Node-Anzahl erreicht haben
  • Pod-Anforderungen untersuchen - nodeSelector, Affinity-Regeln oder Taints, die keine Node Group erfüllen kann
  • Nach PodDisruptionBudgets suchen - sie können den Entscheidungszyklus des Autoscalers blockieren
  • Cloud-Quotas prüfen - Ihrem Provider könnte in dieser Region die Kapazität ausgegangen sein

4. Pods hängen endlos in ContainerCreating

Der Pod wurde gescheduled, startet aber nie. Meist ist das ein CNI- oder Storage-Problem:

  • Probleme mit dem CNI-Plugin - prüfen Sie, ob Calico, Cilium oder Ihre CNI-Pods gesund sind
  • Erschöpfte IP-Adressen - das Subnetz könnte voll sein
  • Probleme mit der Container-Runtime - containerd könnte hängen oder überlastet sein
  • Fehlgeschlagene Storage-Mounts - PVC-Binding-Probleme oder Schwierigkeiten mit dem CSI-Treiber
  • Korruptes Overlay-Dateisystem - manchmal hilft nur Aufräumen und ein Neustart von containerd

5. Sporadische DNS-Fehler in Pods

Manche Requests funktionieren, andere laufen scheinbar zufällig in Timeouts. DNS-Probleme sind notorisch schwer zu debuggen:

  • CoreDNS-Pods prüfen - sie könnten überlastet sein oder abstürzen
  • Conntrack-Limits ansehen - eine erschöpfte Connection-Tracking-Tabelle verursacht sporadische Fehler
  • UDP-Race-Condition - ergänzen Sie single-request-reopen in Ihrer dnsConfig
  • NodeLocal DNSCache in Betracht ziehen - eliminiert die meisten DNS-bedingten Probleme
  • ndots-Einstellung prüfen - hohe Werte verursachen übermäßig viele DNS-Anfragen

Sicherheit und Architektur

6. Betrieb eines Multi-Tenant-Clusters

Mehrere Teams, ein Cluster. Wie halten Sie alle isoliert und sicher?

  • Ein Namespace pro Tenant - das Fundament der Isolation
  • Auf den Namespace begrenzte RBAC-Rollen - Teams sehen nur ihre eigenen Ressourcen
  • Resource Quotas - verhindern, dass ein einzelner Tenant alle Ressourcen verbraucht
  • NetworkPolicy default-deny - kein Namespace-übergreifender Traffic ohne explizite Erlaubnis
  • PodSecurityAdmission - restriktive Sicherheitsrichtlinien pro Namespace durchsetzen
  • Für sensible Workloads - dedizierte Node-Pools pro Tenant in Betracht ziehen

7. NetworkPolicy blockiert Namespace-übergreifenden Traffic

Sie haben NetworkPolicies aktiviert, und jetzt ist alles kaputt. So entwerfen Sie sie richtig:

  • Mit Audit-Modus starten - Werkzeuge wie Cilium zeigen Ihnen vorab, was blockiert würde
  • Zuerst default deny - dann explizit erlauben, was benötigt wird
  • Namespace-Labels verwenden - Traffic aus Namespaces erlauben, nicht von einzelnen Pods
  • Mit Netcat testen - deployen Sie einen Debug-Pod und verifizieren Sie die Konnektivität
  • Mit Hubble visualisieren - reale Traffic-Flüsse in Echtzeit sehen

8. Nur vertrauenswürdige Container-Images durchsetzen

Sie müssen sicherstellen, dass nur freigegebene Images aus Ihrer internen Registry laufen dürfen. Ihre Optionen:

  • Kyverno - einfache YAML-basierte Policies, ideal für die meisten Teams
  • OPA Gatekeeper - mächtiger, aber mit steilerer Lernkurve
  • Eigener Admission Webhook - nur wenn Sie externe Systeme anbinden müssen
  • Profi-Tipp: Image-Signierung ergänzen - Cosign plus Policy Engine für Supply-Chain-Sicherheit

9. Anbindung einer externen Datenbank über VPN

Ihre Anwendung muss eine Datenbank erreichen, die nur über VPN zugänglich ist. Die Architektur-Optionen:

  • Sidecar-VPN-Container - gute Isolation, aber die Verbindungen vervielfachen sich
  • Dedizierte VPN-Gateway-Pods - zentralisiert und leichter zu verwalten
  • VPN auf Node-Ebene (empfohlen) - DaemonSet mit hostNetwork für hohe Verfügbarkeit
  • Sicherheits-Pflichten - Zugangsdaten in Secrets speichern, Zugriff per NetworkPolicy einschränken, mTLS aktivieren

Performance und Zuverlässigkeit

10. Kritischer Pod wurde wegen Node Pressure evicted

Ihr wichtigster Pod wurde beendet, weil dem Node die Ressourcen ausgingen. Der Schlüssel liegt im Verständnis der QoS-Klassen:

  • BestEffort (wird zuerst evicted) - keine Requests oder Limits gesetzt
  • Burstable (wird als Zweites evicted) - Requests niedriger als Limits
  • Guaranteed (wird zuletzt evicted) - Requests gleich Limits für alle Container
  • Für kritische Workloads - immer Guaranteed QoS plus hohe PriorityClass verwenden
  • Eviction-Schwellwerte konfigurieren - Memory- und Disk-Pressure-Einstellungen des Kubelet feinjustieren

11. Rolling Update verursachte Downtime

Sie haben eine neue Version deployt, und Nutzer sahen Fehler. Was ist schiefgelaufen?

  • Fehlende Readiness-Probe - Traffic wurde gesendet, bevor die Anwendung bereit war
  • Zu aggressive Probe - initialDelaySeconds zu kurz für langsam startende Anwendungen
  • Falscher Probe-Endpoint - ein schwergewichtiger Endpoint, der in Timeouts läuft
  • Deployment-Einstellungen zählen - maxUnavailable auf 0 setzen, minReadySeconds ergänzen
  • preStop-Hooks nicht vergessen - geben Sie Pods Zeit für einen Graceful Shutdown

12. Ingress Controller bricht unter Last ein

Der Traffic-Spike kam, und Ihr Ingress wurde zum Flaschenhals. So beheben Sie es:

  • Auf Config-Reload-Stürme prüfen - häufige Ingress-Änderungen verursachen Performance-Einbrüche
  • Horizontal skalieren - mehr Replicas mit Anti-Affinity
  • Worker-Prozesse tunen - in der ConfigMap auf auto stellen
  • Keep-alive aktivieren - Verbindungs-Overhead reduzieren
  • Aufteilung erwägen - getrennte Controller für internen und externen Traffic

13. Der Istio-Sidecar verbraucht mehr CPU als Ihre Anwendung

Der Service-Mesh-Overhead frisst Ihre Ressourcen. Optimierungsstrategien:

  • Sidecar-Scope begrenzen - Egress nur auf die benötigten Namespaces konfigurieren
  • Ressourcen-Limits anpassen - Sidecars brauchen weniger, als die Defaults nahelegen
  • Ungenutzte Features deaktivieren - Access Logging abschalten, Tracing-Sampling reduzieren
  • Ambient Mesh erwägen - der Sidecar-lose Istio-Modus für L4-Traffic

14. etcd bremst die Control Plane aus

Die API-Server-Antworten sind langsam, und alles fühlt sich träge an. Der Übeltäter ist meist etcd:

  • Disk-I/O ist entscheidend - etcd braucht SSDs mit Latenzen unter einer Millisekunde
  • Zu viele Objekte - Secrets, ConfigMaps und Events sammeln sich mit der Zeit an
  • Netzwerklatenz zwischen den Membern - halten Sie etcd-Nodes in derselben Availability Zone
  • Auto-Compaction aktivieren - verhindert, dass die Datenbank unbegrenzt wächst
  • Regelmäßige Defragmentierung einplanen - aber nur in Wartungsfenstern

15. Kubelet startet auf einem Node immer wieder neu

Ein Node macht Probleme, während die anderen sauber laufen. Wo Sie suchen sollten:

  • Systemd-Status prüfen - Kubelet-Logs via journalctl
  • Nach OOM-Kills suchen - das Kubelet selbst könnte wegen Speichermangels beendet werden
  • Container-Runtime verifizieren - containerd könnte nicht mehr reagieren
  • Cgroup-Treiber prüfen - muss zwischen Kubelet und Runtime übereinstimmen
  • Disk Pressure - /var/lib/kubelet läuft voll
  • Abgelaufene Zertifikate - oft übersehen, aber eine häufige Ursache

Die wichtigsten Erkenntnisse

Nach dem Troubleshooting hunderter Produktionsvorfälle haben wir Folgendes gelernt:

  • Zuerst Daten sammeln - Events, Logs, Metriken und Node-Status, bevor Sie etwas ändern
  • Verteidigung in Schichten aufbauen - RBAC plus NetworkPolicy plus Resource Quotas plus Pod Security
  • Für den Ausfall designen - saubere QoS-Klassen, Priority Classes und PodDisruptionBudgets
  • Die Control Plane überwachen - die Gesundheit von etcd und Kubelet sind kritische Indikatoren
  • Testen vor dem Durchsetzen - Audit-Modus für Policies, Canary Deployments für Änderungen

Kubernetes in Produktion ist eine Reise, kein Ziel. Diese 15 Szenarien sind das Fundament - meistern Sie sie, und Sie sind für alles gewappnet, was Ihre Cluster Ihnen entgegenwerfen. Und wenn Sie für solche Szenarien lieber erfahrene Engineers auf Abruf hätten: Unser Managed-Services-Team betreibt Produktions-Cluster jeden Tag.

Sie betreiben so etwas in Produktion? Unser AWS Managed Services-Team betreibt solche Umgebungen rund um die Uhr — Monitoring, Incident Response, Patching und Kostenkontrolle durch namentlich benannte Senior Engineers, ab €3.000/Monat.

Tags: #Kubernetes #K8s #DevOps #Debugging #EKS #Sicherheit #CloudNative