AWS Container本番運用Vol4｜EKS Capabilities(managed Argo CD/ACK/kro)

1. この記事について — EKS Capabilities で運用ツールを AWS にオフロードする

1-1. 本記事のゴール

EKS Capabilities の managed Argo CD・ACK・kro を本番ワークロードで有効化し、GitOps 継続的デプロイ・AWS リソースの宣言的管理・複雑な構成の抽象化を、運用ツール自体の保守作業なしに実現できる状態を到達点とします。self-managed(Vol2)との構成上の違いを理解し、どちらを選ぶべきかを「運用負荷を誰が負うか」という一貫した基準で判断できることに主眼を置きます。有効化手順そのものよりも、self-managed からの移行判断と IAM 設計・監視・コスト最適化までを実装観点で扱います。

本記事を読み終えた時点で、次の判断・実装ができる状態を目指します。

• self-managed(Vol2)と EKS Capability のどちらを採用すべきか、要件(カスタマイズ自由度 vs 運用負荷軽減)に照らして判断できます
• managed Argo CD・ACK・kro それぞれの capability を有効化し、IAM Capability Role を最小権限で設計できます
• 既存の self-managed Argo CD 資産を EKS Capability へ段階的に移行する手順を把握できます
• capability の監視・コスト・セキュリティ運用における注意点を、self-managed との違いを踏まえて説明できます
• ACK・kro を組み合わせて、プラットフォームチームが提供する高レベル API のプロトタイプを設計できます

1-2. 読者像

Vol2 で self-managed Argo CD を Helm でインストールし、App-of-Apps や Argo Rollouts による GitOps パイプラインを本番運用している、あるいは Vol3 で Pod Identity・Karpenter による EKS 縦深化を実施済みで、次に運用ツール自体のアップグレード・可用性確保・パッチ適用にかかる工数を軽減したいプラットフォームエンジニア・SRE を主な読者として想定しています。Argo CD の GitOps 概念(Application/Sync Policy 等)や IAM の基礎知識は前提とし、本記事では managed 化によって何が変わり、何が変わらないかに焦点を当てます。

1-3. 本シリーズの位置づけと既存記事との棲み分け

Container 本番運用シリーズは Vol1(ECS × Fargate × ECR 基礎)・Vol2(EKS × self-managed Argo CD × Kustomize × Argo Rollouts の GitOps 編)・Vol3(EKS Pod Identity × Karpenter × Service Connect の縦深化編)と積み上がってきました。本 Vol4 はこの延長線上で、Vol2 で導入した Argo CD を含む運用ツール群を「誰が保守するか」という軸で再考する内容です。

Vol2 は self-managed Argo CD の運用ノウハウ(App-of-Apps・ApplicationSet・Sync Policy・RBAC・SSO・Drift Detection)を扱っており、これらの詳細は本記事では再解説せず Vol2 へのクロスリンクに委譲します。本 Vol4 が主題とするのは、Argo CD・ACK・kro を EKS Capabilities として有効化した場合に自前運用から何がオフロードされ、何が制約として残るかという managed 化特有の論点であり、self-managed から managed への移行設計と、ACK・kro を組み合わせたプラットフォーム基盤の構築に主眼を置きます。AWS 公式も「EKS Capability for Argo CD と self-managed Argo CD の比較」ドキュメントを個別に用意しており、この差分が実務上重要な判断軸であることを裏付けています。Pod Identity・Karpenter による Node/権限管理の縦深化(Vol3)は本記事の対象外とし、必要な箇所でのみ Vol3 へ接続します。

本記事が扱わない範囲も明確にしておきます。self-managed Argo CD のインストール手順・Kustomize によるマニフェスト管理・Argo Rollouts のカナリアデプロイ詳細は Vol2 の担当範囲であり、本記事では前提知識として扱います。Pod Identity の Association 管理や Karpenter の NodePool 設計も Vol3 の担当範囲とし、本記事の IAM 設計・監視の章では概念面の言及に留めます。

関連：Container Vol2 (self-managed Argo CD・Kustomize・Argo Rollouts) を読む

2. 前提 — EKS Capabilities の全体像・アーキテクチャ・提供状況

2-1. EKS Capabilities とは — 3 つの capability と service-owned アーキテクチャ

EKS Capabilities は、Argo CD・ACK・kro といった運用ソフトウェアのライフサイクル(インストール・設定・パッチ適用・バージョン整合)を AWS が管理する機能です。2025年11月30日に AWS 公式ブログ(Announcing Amazon EKS Capabilities for workload orchestration and cloud resource management)および What’s New で発表され、ローンチ時点で 3 種類の capability が提供されています。

本記事では、AWS が管理する範囲・顧客が管理する範囲を明確に区別しながら解説します。従来の in-cluster 構成では「クラスターで動くものはすべて顧客の責任範囲」という前提が成り立っていましたが、EKS Capabilities の導入によりこの前提が capability の種類ごとに変わります。以降の §3〜§5 では、各 capability を有効化する際に顧客側が設計すべき項目(IAM 権限・Kubernetes RBAC・Git リポジトリ接続方式)を具体的に扱います。

AWS 公式ブログでは、Argo CD が 2024年 CNCF Survey で 45% 超の Kubernetes ユーザーから本番利用・利用予定と回答されるほど広く普及しているツールである点に触れており、その普及度の高さを今回 Argo CD を capability の第一弾に選定した背景として説明しています。ACK・kro についても、いずれも CNCF/OSS エコシステムで実績のあるツールを AWS がマネージド化したものであり、ゼロから AWS 独自ツールを学び直す必要がない点も採用のハードルを下げています。既存の Argo CD マニフェストや ACK カスタムリソースの知識をそのまま活かせる設計であることが、self-managed からの移行判断(§6)を後押しする材料にもなります。

