Hier ist mein automatischer K8s-Pod-Bereiniger „kube-depod“. (CEL-basiert, mit PDB-Unterstützung)

Hallo, wenn man einen K8s-Cluster betreibt, wird es oft unübersichtlich durch Pods mit CrashLoopBackOff, Pods im Status ImagePullBackOff oder Pods, die nach Abschluss eines Batch-Jobs als Succeeded oder Failed einfach liegen bleiben.

Um das Problem zu lösen, dass solche Pods Ressourcen verschwenden und das Monitoring stören, habe ich den Rust-basierten K8s-Operator „kube-depod“ entwickelt.

kube-depod ist nicht einfach nur ein TTL-Cleaner. Der Fokus liegt auf Flexibilität und Sicherheit.

---

🚀 Kernfunktionen

1. Leistungsstarke CEL-Policy-Engine
Statt einfach nur Pods zu löschen, die „älter als 10 Minuten“ sind, lassen sich mit CEL (Common Expression Language) deutlich präzisere Policies erstellen.

# Beispiel: Nur CrashLoopBackOff-Pods löschen, deren Neustartanzahl mindestens 5 beträgt  
when:  
  type: "CEL"  
  expression: |  
    status.containerStatuses.exists(c,  
      has(c.state.waiting) &&  
      c.state.waiting.reason == 'CrashLoopBackOff' &&  
      c.restartCount >= 5  
    )  

(age, status.phase und weitere Variablen werden unterstützt.)

2. „Opt-in“-Ansatz zur Vermeidung von Zwischenfällen
kube-depod überwacht nicht alle Pods im Cluster. Als Bereinigungsziele gelten ausschließlich Pods, bei denen Nutzer explizit eine Annotation wie kube-depod/policy: "my-policy" hinzugefügt haben (Opt-in). Dadurch wird von vornherein verhindert, dass versehentlich wichtige Pods gelöscht werden.

3. Schutzmechanismen für den Produktionseinsatz

• PDB-Unterstützung: Statt Delete wird auch die Aktion Evict unterstützt, sodass Pods unter Beachtung von Pod Disruption Budget (PDB) sicher entfernt werden.
• DryRun: Mit dryRun: true kann sicher getestet werden, wie eine Policy arbeitet.
• Ratenbegrenzung (Rate Limiting): Die Anzahl der Löschvorgänge pro Minute wird begrenzt, um eine Überlastung des API-Servers oder Instabilität des Clusters zu verhindern.
• Schutz von System-Namespaces: Zentrale Namespaces wie kube-system sind standardmäßig geschützt.

4. Hohe Performance und gute Observability

• In Rust geschrieben und mit Distroless-Images ausgestattet, daher leichtgewichtig und schnell.
• Für hohe Performance werden u. a. ArcSwap (lockfreier Policy-Cache) und DashMap (CEL-Kompilierungs-Cache) eingesetzt.
• Mit Prometheus-Metriken und CRD-Status-Feedback (z. B. InvalidCEL) lässt sich der Betriebszustand leicht debuggen.

---

Ähnliche Tools gibt es viele, aber nur wenige konzentrieren sich so stark auf Betriebssicherheit wie dieses Tool – etwa mit der Flexibilität von CEL, der PDB-Unterstützung und dem Opt-in-Design.

Ein Helm-Chart ist ebenfalls vorhanden, sodass die Installation einfach ist.
Ich hoffe, es hilft allen, die ihren K8s-Cluster sauberer und effizienter verwalten möchten.

GitHub-Repository: https://github.com/mrchypark/kube-depod

Interesse und Feedback sind jederzeit willkommen! Vielen Dank.