Azure Kubernetes Service (AKS) の Argo CD Extension の基本

AKS : Argo CD Extension 2026.08.09 - sou (08thse)

AKS : Argo CD Extension アジェンダ とは 2. 自前インストールとの違い 3. インストールとデプロイ 4. Drift Detection と Azure Portal 統合 5. Entra ID / Workload Identity 連携 6. まとめと参考情報 1. Argo CD extension 2 / 22

1. Argo CD extension とは Argo CD と GitOps のおさらい は Kubernetes 上で動作する GitOps 型の Continuous Delivery ツール Git リポジトリの定義を あるべき状態 (Desired State) として扱う クラスターの実状態と継続的に比較し、差分を検出 差分があれば同期 (Sync) して Git の状態に合わせる Pull 型アーキテクチャ クラスター内の Argo CD が Git を参照しに行く Push 型 (GitHub Actions / Azure Pipelines から API Server へ接続) とは逆向き Argo CD 3 / 22

• https://argo-cd.readthedocs.io/

1. Argo CD extension とは Argo CD extension for AKS 年5月に Public Preview として発表 Azure の Cluster Extension の1つとして Argo CD を導入する仕組み 対象は AKS と Azure Arc-enabled Kubernetes Extension type は Microsoft.ArgoCD 2026 重要な前提 内側で動いているのは 通常の Argo CD そのもの Azure 独自のデプロイエンジンではない 既存の Application / ApplicationSet の知識がそのまま通用する 4 / 22

2. 自前インストールとの違い Extension と自前構成の比較 項目 インストール方法 自前導入 Azure Cluster Extension Helm など Application / ApplicationSet 利用可能 利用可能 Microsoft Entra ID SSO Azure 統合あり 自分で構成 Workload Identity Azure 統合あり 自分で構成 バージョン・更新管理 Extension として管理 自分で管理 カスタマイズ性 Extension の範囲内 高い Azure Portal 統合 あり 基本なし Argo CD extension 5 / 22

2. 自前インストールとの違い 何がうれしいのか 大きいのは 「Argo CD のライフサイクルと Azure の ID 管理を Azure 側の仕組みに寄 せられること」 Extension を選ぶ理由 導入・バージョン追従の手間が減る Entra ID / Workload Identity 連携 Azure Portal から状態を確認できる 自前を選ぶ理由 を自由に調整したい 独自プラグインや特殊構成を入れたい Extension の対応バージョンに縛られ たくない Helm values 6 / 22

3. インストールとデプロイ 前提条件 クラスターは Managed Identity ベース Service Principal ベースの旧構成では利用できない 2. Microsoft.KubernetesConfiguration リソースプロバイダの登録 Cluster Extension 全般で必要 登録はサブスクリプション単位、 Registered になるまで待つ 1. AKS // 登録 $ az provider register --namespace Microsoft.KubernetesConfiguration // 確認 $ az provider show --namespace Microsoft.KubernetesConfiguration \ --query registrationState -o tsv 7 / 22

3. インストールとデプロイ Extension のインストール az k8s-extension create \ --resource-group $RESOURCE_GROUP_NAME \ --cluster-name $AKS_CLUSTER_NAME \ --cluster-type managedClusters \ --name argocd \ --extension-type Microsoft.ArgoCD \ --config "redis-ha.enabled=false" ポイント は HA 構成が標準 (ドキュメント上は 4 ノード必要) 検証用の小規模クラスターでは Pod が Pending になるため Redis HA を無効化 --cluster-type は AKS なら managedClusters , Arc なら connectedClusters Extension 8 / 22

3. インストールとデプロイ Kubernetes argocd 側の確認 名前空間に Argo CD のコンポーネント一式 が展開される Pod argocd-application-controller-0 argocd-applicationset-controller argocd-dex-server argocd-notifications-controller argocd-redis argocd-repo-server argocd-server CRD applications.argoproj.io applicationsets.argoproj.io appprojects.argoproj.io configsyncstatuses.aks...azure.com extensionconfigs.aks...azure.com argoproj.io 同じ 系は通常の Argo CD と aks.clusterconfig.azure.com Azure 管理レイヤーとの接点 系が 9 / 22

3. インストールとデプロイ デプロイ対象のマニフェスト Git リポジトリに配置する、ごく普通の Kubernetes マニフェスト リポジトリ構成 repository └── manifests ├── deployment.yaml └── service.yaml を 1 台起動する Deployment ClusterIP で公開する Service Azure 固有の記述は一切なし Nginx deployment.yaml ( 抜粋) spec: replicas: 1 template: spec: containers: - name: nginx image: nginx:stable ports: - containerPort: 80 10 / 22

3. インストールとデプロイ Application CRD で紐付ける apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: sample-app namespace: argocd spec: source: repoURL: <GIT_REPOSITORY_URL> targetRevision: main path: manifests destination: server: https://kubernetes.default.svc namespace: sample-app syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true 11 / 22

• https://kubernetes.default.svc