従来、これらのツールは Helm チャートなどで顧客の EKS クラスター内(Worker Node 上)にインストールし、顧客自身がアップグレード・可用性確保・スケーリングを担う「in-cluster」構成が一般的でした。EKS Capabilities はこの構成を根本から変えます。capability は顧客クラスターではなく EKS の service-owned account で稼働し、顧客からは完全に抽象化されます。顧客が操作するのは kubectl で適用する Kubernetes カスタムリソース(Application・ACK の各種リソース・kro の ResourceGraphDefinition)のみであり、実行基盤のパッチ適用・スケーリング・可用性確保は AWS 側の責任範囲になります。この「誰が運用ソフトウェアの面倒を見るか」という違いが、self-managed との根本的な差分です。

capability の作成は、AWS リソースとしてのライフサイクルを持ちます。capability リソースを作成すると、まず EKS コントロールプレーン側に capability サービスが立ち上がり、続いてクラスターに必要な Custom Resource Definition (CRD) がインストールされます。同時に、指定した Capability Role に対する EKS アクセスエントリが自動作成され、capability が稼働に必要な最低限の Kubernetes 権限を得ます。この一連の処理が完了すると、capability のステータスは CREATING から ACTIVE に遷移し、以降は通常の Kubernetes カスタムリソースとして利用できる状態になります。

3 つの capability は互いに独立しており、個別に有効化・無効化できます。Argo CD だけを先行導入し、後から ACK・kro を追加するといった段階的な採用も可能です。ただし、同一クラスターに同じ種類の capability を複数作成できません(例: Argo CD capability は 1 クラスターにつき 1 つ)。3 capability を組み合わせた場合の典型的な使い方は、Argo CD が Git から Application をデプロイし、ACK がそのアプリケーションに必要な RDS・S3 などの AWS リソースを宣言的にプロビジョニングし、kro が両者を束ねた「WebApplication」のような高レベル API をプラットフォームチームが提供するという構成です。開発チームは kro が提供する API に沿ったマニフェストを適用するだけで、背後の AWS リソースや Argo CD Application の詳細を意識せずにアプリケーションを展開できます。

capability は顧客クラスターの Worker Node ではなく AWS 側の基盤で稼働するため、in-cluster に Argo CD や ACK controller をインストールする場合と異なり、クラスターの CPU・メモリリソースを消費しません。これはクラスター容量をワークロード用に確保できるという副次的な利点であり、Vol3 で扱った Karpenter によるコスト最適化とも相性がよい構成です(運用ツール自体のリソース分だけ Node を余分に確保する必要がなくなります)。

AWS 公式ドキュメントでは、EKS Capabilities の代表的な利用パターンとして次のような構成が紹介されています。

これらのパターンはいずれも self-managed 構成でも実現できますが、EKS Capabilities を使うことで運用ツール自体のライフサイクル管理を AWS に委ねながら実装できる点が異なります。

2-2. self-managed(Vol2)との比較 — 運用負荷の主体

Vol2 で扱った self-managed Argo CD は、ユーザー自身が Helm でクラスターにインストールし、アップグレード・HA構成・認証方式(argocd-rbac-cm によるロール管理)をすべて自前で設計・運用する構成でした。EKS Capability for Argo CD はこれと対極にあり、AWS 公式の比較ドキュメント(Comparing EKS Capability for Argo CD to self-managed Argo CD)でも、両者の違いが運用負荷の所在という観点で整理されています。

自由な拡張性やカスタム SSO・独自ヘルスチェックが必要な場合は self-managed(Vol2)が適し、運用ソフトウェア自体の保守作業をなくしたい場合は managed(本 Vol4)が適するというのが基本的な選定基準になります。両者は排他ではなく、既存の self-managed 資産を段階的に managed へ移行する構成(§6 で解説)も可能です。

managed 化によって非対応となる機能は、実務上見落としやすい落とし穴になります。具体的には Config Management Plugin (CMP) によるカスタムマニフェスト生成、リソースのヘルス判定をカスタマイズする Lua スクリプト(標準リソース向けの組み込みヘルスチェックは利用可能)、Notifications controller、AWS Identity Center 以外の SSO プロバイダー、UI 拡張・カスタムバナー、argocd-cm/argocd-params 等の設定 ConfigMap への直接アクセス、Sync timeout のカスタマイズ(120 秒固定)が非対応になります。一方で Application・ApplicationSet の仕様や kubectl での操作方法は upstream Argo CD と完全互換であり、既存のマニフェストを変更せずに移行できます。

マルチクラスター構成における運用負荷の違いも顕著です。self-managed では、Argo CD からリモートクラスターへアクセスするために IRSA(または Pod Identity)の設定やクロスアカウントの IAM ロール引き受けを自前で構成する必要があります。EKS Capability for Argo CD は EKS アクセスエントリを使ってこれを代替し、IRSA の設定なしにリモートクラスターへのアクセスを許可できます。さらに、完全プライベートな EKS クラスターに対しても VPC ピアリングや特殊なネットワーク設定なしに透過的にアクセスできるよう AWS 側が接続性を管理します。この点は Vol3 で解説した Pod Identity による権限管理の思想(OIDC Provider の個別管理を不要にする)と方向性が近く、EKS Capabilities がプラットフォーム全体で権限管理の簡素化を進めている流れの一部と捉えられます。

2-3. 有効化の前提・IAM・提供状況

