Pod-Eviction-Kaskade

Dem Node ging der Plattenplatz aus. Alle Pods verdrängt. Neue Pods auf demselben Node eingeplant. Wieder verdrängt. Wiederholen, bis jemand aufwachte.

Die Timeline:

• 2:00 Uhr: Der Node überschreitet die Standard-Eviction-Schwelle des Kubelets (nodefs.available < 10%)
• 2:05 Uhr: Das Kubelet verdrängt die Pods; der Node bekommt den Taint node.kubernetes.io/disk-pressure
• 2:10 Uhr: Da die Pods (und ihre Logs) weg sind, fällt die Plattenbelegung wieder unter die Schwelle
• 2:15 Uhr: Nach der eviction-pressure-transition-period (standardmäßig 5 Minuten) verschwindet der Taint — und der Scheduler setzt die Pods direkt wieder auf denselben Node, der jetzt die meisten freien Ressourcen meldet
• 2:25 Uhr: Die Logs wachsen nach, die Schwelle wird erneut überschritten, die Evictions wiederholen sich
• 2:50 Uhr: Der Alert feuert (endlich), zwei volle Schleifen später

Die Ursache:

• Die Anwendung loggte ins Container-Dateisystem
• Keine Log-Rotation konfiguriert
• Keine ephemeral-storage-Limits gesetzt
• Der DiskPressure-Taint verschwindet, sobald die Belegung unter die Schwelle fällt — nicht, wenn das eigentliche Log-Problem behoben ist — also nahm derselbe Node immer wieder dieselben Pods an

Der Fix:

resources:
  requests:
    ephemeral-storage: "1Gi"
  limits:
    ephemeral-storage: "2Gi"

Dazu:

• Nach stdout loggen (eingesammelt von Fluentd)
• Container-Log-Rotation konfigurieren
• Node-Plattenbelegung überwachen, mit Alerts bei 70% — deutlich bevor das Kubelet eingreift

Mit gesetzten ephemeral-storage-Limits wird bei einem außer Kontrolle geratenen Logger nur der eigene Pod verdrängt, statt dass er den Node mitreißt. Disk-Alerts auf Node-Ebene gehören zum Basis-Monitoring, das wir in jedem DevOps-Engagement einrichten.

Lektion: Setzen Sie ephemeral-storage-Limits. Immer.

---

Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.