Argo CD の概念 - Amazon EKS
Argo CD の使用を開始する重要な概念次のステップ

このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

Argo CD の概念

Argo CD は、Git をアプリケーションデプロイの信頼できる単一のソースとして扱うことで GitOps を実装します。このトピックでは、実践的な例を取り上げ、EKS Capability for Argo CD を使用する際に知っておくべきコアとなる概念について説明します。

Argo CD の使用を開始する

Argo CD 機能を作成したら (「Argo CD 機能を作成する」を参照)、アプリケーションのデプロイを開始できます。この例では、クラスターの登録と Application の作成を取り上げます。

ステップ 1: 設定

クラスターを登録する (必須)

アプリケーションのデプロイ先となるクラスターを登録します。この例では、Argo CD が実行されているのと同じクラスターを登録します (in-cluster という名前を使用すると、Argo CD のほとんどの例との互換性を維持できます)。

# Get your cluster ARN
CLUSTER_ARN=$(aws eks describe-cluster \
  --name my-cluster \
  --query 'cluster.arn' \
  --output text)

# Register the cluster using Argo CD CLI
argocd cluster add $CLUSTER_ARN \
  --aws-cluster-name $CLUSTER_ARN \
  --name in-cluster \
  --project default
注記

EKS で Argo CD 機能を使用するように Argo CD CLI を設定する方法については、「マネージド機能で Argo CD CLI を使用する」を参照してください。

あるいは、Kubernetes シークレットを使用してクラスターを登録します (詳細については、「ターゲットクラスターを登録する」を参照)。

リポジトリアクセスを設定する (任意)

この例では、パブリック GitHub リポジトリを使用しているため、リポジトリの設定は不要です。プライベートリポジトリの場合は、AWS Secrets Manager、CodeConnections、または Kubernetes シークレットを使用してアクセスを設定します (詳細については、「リポジトリアクセスを設定する」を参照)。

AWS サービス (ECR Helm チャート、CodeConnections、および CodeCommit) の場合、リポジトリを作成しなくても、Application リソースで直接参照できます。機能ロールには、IAM アクセス許可が必要です。詳細については、「リポジトリアクセスを設定する」を参照してください。

ステップ 2: アプリケーションの作成

my-app.yaml でこの Application マニフェストを作成します。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    name: in-cluster
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Application を適用します。

kubectl apply -f my-app.yaml

この Application を適用したら、Argo CD で次の手順を実行します。1. Git からクラスターにアプリケーションを同期します (初期デプロイ)。2. Git リポジトリに対する変更をモニタリングします。3. 今後変更があればクラスターに自動的に同期します。4. 目的の状態からのドリフトを検出して修正します。5. UI でヘルスステータスと同期履歴を提供します。

アプリケーションのステータスを表示します。

kubectl get application guestbook -n argocd

Argo CD CLI または Argo CD UI (クラスターの [機能] タブの EKS コンソールからアクセス可能) を使用して、アプリケーションを表示することもできます。

注記

マネージド機能で Argo CD CLI を使用する場合は、名前空間プレフィックス argocd app get argocd/guestbook を使用してアプリケーションを指定します。

注記

destination.name でクラスター名 (クラスターの登録時に使用した名前) を使用します。マネージド機能は、ローカルのクラスター内デフォルト (kubernetes.default.svc) をサポートしていません。

重要な概念

GitOps の原則とソースタイプ

Argo CD は、GitOps を実装しており、アプリケーションソースがデプロイの信頼できる単一のソースとなります。

  • 宣言型 - 目的の状態は、YAML マニフェスト、Helm チャート、または Kustomize オーバーレイを使用して宣言されます。

  • バージョン管理 - すべての変更が完全な監査証跡で追跡されます。

  • 自動 - Argo CD は、ソースを継続的にモニタリングし、変更を自動的に同期します。

  • 自己修復 - 目的のクラスター状態と実際のクラスター状態とのドリフトを検出して修正します。