EKS Capabilities は、AWS が EKS を提供する全ての商用リージョンで利用できます(AWS GovCloud (US) および中国リージョンを除く)。東京リージョン(ap-northeast-1)を含め、日本国内から利用する既存の EKS クラスターでもそのまま有効化できます。対応 Kubernetes バージョンは、EKS がサポートする全バージョン(標準サポート・拡張サポートの両方)が対象であり、Vol2/Vol3 で運用中のクラスターバージョンであれば追加のアップグレードなしに capability を作成できます。

有効化には次の前提を満たす必要があります。

• 稼働中の Amazon EKS クラスター(サポート対象バージョン)
• AWS Identity Center の設定(Argo CD capability の認証に必須。ローカルユーザーには非対応)
• capability 用の IAM ロール(以下「Capability Role」)。Git リポジトリアクセスや Secrets Manager 参照など、capability がアクセスできる AWS リソースの範囲を最小権限で定義します
• capability リソースを作成する IAM 権限
• kubectl(クラスターとの疎通用)

有効化は AWS Management Console・AWS CLI・eksctl のいずれからも実行でき、capability を作成すると EKS が自動的に Capability Role へのアクセスエントリを作成し、必要な Custom Resource Definition (CRD) をクラスターに投入します。課金は前払いなしの従量課金で、capability リソースが有効な時間に対して時間単位で発生し、capability が管理する Kubernetes リソースにも別途料金がかかります。

Capability Role の設計は、EKS Capabilities の IAM 設計における最重要ポイントです。ただし、必要な IAM 権限の量は capability の種類によって大きく異なる点に注意が必要です。

capability を作成すると、EKS は Capability Role に対して種類ごとに異なるデフォルトのアクセスエントリポリシー(AmazonEKSKROPolicy・AmazonEKSACKPolicy・AmazonEKSArgoCDPolicy 等)を自動付与し、Kubernetes 側の基本権限を確保します。ACK が Secrets Manager 由来の認証情報(RDS パスワード等)を参照する場合や、kro が任意のリソースを作成できるようにする場合は、これらのデフォルトポリシーに加えて AmazonEKSSecretReaderPolicy などの追加ポリシーや Kubernetes RBAC のロールバインディングを個別に付与する必要があります。self-managed 環境で Git 認証情報や Helm レジストリの認証情報を Kubernetes Secret として個別管理していた場合と比べると、認証情報の管理対象自体は減りますが、Capability Role の権限範囲とアクセスエントリの設定がそのままセキュリティ境界になるため、最小権限の設計はむしろ重要度が増します(具体的な設計パターンは §7 で扱います)。

capability の状態は AWS CLI からも確認できます。

aws eks describe-capability \
  --cluster-name {{my-cluster}} \
  --capability-name {{my-argocd}} \
  --region ap-northeast-1

capability.status が ACTIVE であることを確認してから Application 等のカスタムリソースを適用する運用にすると、CRD 未投入のタイミングでの適用エラーを避けられます。

有効化の前提・提供状況を一覧化すると次の通りです。

capability に対する操作(作成・更新・削除)は、すべて AWS CloudTrail に記録されます。誰がいつ Capability Role の設定を変更したかを追跡できるため、self-managed 構成で Kubernetes の Audit Log だけを頼りに追跡していた場合と比べて、監査の起点を一本化しやすくなります。Argo CD capability の API サーバーはデフォルトで公開エンドポイントを持ちますが、VPC エンドポイントを関連付けることで VPC 内から Argo CD の Web UI・API(CLI 含む)へプライベートに接続する構成にも変更できます。また、完全にプライベートな EKS クラスターへも VPC ピアリングなしにデプロイできる一方、Argo CD が Git リポジトリ(公開リポジトリを含む)から設定を取得してプライベートクラスターへ適用する経路自体はセキュリティ境界になるため、機微なワークロードには private リポジトリと Pull Request ベースのレビュー運用を組み合わせることが推奨されています。

★正式名称について、kro は「Kube Resource Orchestrator」の略称であり、「Kubernetes Resource Orchestrator」ではない点に注意が必要です。AWS 公式ドキュメントでも製品名は小文字表記の “kro” で統一されています。以降の章でもこの正式名称・表記に統一して解説します。

以降の §3〜§8 では、本節で整理した前提を踏まえて次の流れで解説を進めます。

3. managed Argo CD capability の本番運用

3-1. capability の作成 — Capability Role と Identity Center が前提

managed Argo CD capability を有効化する前提は §2-3 で整理した通り、稼働中の EKS クラスター・AWS Identity Center の設定・capability 用の IAM Capability Role の 3 点です。Argo CD の場合、Capability Role には既定では IAM ポリシーのアタッチが不要で、Git リポジトリ認証を Secrets Manager や CodeConnections で行う場合、あるいは ECR 上の Helm チャートを参照する場合にのみ、該当するポリシーを追加します。

capability は AWS Management Console・AWS CLI・eksctl のいずれからも作成できます。作成が完了するまでの内部処理は次の順に進みます。

1. EKS コントロールプレーン側に Argo CD capability サービスが起動する
2. クラスターに Argo CD の Custom Resource Definition(Application・ApplicationSet・AppProject)がインストールされる
3. 指定した Capability Role に対して EKS アクセスエントリが自動作成され、capability 稼働に必要な最低限の Kubernetes 権限が付与される
4. Argo CD がこれらのカスタムリソースの監視を開始する
5. capability のステータスが CREATING から ACTIVE へ遷移し、Argo CD の UI が URL 経由でアクセス可能になる

