View a markdown version of this page

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 アクセス許可を設定する」を参照してください。

セッションタグ: マネージド機能は、すべての AWS API リクエストにセッションタグを自動的に設定し、きめ細かなアクセスコントロールと監査を可能にします。タグには、eks:eks-capability-arn、eks:kubernetes-namespace、および eks:kubernetes-api-group が含まれます。これは、これらのタグをデフォルトで設定しないセルフマネージド ACK とは異なります。IAM ポリシーでのセッションタグの使用の詳細については、「ACK アクセス許可を設定する」を参照してください。

リソースタグ: この機能は、セルフマネージド ACK とは異なるデフォルトタグを AWS リソースに適用します。この機能では、セルフマネージド ACK で使用される services.k8s.aws/ タグの代わりに eks: プレフィックス付きタグ (eks:kubernetes-namespace、eks:eks-capability-arn など) を使用します。デフォルトのリソースタグの完全なリストについては、「EKS を利用する場合の ACK の考慮事項」を参照してください。

リソースの互換性: ACK カスタムリソースは、アップストリーム ACK と同じように動作するため、ACK リソース YAML ファイルを変更する必要はありません。この機能は同じ Kubernetes API と CRD を使用するため、kubectl のようなツールは同じように機能します。この機能は、アップストリーム ACK で一般利用可能な (GA) コントローラーとリソースのみをサポートします。この機能には、アップストリームでプレビューされているコントローラーは含まれません。コントローラーのステータスは、時間の経過とともにプレビューから GA アップストリームに変更され、この機能は自動的に管理を開始できます。この機能とともにセルフマネージドプレビューコントローラーを実行する場合は、移行する前に プレビューコントローラーと自動昇格 をレビューしてください。

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

移行パス

AWS リソースの中断を最小限に抑えながら、セルフマネージド ACK からマネージド機能に移行できます。移行は Kubernetes リーダー選出に依存します。セルフマネージドコントローラーと機能は同じリースに対して競合するため、そのうちの 1 つだけがいつでも特定のリソースを調整します。これを機能させるには、両方が同じ名前空間でリースを共有する必要があります。この機能では、実行中のセルフマネージドコントローラーからリースを強制的に取得しないため、セルフマネージドコントローラーをスケールダウンして、ハンドオーバーが発生するタイミングを制御できます。

重要

開始する前に、セルフマネージドコントローラーが現在使用しているアクセス許可と同等なアクセス許可を IAM 機能ロールに付与します。この機能は、セルフマネージドコントローラーが IRSA や EKS Pod Identity などの現在使用しているメカニズムを通じてではなく、capabilities.eks.amazonaws.com サービスプリンシパルを通じて専用の機能ロールで認証します (ACK アクセス許可を設定する を参照)。機能ロールにアクセス許可がない場合、この機能はリソースを採用します。その後、調整に失敗し、AccessDenied エラーがログに記録されます。

移行するには、以下のステップを実行します。ステップでは、例として S3 コントローラー (ack-s3-controller) を使用します。機能に移行するセルフマネージド ACK コントローラーごとにそれらを繰り返し、対応するコントローラー名と Helm チャートを置き換えます。

注記

