Amazon EKS Pod Identity と KEDA を使用して Amazon EKS でイベント駆動型自動スケーリングをセットアップする - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon EKS Pod Identity と KEDA を使用して Amazon EKS でイベント駆動型自動スケーリングをセットアップする

Amazon Web Services、Dipen Desai、Abhay Diwan、Kamal Joshi、Mahendra Revanasiddappa

概要

Amazon Elastic Kubernetes Service (Amazon EKS) などのオーケストレーションプラットフォームは、コンテナベースのアプリケーションのライフサイクル管理を合理化してきました。これにより、組織はコンテナベースのアプリケーションの構築、保護、運用、保守に集中できます。イベント駆動型デプロイがより一般的になるにつれて、組織はさまざまなイベントソースに基づいて Kubernetes デプロイをより頻繁にスケーリングするようになっています。この方法と自動スケーリングを一緒に使用し、アプリケーションロジックに合わせたオンデマンドコンピューティングリソースと効率的なスケーリングを提供することで、大幅なコスト削減につながります。

KEDA は、Kubernetes ベースのイベント駆動型オートスケーラーです。KEDA は、処理する必要があるイベントの数に基づいて Kubernetes のコンテナをスケールするのに役立ちます。軽量で、任意の Kubernetes クラスターと統合できます。また、Horizontal Pod Autoscaling (HPA) などの標準 Kubernetes コンポーネントでも機能します。KEDA には、認証を委任するのに役立つ機能である TriggerAuthentication も用意されています。これにより、ScaledObject やデプロイコンテナとは別の認証パラメータを記述できます。

AWS は AWS Identity and Access Management 、Amazon EKS、Amazon EKS Anywhere、(ROSA)、Amazon Elastic Compute Cloud (Amazon EC2) 上のセルフマネージド Kubernetes クラスターなど、さまざまな Kubernetes デプロイオプションをサポートする (IAM) ロールを提供します。 Red Hat OpenShift Service on AWS Amazon EC2 これらのロールは、OpenID Connect (OIDC) ID プロバイダーや IAM 信頼ポリシーなどの IAM コンストラクトを使用することにより、Amazon EKS サービスや API に直接依存することなく、さまざまな環境で機能します。詳細については、Amazon EKS ドキュメントの「サービスアカウントの IAM ロール」を参照してください。

Amazon EKS Pod Identity を使用すると、Kubernetes サービスアカウントが OIDC プロバイダーなしで IAM ロールを引き受けるプロセスが簡素化されます。これにより、アプリケーションの認証情報を管理できます。 AWS 認証情報を作成してコンテナに配布したり、Amazon EC2 インスタンスのロールを使用する代わりに、IAM ロールを Kubernetes サービスアカウントに関連付け、サービスアカウントを使用するように Pod を設定します。これにより、複数のクラスターで IAM ロールを使用することができ、IAM ロール間でアクセス許可ポリシーを再利用することでポリシー管理を簡素化することができます。

KEDA と Amazon EKS Pod Identity を実装することで、企業は効率的なイベント駆動型の自動スケーリングとシンプルな認証情報管理を実現できます。アプリケーションは需要に基づいてスケールするため、リソース使用率を最適化し、コストを削減できます。

このパターンは、Amazon EKS Pod Identity を KEDA と統合するのに役立ちます。keda-operator サービスアカウントを使用し、TriggerAuthentication で認証を委任する方法を説明します。また、KEDA オペレータ用の IAM ロールとアプリケーション用の IAM ロールの間に信頼関係をセットアップする方法についても説明します。この信頼関係により、KEDA はイベントキュー内のメッセージをモニタリングし、送信先 Kubernetes オブジェクトのスケーリングを調整することができます。

前提条件と制限

前提条件

制限事項

  • keda-operator ロールと keda-identity ロールの間に信頼関係を確立する必要があります。手順については、このパターンの「エピック」セクションを参照してください。

アーキテクチャ

このパターンでは、次の AWS リソースを作成します。

  • Amazon Elastic Container Registry (Amazon ECR) リポジトリ – このパターンでは、このリポジトリの名前は keda-pod-identity-registry です。このプライベートリポジトリは、サンプルアプリケーションの Docker イメージを保存するために使用されます。

  • Amazon Simple Queue Service (Amazon SQS) キュー – このパターンでは、このキューの名前は event-messages-queue です。キューは、受信メッセージを収集して保存するメッセージバッファとして機能します。KEDA は、メッセージ数やキューの長さなどのキューメトリクスをモニタリングし、これらのメトリクスに基づいてアプリケーションを自動的にスケーリングします。

  • アプリケーションの IAM ロール – このパターンでは、このロールの名前は keda-identity です。keda-operator ロールはこのロールを引き受けます。このロールにより、Amazon SQS キューへのアクセスが許可されます。

  • KEDA オペレーターの IAM ロール – このパターンでは、このロールの名前は keda-operator です。KEDA 演算子は、このロールを使用して必要な AWS API コールを行います。このロールには、keda-identity ロールを引き受けるためのアクセス権限が割り当てられています。keda-operatorkeda-identity ロールの間には信頼関係があるため、keda-operator ロールにも Amazon SQS アクセス権限が割り当てられます。