ここで重要なのは、この自動作成されるアクセスエントリには アプリケーションをデプロイする権限は含まれないという点です。Argo CD が実際にワークロードを展開するには、デプロイ先クラスターごとに Kubernetes RBAC 権限を別途設定する必要があります。self-managed(Vol2)では Argo CD 自身の ServiceAccount に対する RBAC 設定として意識していた作業が、managed では「capability の Capability Role に対する EKS アクセスエントリ + RBAC バインディング」という形に置き換わります。

3-2. デプロイ先クラスターの登録 — in-cluster も明示登録が必要

self-managed Argo CD では、Argo CD をインストールしたクラスター自身(in-cluster)へのデプロイは既定で有効になっていました。managed capability ではこの前提が変わり、同一クラスターへのデプロイであっても明示的な登録が必要です。

apiVersion: v1
kind: Secret
metadata:
  name: local-cluster
  namespace: argocd
  labels:
 argocd.argoproj.io/secret-type: cluster
stringData:
  name: local-cluster
  server: arn:aws:eks:ap-northeast-1:{{account-id}}:cluster/{{my-cluster}}
  project: default

登録時の server フィールドには Kubernetes API サーバー URL ではなく EKS クラスターの ARN を指定します。self-managed の設定ファイルをそのまま流用しようとして kubernetes.default.svc を指定すると失敗するため、移行時に見落としやすい差分です。

リモートクラスター(マルチクラスター構成)へのデプロイでは、対象クラスター側で Argo CD の Capability Role を principal としたアクセスエントリを作成し、アクセスポリシーを関連付けます。

aws eks create-access-entry \
  --region ap-northeast-1 \
  --cluster-name {{remote-cluster}} \
  --principal-arn arn:aws:iam::{{account-id}}:role/ArgoCDCapabilityRole \
  --type STANDARD

aws eks associate-access-policy \
  --region ap-northeast-1 \
  --cluster-name {{remote-cluster}} \
  --principal-arn arn:aws:iam::{{account-id}}:role/ArgoCDCapabilityRole \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

AmazonEKSClusterAdminPolicy は system:masters 相当のフル権限を付与するため検証用途に限り、本番では namespace 単位の RBAC(読み取りはクラスター全体、書き込みはデプロイ先 namespace のみ)に絞り込むのが AWS 公式の推奨です。self-managed で IRSA・クロスアカウント IAM ロールの引き受けを自前構成していたクロスアカウント/クロスリージョンのマルチクラスター運用も、EKS アクセスエントリへの登録だけで完結し、追加の信頼ポリシーは不要になります。完全プライベートな EKS クラスターに対しても VPC ピアリングなしで透過的にアクセスできる点は §2-3 で述べた通りです。

3-3. GitOps 継続的デプロイの運用差分 — アップグレード不要・可用性は AWS 管理

Application リソースの Spec(source/destination/syncPolicy)自体は upstream Argo CD と完全互換であり、Vol2 で運用しているマニフェストをそのまま流用できます。managed 特有の差分は、Application の書き方ではなく capability 自体の運用オペレーションに現れます。

継続的デプロイの運用では、自動 Sync(syncPolicy.automated)・自己修復(selfHeal: true)・Prune の組み合わせは self-managed と同じ考え方が通用します。ただし SkipDryRunOnMissingResource=true のような sync option は、後述する ACK・kro のカスタムリソース(CRD がまだクラスターに存在しないタイミングでの適用)と組み合わせる場面で特に有効に働くため、managed 構成ではこのオプションを既定で有効にしておくケースが増えます。

spec:
  syncPolicy:
 automated:
prune: true
selfHeal: true
 syncOptions:
 - CreateNamespace=true
 - SkipDryRunOnMissingResource=true

App-of-Apps・ApplicationSet・Sync Policy の詳細な設計パターンおよび RBAC 設計そのものは Vol2 で確立済みのため、本節では再解説しません。

関連：Container Vol2 (self-managed Argo CD の App-of-Apps・RBAC 設計) を読む

4. ACK(AWS Controllers for Kubernetes)の本番運用

4-1. ACK の仕組み — Kubernetes カスタムリソースを AWS API 呼び出しに変換する

ACK は、Kubernetes のカスタムリソースの仕様を AWS API 呼び出しに変換するコントローラです。管理対象の AWS サービスごとに専用の CRD が用意されており、たとえば S3 であればバケットやバケットポリシーを表す CRD が提供されます。

apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: my-ack-bucket
spec:
  name: {{my-unique-bucket-name}}

このマニフェストを kubectl apply すると、ACK はアカウント内に S3 バケットが存在しなければ作成し、以降 Kubernetes リソースへの変更(ストレージクラスの指定・ポリシー追加等)を AWS 側の S3 リソースへ反映します。Kubernetes リソースを削除すると、既定では対応する AWS リソースも削除されます(削除ポリシーは後述)。

ACK は Kubernetes リソースの Desired State と AWS リソースの実際の状態を継続的に照合(reconcile)します。Kubernetes 側への変更は即座に AWS リソースへ反映される一方、AWS 側で加えられた変更(コンソール操作等によるドリフト)を検知して補正するまでには最大 10 時間程度(resync 周期)を要する場合があります(実際にはこれより早く検知されることが多い)。EKS Capability としての ACK は S3・RDS・DynamoDB を含む 50 以上の AWS サービスをサポートしており、upstream で GA 済みのサービスは基本的に EKS Capability for ACK でも利用できます。

4-2. IAM 権限設計 — Capability Role 直接付与 vs IAM Role Selector

