Voici mon outil de nettoyage automatique des Pods K8s, « kube-depod » (basé sur CEL, avec prise en charge des PDB)

Bonjour, lorsqu’on exploite un cluster K8s, il est fréquent qu’il finisse par être encombré par des Pods bloqués en CrashLoopBackOff, des Pods en état ImagePullBackOff, ou encore des Pods laissés à l’abandon en Succeeded ou Failed une fois les batchs terminés.

Pour résoudre ce problème de Pods qui gaspillent des ressources et perturbent la supervision, j’ai développé kube-depod, un opérateur K8s basé sur Rust.

kube-depod n’est pas un simple nettoyeur TTL. Il met l’accent sur la souplesse et la sécurité.

---

🚀 Fonctionnalités clés

1. Moteur de politiques CEL puissant
Au lieu de simplement supprimer des Pods « vieux de 10 minutes », il permet de définir des politiques bien plus fines grâce à CEL (Common Expression Language).

# Ex. : supprimer uniquement les Pods en CrashLoopBackOff dont le nombre de redémarrages est d’au moins 5  
when:  
  type: "CEL"  
  expression: |  
    status.containerStatuses.exists(c,  
      has(c.state.waiting) &&  
      c.state.waiting.reason == 'CrashLoopBackOff' &&  
      c.restartCount >= 5  
    )  

(Il prend en charge diverses variables comme age, status.phase, etc.)

2. Un mode « Opt-In » pour éviter les incidents
kube-depod ne surveille pas tous les Pods du cluster. Il ne considère comme cibles de nettoyage que les Pods auxquels l’utilisateur a explicitement ajouté une annotation telle que kube-depod/policy: "my-policy" (Opt-In). Cela évite à la source toute suppression accidentelle de Pods critiques.

3. Garde-fous pour la production

• Prise en charge des PDB : il prend en charge l’action Evict au lieu de Delete, ce qui permet de respecter les Pod Disruption Budget (PDB) et de retirer les Pods en toute sécurité.
• DryRun : il est possible de tester en toute sécurité le comportement d’une politique avec dryRun: true.
• Limitation de débit (Rate Limiting) : le nombre de suppressions par minute peut être limité afin d’éviter une surcharge du serveur API ou une instabilité du cluster.
• Protection des espaces de noms système : les espaces de noms critiques comme kube-system sont protégés par défaut.

4. Hautes performances et excellente observabilité

• Écrit en Rust et utilisant une image Distroless, il est léger et rapide.
• Il vise de hautes performances grâce à l’utilisation de ArcSwap (cache de politiques sans verrou), DashMap (cache de compilation CEL), etc.
• Les métriques Prometheus et les retours de statut du CRD (par ex. InvalidCEL) facilitent le débogage de l’état d’exploitation.

---

Il existe de nombreux outils similaires, mais il est rare d’en trouver un qui mette autant l’accent sur la sécurité en production, avec la souplesse de CEL, la prise en charge des PDB et une conception Opt-In.

Un chart Helm est également prêt, ce qui permet une installation facile.
J’espère que cela sera utile à celles et ceux qui souhaitent gérer leur cluster K8s de façon plus propre et plus efficace.

Dépôt GitHub : https://github.com/mrchypark/kube-depod

Votre intérêt et vos retours sont toujours les bienvenus ! Merci.