🧹 Argo Workflowsリソースクリーンアップマスター: ttlStrategy vs podGC 完全分析

Kubernetesワークフローを自動化していると、いつの間にか完了した多数のPodがクラスターに蓄積されていることに気づくでしょう。「これらを一つ一つ削除しなければならないのか？」という悩みに直面したときに登場するのが、ttlStrategyとpodGCという2つの重要な設定です。

本日は、Argo Workflowsでリソースをきれいに整理するこれら2つの機能の使用方法と決定的な違いを非常に詳細に掘り下げていきます！🚀

こんにちは！Kubernetesベースのワークフローを運用していると、リソース管理がいかに重要であるかを痛感します。特に数千ものジョブが実行される環境では、完了したリソースを適時にクリーンアップしないと、APIサーバーに負荷がかかり、管理が不可能になります。

Argo Workflowsは、この目的のために2つのクリーンアップツールを提供しています。今から10分間で、これら2つの違いを完全に理解しましょう！

---

1. ttlStrategy: ワークフロー自体を削除する ⏳

ttlStrategy（Time To Live Strategy）は、ワークフロー（Workflow）リソース自体をいつ削除するかを決定します。ワークフローが削除されると、それに付随するPodも一緒に削除されます。

✅ 使用方法

ttlStrategyは、ワークフローの結果に応じて2つのオプションを提供します。

• secondsAfterCompletion: 成功/失敗に関わらず、終了後N秒後に削除。
• secondsAfterSuccess: 成功した場合のみN秒後に削除。
• secondsAfterFailure: 失敗した場合のみN秒後に削除（デバッグのために失敗時は長めに設定することが多いです）。

📝 コード例と説明

YAML

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: ttl-strategy-example-
spec:
  entrypoint: main
  # ワークフロー終了後の自動削除戦略を設定
  ttlStrategy:
    secondsAfterSuccess: 300 # 成功後5分(300秒)でワークフローリソースを削除
    secondsAfterFailure: 3600 # 失敗時、デバッグのために1時間(3600秒)後に削除
    
  templates:
  - name: main
    container:
      image: alpine:latest
      command: [sh, -c]
      args: ["echo 'Hello, Clean World!'; sleep 10"]

---

2. podGC: Podだけを選んで削除する 🗑️

podGC（Pod Garbage Collection）は、ワークフローリソースはそのまま残しつつ、ワークフローを構成していた個別のPodだけを先に整理する機能です。

✅ 使用方法

podGCは削除ポリシー（strategy）を通じて制御します。

• OnPodCompletion: Podが正常に終了したらすぐに削除。
• OnPodSuccess: 成功したPodのみ削除。
• OnWorkflowCompletion: ワークフロー全体が終了したらすべてのPodを削除（最も推奨されます）。
• OnWorkflowSuccess: ワークフローが正常に終了した場合のみすべてのPodを削除。

📝 コード例と説明

YAML

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: pod-gc-example-
spec:
  entrypoint: main
  # Podガーベージコレクション設定
  podGC:
    strategy: OnWorkflowCompletion # ワークフロー終了後、結果に関わらずPodのみを先に削除
    
  templates:
  - name: main
    container:
      image: alpine:latest
      command: [echo, "Pods will be deleted, but Workflow CRD stays!"]

---

3. 主要な違いの比較: 何が違うのか？ ⚖️

最も混同しやすい部分をテーブルにまとめました。

区分	ttlStrategy	podGC
—	—	—
削除対象	Workflowリソース全体（Podを含む）	Podリソースのみ削除
Argo UI確認	削除後はUIから記録が消える	記録は残るが、ログ/結果は表示できない
主な目的	Kubernetes APIサーバーの負荷防止と完全な整理	ワークフロー記録を保持しつつノードリソースを整理
時間設定	秒単位で詳細な制御が可能	状態に基づいて即時動作

—

4. 実務運用ヒント: いつどちらを使うべきか？ 💡

シナリオA: 記録が重要なビルド/デプロイ環境

この場合はpodGCを使用してください。ワークフロー記録はArgo UIに残し、「いつデプロイが成功したか」を確認できるようにし、Podだけを削除してクラスターを快適に保ちます。

シナリオB: 数万回実行される短いバッチジョブ

この場合はttlStrategyを使用してください。記録すら多すぎると、Argo CDやKubernetesダッシュボードが遅くなります。一定時間が経過したら記録も完全に削除するのが良いでしょう。

シナリオC: 最も完璧な組み合わせ（ハイブリッド）

最も推奨される方法は、両方を使用することです！

• podGC: OnWorkflowCompletionでPodをすぐに削除し、
• ttlStrategy: secondsAfterCompletion: 86400で24時間後に記録も削除する方式です。

---

5. 注意事項と限界 ⚠️

1. ログ確認の難しさ: podGCでPodが削除されると、kubectl logsコマンドでログを見ることができません。必ずアーカイブ（Artifact Repository）設定や外部ログシステム（ELK、Lokiなど）を連携させてください。
2. リソースの残留: ttlStrategyを設定しないと、ワークフローリソースはユーザーが手動で削除するまで永久に残ります。これはAPIサーバーのメモリ使用量を増加させる主な原因となります。

---

6. 結論 🏁

• 記録も削除したい？ → ttlStrategy
• 記録は残してPodだけを整理したい？ → podGC

これら2つの機能をうまく組み合わせるだけで、Kubernetesクラスターの「快適さ」が完全に変わります。皆さんのワークフローの性質に合わせて最適なクリーンアップ戦略を立ててみてください！🛠️