ACK は infrastructure management capability であり、AWS リソースの作成・変更・削除を行える admin スコープの権限を持ちます。クラスターに Kubernetes リソースを作成できるユーザーは、Capability Role の権限範囲内で事実上 AWS リソースを作成できることになるため、IAM 権限設計は ACK の運用における最重要ポイントです。

権限の与え方には 2 通りあります。

① Capability Role への直接付与(開発・検証向け)

単一アカウント・単一チームで完結する検証環境では、Capability Role に必要な IAM ポリシーを直接アタッチする方式が最も簡単です。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": "*",
"Condition": {
  "StringEquals": { "aws:RequestedRegion": ["ap-northeast-1"] }
}
 }
  ]
}

② IAM Role Selector による namespace 単位の権限分離(本番向け)

本番運用では、namespace ごとに異なる IAM ロールをマッピングする IAM Role Selector を使います。Capability Role には sts:AssumeRole/sts:TagSession の権限のみを与え、実際の AWS サービス権限はサービス別ロールに委譲します。

apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
  name: s3-namespace-config
spec:
  arn: arn:aws:iam::{{account-id}}:role/ACK-S3-Role
  namespaceSelector:
 names:
- s3-resources

この方式により、s3-resources namespace に作成されたリソースは自動的に ACK-S3-Role を引き受けて実行されます。クロスアカウントで AWS リソースを管理する場合も、対象アカウント側に Capability Role を信頼するロールを用意し、IAM Role Selector で namespace にマッピングするだけで済み、追加の信頼ポリシー設計は不要です。チーム分離・最小権限・監査のしやすさの観点から、複数チームが同一クラスターで ACK を利用する構成では IAM Role Selector が事実上必須になります。

EKS Capability for ACK は、すべての AWS API 呼び出しに eks:eks-capability-arn・eks:kubernetes-namespace・eks:kubernetes-api-group のセッションタグを自動付与します。これは self-managed ACK にはない差分で、IAM ポリシーの Condition でこれらのタグを参照することで、namespace 単位のアクセス制御をさらに厳格化できます。

{
  "Effect": "Allow",
  "Action": "s3:CreateBucket",
  "Resource": "*",
  "Condition": {
 "StringEquals": { "aws:PrincipalTag/eks:kubernetes-namespace": "production" }
  }
}

4-3. GitOps との統合パターン — Argo CD からの ACK リソースデプロイ

ACK は Git 連携を必須としませんが、managed Argo CD capability(§3)と組み合わせることで、アプリケーションマニフェストと ACK カスタムリソースを同じ Git リポジトリで一元管理する GitOps ワークフローが成立します。ACK リソースをアプリケーションマニフェストと同じ Application(または隣接する Application)で管理し、syncPolicy.automated.prune: true を有効にしておくと、Git から削除された ACK リソースに対応する AWS リソースも自動的に削除されます。本番では削除ポリシー(後述)と組み合わせて、意図しない AWS リソース削除を防ぐ設計が必須です。

移行時に有用なのが既存 AWS リソースの adopt(取り込み)です。CloudFormation や Terraform で作成済みの S3 バケットなどを、再作成せずに ACK 管理下へ移行できます。

apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: existing-bucket
  annotations:
 services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
  name: {{my-existing-bucket-name}}

adopt 後はそのリソースを Kubernetes マニフェストとして更新でき、既存 IaC ツールと ACK を段階的に併存させながら移行できます。他チームが管理する VPC・IAM ロール・KMS キーなどを参照のみしたい場合は、retain の削除ポリシーと読み取り専用の IAM 権限を組み合わせることで、変更リスクなしに Kubernetes API から共有インフラを検出できます。

削除ポリシーは既定で delete(Kubernetes リソース削除時に AWS リソースも削除)ですが、本番データベースのように誤削除を避けたいリソースには retain を指定します。

apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
  name: production-db
  annotations:
 services.k8s.aws/deletion-policy: "retain"
spec:
  dbInstanceIdentifier: {{prod-db}}

retain を指定したリソースは Kubernetes 上から消えても AWS 上で課金が継続するため、タグによる棚卸しと手動削除の運用ルールを別途定めておく必要があります。ACK が作成した AWS リソースには eks:kubernetes-namespace・eks:kubernetes-resource-name 等のタグが自動付与されるため、self-managed ACK(services.k8s.aws/ プレフィックスのタグを使用)からの移行時にはタグベースのコスト集計ロジックの見直しが必要になる点も本番運用上の注意点です。

kro(§5)と組み合わせることで、ACK が管理する個々の AWS リソースを束ねた高レベル API をプラットフォームチームが提供できるようになります。この統合パターンの詳細は §5 で扱います。

5. kro(Kube Resource Orchestrator)の本番運用

5-1. kro の仕組み — ResourceGraphDefinition によるカスタム API 定義

kro (Kube Resource Orchestrator) は、複数の Kubernetes リソースをひとまとめにして再利用可能なカスタム API へと抽象化する OSS プロジェクトです。中核となるカスタムリソースは ResourceGraphDefinition (RGD) の一種類のみで、RGD には「利用者に公開するスキーマ(SimpleSchema 形式)」と「その背後で作成する Kubernetes リソース群のテンプレート」を1つの YAML で定義します。RGD を適用すると、kro はスキーマ定義から新しい CRD を自動生成・登録し、以降その CRD のインスタンスを作成するだけで背後のリソース群が一括で作成・管理される状態になります。

resources 間の依存関係は宣言時に自動解決されます。あるリソースのテンプレートが CEL (Common Expression Language) 式で別のリソースのフィールド(例: ACK が払い出す ARN)を参照すると、kro はその参照から有向非巡回グラフ(DAG)を構築し、依存順に(依存のないリソース同士は並列に)作成します。循環参照が RGD 作成時点(実行時ではない)で検出・拒否されるため、構成ミスを早期に発見できます。

apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
  name: webapp-with-bucket
spec:
  schema:
 apiVersion: v1alpha1
 kind: WebAppWithBucket
 spec:
name: string | required=true
replicas: integer | default=2
  resources:
 - id: bucket
template:
  apiVersion: s3.services.k8s.aws/v1alpha1
  kind: Bucket
  spec:
 name: ${schema.spec.name}-assets
 - id: deployment
template:
  apiVersion: apps/v1
  kind: Deployment
  metadata:
 name: ${schema.spec.name}
  spec:
 replicas: ${schema.spec.replicas}
 template:
spec:
  containers:
 - name: app
image: nginx:latest
env:
  - name: BUCKET_ARN
 value: ${bucket.status.ackResourceMetadata.arn}

EKS Capability としての kro は、この kro コントローラ自体のインストール・アップグレード・可用性確保を AWS が肩代わりします。§3・§4 で見た Argo CD・ACK と同様、顧客が操作するのは ResourceGraphDefinition とそのインスタンスという Kubernetes カスタムリソースのみです。

5-2. IAM 設計 — kro は AWS API を直接呼び出さない

kro capability は Argo CD・ACK と異なり、kro 自身は AWS API を一切呼び出しません。RGD・インスタンスの管理は Kubernetes API の範囲内で完結するため、Capability Role には信頼ポリシー(trust policy)のみが必要で、IAM ポリシーのアタッチは不要です(§2-3 の一覧で kro が「原則不要」とされているのはこのためです)。

capability 作成時には AmazonEKSKROPolicy を伴うアクセスエントリが自動作成されますが、このポリシーが許可するのは kro が ResourceGraphDefinition とそのインスタンス自体を管理する権限のみです。RGD が定義する背後のリソース(Deployment・Service、あるいは ACK の Bucket・DBInstance 等)を実際に作成させるには、追加のアクセスエントリポリシーまたは Kubernetes RBAC を別途付与する必要があります。ACK リソースを組み込んだ RGD を運用する場合、AWS リソースの作成権限自体は §4-2 で解説した ACK 側の Capability Role(または IAM Role Selector)が担い、kro 側はあくまで「その ACK カスタムリソースを apply する権限」を持てばよい、という役割分担になります。

5-3. RBAC 設計 — プラットフォームチームとアプリケーションチームの権限分離

kro の RBAC は「RGD を設計するプラットフォームチーム」と「RGD のインスタンスを作成するアプリケーションチーム」を分離する前提で設計します。RGD はクラスタースコープのリソースであるのに対し、インスタンスは namespace スコープです。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kro-app-developer
  namespace: my-app
rules:
  - apiGroups: ["kro.run"]
 resources: ["webappwithbuckets"]
 verbs: ["create", "get", "list", "update", "delete"]

この権限分離により、アプリケーションチームは RGD が抽象化した背後の Deployment・Service・ACK リソースの詳細を意識せず、シンプルなカスタムリソースの apply だけでインフラを利用できます。誤設定のリスクが下がり、新規メンバーのオンボーディングも短縮できる点が kro 導入の主な動機です。

5-4. ACK と組み合わせた高レベル API 設計パターン

kro が最も効果を発揮するのは、ACK が管理する複数の AWS リソースを1つの RGD に束ね、プラットフォームチームが標準テンプレートとして提供する構成です。典型的な組み合わせには次のようなパターンがあります。

RGD 内では、ACK リソースが払い出す status.ackResourceMetadata.arn のようなフィールドを CEL 式で参照し、ConfigMap や Deployment の環境変数に注入できます(5-1 の例で ${bucket.status.ackResourceMetadata.arn} として使用している箇所)。これにより、開発チームは ACK の CRD や IAM Role Selector の詳細を意識せず、kro が公開する高レベル API(例 WebAppWithBucket)にマニフェストを適用するだけで、アプリケーションと関連 AWS リソースを一括で展開できます。

5-5. Argo CD との統合 — RGD とインスタンスの GitOps 配布

kro 自体は Git 連携を必須としませんが、managed Argo CD capability(§3)と組み合わせることで RGD・インスタンスの双方を GitOps で配布できます。RGD はプラットフォームチームが管理するリポジトリ(あるいは Application)で、インスタンスはアプリケーションチームのリポジトリで管理するというリポジトリ分割が典型です。RGD はインスタンスより先に存在している必要があるため、同一 Application で両方を管理する場合は Argo CD の Sync Wave(argocd.argoproj.io/sync-wave アノテーション)で RGD の適用順を先行させる設計が必要です。

6. 移行・統合パターン — self-managed から managed へ

6-1. 移行を検討すべき判断基準

§2-2 で整理した通り、self-managed(Vol2)と managed(本 Vol4)の選定基準は「カスタマイズ自由度」と「運用負荷軽減」のどちらを優先するかです。CMP・カスタム Lua ヘルスチェック・Notifications controller・独自 SSO のいずれも使っておらず、Argo CD 本体のアップグレード・可用性確保にかかる工数を削減したいチームは、移行によるメリットがデメリットを上回りやすい候補です。逆に、これらの機能に強く依存している場合は、該当機能を段階的に廃止できる見込みが立つまで移行を見送るのが安全です。

6-2. 移行ステップ — self-managed Argo CD から managed capability へ

AWS 公式ドキュメント(Comparing EKS Capability for Argo CD to self-managed Argo CD)は、次の移行手順を推奨しています。