TriggerAuthentication および ScaledObject Kubernetes カスタムリソースを通じて、オペレーターは keda-identity ロールで Amazon SQS キューに接続します。キューのサイズに基づいて、KEDA は自動的にアプリケーションのデプロイをスケーリングします。キュー内の 5 つの未読メッセージごとに 1 つのポッドを追加します。デフォルト設定では、Amazon SQS キューに未読メッセージがない場合、アプリケーションはポッド数 0 までスケールダウンします。KEDA オペレーターは、指定した間隔でキューをモニタリングします。

 

次の図に、Amazon EKS Pod Identity を使用して keda-operator ロールに Amazon SQS キューへの安全なアクセスを提供する方法を示します。

KEDA と Amazon EKS Pod Identity を使用して、Kubernetes ベースのアプリケーションを自動的にスケーリングします。

この図表は、次のワークフローを示しています:

  1. Amazon EKS Pod Identity エージェントを Amazon EKS クラスターにインストールします。

  2. Amazon EKS クラスターの KEDA 名前空間に KEDA オペレーターをデプロイします。

  3. ターゲットに keda-operatorおよび keda-identity IAM ロールを作成します AWS アカウント。

  4. IAM ロールの間に信頼関係を確立します。

  5. アプリケーションを security 名前空間にデプロイします。

  6. KEDA オペレーターは、Amazon SQS キュー内のメッセージをポーリングします。

  7. KEDA が HPA を開始し、キューのサイズに基づいてアプリケーションが自動的にスケーリングされます。

ツール

AWS のサービス

  • Amazon Elastic Container Registry (Amazon ECR) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。

  • Amazon Elastic Kubernetes Service (Amazon EKS) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。

  • AWS Identity and Access Management (IAM) は、誰を認証し、誰に使用する権限を付与するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。

  • Amazon Simple Queue Service (Amazon SQS)」は、分散したソフトウェアシステムとコンポーネントの統合と切り離しを支援し、セキュアで耐久性があり、利用可能なホスト型キューを提供します。

その他のツール

  • KEDA は、Kubernetes ベースのイベント駆動型オートスケーラーです。

コードリポジトリ

このパターンのコードは、GitHub 内の「Event-driven auto scaling using EKS Pod Identity and KEDA」で入手できます。

ベストプラクティス

ACM のベストプラクティスに従うことをおすすめします。

エピック

タスク説明必要なスキル

KEDA オペレーターの IAM ロールを作成します。

  1. にサインインし AWS マネジメントコンソール、IAM コンソールを開きます。

  2. ナビゲーションペインで Roles (ロール) を選択してください。

  3. [ロールの作成] を選択してください。

  4. [Custom trust policy] (カスタム信頼ポリシー) ロールタイプを選択してください。

  5. [カスタム信頼ポリシー] セクションで、このロールのための次のカスタム信頼ポリシーを入力します。

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] }
  6. [アクセス許可を追加] ページで [次へ] を選択してください。このロールにはポリシーを追加しません。

  7. [Role name] (ロール名) にkeda-operatorと入力します。

  8. [ロールの作成] を選択してください。

AWS 管理者

サンプルアプリケーションの IAM ロールを作成します。

  1. IAM コンソールのナビゲーションペインで [ロール] を選択します。

  2. [ロールの作成] を選択してください。

  3. [Custom trust policy] (カスタム信頼ポリシー) ロールタイプを選択してください。

  4. [カスタム信頼ポリシー] セクションで、このロールのための次のカスタム信頼ポリシーを入力します。<account number> は実際のターゲットアカウント番号に置き換えてください。

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com", "AWS": "arn:aws:iam::<account number>:role/keda-operator" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] }
  5. アクセス許可の追加ページで、次の AWS 管理ポリシーをロールに追加します。

    • AmazonSQSReadOnlyAccess

    • AWSLambdaSQSQueueExecutionRole

  6. [次へ] を選択します。

  7. [Role name] (ロール名) にkeda-identityと入力します。

  8. [ロールの作成] を選択してください。

AWS 管理者