サポートされているソースタイプ:

  • Git リポジトリ - GitHub、GitLab、Bitbucket、CodeCommit (HTTPS、SSH、または CodeConnections)

  • Helm レジストリ - HTTP レジストリ (https://aws.github.io/eks-charts など) および OCI レジストリ (public.ecr.aws など)

  • OCI イメージ - マニフェストまたは Helm チャートが含まれているコンテナイメージ (oci://registry-1.docker.io/user/my-app など)

この柔軟性により、組織のセキュリティ要件とコンプライアンス要件を満たすソースを選択できます。例えば、クラスターからの Git アクセスを制限する場合は、Helm チャートや OCI イメージに ECR を使用できます。

詳細は、Argo CD ドキュメントの「Application ソース」を参照してください。

同期と調整

Argo CD は、ソースとクラスターを継続的にモニタリングして、差分を検出して修正します。

  1. 変更がないかソースをポーリングします (デフォルト: 6 分ごと)。

  2. 目的の状態とクラスターの状態を比較します。

  3. アプリケーションを Synced または OutOfSync としてマークします。

  4. 変更を自動的に同期するか (設定されている場合)、手動による承認を待ちます。

  5. 同期後にリソースのヘルスをモニタリングします。

同期ウェーブは、注釈を使用してリソースの作成順序を制御します。

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "0"  # Default if not specified

リソースはウェーブ順に適用されます (先頭は -1 のような負の数値など、小さい数値です)。指定しない場合は、ウェーブ 0 がデフォルトになります。これにより、サービス (ウェーブ 1) の前にデプロイ (ウェーブ 0)、その前に名前空間 (ウェーブ -1) などの依存関係を作成できます。

自己修復は、手動による変更を自動的に元に戻します。

spec:
  syncPolicy:
    automated:
      selfHeal: true
注記

マネージド機能は、注釈ベース (ラベルベースではない) のリソース追跡を使用して、Kubernetes の規則やその他のツールとの互換性を高めます。

同期フェーズ、フック、高度なパターンの詳細については、Argo CD 同期のドキュメントを参照してください。

アプリケーションのヘルス

Argo CD は、アプリケーション内のすべてのリソースのヘルスをモニタリングします。

ヘルスステータス: * 正常 - すべてのリソースが想定どおりに動作している * 進行中 - リソースが作成中または更新中 * 低下 - 一部のリソースが正常でない (ポッドのクラッシュやジョブの失敗) * 中断 - アプリケーションが意図的に一時停止している * 欠落 - Git に定義されたリソースがクラスターに存在しない

よく使用される Kubernetes リソース (デプロイ、StatefulSet、ジョブなど) に対しては組み込みのヘルスチェックで対処し、CRD に対してはカスタムヘルスチェックをサポートしています。

アプリケーションのヘルスは、アプリケーションのすべてのリソースによって決まります。いずれかのリソースが Degraded であれば、アプリケーションも Degraded です。

詳細については、Argo CD ドキュメントの「リソースのヘルス」を参照してください。

マルチクラスターパターン

Argo CD は、主に 2 つのデプロイパターンをサポートしています。

ハブアンドスポーク - 複数のワークロードクラスターにデプロイする専用の管理クラスターで Argo CD を実行します。* 一元管理と可視性 * すべてのクラスターで一貫したポリシー * Argo CD インスタンスを 1 つ管理 * コントロールプレーンとワークロードとの明確な分離

クラスターあたり - 各クラスターで Argo CD を実行して、そのクラスターのアプリケーションのみを管理します。* クラスターの分離 (あるクラスターの障害が他のクラスターに影響を与えない) * シンプルなネットワーク (クラスター間の通信なし) * シンプルな初期セットアップ (クラスターの登録なし)

プラットフォームチームが多数のクラスターを管理する場合はハブアンドスポークを選択し、チームが独立している場合やクラスターを完全に分離する必要がある場合はクラスターあたりを選択します。

マルチクラスター設定の詳細については、「Argo CD に関する考慮事項」を参照してください。

プロジェクト

Project を使用すると、Application を論理的にグループ化して、アクセスコントロールを付与できます。

  • ソースの制限 - 使用できる Git リポジトリを制限します。

  • 送信先の制限 - ターゲットにできるクラスターと名前空間を制限します。

  • リソースの制限 - デプロイできる Kubernetes リソースタイプを制限します。

  • RBAC の統合 - Project を AWS アイデンティティセンターのユーザー ID とグループ ID にマッピングします。

Application は単一の Project に属します。指定しない場合は、default プロジェクトが使用されます。これにはデフォルトの制限はありません。本番稼働用の場合は、default プロジェクトを編集してアクセスを制限し、適切な制限で新しいプロジェクトを作成します。

Project の設定と RBAC パターンについては、「Argo CD アクセス許可を設定する」を参照してください。

同期オプション

よく使用されるオプションで同期動作をファインチューニングします。

  • CreateNamespace=true - 送信先名前空間を自動的に作成します。

  • ServerSideApply=true - サーバー側の適用機能を使用して的確に競合を解決します。

  • SkipDryRunOnMissingResource=true - CRD がまだ存在しない場合には、ドライランをスキップします (kro インスタンスに有用です)。

spec:
  syncPolicy:
    syncOptions:
    - CreateNamespace=true
    - ServerSideApply=true
    - SkipDryRunOnMissingResource=true

同期オプションの完全なリストについては、Argo CD 同期オプションのドキュメントを参照してください。

次のステップ