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

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

Amazon EKS プロビジョンドコントロールプレーン

概要:

Amazon EKS プロビジョンドコントロールプレーンは、クラスター管理者が一連のスケーリング階層から選択し、選択した階層を指定して、クラスターのコントロールプレーンから非常に高く予測可能なパフォーマンスを実現できるようにする機能です。これにより、クラスター管理者は、コントロールプレーンが常に指定された容量でプロビジョニングされるようにできます。

Amazon EKS には、クラスターのコントロールプレーン用に 2 つのオペレーションモードが用意されています。デフォルトでは、Amazon EKS クラスターはスタンダードモードを使用します。このモードでは、コントロールプレーンはワークロードの需要に応じて自動的にスケールアップおよびスケールダウンします。スタンダードモードでは、ワークロードのニーズを満たすのに十分なコントロールプレーン容量が動的に割り当てられ、ほとんどのユースケースで推奨されるソリューションです。ただし、コントロールプレーンのスケーリングによるパフォーマンスの変動を一切許容できない特殊なワークロードや、非常に大量のコントロールプレーン容量を必要とするワークロードの場合は、オプションでプロビジョンドモードを使用できます。プロビジョンドモードでは、要求の厳しいワークロード要件に常に対応できるコントロールプレーン容量を事前に割り当てることができます。

EKS プロビジョンドコントロールプレーンを使用すると、クラスター管理者は必要なコントロールプレーン容量を事前にプロビジョニングできるため、常に利用可能なクラスターのコントロールプレーンから予測可能で高いパフォーマンスが得られます。また、EKS プロビジョンドコントロールプレーンは、ステージングから本番稼働、ディザスタリカバリサイトまで、環境間で同じコントロールプレーン容量をクラスター管理者がプロビジョニングできるようにします。これは、環境間で得られるコントロールプレーンのパフォーマンスに一貫性があり、予測可能であることを確実にするために重要なことです。最後に、EKS プロビジョンドコントロールプレーンでは、非常に高いレベルのコントロールプレーンパフォーマンスにアクセスできるため、Kubernetes で非常にスケーラブルな AI ワークロード、高性能コンピューティング、大規模なデータ処理ワークロードを実行できます。

既存および新規の Amazon EKS クラスターはすべて、デフォルトでスタンダードモードで動作します。コントロールプレーンから高い予測可能なパフォーマンスを必要とするクラスターでは、EKS プロビジョンドコントロールプレーン機能の使用をオプトインできます。標準または延長サポートの EKS 時間単位料金に加えて、特定のコントロールプレーンのスケーリング階層に対する時間単位料金が請求されます。料金に関する詳細については、「Amazon EKS の料金」を参照してください。

ユースケース

EKS プロビジョンドコントロールプレーンは、高い予測可能なコントロールプレーンのパフォーマンスがオペレーションにとって重要な特定のシナリオに対処するように設計されています。これらのユースケースを理解することで、EKS プロビジョンドコントロールプレーンがワークロードに適したソリューションかどうかを判断できます。

パフォーマンスクリティカルなワークロード – Kubernetes コントロールプレーンから最小のレイテンシーと最大のパフォーマンスを必要とするワークロードの場合、EKS プロビジョンドコントロールプレーンは、コントロールプレーンのスケーリングによるパフォーマンスの変動を排除する容量を提供します。

大規模にスケーラブルなワークロード – AI トレーニングや推論、高性能コンピューティング、大規模なデータ処理など、クラスターで実行されている多数のノードを必要とする非常にスケーラブルなワークロードを実行する場合、プロビジョンドコントロールプレーンは、これらの要求の厳しいワークロードをサポートするために必要なコントロールプレーン容量を提供します。

予想される需要の高いイベント – e コマースの販売やプロモーション、製品の発売、ホリデーシーズンのショッピング、スポーツやエンターテインメントの大規模なイベントなど、今後のイベントが原因でコントロールプレーンのリクエストが急増すると予想される場合、プロビジョンドコントロールプレーンでは、コントロールプレーンの容量を事前にスケールできます。このプロアクティブアプローチにより、自動スケーリングが需要に応答するのを待たずに、増加した負荷をコントロールプレーンが処理できるようになります。