1. 現行の Argo CD 構成を棚卸しし、非対応機能(Notifications controller・CMP・カスタムヘルスチェック・UI 拡張)の利用有無を確認する
2. self-managed Argo CD のコントローラをレプリカ数 0 にスケールダウンし、同じリソースに対する二重の Sync 競合を防ぐ
3. Argo CD capability リソースを作成する(§3-1)
4. 既存の Application・ApplicationSet・AppProject をエクスポートする
5. リポジトリ認証情報・クラスターシークレット・repository credential template (repocreds) を移行する
6. GPG 鍵・TLS 証明書・SSH known_hosts を利用している場合はこれらも移行する
7. destination.server を Kubernetes API サーバー URL から EKS クラスター ARN(または登録したクラスター名)へ書き換える(§3-2)
8. 移行したマニフェストを managed Argo CD instance に適用する
9. Application が正常に Sync していることを検証したうえで、self-managed Argo CD を廃止する

この手順のうち②・⑨が並行運用期間を区切る境界になります。self-managed 側を即座に削除せず、いったんレプリカ 0 で待機させておくことで、④〜⑧で問題が見つかった場合にレプリカ数を戻すロールバックが可能になります。

6-3. 並行運用期間の設計 — 段階的移行と切り替え判断

一括切り替えはリスクが大きいため、Application・ApplicationSet 単位、あるいはチーム単位で段階的に移行するのが実務上の標準的な進め方です。低リスクな検証環境の Application から先行移行し、Sync 状態・ロールバック動作・監視項目(§7 で扱う capability ステータス監視)に問題がないことを確認してから、本番ワークロードを担う Application へ順次移行範囲を広げます。

移行対象を絞る際は、Argo CD capability が Application・ApplicationSet・AppProject を単一の namespace へ限定する点(§3 の内容と同様、capability 作成時に指定した namespace 以外ではこれらのリソースを作成できない)に注意してください。self-managed で複数 namespace に Application を分散配置していた場合、移行時に該当 namespace への集約が必須になります。ワークロード自体のデプロイ先 namespace には制限がないため、影響を受けるのは Argo CD 自身のカスタムリソースの配置場所のみです。

6-4. ACK・kro を組み合わせたプラットフォーム基盤への統合パターン

Argo CD の移行が完了した後は、ACK・kro を組み合わせてプラットフォーム基盤自体を拡張する統合パターンに進めます。典型的な進め方は次の3段階です。

1. Argo CD 移行(6-2): GitOps デプロイの主体を self-managed から managed capability へ切り替える
2. ACK による既存リソースの adopt(§4-3): CloudFormation・Terraform で管理してきた AWS リソースを、再作成せず ACK 管理下へ段階的に取り込む
3. kro による高レベル API 化(§5-4): adopt 済みの ACK リソースと Kubernetes リソースを RGD で束ね、プラットフォームチームが標準テンプレートとして開発チームに提供する

リポジトリ構成は、RGD を管理するプラットフォームリポジトリと、RGD インスタンス・既存 Application を管理するアプリケーションリポジトリを分離する構成が基本です。小規模な組織では両者を1つのリポジトリにまとめても構いませんが、その場合も Argo CD Project を分離し、RGD への書き込み権限をプラットフォームチームに限定することが推奨されます。

6-5. 移行時の注意点 — 既存 Application の扱い・RBAC の移し替え

既存 Application の Sync Policy・Health 判定ロジック自体は upstream Argo CD と完全互換のため書き換え不要ですが、RBAC とデプロイ先 namespace の集約は移行プロジェクトの中で最も工数がかかる作業になりやすい点を見積もりに含めておく必要があります。

7. 監視・コスト・セキュリティ・IAM の本番運用

7-1. capability の稼働監視 — ステータスと CloudTrail

managed 化された capability の監視は、self-managed でコンポーネント個別のヘルスを追いかけていた運用(§3-3 表で既出)から、大きく 2 層に単純化されます。第一層は capability 自体の状態で、aws eks describe-capability が返す status が ACTIVE であり続けているかを定期確認します。作成・更新直後は CREATING/UPDATING を経由するため、これらの遷移状態が想定外に長く続く場合は capability 側の異常を疑うシグナルになります。第二層は capability が管理する Kubernetes カスタムリソースの状態で、Argo CD の Application は status.sync/status.health、ACK の各カスタムリソースは status.conditions に現れる同期状態(Ready 相当の Condition)、kro のインスタンスは status.conditions/status.state を確認します。self-managed(Vol2)で repo-server・application-controller 等の Pod ヘルスを個別監視していた作業は、managed では丸ごと不要になります。

describe-capability の定期呼び出しをスケジュール実行し、結果を CloudWatch カスタムメトリクスとして記録しておくと、capability ステータスの異常をアラーム化できます。あわせて、capability に対する作成・更新・削除操作は §2-3 で述べた通りすべて AWS CloudTrail に記録されるため、誰がいつ Capability Role の設定や capability 自体を変更したかを CloudTrail Insights・EventBridge ルールで追跡し、意図しない変更を検知する運用にしておくと監査の起点を一本化できます。

7-2. コスト — capability 課金モデルと可視化

capability の課金は §2-3 の一覧で述べた通り、前払いなしの従量課金で「capability リソースが有効な時間」と「capability が管理する Kubernetes リソースの利用量」の 2 要素で構成されます。これに加えて、ACK が実際に作成する S3・RDS 等の AWS リソース自体の実費用は capability 課金とは別に発生する点を見積もりに含める必要があります。

