こんにちは！Argo CDを使っているときに、「なぜ私のリソースは自動的に削除されないのだろう？」とか「特定の順序でデプロイしたいけど、方法はないのかな？」と悩んだことはありませんか？そのすべての答えは、アプリケーションマニフェストのspec.syncPolicyセクションにあります。
今日は、デプロイの洗練度を完成させる様々な同期オプションとポリシーについて詳しく見ていきましょう。🛠️
1. 🔍 spec.syncPolicyの主要属性の整理
syncPolicyは、Argo CDがGitの「希望状態」とクラスターの「現在の状態」をどのように一致させるかを定義する最上位のポリシーです。
① automated (自動同期)
Gitの変更を検知し、自動的にクラスターに反映します。
- prune: Gitから削除されたリソースをクラスターからも削除するかどうか (デフォルト: false)。🗑️
- selfHeal: クラスターリソースを手動で修正した場合、Gitの状態に復元するかどうか (デフォルト: false)。🏥
② retry (再試行戦略)
同期失敗時の再試行回数と間隔を設定します。
- limit: 最大再試行回数。
- backoff: 再試行間隔 (指数バックオフをサポート)。🔁
2. ⚡ 主要なsyncOptionsの詳細ガイド
syncOptionsは、同期プロセスで使用する具体的な技術オプションをリスト形式で提供します。
✅ ApplyOutOfSyncOnly=true (パフォーマンス最適化)
デフォルトでは、Argo CDは同期時にアプリのすべてのリソースを再適用します。しかし、リソースが多い場合、これは大きな無駄です。
- 役割: OutOfSync（同期されていない）状態のリソースのみを選択して更新を実行します。
- 利点: APIサーバーの負荷を軽減し、同期速度を飛躍的に向上させます。⚡
✅ Replace=true (強制更新戦略)
Kubernetesの特定のリソースは、kubectl applyによる修正が不可能な場合があります。(例: Immutableフィールドの変更)
- 役割: applyの代わりにreplaceまたはdelete後にcreate方式を使用してリソースを強制的に更新します。
- 注意: リソースが一時的に削除される可能性があるため、サービス中断に注意が必要です。🛠️
✅ PrunePropagationPolicy=foreground (安全な削除)
リソースを削除する際に、子リソース（Podなど）をどのように処理するかを決定します。
- Foreground: 親（Deploymentなど）を削除する前に、子リソースを確実に整理します。最も安全な方法です。🛡️
- Background (デフォルト): 親を先に削除し、子は後でガベージコレクターが処理します。
✅ CreateNamespace=true
対象のネームスペースがクラスターに存在しない場合、Argo CDが自動的に作成します。🏗️
3. 🌊 デプロイ順序の魔法: Sync Waves
アプリケーションをデプロイする際に、「DBが起動してからWASが起動する必要がある」といった順序が必要な場合に使用します。これはsyncOptionsではなく、個別のリソースのAnnotationで設定します。
- 動作原理: 小さい数字（例: -5）から大きい数字（例: 10）の順序でリソースをデプロイします。
- 利点: 依存関係が複雑なマイクロサービス環境でデプロイの安定性を保証します。🌊
4. 💻 実践コード: 全体設定例
上記のすべての内容を統合したArgo CD Applicationマニフェストです。コメントを通じて各設定の意味を再確認してください。
YAML
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: master-ops-app
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/my-org/manifests.git'
targetRevision: main
path: apps/my-service
destination:
server: 'https://kubernetes.default.svc'
namespace: production
# 1. 同期ポリシー設定 🔄
syncPolicy:
automated:
prune: true # 削除の自動反映
selfHeal: true # 手動修正の復旧
# 2. 詳細同期オプションリスト ⚙️
syncOptions:
- ApplyOutOfSyncOnly=true # 変更されたリソースのみを更新
- Replace=true # 修正不可リソースの再生成
- PrunePropagationPolicy=foreground # 子リソースから順次削除
- CreateNamespace=true # ネームスペースの自動作成
- ServerSideApply=true # 大規模マニフェスト処理の最適化
- FailOnSharedResource=true # リソース重複管理の防止 🚫
# 3. 失敗時の再試行戦略 🔁
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3m
---
# 4. 個別リソース（例: ConfigMap）でのSync Wave使用例
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
annotations:
# 最も早くデプロイされるように設定 (数字が小さいほど早い) 🌊
argocd.argoproj.io/sync-wave: "-10"
data:
config: "setting"5. 💡 追加で知っておくと良いsyncOptions
- Validate=false: kubectl apply –validate=falseと同様に、リソーススキーマの検証をスキップします。
- SkipDryRunOnMissingResource=true: CRDがまだインストールされていない状態で、そのカスタムリソースをデプロイする際に発生するDry-runエラーを防ぎます。
- RespectIgnoreDifferences=true: spec.ignoreDifferences設定を同期判断基準に厳密に適用します。
📝 要約テーブル
| 属性 / オプション | 主要な役割 | 比喩 |
| — | — | — |
| prune | Git削除時にクラスターからも削除 | ミニマリズム（使わない物の整理） |
| selfHeal | 手動修正の自動復旧 | 恒常性維持（元に戻す） |
| ApplyOutOfSyncOnly | 変更分のみ更新 | 必要な部分だけ修理する |
| Replace | リソースの再生成 | 直せないなら新しく買う |
| Sync Waves | リソースデプロイ順序の制御 | ドミノのように順序立てて並べる |
—
💡 まとめ
Argo CDのsyncPolicyは、単なる「自動化」を超えて、「いかに安全かつ迅速にデプロイするか」という問いに対する答えを提供します。特に大規模な環境では、ApplyOutOfSyncOnlyやSync Wavesのようなオプションは選択ではなく必須です。🎯
今日のガイドが、皆様の安定したインフラ運用に大いに役立つことを願っています！
コメントを残す