こんにちは!本日は、Kubernetes環境におけるマルチクラスターおよびマルチアプリケーション管理を革新的に簡素化するArgoCD ApplicationSetとその心臓部であるGeneratorについて詳しく見ていきます。
単一のアプリケーションをデプロイするだけでなく、「クラスターが100個あったら?」「ステージングとプロダクション環境が異なったら?」といった悩みを一挙に解決してくれるツールです。

1. ApplicationSetとは何ですか? 🤔
ArgoCDの基本単位であるApplicationリソースは、1つのソース(Git)と1つのデスティネーション(Cluster)を接続します。しかし、管理すべきサービスが増えると、Application YAMLファイルも指数関数的に増加します。
ApplicationSetは一種の「たい焼きの型」です。Generatorというエンジンを通じて、複数のApplicationを動的に生成します。
2. Generatorの種類別詳細分析 🔍
Generatorは「どのようなデータに基づいてApplicationを作成するか?」を決定します。最もよく使われる4つのタイプに焦点を当てて見ていきましょう。
① List Generator: 最も直感的な開始 📋
最もシンプルな形式で、YAML内に生成するリストを直接明記します。
- 用途: 管理対象が少なく明確な場合。
- 利点: 直感的で設定が簡単です。
📝 コード例と説明
YAML
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: my-apps
namespace: argocd
spec:
generators:
- list:
# 生成する要素をリストとして定義します。
elements:
- cluster: engineering-dev
url: https://kubernetes.default.svc # ローカルクラスター
- cluster: engineering-prod
url: https://1.2.3.4 # リモートクラスター
template:
metadata:
# 上記elementsで定義された{{cluster}}変数を動的に使用します。
name: '{{cluster}}-guestbook'
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
server: '{{url}}' # {{url}}変数がここに置換されます。
namespace: guestbook
② Cluster Generator: マルチクラスター管理の核 ☸️
ArgoCDに登録されたクラスター情報を自動的に読み込み、アプリケーションをデプロイします。
- 用途: クラスターが追加されるたびに自動的にアプリケーションをデプロイしたい場合。
- 特徴: ラベルセレクター(labelSelector)を使用して特定のクラスターのみを選択できます。
📝 コード例と説明
YAML
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: cluster-scoped-app
spec:
generators:
- clusters:
# ArgoCDで'env: staging'ラベルが付与されたクラスターのみを対象とします。
selector:
matchLabels:
env: staging
template:
metadata:
# {{name}}はArgoCDに登録されたクラスター名に自動的にマッピングされます。
name: '{{name}}-monitoring'
spec:
project: default
source:
repoURL: https://github.com/my-repo/monitoring.git
targetRevision: main
path: charts/prometheus
destination:
# {{server}}はクラスターのAPIサーバーアドレスに置換されます。
server: '{{server}}'
namespace: monitoring
③ Git Generator: Gitリポジトリ構造が設定そのもの 📂
Gitリポジトリ内のファイル内容やディレクトリ構造を検知してアプリケーションを生成します。
- 用途: apps/app-a, apps/app-b のようにフォルダー構造でアプリケーションを管理する場合。
- 種類:
- Directory: 特定のパスのサブディレクトリを探索。
- File: JSON/YAMLファイルの内容を読み込み、変数として使用。
📝 コード例 (ディレクトリベース)
YAML
spec:
generators:
- git:
repoURL: https://github.com/my-org/infra.git
revision: HEAD
# 'services/*'パスにあるすべてのディレクトリを検索します。
directories:
- path: services/*
template:
metadata:
# ディレクトリ名(例: auth-service)がアプリケーション名になります。
name: '{{path.basename}}'
spec:
source:
repoURL: https://github.com/my-org/infra.git
targetRevision: HEAD
path: '{{path}}' # 実際のGit内のパスを使用。
destination:
server: https://kubernetes.default.svc
namespace: '{{path.basename}}'
④ Matrix Generator: 究極の組み合わせ 🧬
2つ以上のGeneratorを組み合わせ(乗算)ます。例えば、
「すべてのクラスター(Cluster Gen)」
に
「すべてのアプリケーション(Git Gen)」
をデプロイしたい場合に使用します。
- 動作原理: リストA [1, 2]とリストB [a, b]がある場合、結果は [1-a, 1-b, 2-a, 2-b] となります。
📝 コード例 (Cluster x Git 組み合わせ)
YAML
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: matrix-deploy
spec:
generators:
- matrix:
generators:
# 1. 対象クラスターの選定 (開発、運用)
- clusters:
selector:
matchLabels:
tier: backend
# 2. デプロイするアプリケーションリスト (Gitファイルベース)
- git:
repoURL: https://github.com/my-repo/configs.git
revision: HEAD
files:
- path: "config/**/config.json"
template:
metadata:
# 結果: 'dev-cluster-api-server', 'prod-cluster-api-server' などが生成されます
name: '{{name}}-{{customer}}'
spec:
project: default
source:
repoURL: https://github.com/my-repo/apps.git
targetRevision: HEAD
path: app-chart
helm:
# JSONファイル内に定義されたパラメーターをHelm valueとして渡すことが可能!
parameters:
- name: "customerName"
value: "{{customer}}"
destination:
server: '{{server}}'
namespace: '{{customer}}'
⑤ Merge Generator: 条件付き上書き 🔗
Matrixと似ていますが、同じキーを基準にデータをマージします。特定の環境でのみ設定を少し変更したい場合に便利です。
3. 実務のヒント: どのような状況で何を使うべきか?💡
| 状況 | 推奨Generator |
| — | — |
| ArgoCDを始めたばかりで手動管理が嫌だ | List |
| クラスターが継続的に増加するマルチクラスター環境である | Clusters |
| 1つのGitリポジトリに複数のマイクロサービスコードがある | Git (Directory) |
| 顧客ごと(SaaS)に異なるクラスターにデプロイする必要がある | Matrix |
—
4. 注意事項とベストプラクティス ⚠️
- ドライランの活用: ApplicationSetをデプロイする前に、argocd-appset-controllerのログを確認するか、小さな単位でまずテストしてください。誤って数百もの不正なアプリケーションが同時に生成される可能性があります。
- Namespace管理: ApplicationSet自体はargocdネームスペースにあるべきですが、生成されるApplicationのデスティネーションは適切に分離してください。
- リソースの保持: ApplicationSetを削除する際に、実際にデプロイされたリソース(Pod, Serviceなど)も削除するかどうかをポリシー設定を通じて決定できます。運用環境では慎重に行う必要があります。
5. 終わりに 🏁
ApplicationSetは、単なる繰り返し作業を減らすだけでなく、
インフラをコードとして完全に制御(Infrastructure as Code)
できるようにする重要なツールです。最初はMatrix Generatorの複雑さに戸惑うかもしれませんが、一度構築すれば運用効率が何十倍も向上するでしょう。
あなたの環境に合ったGeneratorは何ですか?今すぐ試してみてください!🛠️
コメントを残す