環境の一貫性 – プロビジョンドコントロールプレーンを使用すると、ステージング環境と本番稼働環境間でコントロールプレーンの容量とパフォーマンスを照合できるため、本番稼働環境へのデプロイ前に潜在的な問題を特定できます。環境間で同じコントロールプレーン層を維持することで、テスト結果に本番稼働の動作を正確に反映し、ロールアウト中に発生するパフォーマンス関連の予期しない問題のリスクを減らすことができます。

ディザスタリカバリと事業継続性 – ディザスタリカバリのシナリオでは、プロビジョンドコントロールプレーンを使用すると、プライマリ環境と同じレベルの容量でフェイルオーバー環境をプロビジョニングできます。これにより、ディザスタリカバリクラスターは、アクティブ化された瞬間から本番稼働クラスターと同じコントロールプレーンのパフォーマンス特性を持つため、フェイルオーバーイベント中の中断を最小限に抑え、迅速な復旧が可能になります。

コントロールプレーンのスケーリング階層

EKS プロビジョンドコントロールプレーンは、T シャツサイズ (XL、2XL, 4XL) で命名されたスケーリング階層を提供します。各階層は、クラスターのコントロールプレーンのパフォーマンス特性を決定する 3 つの主要な Kubernetes 属性によって容量を定義します。これらの属性を理解することで、ワークロード要件に適した階層を選択できます。

API リクエスト同時実行数は、Kubernetes コントロールプレーンの API サーバーが同時に処理できるリクエストの数を測定します。これは、高スループットワークロードにとって重要です。

ポッドスケジューリングレートは、デフォルトの Kubernetes スケジューラがノードでポッドをスケジュールできる速度を示し、1 秒あたりのポッド数で測定されます。

クラスターデータベースのサイズは、クラスターの状態/メタデータを保持するデータベースである etcd に割り当てられたストレージ領域を示します。

プロビジョンドコントロールプレーンを使用して特定のスケーリング階層でクラスターのコントロールプレーンをプロビジョニングすると、EKS はクラスターのコントロールプレーンがその階層に対応する制限を維持するようにします。コントロールプレーンのスケーリング階層の制限は、次の表に示すように、Kubernetes のバージョンによって異なります。

EKS v1.28 および v1.29

EKS v1.30 以降

コントロールプレーンのスケーリング階層の使用率のモニタリング

Amazon EKS には、コントロールプレーンの階層使用率のモニタリングに役立つメトリクスがいくつか用意されています。これらのメトリクスは Amazon CloudWatch メトリクスとして公開されており、CloudWatch および EKS コンソールからアクセスできます。さらに、これらのメトリクスは EKS クラスターの Prometheus エンドポイントからスクレイピングできます (こちらを参照)。

Amazon EKS コンソールでコントロールプレーンの使用率を表示できます。クラスターの概要ページから、[クラスターをモニタリング] を選択してオブザーバビリティダッシュボードにアクセスし、[コントロールプレーンのモニタリング] タブを選択して、[コントロールプレーンのスケーリング]セクションでコントロールプレーンの使用率を表示します。

階層容量と実際のパフォーマンスについて

プロビジョンドコントロールプレーンのスケーリング階層を選択すると、階層属性は Amazon EKS がコントロールプレーンに適用する基盤となる設定を表します。ただし、実際のパフォーマンスは、特定のワークロードパターン、設定、Kubernetes のベストプラクティスへの準拠によって異なります。例えば、4XL 階層では API Priority and Fairness (APF) が 6,800 の同時リクエスト枠で設定されていますが、コントロールプレーンから得られる実際のリクエストスループットは、実行されるオペレーションのタイプによって異なります。例えば、Kubernetes は get リクエストよりも list リクエストに対して大きなペナルティを課すため、コントロールプレーンで同時に処理される list リクエストの実効数は、get リクエストより少なくなります (こちらを参照)。同様に、4XL 階層ではデフォルトのスケジューラ QPS が 400 に設定されていますが、実際のポッドスケジューリングレートは、ノードの準備状況やスケジューリング時のヘルスなどの要因によって異なります。最適なパフォーマンスを実現するには、アプリケーションが Kubernetes のベストプラクティス (こちらを参照) に従っており、ワークロードの特性に合わせて適切に設定されていることを確認します。

考慮事項