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

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

# EKS Capability for ACK とセルフマネージド ACK を比較する
<a name="ack-comparison"></a>

EKS Capability for ACK が提供する機能はセルフマネージド ACK コントローラーと同じですが、その操作性に大きなメリットがあります。EKS 機能とセルフマネージドソリューションの全般的な比較については、「[EKS 機能と考慮事項](capabilities-considerations.md)」を参照してください。このトピックでは、ACK に固有の違いに焦点を当てます。

## アップストリーム ACK との違い
<a name="_differences_from_upstream_ack"></a>

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

## 移行パス
<a name="_migration_path"></a>

セルフマネージド 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
   ```

このアプローチにより、移行中、両方のコントローラーを安全に共存させることができます。マネージド機能がこれまでセルフマネージドコントローラーで管理されていたリソースを自動的に採用するため、引き続き競合なく調整を図ることができます。

## 次のステップ
<a name="_next_steps"></a>
+  [ACK 機能を作成する](create-ack-capability.md) - ACK の機能リソースを作成する
+  [ACK の概念](ack-concepts.md) - ACK の概念およびリソースライフサイクルを理解する
+  [ACK アクセス許可を設定する](ack-permissions.md) - IAM およびアクセス許可を設定する