3. インストールとデプロイ Application の各設定 source どの Git のどこを見るか repoURL ブランチ) path (ディレクトリ) targetRevision ( destination どのクラスターの どの名前空間へ 自クラスターは https://kubernetes.default.s vc syncPolicy 自動 Sync prune : 削除も反映 selfHeal : 手動変更を戻す automated : CreateNamespace=true : 名前空間を自動作成 12 / 22

• https://kubernetes.default.s

3. インストールとデプロイ デプロイ結果 kubectl apply した直後から Argo CD が Git を読み、リソースが自動的に作られる NAME sample-app SYNC STATUS Synced HEALTH STATUS Healthy NAME pod/sample-app-5f5c89b95d-64ppj READY 1/1 NAME service/sample-app PORT(S) 80/TCP TYPE ClusterIP STATUS Running とクラスターに差分がない Healthy: ワークロードが正常 sample-app 名前空間は CreateNamespace=true により自動作成 Synced: Git 13 / 22

4. Drift Detection と Azure Portal 統合 Drift Detection と Self Heal を経由しない手動変更 (＝ 構成ドリフト) を検知して自動で戻すかを検証 1. Git の定義: replicas: 1 が Desired State、Application は Synced 2. 手動で変更: kubectl scale で replicas: 3 に変更、Pod が 3 つに 3. 差分を検知: Argo CD が OutOfSync を検出 4. 自動で復帰: selfHeal が働き replicas: 1 に戻る Extension 版でも通常の Argo CD と同じ挙動 Git 14 / 22

4. Drift Detection と Azure Portal 統合 Self Heal が意味すること クラスターの構成が Git に一元化される 手作業での場当たり的な変更が残らない 障害復旧・再構築が容易 Git が唯一の正となるため、同じ状態を何度でも再現できる 運用上の注意 緊急対応で手動スケールしても戻される 恒久的な変更は必ず Git 側を直す運用にそろえる 15 / 22

4. Drift Detection と Azure Portal 統合 Azure Portal AKS 統合 リソースの GitOps メニュー から Argo CD を有効化・確認できる Portal でできること メニューからの有効化 登録された Application の一覧表示 Sync Status / Health Status の確認 GitOps Helm で自前導入した場合との違い の や認証情報を知ら だけで状態を Argo CD UI URL Azure Portal なくても、 確認できる Sync の手動実行や差分の詳細確認は 確認不可 Portal は 俯瞰・確認用 と割り切るの が現実的 16 / 22

5. Entra ID / Workload Identity Azure 連携 の ID 基盤との統合 インストールが楽になること以上に、Azure の ID 基盤とつながること が Extension の 価値 Microsoft Entra ID SSO Workload Identity Federation ユーザーが Argo CD UI にアクセスす Argo CD が Azure リソースへアクセス る際の認証 する際の認証 ローカルユーザー運用からの脱却 Private ACR からの取得などが簡潔に グループ単位で RBAC を設計 Secret の配布・ローテーションが不要 入退社の棚卸しを ID 基盤側に一本化 注意: Extension を入れれば自動で完成するものではなく、設計・構成は別途必要 17 / 22

5. Entra ID / Workload Identity 連携 従来の Flux v2 extension との関係 AKS の GitOps 拡張としては Flux v2 extension が先行 Flux v2 が置き換わるわけではない リポジトリ / Kustomization 中心のモデルで宣言的な構成管理に強い Argo CD extension を選ぶ判断基準 組織で既に Argo CD を標準化 している Application / ApplicationSet でマルチクラスター・マルチ環境を束ねたい Web UI での状態確認 を含めた運用フローを重視する 18 / 22

6. まとめと参考情報 まとめ 導入はシンプル で Argo CD 一式を展開 Helm values の管理もバージョン追従も Azure 側に預けられる az k8s-extension create ただし「Managed Argo CD」ではない 「すべてを Azure が管理してくれるサービス」ではない Application 設計・Git 構成・デプロイ戦略は利用者の責任範囲のまま 19 / 22

6. まとめと参考情報 本番導入前に検討すべきこと 構成 検証では redis-ha.enabled=false 、本番はノード数を確保して HA を有効に 2. 認証・認可 Entra ID SSO と Argo CD RBAC のマッピング、Workload Identity の構成 3. 公開方法とリポジトリ Argo CD UI の公開方法とアクセス制御、Private Repository のアクセス設定 4. Public Preview 前提 GA までのバージョンアップ・構成方法の変更に追従する必要がある 1. HA 20 / 22

6. まとめと参考情報 参考情報 AKS の Argo CD Extension を試してみた (Zenn) Argo CD extension for AKS and Azure Arc-enabled Kubernetes Argo CD Documentation Azure Workload Identity GitOps Flux v2 extension の概要 21 / 22

• https://zenn.dev/08thse/articles/121-aks-argo-extension-pv
• https://learn.microsoft.com/azure/aks/
• https://argo-cd.readthedocs.io/
• https://learn.microsoft.com/azure/aks/workload-identity-overview
• https://learn.microsoft.com/azure/azure-arc/kubernetes/conceptual-gitops-flux2

ありがとうございました！