Amazon SQS キューを作成します。

  1. Amazon SQS コンソールを開きます。

  2. [キューの作成] を選択します。

  3. タイプ] で、[標準] を選択します。

  4. [キューの作成] ページの [名前] に、「event-messages-queue」と入力します。

  5. [キューの作成] を選択します。このキューのデフォルト設定は変更しません。

AWS 全般

Amazon ECR リポジトリを作成します。

  1. Amazon ECR コンソールを開きます。

  2. [Create repository (リポジトリの作成)] を選択します。

  3. [リポジトリ名] に「keda-pod-identity-registry」と入力します。

  4. [Create repository (リポジトリの作成)] を選択します。このリポジトリのデフォルト設定は変更しません。

AWS 全般
タスク説明必要なスキル

Amazon EKS Pod Identity エージェントをデプロイします。

ターゲット Amazon EKS クラスターで、Amazon EKS Pod Identity エージェントをセットアップします。Amazon EKS ドキュメントの「Amazon EKS Pod Identity エージェントのセットアップ」の手順に従います。

AWS DevOps

KEDA をデプロイします。

  1. 次のコマンドを入力して、ターゲット Amazon EKS クラスターに KEDA をデプロイします。

    # Add Helm Repo for Keda helm repo add kedacore https://kedacore.github.io/charts # Update Helm repo helm repo update # Install Keda helm install keda kedacore/keda --namespace keda --create-namespace

    詳細については、KEDA ドキュメントの「Deploying with Helm」を参照してください。

  2. デプロイが成功したら、出力で、KEDA オペレーター用に 3 つのデプロイが作成されていることを確認します。以下は出力例です。

    NAME READY UP-TO-DATE AVAILABLE AGE keda-admission-webhooks 1/1 1 1 89s keda-operator 1/1 1 1 89s keda-operator-metrics-apiserver 1/1 1 1 89s
DevOps エンジニア

IAM ロールを Kubernetes サービスアカウントに割り当てます。

Amazon EKS ドキュメントの「IAM ロールを Kubernetes サービスアカウントに割り当てる」の手順に従ってください。以下の値を使用します。

  • IAM ロールの場合は、「keda-operator」と入力します。

  • Kubernetes 名前空間の場合は、「keda」と入力します。

  • Kubernetes サービスアカウントの場合は、「keda-operator」と入力します。

AWS DevOps

名前空間を作成します。

次のコマンドを入力して、ターゲット Amazon EKS クラスターに security 名前空間を作成します。

kubectl create ns security
DevOps エンジニア
タスク説明必要なスキル

アプリケーションファイルのクローンを作成します。

次のコマンドを入力して、GitHub の「Event-driven auto scaling using EKS Pod Identity and KEDA repository」のクローンを作成します。

git clone https://github.com/aws-samples/event-driven-autoscaling-using-podidentity-and-keda.git
DevOps エンジニア

Docker イメージを作成します。

  1. 次のコマンドを入力して、クローン作成されたリポジトリに移動します。

    cd event-driven-autoscaling-using-podidentity-and-keda
  2. 次のコマンドを入力して、サンプルアプリケーションの Docker イメージを構築します。

    docker build -t keda-pod-identity-registry .
DevOps エンジニア

Amazon ECR にDocker イメージをプッシュします。

  1. Docker イメージをビルドしたターミナルで、次のコマンドを入力して Amazon ECR にログインします。<AWS_REGION> と を AWS 環境の値<AWS_ACCOUNT_ID>に置き換えます。

    aws ecr get-login-password \ --region <AWS_REGION> | docker login \ --username AWS \ --password-stdin <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com
  2. 次のコマンドを入力して、イメージにタグを付けます。<AWS_REGION> と を AWS 環境の値<AWS_ACCOUNT_ID>に置き換えます。

    docker tag keda-pod-identity-registry:latest <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/keda-pod-identity-registry:latest

  3. 次のコマンドを入力して、イメージを Amazon ECR にプッシュします。<AWS_REGION> と を AWS 環境の値<AWS_ACCOUNT_ID>に置き換えます。

    docker push <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/keda-pod-identity-registry:latest

注記

プッシュコマンドを見つけるには、Amazon ECR リポジトリページに移動し、[プッシュコマンドを表示] を選択します。

DevOps エンジニア

サンプルアプリケーションをデプロイします。

  1. クローンしたリポジトリで deploy.yaml ファイルを開きます。

  2. <AWS_ACCOUNT_ID><AWS_REGION> は、実際の環境の値に置き換えます。

  3. deploy.yaml ファイルを保存して閉じます。

  4. 次のコマンドを入力して、ターゲット Amazon EKS クラスターにサンプルアプリケーションをデプロイします。

    kubectl apply -f deploy.yaml

    このコマンドは、クラスターにデプロイとサービスアカウントを作成します。

