EKS スケーラビリティのベストプラクティス

このガイドでは、EKS クラスターのスケーリングに関するアドバイスを提供します。EKS クラスターのスケーリングの目的は、単一のクラスターが実行できる作業量を最大化することです。単一の大規模な EKS クラスターを使用すると、複数のクラスターを使用する場合と比較して運用負荷を軽減できますが、マルチリージョンデプロイ、テナント分離、クラスターのアップグレードなどにはトレードオフがあります。このドキュメントでは、単一のクラスターで最大限のスケーラビリティを実現する方法に焦点を当てます。

このガイドの使い方

このガイドは、AWS での EKS クラスターの作成と管理を担当する開発者と管理者を対象としています。一般的な Kubernetes スケーリングプラクティスに焦点を当てていますが、EKS Anywhere を使用して AWS リージョンの外部で実行されるセルフマネージド Kubernetes クラスターやクラスターに固有のものはありません。

各トピックには簡単な概要があり、その後に EKS クラスターを大規模に運用するための推奨事項とベストプラクティスが続きます。トピックは特定の順序で読み取る必要はなく、推奨事項はクラスターで機能するテストと検証を行わずに適用しないでください。

スケーリングディメンションについて

スケーラビリティはパフォーマンスや信頼性とは異なり、クラスターやワークロードのニーズを計画する際には 3 つすべてを考慮する必要があります。クラスターがスケールする場合はモニタリングする必要がありますが、このガイドではモニタリングのベストプラクティスについては説明しません。EKS は大きなサイズにスケールできますが、クラスターを 300 ノードまたは 5,000 ポッド以上にスケールする方法を計画する必要があります。これらは絶対数ではありませんが、このガイドを複数のユーザー、エンジニア、サポートプロフェッショナルと共同で作成したものです。

Kubernetes でのスケーリングは多次元であり、あらゆる状況で機能する特定の設定や推奨事項はありません。スケーリングのガイダンスを提供できる主な領域は次のとおりです。

EKS クラスターの Kubernetes コントロールプレーンには、AWS が実行およびスケーリングするすべてのサービス (Kubernetes API サーバーなど) が含まれます。コントロールプレーンのスケーリングは AWS の責任ですが、責任を持ってコントロールプレーンを使用するのはお客様の責任です。

Kubernetes Data Plane スケーリングは、クラスターとワークロードに必要な AWS リソースを処理しますが、EKS コントロールプレーンの外部にあります。EC2 インスタンス、kubelet、ストレージなどのリソースはすべて、クラスターのスケールに応じてスケールする必要があります。

クラスターサービスは、クラスター内で実行され、クラスターとワークロードに機能を提供する Kubernetes コントローラーとアプリケーションです。これらは、EKS アドオン、およびコンプライアンスと統合のためにインストールする他の サービスや Helm チャートです。これらのサービスはワークロードによって依存されることが多く、ワークロードがスケールするにつれて、クラスターサービスはそれらに合わせてスケールする必要があります。

ワークロードはクラスターがある理由であり、クラスターと水平方向にスケーリングする必要があります。Kubernetes には、クラスターのスケールに役立つワークロードの統合と設定があります。名前空間やサービスなどの Kubernetes 抽象化には、アーキテクチャ上の考慮事項もあります。

超大規模スケーリング

1,000 個のノードまたは 50,000 個の Pod を超えて単一のクラスターをスケーリングする場合は、ぜひお問い合わせください。サポートチームまたはテクニカルアカウントマネージャーに連絡して、このガイドに記載されている情報を超えて計画とスケーリングを支援できるスペシャリストに連絡することをお勧めします。Amazon EKS は、オンボーディング対象として選択されている場合、1 つのクラスターで最大 100,000 個のノードをサポートできます。