5 ポイント 投稿者 mrchypark 2025-11-18 | まだコメントはありません。 | WhatsAppで共有

こんにちは。K8sクラスターを運用していると、CrashLoopBackOff に陥ったPod、ImagePullBackOff 状態のPod、あるいはバッチ完了後に SucceededFailed のまま放置されたPodのせいで、環境が散らかってしまうことがよくあります。

こうしたPodがリソースを無駄にし、モニタリングの妨げになる問題を解決するため、**RustベースのK8sオペレーター「kube-depod」**を開発しました。

kube-depod は単純なTTLクリーナーではありません。柔軟性安全性に重点を置いています。


🚀 主な機能

1. 強力なCELポリシーエンジン
単に「10分経過した」Podではなく、CEL(Common Expression Language) を使って、はるかに精密なポリシーを作成できます。

# 例: 再起動回数が5回以上のCrashLoopBackOff Podのみ削除  
when:  
  type: "CEL"  
  expression: |  
    status.containerStatuses.exists(c,  
      has(c.state.waiting) &&  
      c.state.waiting.reason == 'CrashLoopBackOff' &&  
      c.restartCount >= 5  
    )  

(age, status.phase など、さまざまな変数をサポートします。)

2. 事故を防ぐ「Opt-In」方式
kube-depod はクラスター内のすべてのPodを監視しません。ユーザーが kube-depod/policy: "my-policy" のようなアノテーションを明示的に追加したPod (Opt-In) だけをクリーンアップ対象として扱います。重要なPodを誤って削除してしまう事故を根本から防ぎます。

3. 本番運用のための安全機構

  • PDB対応: Delete の代わりに Evict アクションをサポートし、Pod Disruption Budget(PDB) を尊重しながらPodを安全に削除します。
  • DryRun: ポリシーがどのように動作するかを dryRun: true で安全にテストできます。
  • 速度制限 (Rate Limiting): 1分あたりの削除回数を制限し、APIサーバーの過負荷やクラスターの不安定化を防ぎます。
  • システム名前空間の保護: kube-system などの重要な名前空間はデフォルトで保護します。

4. 高性能と優れた可観測性

  • Rustで書かれており、Distrolessイメージを使用しているため軽量かつ高速です。
  • ArcSwap (ロックフリーのポリシーキャッシュ)、DashMap (CELコンパイルキャッシュ) などを活用して高性能を追求しました。
  • PrometheusメトリクスとCRD Statusフィードバック (例: InvalidCEL) により、運用状態を簡単にデバッグできます。

似たようなツールは多いですが、CELの柔軟性とPDB対応、Opt-In設計など、運用の安全性に重点を置いたツールはまれでした。

Helmチャートも用意しているので、簡単にインストールできます。
K8sクラスターをよりクリーンで効率的に管理したい方の助けになれば幸いです。

GitHubリポジトリ: https://github.com/mrchypark/kube-depod

ご関心やフィードバックはいつでも歓迎します。ありがとうございます。

まだコメントはありません。

まだコメントはありません。