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

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

# EKS を利用する場合の ACK の考慮事項
<a name="ack-considerations"></a>

このトピックでは、IAM 設定、マルチアカウントパターン、他の EKS 機能との統合など、EKS Capability for ACK を使用する際の重要な考慮事項について説明します。

## IAM 設定のパターン
<a name="_iam_configuration_patterns"></a>

ACK 機能は、IAM 機能ロールを使用して AWS で認証します。要件に基づいて適切な IAM パターンを選択します。

### シンプル: 単一の機能ロール
<a name="_simple_single_capability_role"></a>

開発、テスト、またはシンプルなユースケースの場合、必要なすべてのアクセス許可を機能ロールに直接付与します。

 **どのようなときに使うか**:
+ 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 ロールセレクター
<a name="_production_iam_role_selectors"></a>

本番稼働環境では、IAM ロールセレクターを使用して、最小特権のアクセスと名前空間レベルでの分離を実装します。

 **どのようなときに使うか**:
+ 本番稼働環境
+ マルチチームクラスター
+ マルチアカウントリソース管理
+ 最小特権セキュリティ要件
+ サービスごとに異なるアクセス許可が必要

 **利点:**
+ 名前空間ごとに必要なアクセス許可のみを取得できます。
+ チーム分離 - チーム A は、チーム B のアクセス許可を使用できません。
+ 監査とコンプライアンスが容易です。
+ クロスアカウントリソース管理に必須です。

IAM ロールセレクターの設定の詳細については、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。

## 他の EKS 機能との統合
<a name="_integration_with_other_eks_capabilities"></a>

### GitOps と Argo CD
<a name="_gitops_with_argo_cd"></a>

EKS Capability for Argo CD を使用すると、Git リポジトリから ACK リソースをデプロイして、インフラストラクチャの管理に GitOps ワークフローを使用できます。

 **考慮事項**:
+ エンドツーエンドの GitOps のアプリケーションマニフェストと共に ACK リソースを保存する
+ チーム構造に基づいて環境、サービス、またはリソースタイプ別に整理する
+ Argo CD の自動同期を使用して継続的に調整を行う
+ プルーニングを有効にして削除済みのリソースを自動的に除去する
+ マルチクラスターのインフラストラクチャ管理にハブアンドスポークパターンを検討する

GitOps は、監査証跡、ロールバック機能、および宣言型のインフラストラクチャ管理を備えています。Argo CD の詳細については、「[Argo CD の使用](working-with-argocd.md)」を参照してください。

### kro によるリソース構成
<a name="_resource_composition_with_kro"></a>

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)」を参照してください。

## リソースを整理する
<a name="_organizing_your_resources"></a>

Kubernetes 名前空間と AWS リソースタグを使用して ACK リソースを整理すると、管理、アクセスコントロール、コスト追跡を改善できます。

### 名前空間の整理
<a name="_namespace_organization"></a>

Kubernetes 名前空間を使用すると、環境 (本番稼働、ステージング、開発)、チーム (プラットフォーム、データ、ml)、またはアプリケーション別に ACK リソースを論理的に分離できます。

 **利点:**
+ アクセスコントロール用に RBAC を名前空間範囲で限定する
+ 注釈を使用して名前空間ごとにデフォルトリージョンを設定する
+ リソース管理とクリーンアップが容易になる
+ 組織構造に沿って論理的に分離できる

### リソースのタグ付け
<a name="_resource_tagging"></a>

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 ツールからの移行
<a name="_migration_from_other_infrastructure_as_code_tools"></a>

多くの組織が、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)」を参照してください。

## 削除ポリシー
<a name="_deletion_policies"></a>

削除ポリシーは、対応する Kubernetes リソースを削除したときに AWS リソースがどうなるかを制御します。リソースのライフサイクルと実際の運用要件に基づいて、適切なポリシーを選択します。

### 削除する (デフォルト)
<a name="_delete_default"></a>

Kubernetes リソースを削除すると、AWS リソースも削除されます。そのため、クラスターと AWS との一貫性が維持され、リソースの蓄積を防ぐことができます。

 **どのような場合に削除を使用するか**:
+ 開発環境とテスト環境でクリーンアップが重要な場合
+ エフェメラルリソースがアプリケーションのライフサイクルに結びついている場合 (テストデータベースや一時バケット)
+ リソースがアプリケーションよりも長く存続してはいけない場合 (SQS キューや ElastiCache クラスター)
+ コスト最適化 - 未使用のリソースを自動的にクリーンアップする場合
+ GitOps で管理された環境で、Git からリソースが削除されたらインフラストラクチャも削除される場合

Kubernetes の宣言型モデルに合わせてデフォルトの削除ポリシーを調整します。クラスターの内容は AWS に存在するものと一致します。

### Retain
<a name="_retain"></a>

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)」を参照してください。

## アップストリームドキュメント
<a name="_upstream_documentation"></a>

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/) - ユーザー向けの包括的なドキュメント

## 次のステップ
<a name="_next_steps"></a>
+  [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 リソースを高次の抽象化に構成する