**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# EKS 機能
**ヒント**
使用開始: [ACK 機能の作成](create-ack-capability.md) \$1 [Argo CD 機能の作成](create-argocd-capability.md) \$1 [kro 機能の作成](create-kro-capability.md)
Amazon EKS 機能は、開発者のベロシティを加速させ、Kubernetes での構築とスケールの複雑さを軽減するのに役立つ、完全マネージド型のクラスター機能のレイヤーセットです。EKS 機能は、宣言型の継続的デプロイ、AWS リソース管理、Kubernetes リソースの作成とオーケストレーションに対応した Kubernetes ネイティブの機能であり、いずれも AWS で完全に管理されます。EKS 機能を使用すると、基盤となるプラットフォームサービスのオペレーションにかかる負担を AWS にオフロードして、ワークロードの構築とスケールに集中できます。これらの機能はクラスター内ではなく EKS 内で実行されるため、重要なプラットフォームコンポーネントをワーカーノードにインストール、メンテナンス、スケールする必要がありません。
使用を開始するには、新規または既存の EKS クラスターに 1 つ以上の EKS 機能を作成します。そのためには、AWS CLI、AWS マネジメントコンソール、EKS API、eksctl、または任意の Infrastructure as Code ツールを使用します。EKS 機能は、互いに連携するように設計されていると共に、ユースケースと要件に基づいて選択可能な独立したクラウドリソースです。
EKS でサポートされている Kubernetes バージョンは、いずれも EKS 機能でサポートされています。
**注記**
EKS 機能は、Amazon EKS が利用可能なすべての AWS 商用リージョンで利用できます。サポートされているリージョンの一覧については、「AWS 全般的なリファレンス」の「[Amazon EKS エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/eks.html)」を参照してください。
## 利用可能な機能
### AWS Controllers for Kubernetes (ACK)
ACK を使用すると、Kubernetes API を使用して AWS リソースを管理できるため、Kubernetes カスタムリソースを使用して S3 バケット、RDS データベース、IAM ロールなどの AWS リソースを作成および管理できます。ACK は、目的の状態と AWS での実際の状態とを継続的に調整して、時間の経過に伴うドリフトを修正します。これにより、システムの正常性を維持し、リソースを指定どおりに設定できます。Kubernetes ワークロードと共に、同じツールとワークフローを使用して AWSリソースも管理でき、S3、RDS、DynamoDB、Lambda など 50 を超える AWS サービスをサポートしています。ACK は、クロスアカウントおよびクロスリージョンのリソース管理をサポートし、マルチアカウントでマルチクラスターの複雑なシステム管理アーキテクチャを実現します。また、読み取り専用リソースと読み取り専用採用をサポートしているため、他の Infrastructure as Code ツールから Kubernetes ベースのシステムに容易に移行できます。
[ACK の詳細はこちら →](ack.md)
### Argo CD
Argo CD は、アプリケーションを GitOps ベースで継続的にデプロイする仕組みを実装しており、Git リポジトリをワークロードとシステム状態の信頼できるソースとして使用します。また、アプリケーションリソースを Git リポジトリからクラスターに自動的に同期し、ドリフトを検出および修正して、デプロイしたアプリケーションが目的の状態と一致するようにします。1 つの Argo CD インスタンスから複数のクラスターにわたってアプリケーションをデプロイおよび管理でき、変更がコミットされるたびに Git リポジトリから自動的にデプロイされます。Argo CD と ACK を一緒に使用すると、基盤となる GitOps システムを実現して、ワークロードの依存関係管理をシンプルにし、クラスターやインフラストラクチャを規模に応じて管理するなどシステム全体の設計をサポートできます。Argo CD は、AWS アイデンティティセンターとの統合により認証と認可を実施し、Argo UI のホストによりアプリケーションのヘルスとデプロイのステータスを可視化します。
[Argo CD の詳細はこちら →](argocd.md)
### kro (Kube Resource Orchestrator)
kro でカスタムの Kubernetes API を作成することにより、複数のリソースを高次の抽象化に構成できるため、プラットフォームチームはよく使用されるリソースを組み合わせてクラウド構成要素を構築できるように再利用可能なパターンを定義できます。kro では、Kubernetes リソースと AWS リソースの両方を統合抽象化に構成し、シンプルな構文を使用して、動的設定と条件付きロジックを有効にできます。kro を使用すると、プラットフォームチームが適切なガードレールに沿ってセルフサービス機能を提供できるため、開発者は組織の標準とベストプラクティスを維持しながら、シンプルな目的別 API を使用して複雑なインフラストラクチャをプロビジョニングできます。kro リソースは Kubernetes リソースにすぎず、Kubernetes マニフェストに指定して Git に保存できます。あるいは、Amazon ECR などの OCI 互換のレジストリにプッシュして、組織内に広範に分散させることもできます。
[kro の詳細はこちら →](kro.md)
## EKS 機能のメリット
EKS 機能は、AWS で完全に管理されるため、基礎となるクラスターサービスのインストール、メンテナンス、スケールが不要です。AWS がセキュリティパッチ適用、更新、オペレーション管理を担うため、チームはクラスターオペレーションではなく AWS での構築に集中できます。クラスターリソースを消費する従来の Kubernetes アドオンとは異なり、機能はワーカーノードではなく EKS で動作します。これにより、クラスター内コントローラーやその他のプラットフォームコンポーネントの管理に伴うオペレーションの負担を最小限に抑えながら、ワークロードのクラスターのキャパシティとリソースを解放できます。
EKS 機能により、`kubectl` などネイティブの Kubernetes API とツールを使用して、デプロイ、AWS リソース、カスタム Kubernetes リソース、およびコンポジションを管理できます。すべての機能がクラスターのコンテキストで動作し、アプリケーションリソースとクラウドインフラストラクチャリソースの両方で設定のドリフトを自動的に検出して修正します。1 つのコントロールポイントから複数のクラスター、AWS アカウント、およびリージョンにリソースをデプロイして管理できるため、複雑な分散環境でのオペレーションがシンプルになります。
EKS 機能は、GitOps ワークフロー用に設計されており、インフラストラクチャとアプリケーションのバージョンを宣言型で管理できます。変更が Git からシステムを通じて流れていくため、監査証跡、ロールバック機能、およびコラボレーションワークフローを既存の開発プラクティスと統合できます。この Kubernetes ネイティブアプローチにより、複数のツールを使用したり、クラスターの外部にある Infrastructure as Code システムを管理したりする必要がなく、信頼できる単一のソースを参照すればよくなります。バージョン管理された Kubernetes 宣言型設定に定義された目的の状態は、環境全体に継続的に適用されます。
## 料金
EKS 機能に前払いのコミットメントや料金はありません。機能リソースごとに Amazon EKS クラスターでアクティブになっている時間単位で課金されます。EKS 機能で管理される特定の Kubernetes リソースも、時間単位で課金されます。
現在の料金については、「[Amazon EKS の料金ページ](https://aws.amazon.com/eks/pricing/)」を参照してください。
**ヒント**
AWS Cost Explorer と、コストと使用状況レポートとを使用すると、機能のコストを他の EKS 料金とは別に追跡できます。機能にコスト配分の目的でクラスター名、機能タイプ、その他の詳細のタグを付与できます。
## EKS 機能の仕組み
各機能は、EKS クラスターに作成する AWS リソースです。作成した機能は、EKS で実行され、AWS で完全に管理されます。
**注記**
1 つのクラスターのタイプ (Argo CD、ACK、kro) ごとに機能リソースを 1 つ作成できます。同じクラスターで同じタイプに機能リソースを複数作成することはできません。
クラスターの機能とのインタラクションには、標準の Kubernetes API とツールを使用します。
+ `kubectl` を使用して Kubernetes カスタムリソースを適用します。
+ GitOps ワークフローの信頼できるソースとして Git リポジトリを使用します。
追加のツールがサポートされている機能もあります。例えば、次のようになります。
+ Argo CD CLI を使用して、Argo CD 機能のリポジトリおよびクラスターを設定および管理します。
+ Argo CD UI を使用して、Argo CD 機能で管理されるアプリケーションを可視化および管理します。
各機能は、互いに連携するように設計されていますが、いずれも独立しており、完全にオプトインされています。必要に応じて 1 つ、2 つ、または 3 つすべての機能を有効にし、要件の進化に伴って設定を更新できます。
EKS コンピューティングのいずれのタイプも、EKS 機能で使用できるようにサポートされています。詳細については、「[ノードを使用してコンピューティングリソースを管理する](eks-compute.md)」を参照してください。
IAM ロールでのセキュリティ設定と詳細については、「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。マルチクラスターアーキテクチャパターンについては、「[EKS 機能と考慮事項](capabilities-considerations.md)」を参照してください。
## 一般的なユースケース
**アプリケーションとインフラストラクチャの GitOps**
Argo CD を使用してアプリケーションとオペレーションコンポーネントをデプロイし、ACK を使用してクラスター設定の管理とインフラストラクチャのプロビジョニングを行います。どちらも、Git リポジトリから実施します。アプリケーション、データベース、ストレージ、ネットワークといったスタック全体がコードとして定義され、自動的にデプロイされます。
例: 開発チームが Git に変更をプッシュします。Argo CD が更新後のアプリケーションをデプロイし、ACK が新規 RDS データベースを適切な設定でプロビジョニングします。すべての変更が監査可能で、可逆性があり、環境間で一貫性が保たれます。
**セルフサービスによるプラットフォームエンジニアリング**
kro でカスタム API を作成して、ACK リソースと Kubernetes リソースを構成できます。プラットフォームチームは、ガードレールに沿って承認済みのパターンを定義します。アプリケーションチームは、シンプルで高レベルの API を使用して、完全なスタックをプロビジョニングします。
例: プラットフォームチームは、「WebApplication」という API を作成して、デプロイ、サービス、イングレス、S3 バケットをプロビジョニングします。開発者は、この API を使用するにあたって、その基盤となる複雑さや AWS アクセス許可について知る必要がありません。
**マルチクラスターアプリケーション管理**
Argo CD を使用して、リージョンやアカウントが異なる複数の EKS クラスターにアプリケーションをデプロイします。一貫したポリシーとワークフローに従って、単一の Argo CD インスタンスからすべてのデプロイを管理します。
例: 複数のリージョンにまたがる開発、ステージング、本番稼働用のクラスターに同じアプリケーションをデプロイします。Argo CD により、各環境はその対応する Git ブランチと常に同期するようになります。
**マルチクラスター管理**
ACK を使用して EKS クラスターを定義およびプロビジョニングし、kro を使用して組織の標準に従ってクラスター設定をカスタマイズし、Argo CD を使用してクラスターのライフサイクルと設定を管理します。これにより、作成から継続的な運用までエンドツーエンドでクラスターを管理できます。
例: ACK と kro により、クラスターインフラストラクチャをプロビジョニングおよび管理するように EKS クラスターを定義して、ネットワーク、セキュリティポリシー、アドオンなどの設定に関して組織全体の標準を定義します。Argo CD を使用すると、一貫した標準と自動ライフサイクル管理を利用してフリート全体でクラスター、設定、Kubernetes バージョン更新を作成し、継続的に管理します。
**移行とモダナイズ**
ネイティブのクラウドリソースプロビジョニングと GitOps ワークフローに従って、EKS への移行をシンプルにします。ACK を使用して既存の AWS リソースを再作成することなく採用し、Argo CD を使用して Git からワークロードのデプロイを運用できるようにします。
例: EC2 から EKS に移行するチームは、まず ACK を使用して既存の RDS データベースと S3 バケットを採用し、次に Argo CD を使用して Git からコンテナ化されたアプリケーションをデプロイします。移行パスは明確で、オペレーションは最初から標準化されます。
**アカウントとリージョンのブートストラッピング**
Argo CD と ACK を一緒に使用して、アカウントとリージョン全体にわたるインフラストラクチャのロールアウトを自動化します。Git に Infrastructure as Code を定義し、機能がデプロイと管理を担えるようにします。
例: プラットフォームチームは、VPC、IAM ロール、RDS インスタンス、モニタリングスタックといった標準アカウント設定を定義している Git リポジトリを維持します。Argo CD がこれらの設定を新しいアカウントとリージョンに自動的にデプロイするため、一貫性が確保され、手動セットアップ時間が数日から数分に短縮されます。
# 機能リソースの使用
このトピックでは、すべての機能タイプで機能リソースを管理するための一般的なオペレーションについて説明します。
## EKS 機能リソース
EKS 機能は、Amazon EKS クラスターでマネージド機能を有効にする AWS リソースです。機能は EKS で実行されるため、コントローラーやその他の運用コンポーネントをワーカーノードにインストールして維持する必要がありません。機能は、特定の EKS クラスター用に作成され、ライフサイクル全体でそのクラスターと関連付けられます。
各機能リソースには、次のものがあります。
+ クラスター内で一意の名前
+ 機能タイプ (ACK、ARGOCD、または KRO)
+ 名前とタイプの両方を指定する Amazon リソースネーム (ARN)
+ 機能 IAM ロール
+ 現在の状態を示すステータス
+ 汎用の設定と機能タイプ固有の設定
## 機能ステータスについて
機能リソースには、現在の状態を示すステータスがあります。機能のステータスとヘルスは、EKS コンソールまたは AWS CLI を使用して表示できます。
**コンソール:**
1. https://console.aws.amazon.com/eks/home\$1/clusters で Amazon EKS コンソールを開きます。
1. クラスター名を選択します。
1. **[機能]** タブを選択すると、すべての機能のステータスが表示されます。
1. 詳細なヘルス情報については、**[オブザーバビリティ]** タブを選択し、**[クラスターをモニタリング]** を選択してから、**[機能]** タブを選択します。
**AWS CLI**:
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-capability-name
```
### 機能ステータス
**CREATING**: 機能のセットアップ中です。コンソールから移動できます。この機能はバックグラウンドで引き続き作成されます。
**ACTIVE**: 機能の実行中ですぐに使用できるようになります。リソースが想定どおりに動作しない場合は、リソースのステータスと IAM アクセス許可を確認してください。ガイダンスについては、「[EKS 機能をトラブルシューティングする](capabilities-troubleshooting.md)」を参照してください。
**UPDATING**: 設定変更の適用中です。ステータスが `ACTIVE` に戻るまで待ちます。
**DELETING**: クラスターから機能を削除中です。
**CREATE\$1FAILED**: セットアップでエラーが発生しました。一般的な原因には、以下が含まれます。
+ IAM ロールの信頼ポリシーが正しくないか、見つかりません。
+ IAM ロールが存在しないか、アクセスできません。
+ クラスターアクセスに問題があります。
+ 設定パラメータが無効です。
特定のエラーの詳細については、機能ヘルスセクションを確認してください。
**UPDATE\$1FAILED**: 設定の更新に失敗しました。機能ヘルスセクションで詳細を確認し、IAM アクセス許可を検証します。
**ヒント**
トラブルシューティングの詳細なガイダンスについては、以下を参照してください。
[EKS 機能をトラブルシューティングする](capabilities-troubleshooting.md) - 一般的な機能のトラブルシューティング
[ACK 機能に関する問題をトラブルシューティングする](ack-troubleshooting.md) - ACK 固有の問題
[Argo CD 機能に関する問題をトラブルシューティングする](argocd-troubleshooting.md) - Argo CD 固有の問題
[kro 機能に関する問題をトラブルシューティングする](kro-troubleshooting.md) - kro 固有の問題
## 機能を作成する
クラスターに機能を作成するには、以下のトピックを参照してください。
+ [ACK 機能を作成する](create-ack-capability.md) – Kubernetes API を使用して AWS リソースを管理するための ACK 機能を作成する
+ [Argo CD 機能を作成する](create-argocd-capability.md) – GitOps による継続的デリバリーのための Argo CD 機能を作成する
+ [kro 機能の作成](create-kro-capability.md) – リソースの構成とオーケストレーションのための kro 機能を作成する
## 機能を一覧表示する
クラスター上のすべての機能リソースを一覧表示できます。
### コンソール
1. https://console.aws.amazon.com/eks/home\$1/clusters で Amazon EKS コンソールを開きます。
1. クラスター名を選択して、クラスターの詳細ページを開きます。
1. **[機能]** タブを選択します。
1. **[マネージド機能]** で機能リソースを表示します。
### AWS CLI
`list-capabilities` コマンドを使用して、クラスター上のすべての機能を表示します。*region-code* はクラスターがある AWS リージョンに、*my-cluster* はクラスターの名前に置き換えます。
```
aws eks list-capabilities \
--region region-code \
--cluster-name my-cluster
```
```
{
"capabilities": [
{
"capabilityName": "my-ack",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack/abc123",
"type": "ACK",
"status": "ACTIVE",
"createdAt": "2025-11-02T10:30:00.000000-07:00",
"modifiedAt": "2025-11-02T10:32:15.000000-07:00",
},
{
"capabilityName": "my-kro",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/kro/my-kro/abc123",
"type": "KRO",
"status": "ACTIVE",
"version": "v0.6.3",
"createdAt": "2025-11-02T10:30:00.000000-07:00",
"modifiedAt": "2025-11-02T10:32:15.000000-07:00",
},
{
"capabilityName": "my-argocd",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/argocd/my-argocd/abc123",
"type": "ARGOCD",
"status": "ACTIVE",
"version": "3.1.8-eks-1",
"createdAt": "2025-11-21T08:22:28.486000-05:00",
"modifiedAt": "2025-11-21T08:22:28.486000-05:00"
}
]
}
```
## 機能の説明
設定やステータスなど、特定の機能に関する詳細情報を取得します。
### コンソール
1. https://console.aws.amazon.com/eks/home\$1/clusters で Amazon EKS コンソールを開きます。
1. クラスター名を選択して、クラスターの詳細ページを開きます。
1. **[機能]** タブを選択します。
1. **[マネージド機能]** から表示する機能を選択します。
1. ステータス、設定、作成時刻など、機能の詳細を表示します。
### AWS CLI
`describe-capability` コマンドを使用して、詳細情報を表示します。*region-code* をクラスターがある AWS リージョンに、*my-cluster* をクラスターの名前に、*capacity-name* を機能名 (ack、argocd、または kro) に置き換えます。
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name
```
**出力例:**
```
{
"capability": {
"capabilityName": "my-ack",
"capabilityArn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack/abc123",
"clusterName": "my-cluster",
"type": "ACK",
"roleArn": "arn:aws:iam::111122223333:role/AmazonEKSCapabilityACKRole",
"status": "ACTIVE",
"configuration": {},
"tags": {},
"health": {
"issues": []
},
"createdAt": "2025-11-19T17:11:30.242000-05:00",
"modifiedAt": "2025-11-19T17:11:30.242000-05:00",
"deletePropagationPolicy": "RETAIN"
}
}
```
## 機能の設定を更新する
機能の設定の一部は、作成後に更新できます。使用できる設定オプションは、機能タイプによって異なります。
**注記**
EKS 機能リソースは、パッチ適用やバージョン更新を含め、完全に管理されています。機能を更新すると、リソースの設定が更新されますが、マネージド機能コンポーネントのバージョンは更新されません。
### AWS CLI
`update-capability` コマンドを使用して機能を変更します。
```
aws eks update-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name \
--role-arn arn:aws:iam::[.replaceable]111122223333:role/NewCapabilityRole
```
**注記**
作成後にすべての機能プロパティを更新できるわけではありません。変更できる内容の詳細については、機能固有のドキュメントを参照してください。
## 機能を削除する
クラスター上で機能が不要になった場合は、機能リソースを削除できます。
**重要**
**機能を削除する前に、クラスターリソースを削除します。**
機能リソースを削除しても、その機能を使用して作成されたリソースは自動的に削除されません。
すべての Kubernetes カスタムリソース定義 (CRD) は、クラスターにインストールされたままです。
ACK リソースはクラスターに残り、対応する AWS リソースはアカウントに残ります。
Argo CD アプリケーションとその Kubernetes リソースはクラスターに残ります。
kro ResourceGraphDefinitions とインスタンスはクラスターに残ります。
孤立したリソースを回避するため、機能を削除する前に、これらのリソースを削除する必要があります。
必要に応じて、ACK Kubernetes リソースに関連付けられた AWS リソースを保持することもできます。「[ACK に関する考慮事項](ack-considerations.md)」を参照してください。
### コンソール
1. https://console.aws.amazon.com/eks/home\$1/clusters で Amazon EKS コンソールを開きます。
1. クラスター名を選択して、クラスターの詳細ページを開きます。
1. **[機能]** タブを選択します。
1. **[マネージド機能]** のリストから削除する機能を選択します。
1. **[機能を削除]** を選択します。
1. 確認ダイアログで、機能の名前を入力して削除を確定します。
1. **[削除]** を選択します。
### AWS CLI
`delete-capability` コマンドを使用して、機能リソースを削除します。
*region-code* をクラスターがある AWS リージョンに、*my-cluster* をクラスターの名前に、*capacity-name* を削除する機能名に置き換えます。
```
aws eks delete-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name
```
## 次のステップ
+ [機能の Kubernetes リソース](capability-kubernetes-resources.md) – 各機能タイプによって提供される Kubernetes リソースについて説明する
+ [ACK の概念](ack-concepts.md) – ACK の概念およびリソースライフサイクルを理解する
+ [Argo CD の使用](working-with-argocd.md) – GitOps ワークフローに Argo CD 機能を使用する
+ [kro の概念](kro-concepts.md) – kro の概念とリソース構成を理解する
# 機能の Kubernetes リソース
クラスターで機能を有効にしたら、後は通常クラスターで Kubernetes カスタムリソースを作成して管理することでクラスターを操作することになります。機能ごとに独自のカスタムリソース定義 (CRD) セットを策定して、それぞれに固有の機能で Kubernetes API を拡張できます。
## Argo CD リソース
Argo CD 機能を有効にすると、次の Kubernetes リソースを作成および管理できます。
**アプリケーション**
Git リポジトリからターゲットクラスターへのデプロイを定義します。`Application` リソースでは、ソースリポジトリ、ターゲット名前空間、同期ポリシーを指定します。Argo CD 機能インスタンスごとに最大 1,000 個の `Application` リソースを作成できます。
**ApplicationSet**
テンプレートから複数の `Application` リソースを生成し、マルチクラスターとマルチ環境のデプロイを可能にします。`ApplicationSet` リソースは、ジェネレーターを使用して、クラスターリストや Git ディレクトリといったソースに基づいて `Application` リソースを動的に作成します。
**AppProject**
`Application` リソースを論理的にグループ化してアクセスを制御します。`AppProject` リソースは、`Application` リソースが使用できるリポジトリ、クラスター、名前空間を定義して、マルチテナンシーとセキュリティ境界を有効にします。
`Application` リソースの例:
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/org/repo
targetRevision: main
path: manifests
destination:
server: https://kubernetes.default.svc
namespace: production
```
Argo CD のリソースと概念の詳細については、「[Argo CD の概念](argocd-concepts.md)」を参照してください。
## kro リソース
kro 機能を有効にすると、次の Kubernetes リソースを作成および管理できます。
**ResourceGraphDefinition (RGD)**
複数の Kubernetes と AWS リソースを高次の抽象化に構成するカスタム API を定義します。プラットフォームチームは、ガードレールに沿ってパターンを再利用可能できるように `ResourceGraphDefinition` リソースを作成します。
**カスタムリソースインスタンス**
`ResourceGraphDefinition` リソースを作成したら、`ResourceGraphDefinition` で定義されたカスタム API のインスタンスを作成できます。kro は、`ResourceGraphDefinition` に指定されたリソースを自動的に作成および管理します。
`ResourceGraphDefinition` リソースの例:
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: web-application
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
spec:
name: string
replicas: integer
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
# ... deployment spec
- id: service
template:
apiVersion: v1
kind: Service
# ... service spec
```
`WebApplication` インスタンスの例:
```
apiVersion: v1alpha1
kind: WebApplication
metadata:
name: my-web-app
namespace: default
spec:
name: my-web-app
replicas: 3
```
このインスタンスを適用すると、kro は `ResourceGraphDefinition` に定義された `Deployment` リソースと `Service` リソースを自動的に作成します。
kro のリソースと概念の詳細については、「[kro の概念](kro-concepts.md)」を参照してください。
## ACK リソース
ACK 機能を有効にすると、Kubernetes カスタムリソースを使用して AWS リソースを作成および管理できます。ACK では 50 を超える AWS サービスの 200 を超える CRD を策定できるため、Kubernetes ワークロードと共に AWS リソースを定義し、Kubernetes で専用の AWS インフラストラクチャリソースを管理できます。
ACK リソースの例:
**S3 バケット**
`Bucket` リソースは、バージョニング、暗号化、ライフサイクルポリシーを備えた Amazon S3 バケットを作成および管理します。
**RDS DBInstance**
`DBInstance` リソースは、自動バックアップとメンテナンス期間を備えた Amazon RDS データベースインスタンスをプロビジョニングして管理します。
**DynamoDB テーブル**
`Table` リソースは、プロビジョニング済みのキャパシティまたはオンデマンドキャパシティを備えた DynamoDB テーブルを作成および管理します。
**IAM ロール**
`Role` リソースは、AWS サービスアクセスの信頼ポリシーとアクセス許可ポリシーを備えた IAM ロールを定義します。
**Lambda 関数**
`Function` リソースは、コード、ランタイム、実行ロール設定を備えた Lambda 関数を作成および管理します。
`Bucket` リソースの指定例:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-app-bucket
spec:
name: my-unique-bucket-name-12345
versioning:
status: Enabled
encryption:
rules:
- applyServerSideEncryptionByDefault:
sseAlgorithm: AES256
```
ACK のリソースと概念の詳細については、「[ACK の概念](ack-concepts.md)」を参照してください。
## リソースの制限
EKS 機能には、次のリソース制限があります。
**Argo CD の使用制限**:
+ Argo CD 機能インスタンスあたり最大 1,000 個の `Application` リソース
+ Argo CD 機能インスタンスあたり最大 100 個のリモートクラスターを設定可能
**リソース設定の制限**:
+ Argo CD では `Application` リソースあたり最大 150 個の Kubernetes リソース
+ kro では `ResourceGraphDefinition` あたり最大 64 個の Kubernetes リソース
**注記**
これらの制限は、各機能インスタンスで管理されるリソースの数に適用されます。さらに厳しい制限が必要な場合は、複数のクラスターに機能をデプロイできます。
## 次のステップ
機能に固有のタスクと高度な設定については、以下のトピックを参照してください。
+ [ACK の概念](ack-concepts.md) – ACK の概念およびリソースライフサイクルを理解する
+ [Argo CD の使用](working-with-argocd.md) – GitOps ワークフローに Argo CD 機能を使用する
+ [kro の概念](kro-concepts.md) – kro の概念とリソース構成を理解する
# EKS 機能と考慮事項
このトピックでは、EKS 機能を使用する際の重要な考慮事項について説明します。具体的には、アクセスコントロール設計、EKS 機能かセルフマネージドソリューションかの選択、マルチクラスターデプロイ用のアーキテクチャパターン、運用のベストプラクティスなどです。
## 機能 IAM ロールと Kubernetes RBAC
EKS 機能リソースごとに、機能 IAM ロールが設定されています。機能ロールを使用すると、自分の代わりに EKS 機能を動作させるための AWS サービスアクセス許可を付与できます。例えば、EKS Capability for ACK を使用して Amazon S3 バケットを管理するには、S3 バケットの管理アクセス許可を機能に付与して、バケットを作成および管理できるようにします。
機能を設定すると、クラスター内の Kubernetes カスタムリソースで AWS の S3 リソースを作成および管理できます。Kubernetes RBAC は、こうしたカスタムリソースをどのユーザーとグループが作成および管理できるかを決定するためのクラスター内アクセスコントロールメカニズムです。例えば、特定の Kubernetes RBAC ユーザーとグループに、選択した名前空間で `Bucket` リソースを作成および管理するためのアクセス許可を付与します。
このように、IAM と Kubernetes RBAC は、エンドツーエンドのアクセス管理システムを二等分して、EKS の機能とリソースに関連するアクセス許可を管理しています。ここで重要なのは、ユースケースに適した IAM アクセス許可と RBAC アクセスポリシーを組み合わせることです。
機能 IAM ロールと Kubernetes アクセス許可の詳細については、「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。
## マルチクラスターアーキテクチャパターン
複数のクラスターに機能をデプロイする際は、よく使用される次のアーキテクチャパターンを考慮してください。
**一元管理でのハブとスポーク**
一元管理クラスターで 3 つすべての機能を実行して、ワークロードをオーケストレーションし、複数のワークロードクラスター全体にわたってクラウドインフラストラクチャを管理します。
+ 管理クラスター上の Argo CD は、リージョンやアカウントが異なる複数のワークロードクラスターにアプリケーションをデプロイします。
+ 管理クラスター上の ACK は、すべてのクラスターの AWS リソース (RDS、S3、IAM) をプロビジョニングします。
+ 管理クラスター上の kro は、すべてのクラスターにわたって動作するポータブルプラットフォーム抽象化を作成します。
このパターンにより、ワークロードとクラウドインフラストラクチャの管理が一元化されるため、組織が多数のクラスターを管理する場合の運用をシンプルにできます。
**分散型 GitOps**
ワークロードとクラウドインフラストラクチャは、ワークロードが実行されているのと同じクラスター上の機能で管理されます。
+ Argo CD は、ローカルクラスターのアプリケーションリソースを管理します。
+ ACK リソースは、クラスターとワークロードのニーズに応じて使用されます。
+ kro プラットフォーム抽象化がインストールされ、ローカルリソースをオーケストレーションします。
このパターンでは運用が分散され、各チームは 1 つ以上のクラスターでそれぞれ独自の専用プラットフォームサービスを管理します。
**ハイブリッド ACK デプロイでのハブとスポーク**
モデルを一元化および分散すると共に、範囲と所有権に基づいてアプリケーションのデプロイとリソース管理を一元化します。
+ ハブクラスター:
+ Argo CD は、ローカルクラスターとすべてのリモートワークロードクラスターへの GitOps デプロイを管理します。
+ ACK は、管理クラスター上で管理者範囲のリソース (本番稼働用データベース、IAM ロール、VPC) を操作します。
+ kro は、管理クラスター上でプラットフォーム抽象化を再利用可能にします。
+ スポーククラスター:
+ ワークロードは、一元化されたハブクラスター上で Argo CD によって管理されます。
+ ACK は、ローカルでワークロード範囲のリソース (S3 バケット、ElastiCache インスタンス、SQS キュー) を操作します。
+ kro は、ローカルでリソース構成と構成要素パターンを操作します。
このパターンは関心を分離します。プラットフォームチームは管理クラスター上で重要なインフラストラクチャを (必要に応じてワークロードクラスターも) 一元管理し、アプリケーションチームはワークロードと共にクラウドリソースを指定および管理します。
**パターンを選択する**
アーキテクチャを選択する場合は、次の要因を考慮してください。
+ **組織構造**: 中央集権型のプラットフォームではハブパターンが好まれますが、分散型のチームではクラスターごとの機能が好まれることがあります。
+ **リソース範囲**: 管理者範囲のリソース (データベース、IAM) は一元管理の方がメリットを得られることが多く、一方ワークロードリソース (バケット、キュー) はローカルで管理することもできます。
+ **セルフサービス**: 中央集権型のプラットフォームチームは、規範的なカスタムリソースを作成および配布して、ワークロードの一般的なニーズに合わせてクラウドリソースの安全なセルフサービスを有効にできます。
+ **クラスターフリート管理**: クラスターを一元管理すると、お客様所有のコントロールプレーンにより、EKS クラスターフリートを他の管理者範囲のリソースと共に管理できます。
+ **コンプライアンス要件**: 組織によっては、監査とガバナンスの一元管理が必要です。
+ **運用の複雑さ**: 機能インスタンスが少ないほど、運用はシンプルになりますが、ボトルネックが発生する可能性があります。
**注記**
1 つのパターンから始めて、プラットフォームの成熟に伴って別のパターンに進化させていくことができます。機能は独立しているため、ニーズに応じてクラスター間でデプロイ方法を変えることができます。
## EKS 機能をセルフマネージドソリューションと比較する
EKS 機能では、EKS で実行される一般的な Kubernetes ツールとコントローラーを完全に管理できます。これは、クラスターにインストールして運用するセルフマネージドソリューションとは異なります。
### 主な違い
**デプロイと管理**
AWS が EKS 機能を完全に管理するため、コンポーネントソフトウェアのインストール、設定、メンテナンスが必要ありません。また、AWS はクラスターに必要なすべての Kubernetes カスタムリソース定義 (CRD) を自動的にインストールして管理します。
セルフマネージドソリューションでは、Helm チャート、kubectl、またはその他の演算子を使用して、クラスターソフトウェアをインストールおよび設定します。セルフマネージドソリューションのソフトウェアライフサイクルとランタイム設定を完全に制御できるため、ソリューションのどのレイヤーでもカスタマイズを実施できます。
**運用とメンテナンス**
AWS は、自動更新とセキュリティパッチを使用して、EKS 機能のパッチ適用やその他のソフトウェアライフサイクルの運用を管理します。EKS 機能は、AWS 機能との統合により設定を効率化し、高可用性と耐障害性を備えており、コントローラーワークロードをクラスター内でトラブルシューティングする必要がありません。
セルフマネージドソリューションでは、コンポーネントのヘルスとログのモニタリング、セキュリティパッチとバージョン更新の適用、複数のレプリカとポッド中断の予算による高可用性の設定、コントローラーのワークロードに関する問題のトラブルシューティングと修復、リリースとバージョンの管理を行う必要があります。デプロイを完全に制御できますが、そのためには組織の標準とセキュリティコンプライアンス要件に沿ってプライベートクラスターアクセスやその他の統合を実現するカスタムソリューションが必要です。
**リソース消費**
EKS 機能はクラスターとは別に EKS で実行されるため、ノードリソースとクラスターリソースが解放されます。クラスターワークロードリソースを使用せず、ワーカーノード上で CPU やメモリを消費しません。また、自動的にスケールして、クラスターキャパシティプランニングへの影響を最小限に抑えます。
セルフマネージドソリューションは、ワーカーノードでコントローラーやその他のコンポーネントを実行するためのワーカーノードリソース、クラスター IP、その他のクラスターリソースを直接消費します。クラスターサービスを管理するには、ワークロードのキャパシティプランニングが必要であり、スケールと高可用性の要件を管理するためにリソースのリクエストと制限を計画して設定する必要があります。
**機能のサポート**
EKS 機能は完全マネージド型のサービス機能であるため、セルフマネージドソリューションと比べると、本質的に自由度が低くなります。ほとんどの特徴とユースケースをサポートしますが、セルフマネージドソリューションと比べると、カバレッジに違いがあります。
セルフマネージドソリューションを使用すると、ソフトウェアの設定やオプションなど機能性のさまざまな側面を完全に制御できます。独自のカスタムイメージを実行する、設定のあらゆる側面をカスタマイズする、セルフマネージドソリューションの機能性を完全に制御するといったこともできます。
**コストについて**
EKS 機能のリソースごとに時間単位でコストが伴います。これは機能タイプによって異なります。EKS 機能で管理されるクラスターリソースにも、独自の料金に関連付けられた時間単位のコストが伴います。詳細については「[Amazon EKS の料金](https://aws.amazon.com/eks/pricing/)」を参照してください。
セルフマネージドソリューションには AWS の料金に関連する直接コストはありませんが、コントローラーおよび関連するワークロードでクラスターコンピューティングリソースが使用された場合には料金が発生します。ノードとクラスターのリソースの消費以外にも、セルフマネージドソリューションに伴う総所有コストには、メンテナンス、トラブルシューティング、サポートの運用にかかるオーバーヘッドとコストが含まれます。
### EKS 機能かセルフマネージドソリューションかを選択する
**EKS 機能** 基本要件を満たすためにクラスタープラットフォームを運用することではなく、運用オーバーヘッドを削減し、ソフトウェアとシステムの差別化された価値に集中する場合は、この選択肢を検討してください。セキュリティパッチとソフトウェアライフサイクル管理の運用に伴う負担を最小限に抑える、アプリケーションワークロードのノードとクラスターのリソースを解放する、設定とセキュリティ管理をシンプルにする、AWS サポートカバレッジからメリットが得られるといった場合は、EKS 機能を使用します。EKS 機能は、本番稼働のほとんどのユースケースに最適であり、新規デプロイに推奨されるアプローチです。
**セルフマネージドソリューション** 特定の Kubernetes リソース API バージョンを必要とする、コントローラーを独自に構築する、既存の自動化とツールがセルフマネージドデプロイを軸に構築されている、コントローラーランタイム設定をきめ細かくカスタマイズする必要があるといったは、この選択肢を検討します。セルフマネージドソリューションでは、特殊なユースケースに柔軟に対処し、デプロイとランタイム設定を完全に制御できます。
**注記**
EKS 機能をクラスター内でセルフマネージドソリューションと共存させることができるため、段階的に移行を進めることができます。
### 機能固有の比較
機能に固有の特徴、アップストリームの違い、移行パスなどの詳細な比較については、以下を参照してください。
+ [EKS Capability for ACK とセルフマネージド ACK を比較する](ack-comparison.md)
+ [EKS Capability for Argo CD とセルフマネージド Argo CD を比較する](argocd-comparison.md)
+ [EKS Capability for kro とセルフマネージド kro の比較](kro-comparison.md)
# Kubernetes 用 AWS コントローラー (ACK) で Kubernetes から AWS リソースをデプロイする
Kubernetes 用 AWS コントローラー (ACK) を使用すると、Kubernetes から直接 AWS サービスリソースを定義および管理できます。Kubernetes 用 AWS コントローラー (ACK) により、Kubernetes カスタムリソースを使用してワークロードリソースとクラウドインフラストラクチャを管理できるほか、使い慣れた Kubernetes API とツールを使用してアプリケーションワークロードも管理できます。
AWS では EKS の機能を使用して ACK を完全に管理できるため、クラスターに ACK コントローラーをインストールして保守およびスケールする必要がありません。
## ACK の仕組み
ACK は、Kubernetes カスタムリソース仕様を AWS API コールに変換します。AWS サービスリソースを表す Kubernetes カスタムリソースを作成、更新、または削除すると、ACK は AWS リソースを作成、更新、または削除するために必要な AWS API コールを実行します。
ACK でサポートされている AWS リソースごとに独自のカスタムリソース定義 (CRD) を用意して、そのリソース設定を指定するための Kubernetes API スキーマを定義します。例えば、S3 の CRD にバケットやバケットポリシーなどの S3 リソースを含めることができます。
ACK は、Kubernetes カスタムリソースに定義された目的の状態に合わせて AWS リソースの状態を継続的に調整します。リソースが目的の状態からドリフトした場合、ACK はそれを検出し、是正アクションを実行して調整し直します。Kubernetes リソースへの変更は、すぐに AWS リソースの状態に反映されます。一方、アップストリームの AWS リソースに対する変更の場合、ドリフトをパッシブに検出して修復するには 10 時間もかかることがありますが (再同期期間)、通常ははるかに早く終了します。
**S3 バケットリソースマニフェストの例**
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-ack-bucket
spec:
name: my-unique-bucket-name
```
このカスタムリソースをクラスターに適用すると、アカウントに Amazon S3 バケットがまだ存在しない場合には ACK によって作成されます。以後、このリソースに変更を加えた場合、例えばデフォルト以外のストレージ階層を指定したりポリシーを追加したりすると、その変更が AWS 内の S3 リソースに適用されます。このリソースがクラスターから削除されると、デフォルトでは AWS 内の S3 バケットも削除されます。
## ACK のメリット
ACK では Kubernetes ネイティブの AWS リソース管理を利用できるため、普段アプリケーションで使用しているのと同じ Kubernetes API とツールで AWS リソースを管理できます。このように統合が図られているため、さまざまなツールを切り替えたり、Infrastructure as Code 管理ワークフローを個別に習得したりする必要がありません。Kubernetes マニフェストで AWS リソースを宣言的に定義して、GitOps ワークフローとインフラストラクチャを、既存の開発プロセスとシームレスに統合するコードプラクティスとして有効にします。
ACK は、AWS リソースの目的の状態を実際の状態で継続的に調整し、ドリフトを修正して、インフラストラクチャ全体の一貫性を確保します。このように継続的に調整することで、AWS リソースに必須の帯域外変更が、宣言した設定に合わせて自動的に元に戻されるため、Infrastructure as Code の整合性が維持されます。複数の AWS アカウントとリージョンにわたるリソースを管理するように ACK を設定することで、他にツールを追加することなく、複雑なマルチアカウントアーキテクチャを実現できます。
組織全体で他のインフラストラクチャ管理ツールから移行するできるように、ACK がリソースの採用をサポートしているため、再作成することなく既存の AWS リソースを ACK の管理下に置くことができます。ACK ではこのほか、読み取り専用リソースにより、変更アクセス権がなくても AWS リソースを監視でき、注釈により、Kubernetes リソースがクラスターから削除された場合でもオプションで AWS リソースを保持できます。
EKS Capability for ACK の詳細と使用開始については、「[ACK の概念](ack-concepts.md)」および「[EKS を利用する場合の ACK の考慮事項](ack-considerations.md)」を参照してください。
## サポートされる AWS サービス
ACK は、次のような幅広い AWS サービスをサポートしています。
+ Amazon EC2
+ Amazon S3
+ Amazon RDS
+ Amazon DynamoDB
+ Amazon ElastiCache
+ Amazon EKS
+ Amazon SQS
+ Amazon SNS
+ AWS Lambda
+ AWS IAM
一般提供アップストリームとしてリストされているすべての AWS サービスが、EKS Capability for ACK でサポートされています。詳細については、[サポートされている AWS サービスの完全なリスト](https://aws-controllers-k8s.github.io/community/docs/community/services/)を参照してください。
## 他の EKS マネージド機能との統合
ACK は、他の EKS マネージド機能と統合されています。
+ **Argo CD**: Argo CD を使用すると、複数のクラスターにまたがる ACK リソースのデプロイを管理して、AWS インフラストラクチャの GitOps ワークフローを有効にできます。
+ ACK を ArgoCD と組み合わせると GitOps のメリットが広がりますが、ACK を git と統合する必要はありません。
+ **kro (Kube Resource Orchestrator)**: kro を使用すると、ACK リソースから複雑なリソースを作成して、高次の抽象化を作成してリソース管理をシンプルにできます。
+ kro で Kubernetes リソースと AWS リソースの両方を定義することで、複合カスタムリソースを作成できます。チームメンバーは、こうしたカスタムリソースを使用して、複雑なアプリケーションをすばやくデプロイできます。
## ACK の使用を開始する
EKS Capability for ACK の使用を開始するには:
1. 自分の代わりに ACK で AWS リソースを管理できるように、IAM 機能ロールを作成して、必要なアクセス許可を設定します。
1. AWS コンソール、AWS CLI、または任意の Infrastructure as Code ツールを使用して、EKS クラスターに [ACK 機能リソースを作成](create-ack-capability.md)します。
1. Kubernetes カスタムリソースをクラスターに適用して、Kubernetes での AWS リソースの管理を開始します。
# ACK 機能を作成する
この章では、Amazon EKS クラスターに ACK 機能を作成する方法について説明します。
## 前提条件
ACK 機能を作成する前に、以下の点を確認してください。
+ Amazon EKS クラスター
+ ACK で AWS リソースを管理するためのアクセス許可が IAM 機能ロールに付与されている
+ EKS クラスターに機能リソースを作成するための十分な IAM アクセス許可がある
+ 適切な CLI ツールがインストールおよび設定されているか、EKS コンソールにアクセスできる
IAM 機能ロールを作成する手順については、「[Amazon EKS 機能 IAM ロール](capability-role.md)」を参照してください。
**重要**
ACK は、AWS リソースを作成、変更、削除する権限を付与するインフラストラクチャ管理機能です。これは、制御に慎重を要する管理者範囲の機能です。クラスターに Kubernetes リソースを作成するためのアクセス許可があれば誰でも、IAM 機能ロールのアクセス許可に従って、ACK で AWS リソースを効果的に作成できます。ACK でどの AWS リソースを作成および管理できるかは、どの IAM 機能ロールを使用するかによって決まります。最小特権のアクセス許可を付与した適切なロールを作成する際のガイダンスについては、「[Amazon EKS 機能 IAM ロール](capability-role.md)」および「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。
## ツールを選択する
AWS マネジメントコンソール、AWS CLI、または eksctl を使用して、ACK 機能を作成できます。
+ [コンソールを使用して ACK 機能を作成する](ack-create-console.md) - 指示に従って操作する場合はコンソールを使用します。
+ [AWS CLI を使用して ACK 機能を作成する](ack-create-cli.md) - スクリプトを作成して自動化を図る場合は AWS CLI を使用します。
+ [eksctl を使用して ACK 機能を作成する](ack-create-eksctl.md) - Kubernetes ネイティブの操作をする場合は eksctl を使用します。
## ACK 機能を作成するとどうなるか
ACK 機能を作成すると、次のようになります。
1. EKS が、ACK 機能サービスを作成して、クラスター内のリソースをモニタリングおよび管理するように設定します。
1. カスタムリソース定義 (CRD) がクラスターにインストールされます。
1. Kubernetes のベースラインアクセス許可を付与する機能固有のアクセスエントリポリシーを使用して、IAM 機能ロールのアクセスエントリを自動的に作成します (「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照)。
1. 機能が、指定した IAM 機能ロールを引き受けます。
1. ACK が、クラスター内のカスタムリソースを監視し始めます。
1. 機能のステータスが `CREATING` から `ACTIVE` に変わります。
アクティブになったら、AWS リソースを管理するための ACK カスタムリソースをクラスターに作成できます。
**注記**
自動的に作成されたアクセスエントリには、AWS リソースを管理するための ACK アクセス許可を付与する `AmazonEKSACKPolicy` が含まれます。Kubernetes シークレットを参照する一部の ACK リソース (パスワード付きの RDS データベースなど) には、追加のアクセスエントリポリシーが必要です。アクセスエントリの詳細と追加のアクセス許可の設定方法については、「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。
## 次のステップ
ACK 機能の作成後:
+ [ACK の概念](ack-concepts.md) - ACK の概念を理解し、AWS リソースの使用を開始する
+ [ACK の概念](ack-concepts.md) - 調整、フィールドエクスポート、リソース採用パターンについて学ぶ
+ [ACK アクセス許可を設定する](ack-permissions.md) - IAM アクセス許可およびマルチアカウントパターンを設定する
# コンソールを使用して ACK 機能を作成する
このトピックでは、AWS マネジメントコンソール を使用して Kubernetes 用 AWS コントローラー (ACK) 機能を作成する方法について説明します。
## ACK 機能を作成する
1. https://console.aws.amazon.com/eks/home\$1/clusters で Amazon EKS コンソールを開きます。
1. クラスター名を選択して、クラスターの詳細ページを開きます。
1. **[機能]** タブを選択します。
1. 左側のナビゲーションで、**[Kubernetes 用 AWS コントローラー (ACK)]** を選択します。
1. **[Kubernetes 用 AWS コントローラー (ACK) 機能]** を選択します。
1. **IAM 機能ロール**に対して以下の操作を行います。
+ IAM 機能ロールが既に存在する場合は、ドロップダウンから選択します。
+ ロールを作成する必要がある場合は、**[管理者ロールを作成]** を選択します。
IAM コンソールが新しいタブに開かれます。信頼ポリシーと `AdministratorAccess` 管理ポリシーには、値があらかじめ入力されています。このポリシーを選択解除し、必要に応じて他のアクセス許可を追加できます。
ロールを作成して EKS コンソールに戻ると、そのロールが自動的に選択されます。
**重要**
提案された `AdministratorAccess` ポリシーは、幅広いアクセス許可を付与し、使用開始を効率化することを目的としています。本番稼働で使用する場合は、これをカスタムポリシーに置き換えて、そのポリシーでは ACK で管理する特定の AWS サービスに必要なアクセス許可のみを付与します。最小特権ポリシーを作成する際のガイダンスについては、「[ACK アクセス許可を設定する](ack-permissions.md)」および「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。
1. **[作成]** を選択します。
機能作成プロセスが始まります。
## 機能がアクティブであることを確認する
1. **[機能]** タブで、ACK 機能のステータスを表示します。
1. ステータスが `CREATING` から `ACTIVE` に変わるまで待ちます。
1. アクティブになったら、この機能を使用する準備は完了です。
機能のステータスとトラブルシューティングの詳細については、「[機能リソースの使用](working-with-capabilities.md)」を参照してください。
## カスタムリソースが使用可能であることを確認する
機能がアクティブになったら、ACK カスタムリソースがクラスターで使用可能になっていることを確認します。
**コンソールの使用**
1. Amazon EKS コントロールでクラスターに移動します。
1. **[リソース]** タブを選択します。
1. **[拡張機能]** を選択します。
1. **[CustomResourceDefinitions]** を選択します。
AWS リソースに使用可能な多数の CRD がリストされます。
**kubectl を使用する**
```
kubectl api-resources | grep services.k8s.aws
```
AWS リソースに使用可能な多数の API がリストされます。
**注記**
Kubernetes 用 AWS コントローラーの機能は、さまざまな AWS リソース用に多数の CRD をインストールします。
## 次のステップ
+ [ACK の概念](ack-concepts.md) - ACK の概念を理解して使用を開始する
+ [ACK アクセス許可を設定する](ack-permissions.md) - 他の AWS サービスに対して IAM アクセス許可を設定する
+ [機能リソースの使用](working-with-capabilities.md) - ACK 機能リソースを管理する
# AWS CLI を使用して ACK 機能を作成する
このトピックでは、AWS CLI を使用して Kubernetes 用 AWS コントローラー (ACK) 機能を作成する方法について説明します。
## 前提条件
+ **AWS CLI** バージョン `2.12.3` 以降。バージョンを確認するには、`aws --version` を実行します。詳細についてはAWS コマンドラインインターフェイスユーザーガイドの「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。
+ **`kubectl`** - Kubernetes クラスターを操作するためのコマンドラインツール。詳細については、「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
## ステップ 1: IAM 機能ロールを作成する
信頼ポリシーファイルを作成します。
```
cat > ack-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
IAM ロールを作成します。
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://ack-trust-policy.json
```
`AdministratorAccess` マネージドポリシーをロールにアタッチします。
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
```
**重要**
提案された `AdministratorAccess` ポリシーは、幅広いアクセス許可を付与し、使用開始を効率化することを目的としています。本番稼働で使用する場合は、これをカスタムポリシーに置き換えて、そのポリシーでは ACK で管理する特定の AWS サービスに必要なアクセス許可のみを付与します。最小特権ポリシーを作成する際のガイダンスについては、「[ACK アクセス許可を設定する](ack-permissions.md)」および「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。
## ステップ 2: ACK 機能を作成する
ACK 機能リソースをクラスターに作成します。*region-code* はクラスターがある AWS リージョンに、*my-cluster* はクラスターの名前に置き換えます。
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack \
--type ACK \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ACKCapabilityRole \
--delete-propagation-policy RETAIN
```
このコマンドはすぐに戻りますが、EKS が必要な機能インフラストラクチャとコンポーネントを作成するため、機能がアクティブになるまでにはしばらく時間がかかります。EKS は、この機能に関連する Kubernetes カスタムリソース定義をその作成時にクラスターにインストールします。
**注記**
クラスターが存在しないというエラーやアクセス許可がないというエラーが表示された場合は、以下の点を確認します。
クラスター名が正しいこと
AWS CLI が正しいリージョンに設定されていること
必要な IAM アクセス許可を追加したこと
## ステップ 3: 機能がアクティブであることを確認する
機能がアクティブになるまで待機します。*region-code* はクラスターがある AWS リージョンに、*my-cluster* はクラスターの名前に置き換えます。
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack \
--query 'capability.status' \
--output text
```
ステータスが `ACTIVE` と表示されたら、機能の準備は完了です。ステータスが `ACTIVE` になるまで、次のステップに進まないでください。
機能の詳細全体を表示することもできます。
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack
```
## ステップ 4: カスタムリソースが使用可能であることを確認する
機能がアクティブになったら、ACK カスタムリソースがクラスターで使用可能になっていることを確認します。
```
kubectl api-resources | grep services.k8s.aws
```
AWS リソースに使用可能な多数の API がリストされます。
**注記**
Kubernetes 用 AWS コントローラーの機能は、さまざまな AWS リソース用に多数の CRD をインストールします。
## 次のステップ
+ [ACK の概念](ack-concepts.md) - ACK の概念を理解して使用を開始する
+ [ACK アクセス許可を設定する](ack-permissions.md) - 他の AWS サービスに対して IAM アクセス許可を設定する
+ [機能リソースの使用](working-with-capabilities.md) - ACK 機能リソースを管理する
# eksctl を使用して ACK 機能を作成する
このトピックでは、eksctl を使用して Kubernetes 用 AWS コントローラー (ACK) 機能を作成する方法について説明します。
**注記**
以下のステップを実行するには、eksctl バージョン `0.220.0` 以降が必要です。バージョンを確認するには、`eksctl version` を実行します。
## ステップ 1: IAM 機能ロールを作成する
信頼ポリシーファイルを作成します。
```
cat > ack-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
IAM ロールを作成します。
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://ack-trust-policy.json
```
`AdministratorAccess` マネージドポリシーをロールにアタッチします。
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
```
**重要**
提案された `AdministratorAccess` ポリシーは、幅広いアクセス許可を付与し、使用開始を効率化することを目的としています。本番稼働で使用する場合は、これをカスタムポリシーに置き換えて、そのポリシーでは ACK で管理する特定の AWS サービスに必要なアクセス許可のみを付与します。最小特権ポリシーを作成する際のガイダンスについては、「[ACK アクセス許可を設定する](ack-permissions.md)」および「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。
**重要**
このポリシーは、`"Resource": "*"` で S3 バケット管理に必要なアクセス許可を付与して、すべての S3 バケットに対してオペレーションを実行できるようにします。
本番稼働で使用する場合: \$1 `Resource` フィールドを特定のバケット ARN または名前パターンに制限します。\$1 IAM 条件キーを使用すると、リソースタグでアクセスを制限できます。\$1 ユースケースに必要な最小限のアクセス許可のみを付与します。
その他の AWS サービスについては、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。
ロールにポリシーを付与します。
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):policy/ACKS3Policy
```
## ステップ 2: ACK 機能を作成する
eksctl を使用して ACK 機能を作成します。*region-code* はクラスターがある AWS リージョンに、*my-cluster* はクラスターの名前に置き換えます。
```
eksctl create capability \
--cluster [.replaceable]`my-cluster` \
--region [.replaceable]`region-code` \
--name ack \
--type ACK \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ACKCapabilityRole \
--ack-service-controllers s3
```
**注記**
`--ack-service-controllers` フラグはオプションです。省略した場合、ACK は使用可能なすべてのコントローラーを有効にします。パフォーマンスとセキュリティを高めるため、必要なコントローラーのみを有効にすることを検討してください。`--ack-service-controllers s3,rds,dynamodb` のように、複数のコントローラーを指定できます。
このコマンドはすぐに戻りますが、機能がアクティブになるまでにはしばらく時間がかかります。
## ステップ 3: 機能がアクティブであることを確認する
機能のステータスを確認します。
```
eksctl get capability \
--cluster [.replaceable]`my-cluster` \
--region [.replaceable]`region-code` \
--name ack
```
ステータスが `ACTIVE` と表示されたら、機能の準備は完了です。
## ステップ 4: カスタムリソースが使用可能であることを確認する
機能がアクティブになったら、ACK カスタムリソースがクラスターで使用可能になっていることを確認します。
```
kubectl api-resources | grep services.k8s.aws
```
AWS リソースに使用可能な多数の API がリストされます。
**注記**
Kubernetes 用 AWS コントローラーの機能は、さまざまな AWS リソース用に多数の CRD をインストールします。
## 次のステップ
+ [ACK の概念](ack-concepts.md) - ACK の概念を理解して使用を開始する
+ [ACK アクセス許可を設定する](ack-permissions.md) - 他の AWS サービスに対して IAM アクセス許可を設定する
+ [機能リソースの使用](working-with-capabilities.md) - ACK 機能リソースを管理する
# ACK の概念
ACK は、AWS の実際の状態に照らしてマニフェストの目的の状態を継続的に調整することで、Kubernetes API を利用して AWS リソースを管理します。Kubernetes カスタムリソースを作成または更新すると、ACK は対応する AWS リソースを作成または変更するために必要な AWS API コールを実行し、ドリフトがないかモニタリングして、現在の状態を反映するように Kubernetes ステータスを更新します。このアプローチにより、クラスターと AWS との一貫性を維持しながら、使い慣れた Kubernetes ツールとワークフローを使用してインフラストラクチャを管理できます。
このトピックでは、ACK が Kubernetes API を利用して AWS リソースを管理する際の土台となる概念について説明します。
## ACK の使用を開始する
ACK 機能を作成したら (「[ACK 機能を作成する](create-ack-capability.md)」を参照)、クラスターで Kubernetes マニフェストを使用して AWS リソースの管理を開始できます。
例えば、`bucket.yaml` でこの S3 バケットマニフェストを作成して、独自のバケット名を選択します。
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-test-bucket
namespace: default
spec:
name: my-unique-bucket-name-12345
```
マニフェストを適用します。
```
kubectl apply -f bucket.yaml
```
ステータスを確認します。
```
kubectl get bucket my-test-bucket
kubectl describe bucket my-test-bucket
```
AWS にバケットが作成されたことを確認します。
```
aws s3 ls | grep my-unique-bucket-name-12345
```
Kubernetes リソースを削除します。
```
kubectl delete bucket my-test-bucket
```
AWS からバケットが削除されたことを確認します。
```
aws s3 ls | grep my-unique-bucket-name-12345
```
バケットがリストに表示されなくなるはずです。つまり、ACK で AWS リソースのライフサイクル全体を管理できていることになります。
ACK の使用を開始する方法の詳細については、「[ACK の使用を開始する](https://aws-controllers-k8s.github.io/community/docs/user-docs/getting-started/)」を参照してください。
## リソースのライフサイクルと調整
ACK は、継続的な調整ループを使用して、AWS リソースが Kubernetes マニフェストに定義された目的の状態と一致するようにします。
**調整の仕組み**:
1. ユーザーが Kubernetes カスタムリソース (S3 バケットなど) を作成または更新します。
1. ACK がその変更を検出し、目的の状態を AWS の実際の状態と比較します。
1. 両者が異なる場合、ACK は AWS API コールを実行して差分を調整します。
1. ACK が現在の状態を反映するように Kubernetes のリソースステータスを更新します。
1. このループが通常数時間ごとに継続的に繰り返されます。
調整がトリガーされるのは、Kubernetes リソースを新規に作成したとき、既存のリソースの `spec` を更新したとき、または ACK 外での手動変更によって AWS でドリフトが発生したことを ACK が検出したときです。また、ACK は 10 時間という再同期期間で定期的に調整を行います。Kubernetes リソースを変更した場合は即時調整がトリガーされるのに対して、アップストリームの AWS リソースを変更した場合はパッシブなドリフト検出が定期的な再同期で行われます。
上記のように使用を開始すると、ACK は次のステップを実行します。
1. バケットが AWS に存在するかどうかを確認します。
1. 存在しない場合は、`s3:CreateBucket` を呼び出します。
1. バケットの ARN と状態で Kubernetes ステータスを更新します。
1. ドリフトがないか継続的にモニタリングします。
ACK の仕組みの詳細については、「[ACK 調整](https://aws-controllers-k8s.github.io/community/docs/user-docs/reconciliation/)」を参照してください。
## ステータス条件
ACK リソースは、ステータス条件を使用してリソースの状態を伝えます。ステータス条件を理解すると、問題のトラブルシューティングとリソース状態の把握に役立ちます。
+ **Ready**: リソースを消費する準備ができていることを示します (標準化された Kubernetes 条件)。
+ **ACK.ResourceSynced**: リソース仕様が AWS リソースの状態と一致することを示します。
+ **ACK.Terminal**: 回復不能なエラーが発生したことを示します。
+ **ACK.Adopted**: リソースが新規に作成されたのではなく既存の AWS リソースから採用されたことを示します。
+ **ACK.Recoverable**: 回復可能なエラーであるものの、仕様を更新することなく解決可能であることを示します。
+ **ACK.Advisory**: リソースのアドバイザリ情報を提供します。
+ **ACK.LateInitialized**: フィールドの遅延初期化が完了しているかどうかを示します。
+ **ACK.ReferencesResolved**: すべての `AWSResourceReference` フィールドが解決されたかどうかを示します。
+ **ACK.IAMRoleSelected**: このリソースを管理するために IAMRoleSelector が選択されたかどうかを示します。
リソースのステータスを確認する:
```
# Check if resource is ready
kubectl get bucket my-bucket -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
# Check for terminal errors
kubectl get bucket my-bucket -o jsonpath='{.status.conditions[?(@.type=="ACK.Terminal")]}'
```
ステータスの例:
```
status:
conditions:
- type: Ready
status: "True"
lastTransitionTime: "2024-01-15T10:30:00Z"
- type: ACK.ResourceSynced
status: "True"
lastTransitionTime: "2024-01-15T10:30:00Z"
- type: ACK.Terminal
status: "True"
ackResourceMetadata:
arn: arn:aws:s3:::my-unique-bucket-name
ownerAccountID: "111122223333"
region: us-west-2
```
ACK のステータスと条件の詳細については、「[ACK の条件](https://aws-controllers-k8s.github.io/community/docs/user-docs/conditions/)」を参照してください。
## 削除ポリシー
ACK の削除ポリシーは、Kubernetes AWS リソースを削除したときにリソースがどうなるかを制御します。
**削除する (デフォルト)**
Kubernetes リソースを削除すると、AWS リソースも削除されます。これがデフォルトの動作です。
```
# No annotation needed - this is the default
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: temp-bucket
spec:
name: temporary-bucket
```
このリソースを削除すると、AWS の S3 バケットも削除されます。
**Retain**:
AWS リソースは、Kubernetes リソースを削除しても保持されます。
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: important-bucket
annotations:
services.k8s.aws/deletion-policy: "retain"
spec:
name: production-data-bucket
```
このリソースを削除すると、Kubernetes から削除されますが、S3 バケットは AWS に残ります。
本番稼働用データベースでは、Kubernetes リソース、複数のアプリケーションで使用される共有リソース、誤って削除されてはならない重要なデータがあるリソースを長く維持する必要があります。また、リソースを採用して設定した後、手動管理に戻すという一時的な ACK 管理も必要です。`retain` ポリシーは、こうした用途に有益です。
ACK 削除ポリシーの詳細については、「[ACK 削除ポリシー](https://aws-controllers-k8s.github.io/community/docs/user-docs/deletion-policy/)」を参照してください。
## リソースの採用
リソースを採用すると、既存の AWS リソースを再作成することなく ACK の管理下に置くことができます。
どのような場合に採用するか:
+ 既存のインフラストラクチャを ACK 管理に移行する場合
+ Kubernetes で AWS リソースを誤って削除したときに孤立したリソースを復旧する場合
+ 他のツール (CloudFormation や Terraform) で作成されたリソースをインポートする場合
採用の仕組み:
```
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
```
このリソースを作成すると、次のようになります。
1. ACK が、その名前のバケットが AWS に存在するかどうかを確認します。
1. 存在すれば、ACK はそのバケットを採用します (API コールは作成されません)。
1. ACK が AWS から現在の設定を読み取ります。
1. ACK が実際の状態を反映するように Kubernetes ステータスを更新します。
1. 今後の更新でリソースを正常に調整します。
採用されたら、リソースは他の ACK リソースと同様に管理され、`retain` 削除ポリシーを使用しない限り、Kubernetes リソースを削除すると、AWS リソースも削除されます。
リソースを採用するときに、AWS リソースは既に存在している必要があり、それを検出するためには ACK に読み取りアクセス許可が必要です。`adopt-or-create` ポリシーは、リソースが存在すれば採用し、存在しなければ作成します。これは、リソースが存在するかどうかにかかわらず宣言型ワークフローを機能させるときに便利です。
ACK リソースの採用の詳細については、「[ACK リソースの採用](https://aws-controllers-k8s.github.io/community/docs/user-docs/adopted-resource/)」を参照してください。
## クロスアカウントおよびクロスリージョンのリソース
ACK は、1 つのクラスターからさまざまな AWS アカウントとリージョンのリソースを管理できます。
**クロスリージョンリソースの注釈**
注釈を使用すると、AWS リソースのリージョンを指定できます。
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: eu-bucket
annotations:
services.k8s.aws/region: eu-west-1
spec:
name: my-eu-bucket
```
特定の名前空間に作成されたすべての AWS リソースのリージョンを指定することもできます。
**名前空間の注釈**
名前空間内のすべてのリソースに対してデフォルトのリージョンを設定します。
```
apiVersion: v1
kind: Namespace
metadata:
name: production
annotations:
services.k8s.aws/default-region: us-west-2
```
この名前空間に作成されたリソースは、リソースレベルの注釈で上書きされない限り、このリージョンを使用します。
**クロスアカウント**
IAM ロールセレクターを使用すると、特定の IAM ロールを名前空間にマッピングできます。
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: target-account-config
spec:
arn: arn:aws:iam::444455556666:role/ACKTargetAccountRole
namespaceSelector:
names:
- production
```
マッピングされた名前空間に作成されたリソースは、指定されたロールを自動的に使用します。
IAM ロールセレクターの詳細については、「[ACK クロスアカウントリソース管理](https://aws-controllers-k8s.github.io/docs/guides/cross-account)」を参照してください。クロスアカウント設定の詳細については、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。
## エラー処理と再試行動作
ACK は、一時的なエラーを自動的に処理し、失敗したオペレーションを再試行します。
再試行戦略:
+ 一時的なエラー (レート制限、サービスの一時的な問題、不十分なアクセス許可) が発生したら、自動再試行をトリガーします。
+ エクスポネンシャルバックオフにより、AWS API が過剰になるのを防ぎます。
+ エラータイプに応じて最大再試行回数を変えます。
+ 永続的なエラー (無効なパラメータ、リソース名の競合) は再試行されません。
`kubectl describe` を使用して、エラーの詳しい情報がないかリソースのステータスを確認します。
```
kubectl describe bucket my-bucket
```
エラーメッセージでステータス条件を確認し、最近調整を試みたことを示すイベントがないかチェックし、ステータス条件の `message` フィールドで障害に関する説明を参照します。よくあるエラーには、IAM アクセス許可が十分でない、AWS でリソース名が競合している、`spec` に無効な設定値がある、AWS サービスクォータが超過しているといったことがあります。
よくあるエラーのトラブルシューティングについては、「[ACK 機能に関する問題をトラブルシューティングする](ack-troubleshooting.md)」を参照してください。
## kro によるリソース構成
複数の ACK リソースをまとめて作成および接続するには、EKS Capability for kro (Kube Resource Orchestrator) を使用します。kro を使用すると、リソースのグループを宣言的に定義し、リソース間で設定を渡して、複雑なインフラストラクチャパターンを容易に管理できます。
ACK リソースでカスタムリソース構成を作成する詳細な例については、「[kro の概念](kro-concepts.md)」を参照してください。
## 次のステップ
+ [EKS を利用する場合の ACK の考慮事項](ack-considerations.md) - EKS に固有のパターンと統合戦略
# ACK アクセス許可を設定する
自分の代わりに ACK で AWS リソースを作成および管理できるようにするには、IAM アクセス許可が必要です。このトピックでは、IAM が ACK でどのように機能するかを説明し、さまざまなユースケースに合わせてアクセス許可を設定する際のガイダンスを示します。
## IAM は ACK でどのように機能するか
ACK は、IAM ロールを使用して AWS で認証し、リソースに対してアクションを実行します。ACK にアクセス許可を付与する方法が 2 つあります。
**機能ロール**: ACK 機能の作成時に指定する IAM ロールです。このロールは、デフォルトではすべての ACK オペレーションに使用されます。
**IAM ロールセレクター**: 特定の名前空間またはリソースにマッピングできる追加の IAM ロールです。これらのロールの範囲内にあるリソースの機能ロールは上書きされます。
リソースを作成または管理する必要があるときに、ACK はどの IAM ロールを使用するかを決定します。
1. IAMRoleSelector がリソースの名前空間に一致するかどうかを確認します。
1. 一致した場合、その IAM ロールを引き受けます。
1. 一致しない場合、機能ロールを使用します。
このアプローチにより、シンプルな単一ロールセットアップから複雑なマルチアカウントかつマルチチームの設定まで、アクセス許可を柔軟に管理できます。
## 使用開始: シンプルなアクセス許可セットアップ
開発、テスト、またはシンプルなユースケースの場合、必要なすべてのサービスアクセス許可を機能ロールに直接追加できます。
このアプローチは、次の場合に適しています。
+ ACK の使用を開始している
+ すべてのリソースが同じ AWS アカウントにある
+ 1 つのチームがすべての ACK リソースを管理する
+ すべての ACK ユーザーに同じアクセス許可が付与されていると確信している
## 本番稼働でのベストプラクティス: IAM ロールセレクター
本番稼働環境では、IAM ロールセレクターを使用して、最小特権のアクセスと名前空間レベルでの分離を実装します。
IAM ロールセレクターを使用する場合、機能ロールに必要なアクセス許可はサービス固有のロールを引き受けるための `sts:AssumeRole` および `sts:TagSession` アクセス許可だけです。機能ロール自体に AWS サービスアクセス許可 (S3 や RDS など) を追加する必要はありません。そうしたアクセス許可は、機能ロールが引き受ける個々の IAM ロールに付与します。
**アクセス許可モデルを選択する**:
次の場合は、**直接アクセス許可** (機能ロールにサービスアクセス許可を追加すること) を使用します。
+ 使用を開始し、最もシンプルなセットアップにする場合
+ すべてのリソースがクラスターと同じアカウントにある場合
+ クラスター全体の管理アクセス許可を必要とする場合
+ すべてのチームが同じアクセス許可を共有できる場合
次の場合は、**IAM ロールセレクター**を使用します。
+ 複数の AWS アカウント全体のリソースを管理する場合
+ チームや名前空間ごとに異なるアクセス許可が必要な場合
+ 名前空間ごとにきめ細かなアクセスコントロールが必要な場合
+ 最小特権のセキュリティプラクティスに従う場合
直接アクセス許可から開始し、その後、要件の増大に応じて IAM ロールセレクターに移行できます。
**なぜ本番稼働で IAM ロールセレクターを使用するのか:**
+ **最小特権**: 名前空間ごとに必要なアクセス許可のみを取得します。
+ **チーム分離**: チーム A が誤ってチーム B のアクセス許可を使用することがないようにします。
+ **容易な監査**: どの名前空間がどのロールを使用するかを明確にマッピングします。
+ **クロスアカウントサポート**: 複数のアカウントのリソースを管理する場合に必要です。
+ **関心の分離**: サービスや環境ごとに異なるロールを使用します。
### 基本的な IAM ロールセレクターのセットアップ
**ステップ 1: サービス固有の IAM ロールを作成する**
特定の AWS サービスに対するアクセス許可を付与した IAM ロールを作成します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": "*"
}
]
}
```
機能ロールに引き受けられるように信頼ポリシーを設定します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
]
}
```
**ステップ 2: AssumeRole アクセス許可を機能ロールに付与する**
サービス固有のロールを引き受けるためのアクセス許可を機能ロールに追加します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::111122223333:role/ACK-S3-Role"
}
]
}
```
**ステップ 3: IAMRoleSelector を作成する**
名前空間に IAM ロールをマッピングします。
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: s3-namespace-config
spec:
arn: arn:aws:iam::111122223333:role/ACK-S3-Role
namespaceSelector:
names:
- s3-resources
```
**ステップ 4: マッピングした名前空間にリソースを作成する**
`s3-resources` 名前空間内のリソースは、指定されたロールを自動的に使用します。
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-bucket
namespace: s3-resources
spec:
name: my-production-bucket
```
## マルチアカウント管理
IAM ロールセレクターを使用すると、複数の AWS アカウントのリソースを管理できます。
**ステップ 1: クロスアカウント IAM ロールを作成する**
ターゲットアカウント (444455556666) に、ソースアカウントの機能ロールを信頼するロールを作成します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
]
}
```
このロールにサービス固有のアクセス許可をアタッチします。
**ステップ 2: AssumeRole アクセス許可を付与する**
ソースアカウント (111122223333) で、機能ロールがターゲットアカウントロールを引き受けられるようにします。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::444455556666:role/ACKTargetAccountRole"
}
]
}
```
**ステップ 3: IAMRoleSelector を作成する**
名前空間にクロスアカウントロールをマッピングします。
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: production-account-config
spec:
arn: arn:aws:iam::444455556666:role/ACKTargetAccountRole
namespaceSelector:
names:
- production
```
**ステップ 4: リソースを作成する**
`production` 名前空間内のリソースは、ターゲットアカウントに作成します。
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-bucket
namespace: production
spec:
name: my-cross-account-bucket
```
## セッションタグ
EKS ACK 機能は、すべての AWS API リクエストにセッションタグを自動的に設定します。これらのタグは、各リクエストのソースを特定することで、きめ細かなアクセスコントロールと監査を可能にします。
### 利用可能なセッションタグ
ACK によって行われるすべての AWS API コールには、次のセッションタグが含まれています。
| タグキー | 説明 |
| --- | --- |
| `eks:eks-capability-arn` | リクエストを行う EKS 機能の ARN |
| `eks:kubernetes-namespace` | 管理対象のリソースの Kubernetes 名前空間 |
| `eks:kubernetes-api-group` | リソースの Kubernetes API グループ (例: `s3.services.k8s.aws`) |
### セッションタグを使用したアクセス制御
これらのセッションタグを IAM ポリシー条件で使用して、ACK が管理できるリソースを制限できます。これにより、名前空間ベースの IAM ロールセレクターに加えて追加セキュリティレイヤーが設定されます。
**例: 名前空間による制限**
リクエストが `production` 名前空間から発信された場合にのみ、ACK が S3 バケットを作成できるようにします。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:CreateBucket",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/eks:kubernetes-namespace": "production"
}
}
}
]
}
```
**例: 機能による制限**
特定の ACK 機能からのアクションのみを許可します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/eks:eks-capability-arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack"
}
}
}
]
}
```
**注記**
セッションタグは、デフォルトでこれらのタグを設定しないセルフマネージド ACK とは異なります。これにより、マネージド機能によるより詳細なアクセスコントロールが可能になります。
## 高度な IAM ロールセレクターパターン
ラベルセレクターやリソース固有のロールマッピングなどの例に見られる高度な設定については、「[ACK IRSA ドキュメント](https://aws-controllers-k8s.github.io/community/docs/user-docs/irsa/)」を参照してください。
## 次のステップ
+ [ACK の概念](ack-concepts.md) - ACK の概念およびリソースライフサイクルを理解する
+ [ACK の概念](ack-concepts.md) - リソースの採用と削除ポリシーについて学ぶ
+ [EKS 機能のセキュリティに関する考慮事項](capabilities-security.md) - 機能のセキュリティベストプラクティスを理解する
# EKS を利用する場合の ACK の考慮事項
このトピックでは、IAM 設定、マルチアカウントパターン、他の EKS 機能との統合など、EKS Capability for ACK を使用する際の重要な考慮事項について説明します。
## IAM 設定のパターン
ACK 機能は、IAM 機能ロールを使用して AWS で認証します。要件に基づいて適切な IAM パターンを選択します。
### シンプル: 単一の機能ロール
開発、テスト、またはシンプルなユースケースの場合、必要なすべてのアクセス許可を機能ロールに直接付与します。
**どのようなときに使うか**:
+ ACK の使用を開始する
+ シングルアカウントでデプロイする
+ 1 つのチームがすべてのリソースを管理する
+ 開発環境とテスト環境
**例**: リソースのタグ付け条件に従って、S3 と RDS のアクセス許可を機能ロールに追加します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-west-2", "us-east-1"]
}
}
},
{
"Effect": "Allow",
"Action": ["rds:*"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-west-2", "us-east-1"]
},
}
}
]
}
```
この例では、S3 と RDS のオペレーションを特定のリージョンに制限し、RDS リソースに `ManagedBy: ACK` タグが必要です。
### 本番稼働: IAM ロールセレクター
本番稼働環境では、IAM ロールセレクターを使用して、最小特権のアクセスと名前空間レベルでの分離を実装します。
**どのようなときに使うか**:
+ 本番稼働環境
+ マルチチームクラスター
+ マルチアカウントリソース管理
+ 最小特権セキュリティ要件
+ サービスごとに異なるアクセス許可が必要
**利点:**
+ 名前空間ごとに必要なアクセス許可のみを取得できます。
+ チーム分離 - チーム A は、チーム B のアクセス許可を使用できません。
+ 監査とコンプライアンスが容易です。
+ クロスアカウントリソース管理に必須です。
IAM ロールセレクターの設定の詳細については、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。
## 他の EKS 機能との統合
### GitOps と Argo CD
EKS Capability for Argo CD を使用すると、Git リポジトリから ACK リソースをデプロイして、インフラストラクチャの管理に GitOps ワークフローを使用できます。
**考慮事項**:
+ エンドツーエンドの GitOps のアプリケーションマニフェストと共に ACK リソースを保存する
+ チーム構造に基づいて環境、サービス、またはリソースタイプ別に整理する
+ Argo CD の自動同期を使用して継続的に調整を行う
+ プルーニングを有効にして削除済みのリソースを自動的に除去する
+ マルチクラスターのインフラストラクチャ管理にハブアンドスポークパターンを検討する
GitOps は、監査証跡、ロールバック機能、および宣言型のインフラストラクチャ管理を備えています。Argo CD の詳細については、「[Argo CD の使用](working-with-argocd.md)」を参照してください。
### kro によるリソース構成
EKS Capability for kro (Kube Resource Orchestrator) を使用すると、複数の ACK リソースを高次の抽象化とカスタム API に構成できます。
**どのような場合に ACK で kro を使用するか**:
+ よく見られるインフラストラクチャスタック用に再利用可能なパターンを作成する場合 (データベース \$1 バックアップ \$1 モニタリング)
+ アプリケーションチーム向けに API をシンプルにしてセルフサービスプラットフォームを構築する場合
+ リソースの依存関係を管理し、リソース間で値を渡す (S3 バケット ARN を Lambda 関数に渡す) 場合
+ チーム間でインフラストラクチャ設定を標準化する場合
+ カスタムリソースの背後に実装の詳細を隠して複雑さを軽減する場合
**パターンの例**:
+ アプリケーションスタック: S3 バケット \$1 SQS キュー \$1 通知設定
+ データベースセットアップ: RDS インスタンス \$1 パラメータグループ \$1 セキュリティグループ \$1 シークレット
+ ネットワーク: VPC \$1 サブネット \$1 ルートテーブル \$1 セキュリティグループ
kro は、構成済みのリソースに対して依存関係の順序付け、ステータスの伝播、ライフサイクルの管理を行います。kro の詳細については、「[kro の概念](kro-concepts.md)」を参照してください。
## リソースを整理する
Kubernetes 名前空間と AWS リソースタグを使用して ACK リソースを整理すると、管理、アクセスコントロール、コスト追跡を改善できます。
### 名前空間の整理
Kubernetes 名前空間を使用すると、環境 (本番稼働、ステージング、開発)、チーム (プラットフォーム、データ、ml)、またはアプリケーション別に ACK リソースを論理的に分離できます。
**利点:**
+ アクセスコントロール用に RBAC を名前空間範囲で限定する
+ 注釈を使用して名前空間ごとにデフォルトリージョンを設定する
+ リソース管理とクリーンアップが容易になる
+ 組織構造に沿って論理的に分離できる
### リソースのタグ付け
EKS ACK 機能は、作成するすべての AWS リソースにデフォルトのタグを自動的に適用します。これらのタグはセルフマネージド ACK とは異なり、トレーサビリティが強化されています。
**この機能によって適用されるデフォルトのタグ**:
| タグキー | 説明 |
| --- | --- |
| `eks:controller-version` | ACK コントローラーのバージョン |
| `eks:kubernetes-namespace` | ACK リソースの Kubernetes 名前空間 |
| `eks:kubernetes-resource-name` | Kubernetes リソースの名前 |
| `eks:kubernetes-api-group` | Kubernetes API グループ (例: `s3.services.k8s.aws`) |
| `eks:eks-capability-arn` | EKS ACK 機能の ARN |
**注記**
セルフマネージド ACK は、`services.k8s.aws/controller-version` や `services.k8s.aws/namespace` といった異なるデフォルトタグを使用します。この機能のタグは、他の EKS 機能との一貫性を保つために `eks:` プレフィックスを使用します。
**その他の推奨タグ**:
コスト配分、所有権追跡、および整理目的でカスタムタグを追加します。
+ 環境 (本番稼働、ステージング、開発)
+ チームまたは部門の所有権
+ 請求を配分するためのコストセンター
+ アプリケーション名やサービス名
## 他の Infrastructure as Code ツールからの移行
多くの組織が、Kubernetes を土台にワークロードのオーケストレーションを超えた標準化を図ることに価値を見出しています。インフラストラクチャと AWS リソースの管理を ACK に移行することで、アプリケーションワークロードと共に Kubernetes API を使用してインフラストラクチャ管理を標準化できます。
**Kubernetes を土台にインフラストラクチャを標準化するメリット**:
+ **信頼できる単一のソース**: Kubernetes でアプリケーションとインフラストラクチャの両方を管理して、エンドツーエンドの GitOps プラクティスを実現する
+ **統一されたツール**: チームは Kubernetes のリソースとツールを使用すればよく、いくつものツールやフレームワークを学習する必要がない
+ **一貫性のある調整**: ACK は、Kubernetes がワークロードに対してそうであるように、AWS リソースを継続的に調整し、必須のツールと比較してドリフトを検出して修正する
+ **ネイティブコンポジション**: kro と ACK を一緒に使用して、アプリケーションとリソースのマニフェストで AWS リソースを直接参照し、リソース間で接続文字列と ARN を渡す
+ **シンプルなオペレーション**: 1 つのコントロールプレーンでシステム全体のデプロイ、ロールバック、オブザーバビリティを実現する
ACK は、AWS リソースを再作成せずに既存のものを採用するため、CloudFormation、Terraform、またはクラスター外のリソースからダウンタイムなしで移行できます。
**既存のリソースを採用する**:
```
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
```
採用されたリソースは、ACK によって管理され、Kubernetes マニフェストを介して更新できます。段階的に移行できるため、必要に応じてリソースを採用しながら、他のリソースでは既存の IaC ツールを維持できます。
また、ACK は読み取り専用リソースもサポートしています。他のチームやツールで管理されるリソースを変更するのではなく参照するだけにする場合は、採用と `retain` 削除ポリシーとを組み合わせて、読み取り IAM アクセス許可のみを付与します。これにより、アプリケーションは変更のリスクを冒すことなく Kubernetes API を介して共有インフラストラクチャ (VPC、IAM ロール、KMS キー) を検出できます。
リソースの採用の詳細については、「[ACK の概念](ack-concepts.md)」を参照してください。
## 削除ポリシー
削除ポリシーは、対応する Kubernetes リソースを削除したときに AWS リソースがどうなるかを制御します。リソースのライフサイクルと実際の運用要件に基づいて、適切なポリシーを選択します。
### 削除する (デフォルト)
Kubernetes リソースを削除すると、AWS リソースも削除されます。そのため、クラスターと AWS との一貫性が維持され、リソースの蓄積を防ぐことができます。
**どのような場合に削除を使用するか**:
+ 開発環境とテスト環境でクリーンアップが重要な場合
+ エフェメラルリソースがアプリケーションのライフサイクルに結びついている場合 (テストデータベースや一時バケット)
+ リソースがアプリケーションよりも長く存続してはいけない場合 (SQS キューや ElastiCache クラスター)
+ コスト最適化 - 未使用のリソースを自動的にクリーンアップする場合
+ GitOps で管理された環境で、Git からリソースが削除されたらインフラストラクチャも削除される場合
Kubernetes の宣言型モデルに合わせてデフォルトの削除ポリシーを調整します。クラスターの内容は AWS に存在するものと一致します。
### Retain
Kubernetes リソースを削除しても、AWS リソースは保持されます。これにより、重要なデータが保護され、リソースは Kubernetes 表現よりも長く存続できます。
**どのような場合に保持を使用するか**:
+ 本番稼働用データベースにクラスターの変更後も存続する必要がある重要なデータが保存されている場合
+ 長期ストレージバケットにコンプライアンス要件や監査要件がある場合
+ 複数のアプリケーションやチームが共有リソースを使用している場合
+ さまざまな管理ツールにリソースを移行する場合
+ ディザスタリカバリでインフラストラクチャを維持する場合
+ 廃止に慎重を要する複雑な依存関係がリソースにある場合
```
apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
name: production-db
annotations:
services.k8s.aws/deletion-policy: "retain"
spec:
dbInstanceIdentifier: prod-db
# ... configuration
```
**重要**
保持したリソースは、引き続き AWS コストが発生するため、不要になったら AWS から手動で削除する必要があります。リソースのタグ付けを使用すると、保持したリソースの中にクリーンアップが必要なものがないかを追跡できます。
削除ポリシーの詳細については、「[ACK の概念](ack-concepts.md)」を参照してください。
## アップストリームドキュメント
ACK の使用の詳細については、以下を参照してください。
+ [ACK 使用ガイド](https://aws-controllers-k8s.github.io/community/docs/user-docs/usage/) - リソースの作成および管理
+ [ACK API リファレンス](https://aws-controllers-k8s.github.io/community/reference/) - すべてのサービスの詳細な API ドキュメント
+ [ACK ドキュメント](https://aws-controllers-k8s.github.io/community/docs/) - ユーザー向けの包括的なドキュメント
## 次のステップ
+ [ACK アクセス許可を設定する](ack-permissions.md) - IAM アクセス許可およびマルチアカウントパターンを設定する
+ [ACK の概念](ack-concepts.md) - ACK の概念およびリソースライフサイクルを理解する
+ [ACK 機能に関する問題をトラブルシューティングする](ack-troubleshooting.md) - ACK の問題をトラブルシューティングする
+ [Argo CD の使用](working-with-argocd.md) - GitOps で ACK リソースをデプロイする
+ [kro の概念](kro-concepts.md) - ACK リソースを高次の抽象化に構成する
# ACK 機能に関する問題をトラブルシューティングする
このトピックでは、機能のヘルスチェック、リソースステータスの確認、IAM アクセス許可の問題など、EKS Capability for ACK をトラブルシューティングする際のガイダンスを示します。
**注記**
EKS の機能は完全に管理され、クラスターの外部で実行されます。コントローラーのログや名前空間にアクセスすることはできません。トラブルシューティングでは、機能のヘルス、リソースのステータス、IAM の設定に焦点を当てています。
## 機能がアクティブなのにリソースが作成されない
ACK 機能のステータスが `ACTIVE` なのに AWS にリソースが作成されない場合は、機能のヘルス、リソースのステータス、IAM アクセス許可を確認してください。
**機能のヘルスを確認する**:
機能のヘルスとステータスの問題は、EKS コンソールまたは AWS CLI を使用して表示できます。
**コンソール:**
1. https://console.aws.amazon.com/eks/home\$1/clusters で Amazon EKS コンソールを開きます。
1. クラスター名を選択します。
1. **[オブザーバビリティ]** タブを選択します。
1. **[クラスターを監視する]** を選択します。
1. **[機能]** タブを選択すると、すべての機能のヘルスとステータスが表示されます。
**AWS CLI**:
```
# View capability status and health
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack
# Look for issues in the health section
```
**一般的な原因:**
+ **IAM アクセス許可がない**: 機能ロールに AWS サービスのアクセス許可が付与されていません。
+ **名前空間が間違っている: **IAMRoleSelector が適切でない名前空間にリソースが作成されました。
+ **リソース仕様が無効である**: リソースのステータス条件に検証エラーがないか確認してください。
+ **API スロットリング**: AWS API レートリミットに達しています。
+ **アドミッションウェブフック**: アドミッションウェブフックのために、コントローラーがリソースステータスにパッチを適用できません。
**リソースのステータスを確認する**:
```
# Describe the resource to see conditions and events
kubectl describe bucket my-bucket -n default
# Look for status conditions
kubectl get bucket my-bucket -n default -o jsonpath='{.status.conditions}'
# View resource events
kubectl get events --field-selector involvedObject.name=my-bucket -n default
```
**IAM アクセス許可を確認する**:
```
# View the Capability Role's policies
aws iam list-attached-role-policies --role-name my-ack-capability-role
aws iam list-role-policies --role-name my-ack-capability-role
# Get specific policy details
aws iam get-role-policy --role-name my-ack-capability-role --policy-name policy-name
```
## AWS にリソースが作成されているのに Kubernetes に表示されない
ACK で追跡できるリソースは、Kubernetes マニフェストを介して作成されたものだけです。ACK で既存の AWS リソースを管理するには、採用機能を使用します。
```
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
```
リソースの採用の詳細については、「[ACK の概念](ack-concepts.md)」を参照してください。
## クロスアカウントリソースが作成されない
IAM ロールセレクターの使用時にターゲット AWS アカウントにリソースが作成されない場合は、信頼関係と IAMRoleSelector 設定を確認します。
**信頼関係を確認する**:
```
# Check the trust policy in the target account role
aws iam get-role --role-name cross-account-ack-role --query 'Role.AssumeRolePolicyDocument'
```
信頼ポリシーは、ソースアカウントの機能ロールに引き受けられるようになっている必要があります。
**IAMRoleSelector 設定を確認する**:
```
# List IAMRoleSelectors (cluster-scoped)
kubectl get iamroleselector
# Describe specific selector
kubectl describe iamroleselector my-selector
```
**名前空間の配置を確認する**:
IAMRoleSelectors は、クラスター範囲のリソースですが、特定の名前空間をターゲットとします。ACK リソースが IAMRoleSelector の名前空間セレクターに一致する名前空間にあることを確認してください。
```
# Check resource namespace
kubectl get bucket my-cross-account-bucket -n production
# List all IAMRoleSelectors (cluster-scoped)
kubectl get iamroleselector
# Check which namespace the selector targets
kubectl get iamroleselector my-selector -o jsonpath='{.spec.namespaceSelector}'
```
**IAMRoleSelected 条件を確認する**:
`ACK.IAMRoleSelected` 条件を調べて、IAMRoleSelector がリソースに正常に一致したものであることを確認します。
```
# Check if IAMRoleSelector was matched
kubectl get bucket my-cross-account-bucket -n production -o jsonpath='{.status.conditions[?(@.type=="ACK.IAMRoleSelected")]}'
```
条件が `False` であるか指定されていない場合は、IAMRoleSelector の名前空間セレクターがリソースの名前空間と一致しません。セレクターの `namespaceSelector` がリソースの名前空間ラベルと一致していることを確認します。
**機能ロールのアクセス許可を確認する**:
機能ロールには、ターゲットアカウントロールの `sts:AssumeRole` および `sts:TagSession` のアクセス許可が必要です。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::[.replaceable]`444455556666`:role/[.replaceable]`cross-account-ack-role`"
}
]
}
```
クロスアカウント設定の詳細については、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。
## 次のステップ
+ [EKS を利用する場合の ACK の考慮事項](ack-considerations.md) - ACK の考慮事項とベストプラクティス
+ [ACK アクセス許可を設定する](ack-permissions.md) - IAM アクセス許可およびマルチアカウントパターンを設定する
+ [ACK の概念](ack-concepts.md) - ACK の概念およびリソースライフサイクルを理解する
+ [EKS 機能をトラブルシューティングする](capabilities-troubleshooting.md) - 一般的な機能をトラブルシューティングする際のガイダンス
# EKS Capability for ACK とセルフマネージド ACK を比較する
EKS Capability for ACK が提供する機能はセルフマネージド ACK コントローラーと同じですが、その操作性に大きなメリットがあります。EKS 機能とセルフマネージドソリューションの全般的な比較については、「[EKS 機能と考慮事項](capabilities-considerations.md)」を参照してください。このトピックでは、ACK に固有の違いに焦点を当てます。
## アップストリーム ACK との違い
EKS Capability for ACK は、アップストリーム ACK コントローラーに基づいていますが、IAM との統合に違いがあります。
**IAM 機能ロール**: この機能は、信頼ポリシーが付与された専用の IAM ロールを使用して `capabilities.eks.amazonaws.com` サービスプリンシパルを許可します。IRSA (サービスアカウントの IAM ロール) は使用しません。IAM ポリシーを直接アタッチできるため、Kubernetes サービスアカウントを作成して注釈を付ける必要も、OIDC プロバイダーを設定する必要もありません。本番稼働のユースケースでは、`IAMRoleSelector` を使用してサービスアクセス許可を設定するのがベストプラクティスです。詳細については、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。
**セッションタグ**: マネージド機能は、すべての AWS API リクエストにセッションタグを自動的に設定し、きめ細かなアクセスコントロールと監査を可能にします。タグには、`eks:eks-capability-arn`、`eks:kubernetes-namespace`、および `eks:kubernetes-api-group` が含まれます。これは、これらのタグをデフォルトで設定しないセルフマネージド ACK とは異なります。IAM ポリシーでのセッションタグの使用の詳細については、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。
**リソースタグ**: この機能は、セルフマネージド ACK とは異なるデフォルトタグを AWS リソースに適用します。この機能では、セルフマネージド ACK で使用される `services.k8s.aws/` タグの代わりに `eks:` プレフィックス付きタグ (`eks:kubernetes-namespace`、`eks:eks-capability-arn` など) を使用します。デフォルトのリソースタグの完全なリストについては、「[EKS を利用する場合の ACK の考慮事項](ack-considerations.md)」を参照してください。
**リソースの互換性**: ACK カスタムリソースは、アップストリーム ACK と同じように動作するため、ACK リソース YAML ファイルを変更する必要はありません。この機能は同じ Kubernetes API と CRD を使用するため、`kubectl` のようなツールは同じように機能します。アップストリーム ACK のすべての GA コントローラーおよびリソースがサポートされています。
ACK ドキュメントとサービス固有の詳細なガイドについては、[ACK ドキュメント](https://aws-controllers-k8s.github.io/community/)を参照してください。
## 移行パス
セルフマネージド ACK からマネージド機能にダウンタイムなしで移行できます。
1. リーダー選出リースに `kube-system` を使用するようにセルフマネージド ACK コントローラーを更新します。次に例を示します。
```
helm upgrade --install ack-s3-controller \
oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
--namespace ack-system \
--set leaderElection.namespace=kube-system
```
これにより、コントローラーのリースが `kube-system` に移動するため、マネージド機能がコントローラーを調整できるようになります。
1. クラスターに ACK 機能を作成します (「[ACK 機能を作成する](create-ack-capability.md)」を参照)。
1. マネージド機能が既存の ACK マネージド AWS リソースを認識して、調整を引き継ぎます。
1. セルフマネージドコントローラーのデプロイを段階的にスケールダウンするか、削除します。
```
helm uninstall ack-s3-controller --namespace ack-system
```
このアプローチにより、移行中、両方のコントローラーを安全に共存させることができます。マネージド機能がこれまでセルフマネージドコントローラーで管理されていたリソースを自動的に採用するため、引き続き競合なく調整を図ることができます。
## 次のステップ
+ [ACK 機能を作成する](create-ack-capability.md) - ACK の機能リソースを作成する
+ [ACK の概念](ack-concepts.md) - ACK の概念およびリソースライフサイクルを理解する
+ [ACK アクセス許可を設定する](ack-permissions.md) - IAM およびアクセス許可を設定する
# Argo CD による継続的デプロイ
Argo CD は、Kubernetes 向けの宣言型 GitOps 継続的デリバリーツールです。Argo CD を使用すると、複数のクラスターと環境にわたるアプリケーションのデプロイとライフサイクルを自動的に管理できます。Argo CD は、Git リポジトリ、Helm レジストリ (HTTP および OCI)、OCI イメージなど複数のソースタイプをサポートしており、セキュリティとコンプライアンスの要件がさまざまに異なる組織に柔軟に対応できます。
AWS では EKS の機能を使用して Argo CD を完全に管理できるため、クラスターに Argo CD コントローラーとその依存関係をインストールしてメンテナンスおよびスケールする必要がありません。
## Argo CD の仕組み
Argo CD は GitOps パターンに従い、アプリケーションソース (Git リポジトリ、Helm レジストリ、または OCI イメージ) を、目的のアプリケーション状態を定義するための信頼できるソースとします。Argo CD `Application` リソースを作成するときは、アプリケーションマニフェストが含まれているソースと、ターゲットとなる Kubernetes クラスターおよび名前空間を指定します。Argo CD は、クラスター内のソース状態とライブ状態の両方を継続的にモニタリングし、変更が加えられたら自動的に同期して、クラスターの状態が目的の状態と一致するようにします。
**注記**
EKS Capability for Argo CD では、Argo CD ソフトウェアはワーカーノードではなく AWS コントロールプレーンで動作します。つまり、ワーカーノードが Git リポジトリや Helm レジストリに直接アクセスする必要はありません。この機能は、AWS アカウントからのソースアクセスを処理します。
Argo CD には、主に 3 つのリソースタイプがあります。
+ **Application**: Git リポジトリからターゲットクラスターへのデプロイを定義します。
+ **ApplicationSet**: 複数のクラスターにデプロイできるように、テンプレートから複数の Application を生成します
+ **AppProject**: Application を論理的にグループ化し、アクセスコントロールを付与できます。
**例: Argo CD Application を作成する**
次の例は、Argo CD `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
```
**注記**
クラスターの登録時に使用したクラスター名で `destination.name` を使用します (ローカルクラスターの `in-cluster` の場合など)。`destination.server` フィールドは EKS クラスター ARN でも機能しますが、読みやすくするためにクラスター名を使用することをお勧めします。
## Argo CD のメリット
GitOps ワークフローを実装しているため、Git リポジトリにアプリケーション設定を定義できます。また、目的の状態に合わせてアプリケーションを自動的に同期する機能も備えています。この Git 中心のアプローチにより、すべての変更が漏れなく監査証跡に残され、ロールバックが容易になり、既存のコードレビューおよび承認プロセスと必然的に統合されます。Argo CD は、Git の目的の状態とクラスターの実際の状態との間のドリフトを自動的に検出して調整し、デプロイと宣言された設定との整合性が確保されるようにします。
Argo CD を使用すると、単一の Argo CD インスタンスから複数のクラスターにアプリケーションをデプロイして管理できるため、マルチクラスター環境とマルチリージョン環境でのオペレーションがシンプルになります。Argo CD UI に可視化とモニタリングの機能が用意されているため、アプリケーションのデプロイステータス、ヘルス、履歴を確認できます。この UI は AWS アイデンティティセンター (以前の AWS SSO) と統合されており、認証と認可をシームレスに進めて、既存の ID 管理インフラストラクチャを使用してアクセスを制御できます。
AWS では、Argo CD が EKS マネージド機能の一部として完全に管理されるため、Argo CD インフラストラクチャを導入、設定、メンテナンスする必要がありません。AWS がスケール、パッチ適用、運用管理を行うので、チームはツールのメンテナンスではなくアプリケーションの配信に集中できます。
## AWS アイデンティティセンターとの統合
EKS マネージド機能により、Argo CD と AWS アイデンティティセンターを直接統合して、ユーザーの認証と認可をシームレスに進めることができます。Argo CD 機能を有効にすると、アイデンティティセンターのグループとユーザーを Argo CD RBAC ロールにマッピングするように AWS アイデンティティセンターの統合を設定して、Argo CD で誰がアプリケーションにアクセスおよび管理できるかを制御できます。
## 他の EKS マネージド機能との統合
Argo CD は、他の EKS マネージド機能と統合されています。
+ **Kubernetes 用 AWS コントローラー (ACK)**: Argo CD を使用すると、複数のクラスターにまたがる ACK リソースのデプロイを管理して、AWS インフラストラクチャの GitOps ワークフローを有効にできます。
+ **kro (Kube Resource Orchestrator)**: Argo CD を使用すると、複数のクラスターに kro コンポジションをデプロイして、Kubernetes エステート全体で一貫性のあるリソース構成を実現できます。
## Argo CD の使用を開始する
EKS Capability for Argo CD の使用を開始するには:
1. IAM 機能ロールを作成し、Argo CD がソースにアクセスしてアプリケーションを管理できるように必要なアクセス許可を設定します。
1. AWS コンソール、AWS CLI、または任意の Infrastructure as Code ツールを使用して、EKS クラスターに [Argo CD 機能リソースを作成](create-argocd-capability.md)します。
1. アプリケーションをデプロイするために、リポジトリアクセスを設定し、クラスターを登録します。
1. Application リソースを作成して、宣言型ソースからアプリケーションをデプロイします。
# Argo CD 機能を作成する
このトピックでは、Amazon EKS クラスターに Argo CD 機能を作成する方法について説明します。
## 前提条件
Argo CD 機能を作成する前に、以下の点を確認してください。
+ サポート対象の Kubernetes バージョン (標準サポートと延長サポートのすべてのバージョンがサポート対象) を実行している Amazon EKS クラスターが存在する
+ **AWS アイデンティティセンターが設定されている** - Argo CD の認証に必要 (ローカルユーザーはサポート対象外)
+ Argo CD に対するアクセス許可が付与された IAM 機能ロールがある
+ EKS クラスターに機能リソースを作成するための十分な IAM アクセス許可がある
+ クラスターと通信できるように `kubectl` が設定されていること
+ (オプション) Argo CD CLI をインストールしてクラスターとリポジトリの管理を容易にしている
+ (CLI/eksctl の場合) 適切な CLI ツールがインストールおよび設定されている
IAM 機能ロールを作成する手順については、「[Amazon EKS 機能 IAM ロール](capability-role.md)」を参照してください。アイデンティティセンターのセットアップについては、「[AWS アイデンティティセンターの使用を開始する](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)」を参照してください。
**重要**
Argo CD でどの AWS リソースにアクセスできるかは、どの IAM 機能ロールを使用するかによって決まります。例えば、Git リポジトリへのアクセスには CodeConnections を利用し、シークレットへのアクセスには Secrets Manager を使用します。最小特権のアクセス許可を付与した適切なロールを作成する際のガイダンスについては、「[Amazon EKS 機能 IAM ロール](capability-role.md)」および「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。
## ツールを選択する
AWS マネジメントコンソール、AWS CLI、または eksctl を使用して、Argo CD 機能を作成できます。
+ [コンソールを使用して Argo CD 機能を作成する](argocd-create-console.md) - 指示に従って操作する場合はコンソールを使用します。
+ [AWS CLI を使用して Argo CD 機能を作成する](argocd-create-cli.md) - スクリプトを作成して自動化を図る場合は AWS CLI を使用します。
+ [eksctl を使用して Argo CD 機能を作成する](argocd-create-eksctl.md) - Kubernetes ネイティブの操作をする場合は eksctl を使用します。
## Argo CD 機能を作成するとどうなるか
Argo CD 機能を作成すると、次のようになります。
1. EKS が AWS コントロールプレーンに Argo CD 機能サービスを作成します。
1. カスタムリソース定義 (CRD) がクラスターにインストールされます。
1. Kubernetes のベースラインアクセス許可を付与する機能固有のアクセスエントリポリシーを使用して、IAM 機能ロールのアクセスエントリを自動的に作成します (「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照)。
1. Argo CD がカスタムリソース (Application、ApplicationSet、AppProject) の監視を開始します。
1. 機能のステータスが `CREATING` から `ACTIVE` に変わります。
1. Argo CD UI が URL 経由でアクセス可能になります。
機能がアクティブになったら、宣言型ソースからデプロイするようにクラスターに Argo CD Application を作成できます。
**注記**
自動的に作成されるアクセスエントリは、アプリケーションをクラスターにデプロイするアクセス許可を付与しません。アプリケーションをデプロイするには、ターゲットクラスターごとに追加の Kubernetes RBAC アクセス許可を設定する必要があります。クラスターの登録とアクセスの設定の詳細については、「[ターゲットクラスターを登録する](argocd-register-clusters.md)」を参照してください。
## 次のステップ
Argo CD 機能の作成後:
+ [Argo CD の概念](argocd-concepts.md) - GitOps の原則、同期ポリシー、マルチクラスターパターンについて学ぶ
+ [Argo CD の使用](working-with-argocd.md) - リポジトリアクセスを設定し、ターゲットクラスターを登録して、Application を作成する
+ [Argo CD に関する考慮事項](argocd-considerations.md) - マルチクラスターアーキテクチャパターンと高度な設定を探る
# コンソールを使用して Argo CD 機能を作成する
このトピックでは、AWS マネジメントコンソール を使用して Argo CD 機能を作成する方法について説明します。
## 前提条件
+ **AWS アイデンティティセンターが設定されていること** – Argo CD での認証には AWS アイデンティティセンターが必要です。ローカルユーザーはサポートされていません。AWS アイデンティティセンターをセットアップしていない場合は、「[AWS アイデンティティセンターの使用を開始する](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)」を参照してアイデンティティセンターインスタンスを作成し、「[ユーザーを追加する](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html)」と「[グループを追加する](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)」を参照して Argo CD へのアクセスに必要なユーザーとグループを作成します。
## Argo CD 機能を作成する
1. https://console.aws.amazon.com/eks/home\$1/clusters で Amazon EKS コンソールを開きます。
1. クラスター名を選択して、クラスターの詳細ページを開きます。
1. **[機能]** タブを選択します。
1. 左のナビゲーションで、**[Argo CD]** を選択します。
1. **[Argo CD 機能を作成]** を選択します。
1. **IAM 機能ロール**に対して以下の操作を行います。
+ IAM 機能ロールが既に存在する場合は、ドロップダウンから選択します。
+ ロールを作成する必要がある場合は、**[Argo CD ロールを作成]** を選択します。
IAM コンソールが新しいタブに開かれます。信頼ポリシーには値があらかじめ入力され、Secrets Manager にはフル読み取りアクセスが付与されています。デフォルトでは他にアクセス許可は追加されませんが、必要に応じて追加することもできます。CodeCommit リポジトリや他の AWS サービスを使用する場合は、ロールを作成する前に適切なアクセス許可を追加します。
ロールを作成して EKS コンソールに戻ると、そのロールが自動的に選択されます。
**注記**
AWS Secrets Manager または AWS CodeConnections とをオプションで統合する場合は、ロールにアクセス許可を追加する必要があります。IAM ポリシーの例と設定ガイダンスについては、「[AWS Secrets Manager を使用してアプリケーションシークレットを管理する](integration-secrets-manager.md)」および「[AWS CodeConnections を使用して Git リポジトリに接続する](integration-codeconnections.md)」を参照してください。
1. AWS アイデンティティセンターの統合を設定します。
1. **[AWS アイデンティティセンターの統合を有効にする]** を選択します。
1. ドロップダウンからアイデンティティセンターインスタンスを選択します。
1. ユーザーまたはグループを Argo CD ロール (ADMIN、EDITOR、または VIEWER) に割り当てて、RBAC 用にロールマッピングを設定します。
1. **[作成]** を選択します。
機能作成プロセスが始まります。
## 機能がアクティブであることを確認する
1. **[機能]** タブで、Argo CD 機能のステータスを表示します。
1. ステータスが `CREATING` から `ACTIVE` に変わるまで待ちます。
1. アクティブになったら、この機能を使用する準備は完了です。
機能のステータスとトラブルシューティングの詳細については、「[機能リソースの使用](working-with-capabilities.md)」を参照してください。
## Argo CD UI にアクセスする
機能がアクティブになったら、以下の手順で Argo CD UI にアクセスできます。
1. Argo CD 機能のページで、**[Argo CD UI を開く]** を選択します。
1. Argo CD UI がブラウザの新しいタブに開かれます。
1. アプリケーションの作成とデプロイの管理を UI から行えるようになりました。
## 次のステップ
+ [Argo CD の使用](working-with-argocd.md) - リポジトリを設定し、クラスターを登録し、Application を作成する
+ [Argo CD に関する考慮事項](argocd-considerations.md) - マルチクラスターアーキテクチャと高度な設定
+ [機能リソースの使用](working-with-capabilities.md) - Argo CD 機能リソースを管理する
# AWS CLI を使用して Argo CD 機能を作成する
このトピックでは、AWS CLI を使用して Argo CD 機能を作成する方法について説明します。
## 前提条件
+ **AWS CLI** バージョン `2.12.3` 以降。バージョンを確認するには、`aws --version` を実行します。詳細についてはAWS コマンドラインインターフェイスユーザーガイドの「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。
+ **`kubectl`** - Kubernetes クラスターを操作するためのコマンドラインツール。詳細については、「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ **AWS アイデンティティセンターが設定されていること** – Argo CD での認証には AWS アイデンティティセンターが必要です。ローカルユーザーはサポートされていません。AWS アイデンティティセンターをセットアップしていない場合は、「[AWS アイデンティティセンターの使用を開始する](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)」を参照してアイデンティティセンターインスタンスを作成し、「[ユーザーを追加する](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html)」と「[グループを追加する](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)」を参照して Argo CD へのアクセスに必要なユーザーとグループを作成します。
## ステップ 1: IAM 機能ロールを作成する
信頼ポリシーファイルを作成します。
```
cat > argocd-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
IAM ロールを作成します。
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**注記**
AWS Secrets Manager または AWS CodeConnections とをオプションで統合する場合は、ロールにアクセス許可を追加する必要があります。IAM ポリシーの例と設定ガイダンスについては、「[AWS Secrets Manager を使用してアプリケーションシークレットを管理する](integration-secrets-manager.md)」および「[AWS CodeConnections を使用して Git リポジトリに接続する](integration-codeconnections.md)」を参照してください。
## ステップ 2: Argo CD 機能を作成する
クラスターに Argo CD 機能リソースを作成します。
まず、アイデンティティセンターを設定するための環境変数を設定します。
```
# Get your Identity Center instance ARN (replace region if your IDC instance is in a different region)
export IDC_INSTANCE_ARN=$(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].InstanceArn' --output text)
# Get a user ID for RBAC mapping (replace with your username and region if needed)
export IDC_USER_ID=$(aws identitystore list-users \
--region [.replaceable]`region` \
--identity-store-id $(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text)
echo "IDC_INSTANCE_ARN=$IDC_INSTANCE_ARN"
echo "IDC_USER_ID=$IDC_USER_ID"
```
アイデンティティセンター統合で機能を作成します。*region-code* をクラスターがある AWS リージョンに、*my-cluster* をクラスター名に、*idc-region-code* をお使いの IAM アイデンティティセンターが設定されているリージョンコードに置き換えます。
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--type ARGOCD \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ArgoCDCapabilityRole \
--delete-propagation-policy RETAIN \
--configuration '{
"argoCd": {
"awsIdc": {
"idcInstanceArn": "'$IDC_INSTANCE_ARN'",
"idcRegion": "'[.replaceable]`idc-region-code`'"
},
"rbacRoleMappings": [{
"role": "ADMIN",
"identities": [{
"id": "'$IDC_USER_ID'",
"type": "SSO_USER"
}]
}]
}
}'
```
このコマンドはすぐに戻りますが、EKS が必要な機能インフラストラクチャとコンポーネントを作成するため、機能がアクティブになるまでにはしばらく時間がかかります。EKS は、この機能に関連する Kubernetes カスタムリソース定義をその作成時にクラスターにインストールします。
**注記**
クラスターが存在しないというエラーやアクセス許可がないというエラーが表示された場合は、以下の点を確認します。
クラスター名が正しいこと
AWS CLI が正しいリージョンに設定されていること
必要な IAM アクセス許可を追加したこと
## ステップ 3: 機能がアクティブであることを確認する
機能がアクティブになるまで待機します。*region-code* はクラスターが配置された AWS リージョンに置き換え、*my-cluster* はクラスターの名前に置き換えます。
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--query 'capability.status' \
--output text
```
ステータスが `ACTIVE` と表示されたら、機能の準備は完了です。ステータスが `ACTIVE` になるまで、次のステップに進まないでください。
機能の詳細全体を表示することもできます。
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd
```
## ステップ 4: カスタムリソースが使用可能であることを確認する
機能がアクティブになったら、Argo CD カスタムリソースがクラスターで使用可能になっていることを確認します。
```
kubectl api-resources | grep argoproj.io
```
`Application` と `ApplicationSet` のリソースタイプがリストされます。
## 次のステップ
+ [Argo CD の使用](working-with-argocd.md) - リポジトリを設定し、クラスターを登録し、Application を作成する
+ [Argo CD に関する考慮事項](argocd-considerations.md) - マルチクラスターアーキテクチャと高度な設定
+ [機能リソースの使用](working-with-capabilities.md) - Argo CD 機能リソースを管理する
# eksctl を使用して Argo CD 機能を作成する
このトピックでは、eksctl で Argo CD 機能を作成する方法について説明します。
**注記**
以下のステップを実行するには、eksctl バージョン `0.220.0` 以降が必要です。バージョンを確認するには、`eksctl version` を実行します。
## ステップ 1: IAM 機能ロールを作成する
信頼ポリシーファイルを作成します。
```
cat > argocd-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
IAM ロールを作成します。
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**注記**
こうした基本的なセットアップの場合、追加の IAM ポリシーは必要ありません。リポジトリ認証情報や CodeConnections に Secrets Manager を使用する場合は、ロールにアクセス許可を追加する必要があります。IAM ポリシーの例と設定ガイダンスについては、「[AWS Secrets Manager を使用してアプリケーションシークレットを管理する](integration-secrets-manager.md)」および「[AWS CodeConnections を使用して Git リポジトリに接続する](integration-codeconnections.md)」を参照してください。
## ステップ 2: AWS アイデンティティセンター設定を取得する
RBAC 設定用にアイデンティティセンターインスタンス ARN とユーザー ID を取得します。
```
# Get your Identity Center instance ARN
aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text
# Get a user ID for admin access (replace 'your-username' with your Identity Center username)
aws identitystore list-users \
--identity-store-id $(aws sso-admin list-instances --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text
```
これらの値をメモしてください。次のステップで必要になります。
## ステップ 3: eksctl 設定ファイルを作成する
`argocd-capability.yaml` という名前のファイルを作成し、次の内容を記述します。各プレースホルダーの値をそれぞれクラスター名、クラスターのリージョン、IAM ロール ARN、アイデンティティセンターインスタンス ARN、アイデンティティセンターリージョン、およびユーザー ID に置き換えます。
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: cluster-region-code
capabilities:
- name: my-argocd
type: ARGOCD
roleArn: arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole
deletePropagationPolicy: RETAIN
configuration:
argocd:
awsIdc:
idcInstanceArn: arn:aws:sso:::instance/ssoins-123abc
idcRegion: idc-region-code
rbacRoleMappings:
- role: ADMIN
identities:
- id: 38414300-1041-708a-01af-5422d6091e34
type: SSO_USER
```
**注記**
RBAC マッピングに複数のユーザーまたはグループを追加できます。グループの場合、`type: SSO_GROUP` を使用してグループ ID を指定します。使用可能なロールは、`ADMIN`、`EDITOR`、および `VIEWER` です。
## ステップ 4: Argo CD 機能を作成する
設定ファイルを適用します。
```
eksctl create capability -f argocd-capability.yaml
```
このコマンドはすぐに戻りますが、機能がアクティブになるまでにはしばらく時間がかかります。
## ステップ 5: 機能がアクティブであることを確認する
機能のステータスを確認します。*region-code* はクラスターがある AWS リージョンに、*my-cluster* はクラスターの名前に置き換えます。
```
eksctl get capability \
--region region-code \
--cluster my-cluster \
--name my-argocd
```
ステータスが `ACTIVE` と表示されたら、機能の準備は完了です。
## ステップ 6: カスタムリソースが使用可能であることを確認する
機能がアクティブになったら、Argo CD カスタムリソースがクラスターで使用可能になっていることを確認します。
```
kubectl api-resources | grep argoproj.io
```
`Application` と `ApplicationSet` のリソースタイプがリストされます。
## 次のステップ
+ [Argo CD の使用](working-with-argocd.md) - Argo CD Application を作成および管理する方法を学ぶ
+ [Argo CD に関する考慮事項](argocd-considerations.md) - SSO とマルチクラスターアクセスを設定する
+ [機能リソースの使用](working-with-capabilities.md) - Argo CD 機能リソースを管理する
# Argo CD の概念
Argo CD は、Git をアプリケーションデプロイの信頼できる単一のソースとして扱うことで GitOps を実装します。このトピックでは、実践的な例を取り上げ、EKS Capability for Argo CD を使用する際に知っておくべきコアとなる概念について説明します。
## Argo CD の使用を開始する
Argo CD 機能を作成したら (「[Argo CD 機能を作成する](create-argocd-capability.md)」を参照)、アプリケーションのデプロイを開始できます。この例では、クラスターの登録と 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 を使用する](argocd-comparison.md#argocd-cli-configuration)」を参照してください。
あるいは、Kubernetes シークレットを使用してクラスターを登録します (詳細については、「[ターゲットクラスターを登録する](argocd-register-clusters.md)」を参照)。
**リポジトリアクセスを設定する** (任意)
この例では、パブリック GitHub リポジトリを使用しているため、リポジトリの設定は不要です。プライベートリポジトリの場合は、AWS Secrets Manager、CodeConnections、または Kubernetes シークレットを使用してアクセスを設定します (詳細については、「[リポジトリアクセスを設定する](argocd-configure-repositories.md)」を参照)。
AWS サービス (ECR Helm チャート、CodeConnections、および CodeCommit) の場合、リポジトリを作成しなくても、Application リソースで直接参照できます。機能ロールには、IAM アクセス許可が必要です。詳細については、「[リポジトリアクセスを設定する](argocd-configure-repositories.md)」を参照してください。
### ステップ 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 ソース](https://argo-cd.readthedocs.io/en/stable/user-guide/application-sources/)」を参照してください。
### 同期と調整
Argo CD は、ソースとクラスターを継続的にモニタリングして、差分を検出して修正します。
1. 変更がないかソースをポーリングします (デフォルト: 6 分ごと)。
1. 目的の状態とクラスターの状態を比較します。
1. アプリケーションを `Synced` または `OutOfSync` としてマークします。
1. 変更を自動的に同期するか (設定されている場合)、手動による承認を待ちます。
1. 同期後にリソースのヘルスをモニタリングします。
**同期ウェーブ**は、注釈を使用してリソースの作成順序を制御します。
```
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 同期のドキュメント](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/)を参照してください。
### アプリケーションのヘルス
Argo CD は、アプリケーション内のすべてのリソースのヘルスをモニタリングします。
**ヘルスステータス**: \$1 **正常** - すべてのリソースが想定どおりに動作している \$1 **進行中** - リソースが作成中または更新中 \$1 **低下** - 一部のリソースが正常でない (ポッドのクラッシュやジョブの失敗) \$1 **中断** - アプリケーションが意図的に一時停止している \$1 **欠落** - Git に定義されたリソースがクラスターに存在しない
よく使用される Kubernetes リソース (デプロイ、StatefulSet、ジョブなど) に対しては組み込みのヘルスチェックで対処し、CRD に対してはカスタムヘルスチェックをサポートしています。
アプリケーションのヘルスは、アプリケーションのすべてのリソースによって決まります。いずれかのリソースが `Degraded` であれば、アプリケーションも `Degraded` です。
詳細については、Argo CD ドキュメントの「[リソースのヘルス](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/)」を参照してください。
### マルチクラスターパターン
Argo CD は、主に 2 つのデプロイパターンをサポートしています。
**ハブアンドスポーク** - 複数のワークロードクラスターにデプロイする専用の管理クラスターで Argo CD を実行します。\$1 一元管理と可視性 \$1 すべてのクラスターで一貫したポリシー \$1 Argo CD インスタンスを 1 つ管理 \$1 コントロールプレーンとワークロードとの明確な分離
**クラスターあたり** - 各クラスターで Argo CD を実行して、そのクラスターのアプリケーションのみを管理します。\$1 クラスターの分離 (あるクラスターの障害が他のクラスターに影響を与えない) \$1 シンプルなネットワーク (クラスター間の通信なし) \$1 シンプルな初期セットアップ (クラスターの登録なし)
プラットフォームチームが多数のクラスターを管理する場合はハブアンドスポークを選択し、チームが独立している場合やクラスターを完全に分離する必要がある場合はクラスターあたりを選択します。
マルチクラスター設定の詳細については、「[Argo CD に関する考慮事項](argocd-considerations.md)」を参照してください。
### プロジェクト
Project を使用すると、Application を論理的にグループ化して、アクセスコントロールを付与できます。
+ **ソースの制限** - 使用できる Git リポジトリを制限します。
+ **送信先の制限** - ターゲットにできるクラスターと名前空間を制限します。
+ **リソースの制限** - デプロイできる Kubernetes リソースタイプを制限します。
+ **RBAC の統合** - Project を AWS アイデンティティセンターのユーザー ID とグループ ID にマッピングします。
Application は単一の Project に属します。指定しない場合は、`default` プロジェクトが使用されます。これにはデフォルトの制限はありません。本番稼働用の場合は、`default` プロジェクトを編集してアクセスを制限し、適切な制限で新しいプロジェクトを作成します。
Project の設定と RBAC パターンについては、「[Argo CD アクセス許可を設定する](argocd-permissions.md)」を参照してください。
### 同期オプション
よく使用されるオプションで同期動作をファインチューニングします。
+ `CreateNamespace=true` - 送信先名前空間を自動的に作成します。
+ `ServerSideApply=true` - サーバー側の適用機能を使用して的確に競合を解決します。
+ `SkipDryRunOnMissingResource=true` - CRD がまだ存在しない場合には、ドライランをスキップします (kro インスタンスに有用です)。
```
spec:
syncPolicy:
syncOptions:
- CreateNamespace=true
- ServerSideApply=true
- SkipDryRunOnMissingResource=true
```
同期オプションの完全なリストについては、[Argo CD 同期オプションのドキュメント](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/)を参照してください。
## 次のステップ
+ [リポジトリアクセスを設定する](argocd-configure-repositories.md) - Git リポジトリアクセスを設定する
+ [ターゲットクラスターを登録する](argocd-register-clusters.md) - デプロイ用にターゲットクラスターを登録する
+ [Application を作成する](argocd-create-application.md) - 最初の Application を作成する
+ [Argo CD に関する考慮事項](argocd-considerations.md) - EKS 固有のパターン、アイデンティティセンター統合、マルチクラスター設定
+ [Argo CD ドキュメント](https://argo-cd.readthedocs.io/en/stable/) - 同期フック、ヘルスチェック、高度なパターンなどについて説明した包括的な Argo CD ドキュメント
# Argo CD アクセス許可を設定する
Argo CD マネージド機能は、AWS アイデンティティセンターとの統合により認証を実施し、組み込みの RBAC ロールを使用して認可を行います。このトピックでは、ユーザーとチームに対するアクセス許可を設定する方法について説明します。
## Argo CD によるアクセス許可の仕組み
Argo CD 機能は、AWS アイデンティティセンターを使用して認証を実施し、組み込みの 3 つの RBAC ロールを使用して認可を行います。
ユーザーが Argo CD にアクセスすると、次のようになります。
1. AWS アイデンティティセンターを使用してユーザーが認証されます (社内の ID プロバイダーにフェデレーションできます)。
1. AWS アイデンティティセンターは、ユーザーとグループの情報を Argo CD に提供します。
1. Argo CD は、現在の設定に基づいてユーザーとグループを RBAC ロールにマッピングします。
1. ユーザーには、自分がアクセス許可を持つアプリケーションとリソースのみが表示されます。
## 組み込みの RBAC ロール
Argo CD 機能には、AWS アイデンティティセンターのユーザーとグループにマッピングする組み込みのロールが 3 つあります。これらは、プロジェクト、クラスター、リポジトリなどの Argo CD リソースへのアクセスを制御する**グローバルスコープのロール**です。
**重要**
グローバルロールは、Application などのプロジェクトスコープのリソースではなく、Argo CD 自体へのアクセスを制御します。EDITOR ユーザーおよび VIEWER ユーザーは、デフォルトでは Application を表示または管理できません。プロジェクトスコープのリソースにアクセスするには、プロジェクトロールが必要です。Application およびその他のプロジェクトスコープのリソースへのアクセス許可の詳細については、「[プロジェクトロールとプロジェクトスコープのアクセス](#project-roles)」を参照してください。
**ADMIN**
すべての Argo CD リソースと設定へのフルアクセス:
+ 任意のプロジェクト内の Application と ApplicationSet を作成、更新、削除する
+ Argo CD 設定を管理する
+ デプロイターゲットクラスターを登録して管理する
+ リポジトリアクセスを設定する
+ プロジェクトを作成および管理する
+ すべてのアプリケーションのステータスと履歴を表示する
+ すべてのクラスターとリポジトリを一覧表示してアクセスする
**EDITOR**
プロジェクトを更新してプロジェクトロールを設定できますが、グローバル Argo CD 設定を変更することはできません。
+ 既存のプロジェクトを更新する (プロジェクトの新規作成および削除はできません)
+ プロジェクトロールとアクセス許可を設定する
+ GPG キーと証明書を表示する
+ グローバル Argo CD 設定を変更できない
+ クラスターとリポジトリを直接管理できない
+ プロジェクトロールがないと Application を表示または管理できない
**VIEWER**
Argo CD リソースへの読み取り専用アクセス:
+ プロジェクト設定を表示する
+ すべてのプロジェクト (ユーザーが割り当てられていないプロジェクトを含む) を一覧表示する
+ GPG キーと証明書を表示する
+ クラスターまたはリポジトリを一覧表示できない
+ 変更を加えることはできない
+ プロジェクトロールがないと Application を表示または管理できない
**注記**
EDITOR ユーザーまたは VIEWER ユーザーに Application へのアクセス権を付与するには、ADMIN または EDITOR が、アイデンティティセンターグループをプロジェクト内の特定のアクセス許可にマッピングするプロジェクトロールを作成する必要があります。
## プロジェクトロールとプロジェクトスコープのアクセス
グローバルロール (ADMIN、EDITOR、VIEWER) は、Argo CD 自体へのアクセスを制御します。プロジェクトロールは、以下を含む特定のプロジェクト内のリソースと機能へのアクセスを制御します。
+ **リソース**: Application、ApplicationSet、リポジトリ認証情報、クラスター認証情報
+ **機能**: アプリケーションポッドへのログアクセスと実行アクセス
**2 レベルのアクセス許可モデルについて**:
+ **グローバルスコープ**: 組み込みロールは、ユーザーがプロジェクト、クラスター、リポジトリ、および Argo CD 設定で何ができるかを決定します
+ **プロジェクトスコープ**: プロジェクトロールは、ユーザーが特定のプロジェクト内のリソースと機能で何ができるかを決定します
つまり、次のようになります。
+ ADMIN ユーザーは、追加の設定なしですべてのプロジェクトリソースと機能にアクセスできます
+ EDITOR ユーザーおよび VIEWER ユーザーには、プロジェクトのリソースと機能にアクセスするためのプロジェクトロールを付与する必要があります
+ EDITOR ユーザーは、更新できるプロジェクト内で、自分やそれ以外のユーザーにアクセス権を付与するプロジェクトロールを作成できます。
**ワークフローの例**:
1. ADMIN は、アイデンティティセンターグループを EDITOR ロールにグローバルにマッピングします。
1. ADMIN がチームのプロジェクトを作成する
1. EDITOR は、そのプロジェクト内のプロジェクトロールを設定して、チームメンバーにプロジェクトスコープのリソースへのアクセス権を付与します。
1. チームメンバー (VIEWER グローバルロールを持つ可能性がある) は、プロジェクトロールのアクセス許可に基づいて、そのプロジェクトの Application を表示および管理できるようになりました。
プロジェクトロールの設定の詳細については、「[Project ベースのアクセスコントロール](#_project_based_access_control)」を参照してください。
## ロールマッピングを設定する
機能の作成時や更新時に、AWS アイデンティティセンターのユーザーとグループを Argo CD ロールにマッピングします。
**ロールマッピングの例**:
```
{
"rbacRoleMapping": {
"ADMIN": ["AdminGroup", "alice@example.com"],
"EDITOR": ["DeveloperGroup", "DevOpsTeam"],
"VIEWER": ["ReadOnlyGroup", "bob@example.com"]
}
}
```
**注記**
ロール名は、大文字と小文字が区別され、大文字 (ADMIN、EDITOR、VIEWER) にする必要があります。
**重要**
EKS 機能と AWS アイデンティティセンターが統合されている場合、Argo CD 機能あたり最大 1,000 個の ID がサポートされます。ユーザーやグループを ID にすることができます。
**ロールマッピングを更新する**:
```
aws eks update-capability \
--region us-east-1 \
--cluster-name cluster \
--capability-name capname \
--endpoint "https://eks.ap-northeast-2.amazonaws.com" \
--role-arn "arn:aws:iam::[.replaceable]111122223333:role/[.replaceable]`EKSCapabilityRole`" \
--configuration '{
"argoCd": {
"rbacRoleMappings": {
"addOrUpdateRoleMappings": [
{
"role": "ADMIN",
"identities": [
{ "id": "686103e0-f051-7068-b225-e6392b959d9e", "type": "SSO_USER" }
]
}
]
}
}
}'
```
## 管理者アカウントの使用法
管理者アカウントは、クラスターの登録やリポジトリの設定など、初期セットアップと管理タスク向けに設計されています。
**どのような場合に管理者アカウントが適切か**:
+ 機能の初期セットアップと設定
+ 単独開発や迅速なデモンストレーション
+ 管理タスク (クラスターの登録、リポジトリの設定、Project の作成)
**管理者アカウントのベストプラクティス**:
+ アカウントトークンをバージョン管理にコミットしない
+ トークンが漏洩したらすぐにローテーションさせる
+ アカウントトークンの用途をセットアップと管理タスクに制限する
+ 有効期限を短くする (最大 12 時間)
+ 一度に作成できるアカウントトークンを 5 つまでとする
**どのような場合に Project ベースのアクセスを使用するか**:
+ 複数のユーザーと開発環境を共有する場合
+ いずれの環境も本番稼働と同様にする場合
+ 誰がアクションを実行したかを監査証跡に残す場合
+ リソース制限やアクセス境界を設ける場合
本番稼働環境とマルチユーザーシナリオでは、専用の RBAC ロールを AWS アイデンティティセンターグループにマッピングして、Project ベースのアクセスコントロールを使用します。
## Project ベースのアクセスコントロール
Argo CD Project (AppProject) を使用すると、チームを対象にアクセスコントロールとリソース分離をきめ細かく設定できます。
**重要**
ユーザーまたはグループをプロジェクト固有のロールに割り当てる前に、まず機能設定でグローバル Argo CD ロール (ADMIN、EDITOR、または VIEWER) にマッピングする必要があります。ユーザーは、プロジェクトロールに割り当てられていても、グローバルロールマッピングなしで Argo CD にアクセスすることはできません。
ユーザーを VIEWER ロールにグローバルにマッピングし、プロジェクト固有のロールを通じて追加のアクセス許可を付与することを検討してください。これにより、ベースラインアクセスが可能になり、プロジェクトレベルでのきめ細かな制御が可能になります。
Project でできることは以下のとおりです。
+ **ソースの制限**: 使用できる Git リポジトリを制限します。
+ **送信先の制限**: ターゲットにできるクラスターと名前空間を制限します。
+ **リソースの制限**: デプロイできる Kubernetes リソースタイプを制限します。
+ **RBAC の統合**: Project を AWS アイデンティティセンターグループまたは Argo CD ロールにマッピングします。
**チームを分離する Project の例**:
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
description: Team A applications
# Required: Specify which namespaces this project watches for Applications
sourceNamespaces:
- argocd
# Source restrictions
sourceRepos:
- https://github.com/myorg/team-a-apps
# Destination restrictions
destinations:
- namespace: team-a-*
server: arn:aws:eks:us-west-2:111122223333:cluster/production
# Resource restrictions
clusterResourceWhitelist:
- group: ''
kind: Namespace
namespaceResourceWhitelist:
- group: 'apps'
kind: Deployment
- group: ''
kind: Service
- group: ''
kind: ConfigMap
```
### ソース名前空間
EKS Argo CD 機能を使用する場合は、AppProject 定義で `spec.sourceNamespaces` フィールドが必要です。このフィールドは、このプロジェクトを参照する Application または ApplicationSet を含めることができる名前空間を指定します。
**重要**
EKS Argo CD 機能は、Application と ApplicationSet 向けに一つの名前空間のみをサポートします。具体的には、機能の作成時に指定した名前空間になります (通常は `argocd`)。これは、複数の名前空間をサポートするオープンソースの Argo CD とは異なります。
**AppProject の設定**
すべての AppProject は、その機能の設定済み名前空間を `sourceNamespaces` に含める必要があります。
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a-project
namespace: argocd
spec:
description: Applications for Team A
# Required: Specify the capability's configured namespace (configuration.argoCd.namespace)
sourceNamespaces:
- argocd # Must match your capability's namespace configuration
# Source repositories this project can deploy from
sourceRepos:
- 'https://github.com/my-org/team-a-*'
# Destination restrictions
destinations:
- namespace: 'team-a-*'
server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster
```
**注記**
機能の名前空間を `sourceNamespaces` に含めないと、その名前空間の Application または ApplicationSet はこのプロジェクトを参照できず、デプロイが失敗します。
**ユーザーを Project に割り当てる**:
プロジェクトロールは、EDITOR ユーザーおよび VIEWER ユーザーにプロジェクトリソース (Application、ApplicationSet、リポジトリ、クラスター認証情報) と機能 (ログ、実行) へのアクセスを許可します。プロジェクトロールがないと、これらのユーザーは、グローバルロールアクセスを持っていてもこれらのリソースにアクセスできません。
ADMIN ユーザーは、プロジェクトロールを必要とせずに、すべての Application にアクセスできます。
**例: チームメンバーに Application へのアクセスを許可する**
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
# ... project configuration ...
sourceNamespaces:
- argocd
# Project roles grant Application-level access
roles:
- name: developer
description: Team A developers - can manage Applications
policies:
- p, proj:team-a:developer, applications, *, team-a/*, allow
- p, proj:team-a:developer, clusters, get, *, allow # See cluster names in UI
groups:
- 686103e0-f051-7068-b225-e6392b959d9e # Identity Center group ID
- name: viewer
description: Team A viewers - read-only Application access
policies:
- p, proj:team-a:viewer, applications, get, team-a/*, allow
- p, proj:team-a:viewer, clusters, get, *, allow # See cluster names in UI
groups:
- 786203e0-f051-7068-b225-e6392b959d9f # Identity Center group ID
```
**注記**
プロジェクトロールに `clusters, get, *, allow` を含めることで、ユーザーが UI でクラスター名を表示できるようにします。このアクセス許可がない場合、送信先クラスターは「Unknown」として表示されます。
**プロジェクトロールポリシーについて**:
ポリシーの形式は次のとおりです: `p, proj::, , ,