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

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

# Kubernetes 用 AWS コントローラー (ACK) で Kubernetes から AWS リソースをデプロイする
<a name="ack"></a>

 Kubernetes 用 AWS コントローラー (ACK) を使用すると、Kubernetes から直接 AWS サービスリソースを定義および管理できます。Kubernetes 用 AWS コントローラー (ACK) により、Kubernetes カスタムリソースを使用してワークロードリソースとクラウドインフラストラクチャを管理できるほか、使い慣れた Kubernetes API とツールを使用してアプリケーションワークロードも管理できます。

AWS では EKS の機能を使用して ACK を完全に管理できるため、クラスターに ACK コントローラーをインストールして保守およびスケールする必要がありません。

## ACK の仕組み
<a name="_how_ack_works"></a>

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 のメリット
<a name="_benefits_of_ack"></a>

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 サービス
<a name="supported_shared_aws_services"></a>

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 マネージド機能との統合
<a name="_integration_with_other_eks_managed_capabilities"></a>

ACK は、他の EKS マネージド機能と統合されています。
+  **Argo CD**: Argo CD を使用すると、複数のクラスターにまたがる ACK リソースのデプロイを管理して、AWS インフラストラクチャの GitOps ワークフローを有効にできます。
  + ACK を ArgoCD と組み合わせると GitOps のメリットが広がりますが、ACK を git と統合する必要はありません。
+  **kro (Kube Resource Orchestrator)**: kro を使用すると、ACK リソースから複雑なリソースを作成して、高次の抽象化を作成してリソース管理をシンプルにできます。
  + kro で Kubernetes リソースと AWS リソースの両方を定義することで、複合カスタムリソースを作成できます。チームメンバーは、こうしたカスタムリソースを使用して、複雑なアプリケーションをすばやくデプロイできます。

## ACK の使用を開始する
<a name="_getting_started_with_ack"></a>

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 リソースの管理を開始します。