spec.ttlStrategy
完了後のワークフローを何時間後に削除するかなどを制御。
成功/失敗した Workflow を TTL に基づいて自動削除する。
Workflow専用
Claude Code.icon
Argo Workflows の ttlStrategy
TTL = Time To Live（生存期間）の略で、「Workflow が完了してから何秒後に削除するか」を制御します。
なぜ必要か
Argo Workflows は完了後も Workflow リソース（と関連する Pod）を etcd / Kubernetes API に残し続けます。放置すると：
etcd に完了済み Workflow が溜まり続ける
kubectl get wf が大量の完了済みで埋まる
API サーバーの負荷やストレージ圧迫
ttlStrategy を設定すると、完了した Workflow が自動的にガベージコレクトされます。
基本的な書き方
code:yaml
apiVersion: argoproj.io/v1alpha1
kind: Workflow
spec:
ttlStrategy:
secondsAfterCompletion: 300 # 完了後 300 秒で削除（成功・失敗問わず）
secondsAfterSuccess: 120 # 成功後 120 秒で削除
secondsAfterFailure: 3600 # 失敗後 3600 秒で削除
3 つのフィールド
table:_
フィールド 意味
secondsAfterCompletion 完了（成功 or 失敗どちらでも）してからの秒数
secondsAfterSuccess 成功して完了してからの秒数
secondsAfterFailure 失敗して完了してからの秒数
優先順位のポイント
より具体的な条件（secondsAfterSuccess / secondsAfterFailure）が、包括的な secondsAfterCompletion より 優先されます。
例：成功した Workflow には secondsAfterSuccess があればそれが使われ、なければ secondsAfterCompletion にフォールバックします。
これにより「失敗したものはデバッグ用に長く残し、成功したものはすぐ消す」といった運用がよくされます：
code:yaml
ttlStrategy:
secondsAfterSuccess: 60 # 成功は 1 分で消す
secondsAfterFailure: 86400 # 失敗は 1 日残してデバッグ
注意点・つまづきやすいところ
1. 削除されるのは Workflow リソースそのもの
→ 関連 Pod も一緒に消えるので、kubectl logs でログが見られなくなります。ログを永続化したい場合は アーカイブ（archiveLogs + S3 等の artifact repository） や、Workflow 自体を DB にアーカイブする Workflow Archive 機能を併用します。
ttlStrategy：Workflow リソース全体の削除
podGC：Workflow は残しつつ Pod だけ削除（OnPodCompletion / OnWorkflowSuccess など）両者は組み合わせて使えます。「Pod は早めに消すが Workflow リソースは少し残す」といった調整が可能です。
3. Controller の設定でデフォルトを与えられる
個々の Workflow に書かなくても、workflow-controller-configmap の workflowDefaults でクラスタ全体のデフォルト ttlStrategy を設定できます。
code:yaml
# workflow-controller-configmap
data:
workflowDefaults: |
spec:
ttlStrategy:
secondsAfterCompletion: 600
4. 削除タイミングは厳密ではない
TTL コントローラーが定期的にチェックして削除するため、指定秒数ぴったりではなく多少の遅延があります。
5. WorkflowTemplate / CronWorkflow でも指定可能
CronWorkflow の場合は workflowSpec.ttlStrategy の下に書きます。CronWorkflow は定期実行で Workflow が量産されるため、TTL 設定はほぼ必須です。