複数のクラスターにまたがってアプリケーションを管理する場合、各クラスターごとに個別の Argo CD Application リソースを別々に維持するのは、エラーが発生しやすく、スケールも困難です。ACK One のマルチクラスター GitOps 機能では、Argo CD ApplicationSet を活用してこの課題を解決します。1 つのアプリケーションセットテンプレートにより、対象となる各クラスターに対して自動的に 1 つの Argo CD Application が生成されるため、単一のコミットで同時にすべてのクラスターへ変更を適用できます。
本トピックでは、ACK One コンソールでマルチクラスター アプリケーションを作成する手順について説明します。
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
フリート管理が有効
複数のクラスターが フリートインスタンスに関連付けられていること
マルチクラスター アプリケーションの作成
ACK One コンソール にログインします。左側のナビゲーションウィンドウで、フリート > マルチクラスター GitOps を選択します。
マルチクラスター GitOps ページの左上隅にあるフリート名の横の
アイコンをクリックし、ドロップダウンリストから対象のフリートを選択します。マルチクラスター アプリケーションの作成 > GitOps をクリックして、マルチクラスター アプリケーションの作成 - GitOps ページを開きます。
［Quick Create］タブで、次のパラメーターを設定します。［Advanced Configuration］で、同期ポリシーを設定します。［Automatic］が選択されている場合、次のオプションを有効にできます。同期操作では、次のオプションを利用できます。同期オプションの完全なリファレンスについては、「Argo CD 同期オプション」をご参照ください。
パラメーター 説明 例 マルチクラスター アプリケーションセット名 アプリケーションセットの名前です。 appset-echo-server-demoプロジェクト アプリケーションセットが属する Argo CD プロジェクトです。 defaultソースコード URL アプリケーションマニフェストを含む Git リポジトリの URL です。 https://github.com/AliyunContainerService/gitops-demo.gitGit ブランチ リポジトリ内でトラックするブランチです。 mainパス リポジトリ内のアプリケーションマニフェストへのパスです。YAML ファイルのディレクトリ、Helm チャートのルート、または Kustomize ディレクトリを指定できます。 manifests/helm/echo-server送信先クラスター アプリケーションをデプロイするクラスターです。空欄のままにした場合、Argo CD に登録されたすべてのクラスター（フリートおよび Argo CD が実行されるインクラスターよりも除く）が送信先クラスターとして使用されます。 — 名前空間 アプリケーションがデプロイされる各送信先クラスター内の名前空間です。 demoアプリケーション名 生成される各 Argo CD Application の名前テンプレートです。デフォルトで利用可能な変数は以下のとおりです： {{.name}}、{{.metadata.annotations.cluster_name}}、および{{.metadata.annotations.cluster_id}}。{{.metadata.annotations.cluster_id}}-echoserver同期ポリシー（ApplicationSet）
オプション 説明 削除時にリソースを保持 選択すると、このアプリケーションセットによって作成された子リソースは、アプリケーションセットが削除されても保持されます。アプリケーションセットの誤削除によるワークロードへの影響を防ぐために選択します。 同期ポリシー（Application）
オプション 説明 手動 同期は、手動で実行を指示した場合のみトリガーされます。 自動 Git リポジトリとライブクラスターの状態に差分がある場合、Argo CD が自動的にアプリケーションを同期します。 オプション 説明 リソースの削除（Prune） デフォルトでは、Argo CD は Git に存在しないリソースを削除しません。これは、意図しないデータ損失を防ぐための安全機構です。有効化すると、Git リポジトリから削除されたリソースがクラスターから自動的に削除されます。クラスターの状態を Git に完全に依存させる場合にのみ有効化してください。 自己修復（Self Heal） デフォルトでは、ライブクラスターのリソースに対する手動変更は自動同期をトリガーしません。有効化すると、ライブクラスターのリソースに対するアウトオブバンド変更が検出されると、Git に定義された望ましい状態に自動的に復元されます。クラスターへの直接変更による構成ドリフトを防止するために有効化します。 オプション 説明 スキーマ検証のスキップ 適用前に Kubernetes リソース仕様の検証をスキップします。kubectl apply --validate=true|false と同等です。デフォルトで有効です。 名前空間の自動作成 クラスター内にターゲット名前空間が存在しない場合、自動的に作成します。 最後に削除（Prune Last） 他のすべてのリソースがデプロイされ、正常な状態になってから削除対象のリソースを削除するため、同期中のダウンタイムリスクを低減します。 同期外のみ適用（Apply Out of Sync Only） OutOfSync状態のリソースのみを同期するため、ほとんどのリソースが既に同期済みの場合に同期操作を高速化できます。無視する差分の尊重（Respect Ignore Differences） 同期時に、 ignoreDifferences構成で指定されたフィールドを無視し、これらのフィールドが上書きされないようにします。サーバー側適用（Server-Side Apply） デフォルトのクライアント側適用ではなく、Kubernetes のサーバー側適用を使用します。リソースが許容されるアノテーションサイズを超える場合、Argo CD で完全に管理されていないリソースをパッチする場合、または宣言的なフィールド管理を希望する場合に使用します。 置き換え kubectl replace（削除後再作成）を、kubectl apply（パッチ）の代わりに使用します。immutable フィールドなど、applyでは対応できない場合にのみ使用します。再試行 失敗した同期操作を再試行します。再試行回数、再試行間隔、およびバックオフポリシーを設定できます。 クイック作成 では要件を満たさない場合、YAML からの作成 タブを選択し、ApplicationSet YAML を直接編集します。
クイック作成 と YAML からの作成 は同期されています。いずれかのタブで行った変更は、もう一方のタブにも反映されます。
OK をクリックします。アプリケーションセットが作成され、各生成アプリケーションのステータスが ステータス 列に表示されます（マルチクラスター GitOps ページ）。
生成されたアプリケーションを確認するには、アプリケーションセット名の横にある アプリケーション 列の数字をクリックします。このアプリケーションセットから作成されたすべてのアプリケーションのまとめが表示されます。その後、アプリケーション名 をクリックして、該当アプリケーションの Argo CD UI を開きます。