self-managed とのコスト比較で見落としやすいのは、capability は顧客クラスターの Worker Node ではなく service-owned account で稼働するため(§2-1 既出)、Argo CD・ACK・kro のコントローラ Pod 分の CPU・メモリを Worker Node 側で確保する必要がないという点です。self-managed では HA 構成のために複数レプリカ分の Node 容量を常時確保していたのに対し、managed ではその容量をワークロード用に転用できます。一方で capability 自体の稼働時間課金が新たに発生するため、小規模なクラスターではこの損益分岐点を試算したうえで移行判断(§6-1)に反映するのが実務的です。

コストの可視化には、§4-3 で述べた ACK 作成リソースへの eks:kubernetes-namespace 等のタグ自動付与を活用します。Cost Explorer のコスト配分タグでこれらを有効化すると、namespace 単位・チーム単位でのコスト按分が可能になります。self-managed ACK(services.k8s.aws/ プレフィックスのタグ)からの移行時は、コスト集計クエリのタグキーも合わせて見直す必要がある点は §4-3 で述べた通りです。また、retain の削除ポリシー(§4-3)を付与したリソースは Kubernetes 上から消えても AWS 上の課金が継続するため、タグによる棚卸しを定期実行し、意図しない課金の残存を防ぐ運用ルールを定めておきます。

7-3. セキュリティ — 責任分界と IAM 最小権限

EKS Capabilities における責任分界は明確です。capability 基盤自体(コントローラソフトウェアのパッチ適用・可用性確保・スケーリング)は AWS の責任範囲であり、顧客が設計すべきなのは Capability Role の IAM 権限・Kubernetes RBAC・Git リポジトリの内容の 3 点に集約されます。§4-2 で解説した IAM Role Selector による namespace 単位の権限分離、§5-2 で解説した kro の trust policy のみで足りる原則は、いずれも「Capability Role には必要最小限の権限しか持たせない」という同じ最小権限の考え方の capability ごとの現れ方です。ACK に限らず、Capability Role へ IAM ポリシーを直接付与する構成(§4-2 ①)は検証用途に留め、本番では IAM Role Selector や namespace 単位のスコープ設定を徹底します。

Pod Identity(Vol3)との関係も整理しておく必要があります。capability 自体は顧客クラスターの Worker Node ではなく service-owned account で稼働するため、Pod Identity Association の直接の対象にはなりません。Pod Identity が関係するのは、ACK・kro が管理する Deployment 等のワークロード Pod が別途 AWS リソースへアクセスする場合で、この権限は Capability Role とは別レイヤーの Pod Identity Association(Vol3 の設計)で付与します。「capability 自体の権限(Capability Role)」と「capability が展開したアプリケーションの権限(Pod Identity)」を混同しないことが、IAM 設計を複雑化させないための要点です。

Git 認証情報・RDS パスワード等のシークレットは、Kubernetes Secret への直接埋め込みではなく Secrets Manager 経由で参照し、AmazonEKSSecretReaderPolicy(§2-3 既出)のような追加ポリシーで参照範囲をスコープします。capability に対する操作は CloudTrail に記録される(§7-1)ため、Kubernetes Audit Log だけに依存していた self-managed 時代と比べて監査証跡の一本化が図れる点もセキュリティ運用上の利点です。

7-4. アップグレード運用 — AWS 管理範囲と顧客側の確認事項

Argo CD・ACK・kro のコントローラ本体のバージョンアップ作業自体は AWS が実施するため、self-managed で必要だった Helm chart のバージョンアップ計画・実施(§3-3 表)は不要になります。ただし、顧客側で確認しておくべき事項が残ります。第一に、ACK の各カスタムリソースで使う API バージョン(例 v1alpha1)がアップグレードで非推奨化されないか、マニフェストの互換性を継続的に確認します。第二に、kro の RGD スキーマや CEL 式の挙動に変更が入った場合の影響範囲です。第三に、Argo CD の Sync Policy・Health 判定ロジックは upstream 互換を維持する前提のため(§3-3・§6-5 既出)、本番反映前にステージング環境で Application の Sync 結果を確認してから展開する運用を徹底します。capability 側のアップグレード自体は透過的でも、マニフェストの互換性検証という顧客側の作業は残る、という認識を持っておくことが重要です。

7-5. capability 横断の運用チェックリスト

8. 詰まりポイント・アンチパターン・まとめ

8-1. 詰まりポイント — 実践的な失敗例

8-2. アンチパターン → 正解パターン変換

8-3. 本番移行前チェックリスト

8-4. まとめと次巻予告

本 Vol4 では、EKS Capabilities として提供される managed Argo CD・ACK・kro を「運用負荷の主体」という一貫した軸で扱いました。self-managed(Vol2)がカスタマイズ自由度を最大化する選択であるのに対し、managed capability は運用ソフトウェア自体の保守作業を AWS に委ね、IAM 設計・移行設計・監視運用に集中できる選択です。両者は排他ではなく、§6 で見た通り Argo CD の移行を起点に ACK による既存リソースの adopt、kro による高レベル API 化へと段階的に統合していける関係にあります。Container 本番運用シリーズは Vol1 の基礎から Vol2 の GitOps、Vol3 の縦深化、そして本 Vol4 の運用オフロードまで到達し、EKS 本番運用における主要な運用軸を一通りカバーしました。次巻では、これらの運用ツール群を含む Container ワークロード全体の可観測性・FinOps・マルチテナント設計といった、シリーズ全体を横断する運用トピックを扱う予定です。

関連：Container Vol1 (ECS・Fargate・ECR 基礎編) を読む
関連：Container Vol2 (self-managed Argo CD・Kustomize・Argo Rollouts) を読む
関連：Container Vol3 (Pod Identity・Karpenter・Service Connect) を読む