機能とともにコントローラーをセルフマネージドで実行することは、長期的な設定ではなく、移行中の一時的な状態を想定しています。両方が実行されている間、どちらか一方の中断 (機能のデプロイやセルフマネージドコントローラーのアップグレードなど) によってリースが解放され、もう一方の側でリースが取得され、調整がそれらの間で予期せず切り替わる可能性があります。機能とともに無期限にセルフマネージドで実行するのではなく、各コントローラーの移行を完了してください。

  1. セルフマネージド ACK コントローラーでリーダー選出を有効にし、リースを kube-system に移動します:

    helm upgrade --install ack-s3-controller \
  oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
  --namespace ack-system \
  --set leaderElection.enabled=true \
  --set leaderElection.namespace=kube-system

    両方の値を設定する必要があります。ACK Helm チャートでは、--leader-election-namespace フラグは leaderElection.enabled が true の場合にのみ適用され、リーダー選出はデフォルトで無効になっています。leaderElection.namespace を設定するのみでは、一切影響を与えません。コントローラーはリースなしで実行され続け、両方のコントローラーは機能の作成後に同じリソースを同時に調整します。これは、S3 だけでなく、すべての ACK サービスコントローラーチャートに適用されます。

    これにより、コントローラーのリースが kube-system に移動するため、マネージド機能がコントローラーを調整できるようになります。

  2. クラスターに ACK 機能を作成します (ACK 機能を作成する を参照)。この機能は起動してリースに対して競合しますが、セルフマネージドコントローラーはリースを保持し続けます。セルフマネージドコントローラーはリソースの調整を継続し、この機能はテイクオーバーを適用するのではなくリーダーシップを待機します。

  3. 移行を開始する準備ができたら、セルフマネージドコントローラーをゼロレプリカにスケールダウンします。これによりリースが解放されるので、この機能がリーダーシップを取得して調整を引き継ぐことができます。

    kubectl scale deployment ack-s3-controller \
  --namespace ack-system --replicas=0

    セルフマネージドコントローラーをスケールダウンすると、この機能はリースを取得し、通常は短時間で調整を開始します。セルフマネージドコントローラーをスケールアップしても、この機能がリースを保持および更新し続けるため、リースは返されません。セルフマネージドコントローラーに調整を返すには、少なくとも 1 つのレプリカにスケールアップしてから ACK 機能を削除します。この機能を削除すると、セルフマネージドコントローラーはリースを再取得し、調整を再開します。

    採用時に、この機能はセルフマネージド ACK で使用される services.k8s.aws/ タグの代わりに、独自のデフォルトリソースタグ (eks: プレフィックス付き) を適用します (EKS を利用する場合の ACK の考慮事項 を参照)。採用したリソースに対するタグ付け API コールの 1 回限りのセットを想定し、services.k8s.aws/ タグプレフィックスをキーとするコスト配分またはポリシーツールを更新します。

  4. この機能が正常であり、リソースの調整を引き継いでいることを確認します。リソースが True の Synced 条件をレポートし、この機能が AccessDenied エラーをログに記録していないことを確認します。

  5. この機能が正しくリソースを管理していることを確認したら、セルフマネージドコントローラーを削除します。

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

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

プレビューコントローラーと自動昇格

この機能は、アップストリーム ACK で GA であるコントローラーのみをサポートします。現在プレビュー中のコントローラーは、後で GA アップストリームに昇格できます。それが発生した場合、この機能はユーザー側のアクションなしで、そのコントローラーの管理を自動的に開始します。

これにより、他のコントローラーにもこの機能を使用しているクラスターでセルフマネージドプレビューコントローラーを実行すると、リスクが発生します。プレビューコントローラーは、調整する他のコントローラーがないため、リーダー選出が無効になっている単一のレプリカとして実行できます。そのコントローラーが GA に昇格すると、この機能はそのコントローラーの管理を開始します。この時点で、2 つのリコンシラーは同じリソースに対して動作し、それらを調整するための共有リースはありません。その結果、移行ステップが防止するように設計されているのと同じ二重調整の競合が発生します。どちらのリコンシラーも競合する AWS API コールを発行し、相反する更新をカスタムリソースステータスに書き込みます。

これを回避するには、この機能とともにセルフマネージドプレビューコントローラーを実行する前に、次の操作を行います:

  • セルフマネージドプレビューコントローラーでリーダー選出を有効にし、移行ステップに示されているのと同じ leaderElection.enabled=true および leaderElection.namespace=kube-system 設定を使用して、リースを kube-system にポイントします。これにより、コントローラーが昇格され、この機能がそれを引き継ぐ場合、2 つは並行して調整するのではなく、共有リースを介して調整されます。

  • 依存するプレビューコントローラーのアップストリーム GA ステータスを追跡し、昇格時に移行パスに従ってそれらを移行する計画を立てます。各コントローラーの現在のステータスは、ACK ウェブサイトの 「ACK サービスページ」で確認できます。

次のステップ