🏗️ Argo CDアーキテクチャを深く掘り下げる：主要なCRと関係性の完全ガイド

こんにちは！KubernetesでGitOpsを実現する際、私たちにとって最も馴染み深いツールは間違いなくArgo CDです。しかし、ダッシュボードの向こう側で実際にどのようなリソースが動いているのかを正確に把握するのは、また別の領域です。

本日は、Argo CDの核をなすCustom Resources(CR)について掘り下げ、これらがクラスター内部でどのように連携して「宣言的デプロイ」を完成させるのかを詳しく見ていきましょう。🛠️

---

1. 🌟 Argo CDの4つの主要カスタムリソース（CR）

Argo CDをインストールすると、クラスター内に複数のCRDが作成されます。その中でも、オペレーターが必ず知っておくべき主要なリソースは以下の4つです。

① Application (最も重要！)

ユーザーが定義した「ソース（Git）」と「ターゲット（クラスター）」を接続する最小単位です。

• 役割: どのリポジトリのどのパスにあるマニフェストを、どのクラスターのどのネームスペースにデプロイするかを定義します。

② AppProject (論理グループ)

Applicationをまとめるガバナンスおよびセキュリティ境界です。

• 役割: マルチテナンシー環境において、チームごとにアクセス可能なリポジトリ、ターゲットクラスター、リソースの種類を制限します。

③ ApplicationSet (自動化の華)

複数のApplicationをパターンに基づいて動的に生成するテンプレートエンジンです。

• 役割: 「このアプリをすべてのリージョンにデプロイしてほしい」や「Gitのすべてのフォルダーをそれぞれアプリとして作成してほしい」といった要件を処理します。

④ ArgoCD (インスタンス管理)

Argo CDオペレーターを通じてインストールされた際に現れるリソースで、Argo CD自体の設定を担当します。

---

2. 🧬 リソース間の関係 (Relationship)

これらのリソースは独立して存在するのではなく、歯車のように連動して動作します。

• AppProject ↔ Application: すべてのApplicationは、必ず1つのAppProjectに属する必要があります。プロジェクトは親のような役割を果たし、子であるアプリの権限を制御します。
• ApplicationSet ↔ Application: ApplicationSetは一種の「たい焼きの型」です。設定されたGenerator（パターン）に従って、複数のApplicationリソースを自動的に生成します。
• Application ↔ Kubernetes Resources: Applicationが同期（Sync）されると、初めて実際のDeployment、Serviceのような標準Kubernetesリソースが作成されます。

---

3. 💻 実践コードと詳細説明

各リソースのYAML構造を見ながら、実務でどのように設定するかを見ていきましょう。

📜 AppProject: セキュリティと境界の設定

まず、アプリを格納する「器」であるプロジェクトを作成します。

YAML

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: platform-team-project
  namespace: argocd
spec:
  description: "플랫폼 팀 전용 프로젝트"
  # 1. 許可するGitリポジトリの制限 📦
  sourceRepos:
    - "https://github.com/my-org/platform-infra.git"
  # 2. デプロイ可能なターゲットクラスターとネームスペースを指定 🎯
  destinations:
    - server: "https://kubernetes.default.svc"
      namespace: "production-*"
  # 3. デプロイ可能なリソースの種類を制限 (セキュリティ強化) 🛡️
  clusterResourceWhitelist:
    - group: ""
      kind: Namespace

📜 Application: ソースとターゲットのマッピング

最も頻繁に使用することになるリソースです。

YAML

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook-app
  namespace: argocd
spec:
  # どのプロジェクトに属するかを指定 (上記で作成したプロジェクト)
  project: platform-team-project
  source:
    repoURL: "https://github.com/my-org/platform-infra.git"
    targetRevision: HEAD
    path: "guestbook" # Git内部パス
  destination:
    server: "https://kubernetes.default.svc"
    namespace: "production-apps"
  # 自動同期ポリシーの設定 🔄
  syncPolicy:
    automated:
      prune: true     # Gitから削除されたらクラスターからも削除
      selfHeal: true  # クラスターで手動修正された場合、元に戻す

📜 ApplicationSet: 大規模デプロイの自動化

複数のクラスターや複数のフォルダーを一度に管理する際に使用します。

YAML

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: microservices-set
  namespace: argocd
spec:
  # 1. 生成パターンを定義 (ここではListを使用) 📋
  generators:
    - list:
        elements:
          - cluster: engineering-dev
            url: https://1.2.3.4
          - cluster: engineering-prod
            url: https://5.6.7.8
  # 2. 実際に生成されるApplicationのテンプレート 🏗️
  template:
    metadata:
      name: '{{cluster}}-guestbook' # 変数置換
    spec:
      project: default
      source:
        repoURL: https://github.com/argoproj/argocd-example-apps.git
        targetRevision: HEAD
        path: guestbook
      destination:
        server: '{{url}}'
        namespace: guestbook

---

4. 🔍 深化：リソース間のライフサイクルと依存性

これまでに議論した内容に基づいて、実務で注意すべき点をまとめてみましょう。

1. Cascading Delete (カスケード削除): Applicationを削除する際に、実際にデプロイされたリソースも一緒に削除するかどうかを決定できます。finalizers設定を通じて制御します。
2. Project-level RBAC: AppProject内に定義されたRoleは、argocd-rbac-cmと連携し、特定のチームが自身のプロジェクトのみを閲覧できるようにします。
3. Status Sync: Application CR内部のstatusフィールドは、現在のGitとクラスター間の差異（Diff）とヘルス状態をリアルタイムで保存します。

---

📝 要約テーブル

リソース名	主要な役割	比喩
AppProject	権限制御、リソース制限	フェンス、管理区域
Application	1つのアプリのデプロイ定義	実際のデプロイ仕様書
ApplicationSet	動的/大量アプリ生成	たい焼きの型
ArgoCD	Argo CD設定制御	管制塔の設定

—

💡 終わりに

Argo CDのCR構造を理解することは、安定したGitOps運用への第一歩です。特にApplicationSetとAppProjectの関係をうまく設計すれば、数百ものマイクロサービスをわずか数行のコードで安全に管理できます。🎯

皆さんのクラスターにもこのような構造設計を適用して、より強固なインフラを構築してみてください！

---