EKS Capability for ACK とセルフマネージド ACK を比較する - Amazon EKS
アップストリーム ACK との違い移行パス次のステップ

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

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

EKS Capability for ACK とセルフマネージド ACK を比較する

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

アップストリーム ACK との違い

EKS Capability for ACK は、アップストリーム ACK コントローラーに基づいていますが、IAM との統合に違いがあります。

IAM 機能ロール: この機能は、信頼ポリシーが付与された専用の IAM ロールを使用して capabilities.eks.amazonaws.com サービスプリンシパルを許可します。IRSA (サービスアカウントの IAM ロール) は使用しません。IAM ポリシーを直接アタッチできるため、Kubernetes サービスアカウントを作成して注釈を付ける必要も、OIDC プロバイダーを設定する必要もありません。本番稼働のユースケースでは、IAMRoleSelector を使用してサービスアクセス許可を設定するのがベストプラクティスです。詳細については、「ACK アクセス許可を設定する」を参照してください。

リソースの互換性: ACK カスタムリソースは、アップストリーム ACK と同じように動作するため、ACK リソース YAML ファイルを変更する必要はありません。この機能は同じ Kubernetes API と CRD を使用するため、kubectl のようなツールは同じように機能します。アップストリーム ACK のすべての GA コントローラーおよびリソースがサポートされています。

ACK ドキュメントとサービス固有の詳細なガイドについては、ACK ドキュメントを参照してください。

移行パス

セルフマネージド 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 に移動するため、マネージド機能がコントローラーを調整できるようになります。

  2. クラスターに ACK 機能を作成します (「ACK 機能を作成する」を参照)。

  3. マネージド機能が既存の ACK マネージド AWS リソースを認識して、調整を引き継ぎます。

  4. セルフマネージドコントローラーのデプロイを段階的にスケールダウンするか、削除します。

    helm uninstall ack-s3-controller --namespace ack-system

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

次のステップ