DevOps エンジニア

IAM ロールをアプリケーションサービスアカウントに割り当てます。

keda-identity IAM ロールをサンプルアプリケーションのサービスアカウントに関連付けるには、次のいずれかを実行します。

  • Amazon EKS ドキュメントの「IAM ロールを Kubernetes サービスアカウントに割り当てる」の手順に従ってください。以下の値を使用します。

    • IAM ロールの場合は、「keda-identity」と入力します。

    • Kubernetes 名前空間の場合は、「security」と入力します。

    • Kubernetes サービスアカウントの場合は、「my-sqs-read-msgs」と入力します。

  • 次のコマンドを入力します AWS CLI 。<cluster-name> をターゲット Amazon EKS クラスターの名前に置き換え、<role-ARN>keda-identity ロールの Amazon リソースネーム (ARN) に置き換えます。

    aws eks create-pod-identity-association \ --cluster-name <cluster-name> \ --role-arn <role-ARN> \ --namespace security \ --service-account my-sqs-read-msgs
DevOps エンジニア

ScaledObjectTriggerAuthentication をデプロイします。

  1. クローンしたリポジトリで keda.yaml ファイルを開きます。

  2. をターゲットの ID {{AWS_ACCOUNT_ID}}に置き換えます AWS アカウント。

  3. をターゲット{{AWS_REGION}}に置き換えます AWS リージョン。

  4. (オプション) 21~24 行目で、ScaledObject スケーリングポリシーのパラメータを更新します。これらのパラメータの詳細については、以下を参照してください。

  5. keda.yaml ファイルを保存して閉じます。

  6. 次のコマンドを入力して、ScaledObject および TriggerAuthentication リソースをデプロイします。

    kubectl -n security apply -f keda.yaml
DevOps エンジニア
タスク説明必要なスキル

Amazon SQS キューにメッセージを送信します。

  1. 次のコマンドを入力して、クローン作成されたリポジトリに移動します。

    cd event-driven-autoscaling-using-podidentity-and-keda
  2. 次のコマンドを入力して、Amazon SQS キューにテストメッセージを送信します。

    python sqs_send_msg.py

    sqs_send_msg.py スクリプトは、自動スケーリングをテストするためのメッセージを生成するアプリケーションとして機能します。

    注記

    Python 3 を使用している場合は、「python3 sqs_send_msg.py」と入力します。

DevOps エンジニア

アプリケーションポッドをモニタリングします。

  1. 別のターミナルで、次のコマンドを入力してポッドをモニタリングします。

    kubectl -n security get po 
  2. Amazon SQS キュー内の未読メッセージ 5 件ごとに、KEDA は 1 つのポッドを追加します。前のコマンドの出力で、新しいポッドが追加されていることを確認します。以下は出力例です。

    kubectl -n security get po NAME READY STATUS RESTARTS AGE q-read-797f4c7589-2bj76 1/1 Running 0 2s q-read-797f4c7589-4zxph 1/1 Running 0 49s q-read-797f4c7589-cg9dt 1/1 Running 0 18s q-read-797f4c7589-slc69 1/1 Running 0 33s
  3. テストが完了したら、元のターミナルで、Ctrl + C (Windows) または CMD + C (macOS) を押します。これにより、python sqs_send_msg.py スクリプトが停止します。

DevOps エンジニア

トラブルシューティング

問題ソリューション

KEDA オペレーターがアプリケーションをスケールできません。

次のコマンドを入力して、keda-operator IAM ロールのログを確認します。

kubectl logs -n keda -l app=keda-operator -c keda-operator

 

HTTP 403 レスポンスコードがある場合、アプリケーションと KEDA スケーラーには Amazon SQS キューにアクセスするための十分な権限がありません。以下のステップを実行します。

  1. keda-identity ロールの IAM ポリシーとステートメントをチェックして、キューの読み取りアクセス権限が付与されていることを確認します。

  2. IAM ロール間の信頼関係を検証します。以下に例を示します。

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] }

Assume-Role エラーが発生した場合、Amazon EKS ノードの IAM ロールは、TriggerAuthentication に定義されている IAM ロールを引き受けることができません。以下のステップを実行します。

  1. 次のコマンドを入力して keda-operator ポッドを削除し、新しいポッドを作成します。

    kubectl delete pod keda-operator-<alphenumeric-value> --namespace keda
  2. 次のコマンドを入力して、ポッドが引き受ける ID を確認します。

    kubectl describe pod <keda-operator-pod-name> --namespace keda
  3. ポッドが正常に再起動したら、次の 2 つの変数がポッドの記述に追加されていることを確認します。

    • AWS_CONTAINER_CREDENTIALS_FULL_URI

    • AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE

関連リソース