大規模な GKE クラスタを計画する

このページでは、非常に大規模なクラスタを計画して設計する際のベスト プラクティスについて説明します。

大規模な GKE クラスタを計画する理由

Kubernetes を含むすべてのコンピュータ システムには、アーキテクチャ上の制限があります。上限を超えるとクラスタのパフォーマンスに影響することがあり、場合によってはダウンタイムが発生することもあります。クラスタで大規模にワークロードを確実に実行するには、ベスト プラクティスに沿って推奨アクションを実行してください。

大規模な GKE クラスタの制限事項

GKE がクラスタを多数のノードにスケーリングする場合、GKE はサービスレベル目標（SLO）の範囲内で、システムのニーズに合わせて使用可能なリソースの量を変更します。Google Cloud は大規模なクラスタをサポートしています。ただし、ユースケースに応じて、大規模なクラスタの制限を考慮し、インフラストラクチャのスケール要件に適切に対応する必要があります。

このセクションでは、想定されるノード数に基づいて大規模な GKE クラスタを設計する場合の制限事項と考慮事項について説明します。

5,000 ノードまでのクラスタ

5,000 ノードまでスケールアップするクラスタ アーキテクチャを設計する場合は、次の条件を考慮してください。

  • リージョン クラスタでのみ使用できます。
  • Private Service Connect を使用するクラスタでのみ使用できます。
  • ゾーンクラスタからリージョン クラスタに移行するには、クラスタを再作成して、より高いノード割り当てレベルのロックを解除する必要があります。

クラスタを 5,000 ノード以上にスケーリングする場合は、Cloud カスタマーケアにお問い合わせのうえ、クラスタサイズと割り当て上限を増やしてください。

5,000 ノードを超えるクラスタ

GKE は、最大 15,000 ノードの大規模な Standard クラスタをサポートしています。バージョン 1.31 以降では、GKE は最大 65,000 ノードの大規模なクラスタをサポートしています。65,000 という上限は、大規模な AI ワークロードの実行を目的としています。

クラスタを 15,000 ノードまたは 65,000 ノードにスケーリングする場合は、次のタスクを完了します。

  1. 次の制限事項を考慮してください。

  2. クラスタサイズと割り当て上限を 15,000 ノードまたは 65,000 ノード（スケーリングのニーズに応じて）に増やすには、Cloud カスタマーケアにお問い合わせください。

ワークロードを複数のクラスタに分割するためのおすすめの方法

ワークロードは、単一の大規模なクラスタ上で実行できます。このアプローチは、複数のクラスタよりも管理が容易で、コスト効率が高く、リソース使用率も高くなります。ただし、複数クラスタへのワークロードの分割を検討することが必要な場合があります。

  • 複数クラスタのユースケースを確認して、複数のクラスタを使用するための一般的な要件とシナリオについて詳細をご覧ください。
  • さらに、スケーラビリティの観点からは、クラスタが以下のセクションで説明する上限のいずれか、または GKE の割り当てのいずれかを超える可能性がある場合は、クラスタを分割してください。GKE の上限到達に関するリスクを軽減すると、ダウンタイムやその他の信頼性の問題のリスクを軽減できます。

クラスタを分割する場合は、フリート管理を使用してマルチクラスタ フリートの管理を簡素化します。

制限とおすすめの方法

アーキテクチャで大規模な GKE クラスタがサポートされるように、次の上限と関連するベスト プラクティスを確認してください。これらの上限を超えると、クラスタのパフォーマンスの低下や信頼性の問題が発生する可能性があります。

これらのベスト プラクティスは、拡張機能がインストールされていないデフォルトの Kubernetes クラスタに適用されます。Webhook やカスタム リソース定義（CRD）を使用して Kubernetes クラスタを拡張することは一般的ですが、クラスタのスケーリングが制限される可能性があります。

次の表は、主な GKE の割り当てと上限を拡張したものです。また、大規模なクラスタを対象としたオープンソースの Kubernetes の上限についても理解しておく必要があります。

表に記載されている GKE バージョンの要件は、ノードとコントロール プレーンの両方に適用されます。

GKE の上限 説明 ベスト プラクティス
クラスタ状態データベースのサイズ クラスタ状態データベースの最大サイズは 6 GB です。数万のリソースを持つ非常に大規模なクラスタを実行している場合、クラスタ状態データベースはこの上限を超えることがあります。クラスタの使用率レベルは Google Cloud コンソールで確認できます。 この上限を超えると、GKE によってクラスタ状態データベースが異常としてマークされる可能性があります。これにより、クラスタ コントロール プレーンが応答しなくなります。

この上限を超える場合は、Google Cloud サポートにお問い合わせください。
タイプごとの Kubernetes API オブジェクトの合計サイズ 指定されたリソースタイプのすべてのオブジェクトの合計サイズは 800 MB を超えないようにしてください。たとえば、750 MB の Pod インスタンスと 750 MB の Secret を作成できますが、850 MB の Secret は作成できません。800 MB を超えるオブジェクトを作成すると、Kubernetes またはカスタマイズされたコントローラで初期化に失敗し、中断が発生する可能性があります。

クラスタ内の各タイプのすべての Kubernetes API オブジェクトの合計サイズを 800 MB 未満にしてください。これは特に、多数のサイズが大きな Secret または ConfigMap を使用するクラスタ、または大量の CRD を使用するクラスタについて該当します。
GKE Dataplane V2 が有効になっていないクラスタの Service の数 次のいずれかの状態になると、kube-proxy で使用される iptables のパフォーマンスが低下します。
  • 過剰な数の Service が存在する。
  • Service の背後で実行されるバックエンドの数が多い。

GKE Dataplane V2 を有効にすると、この上限はなくなります。

クラスタ内の Service 数を 10,000 未満にします。

詳細については、Service を使用したアプリケーションの公開をご覧ください。
Namespace あたりの Service の数 Service 用に生成された環境変数の数が、シェルの上限を超えることがあります。これによって起動時に Pod がクラッシュすることがあります。

Namespace あたりの Service の数を 5,000 未満にします。

これらの環境変数の設定を無効にできます。PodSpec の enableServiceLinks を false に設定する方法のドキュメントをご覧ください。

詳細については、Service を使用したアプリケーションの公開をご覧ください。
GKE Dataplane V2 が有効になっていないクラスタで、1 つの Service の背後にある Pod の数

すべてのノードは kube-proxy を実行します。これは、ウォッチを使用して Service の変更をモニタリングします。クラスタが大きいほど、エージェントが処理する変更関連のデータが多くなります。これは、500 ノードを超えるクラスタで特に顕著です。

エンドポイントに関する情報は別々の EndpointSlices に分割されます。この分割により、変更のたびに転送されるデータの量が削減されます。

エンドポイント オブジェクトは引き続きコンポーネントで使用できますが、1,000 を超える Pod は自動的に切り捨てられます。

1 つの Service の背後の Pod 数を 10,000 未満に維持します。

詳細については、Service を使用したアプリケーションの公開をご覧ください。
GKE Dataplane V2 が有効になっているクラスタで、1 つの Service の背後にある Pod の数

GKE Dataplane V2 には、単一の Service で公開される Pod の数の上限が含まれています。

GKE Dataplane V2 を使用するため、Autopilot クラスタには同じ上限が適用されます。

GKE 1.23 以前では、1 つの Service の背後の Pod 数を 1,000 未満に維持します。

GKE 1.24 以降では、単一の Service の背後の Pod 数を 10,000 未満に維持します。

詳細については、Service を使用したアプリケーションの公開をご覧ください。
ヘッドレス Service あたりの DNS レコード数

ヘッドレス Service あたりの DNS レコード数は、kube-dns と Cloud DNS の両方で制限されています。

ヘッドレス Service あたりの DNS レコード数を、kube-dns の場合は 1,000 未満、Cloud DNS の場合は 3,500 / 2,000（IPv4 / IPv6）未満に保ちます。
すべての Service エンドポイントの数 すべての Service のエンドポイントの数が上限に達する可能性があります。これにより、プログラミングのレイテンシが増加する、または新しいエンドポイントをまったく作成できなくなる可能性があります。

すべての Service に含まれる、すべてのエンドポイントの数を 260,000 未満にします。

GKE Autopilot のデフォルトのデータプレーンである GKE Dataplane V2 は、eBPF マップに依存しています。このマップは現在のところ、すべての Service の合計で 260,000 エンドポイントに制限されています。
クラスタごとの HorizontalPodAutoscaler オブジェクトの数

各 HorizontalPodAutoscaler（HPA）は 15 秒ごとに処理されます。

HPA オブジェクトの数が 300 を超えると、パフォーマンスが直線的に低下する可能性があります。

HPA オブジェクトの数は、この上限内に収めてください。そうしないと、HPA 処理の頻度が直線的に低下する場合があります。たとえば、HPA が 2,000 の GKE 1.22 では、1 つの HPA が 1 分 40 秒ごとに再処理されます。

詳細については、リソース使用率に基づく自動スケーリングと水平 Pod 自動スケーリングのスケーラビリティをご覧ください。
ノードあたりの Pod の数 GKE にはノードあたり 256 個の Pod のハードリミットがあります。これは、Pod あたり平均 2 つ以下のコンテナを前提としています。Pod あたりのコンテナの数を増やすと、GKE がコンテナごとにより多くのリソースを割り当てるため、この上限が低下することがあります。

10 個の Pod ごとに少なくとも 1 つの vCPU を持つワーカーノードを使用することをおすすめします。

詳細については、クラスタまたはノードプールの手動アップグレードをご覧ください。
Pod の変更率

Kubernetes には内部スケーリングの上限があり、スケーリング リクエストに応じて Pod の作成や削除を行うレート（Pod のチャーン）に影響します。Service の一部である Pod を削除するなどの追加要因も、この Pod のチャーンレートに影響を与える可能性があります。

最大 500 ノードのクラスタの場合、1 秒あたり平均 20 個の Pod が作成され、1 秒あたり 20 個の Pod が削除されます。

500 ノードを超えるクラスタでは、1 秒あたり平均 100 個の Pod が作成され、1 秒あたり 100 個の Pod が削除されます。

ワークロードのスケール方法を計画する際は、Pod の作成と削除のレート上限を考慮してください。

Pod は、他のリソースタイプ（EndpointSlice など）と同じ削除スループットを共有します。削除スループットは、Service の一部として Pod を定義するときに削減できます。

クラスタ オートスケーラーが使用率の低いノードから Pod を効果的に削除できるようにするには、制限が厳しい PodDisruptionBudgets と長い終了猶予期間を使用しないでください。

ワイルドカードの toleration も、削除中のノードでワークロードがスケジュールされる可能性があるため、おすすめしません。
開いているウォッチの数

ノードは、Pod に構成するすべての Secret と ConfigMap に対してウォッチを作成します。すべてのノードによって作成されたウォッチの合計量により、クラスタ コントロール プレーンにかなりの負荷が発生する場合があります。

1 つのクラスタに 200,000 回を超えるウォッチがあると、クラスタの初期化時間に影響する可能性があります。この問題により、コントロール プレーンが頻繁に再起動する可能性があります。

大規模なノードを定義して、多数のウォッチが原因で発生する問題の可能性と重大度を低減します。Pod の密度が高いほど（つまりサイズの大きなノードが減少するほど）、ウォッチの数が減少し、問題の重大度が低下する可能性があります。

詳細については、マシンシリーズの比較をご覧ください。
アプリケーション レイヤでの Secret の暗号化が有効な場合の、クラスタごとの Secret の数 アプリケーション レイヤでの Secret の暗号化が有効になっている場合、クラスタはクラスタの起動時にすべての Secret を復号する必要があります。30,000 個を超える Secret を保存すると、起動またはアップグレード中にクラスタが不安定になり、ワークロードが停止する可能性があります。

アプリケーション レイヤでの Secret の暗号化で 30,000 個未満の Secret を保存します。

詳しくは、アプリケーション レイヤで Secret を暗号化するをご覧ください。
ノードあたりのログ帯域幅

各ノードから Cloud Logging API に送信されるログの最大量には上限があります。デフォルトの上限は、負荷に応じて 100～500 Kbps の間で変化します。Standard クラスタの場合は、高スループットの Logging エージェント構成をデプロイすることで、この上限を 10 MiB に引き上げることができます。この上限を超えると、ログエントリが破棄される可能性があります。

デフォルトの上限を超えないように Logging を構成するか、高スループットの Logging エージェントを構成します。

詳細については、ログ スループットの調整をご覧ください。
Backup for GKE の上限

Backup for GKE を使用すると、GKE ワークロードをバックアップおよび復元できます。

Backup for GKE には、バックアップ プランを定義する際に留意する必要がある上限が適用されます。

Backup for GKE の上限を確認してください。

ワークロードがこれらの上限を超える可能性がある場合は、バックアップを分割して上限内に収まるように、複数のバックアップ プランを作成することをおすすめします。
Config Connector の上限

Config Connector を使用して、Kubernetes を通じて Google Cloud リソースを管理できます。Config Connector には 2 つの運用モードがあります。

  • クラスタモード。GKE クラスタごとに単一の Config Connector インスタンスがあります。

    このモードでは、単一の Config Connector インスタンスがすべてのリソースを読み込みます。

  • Namespace モード。クラスタ内の各 Namespace には別々の Config Connector インスタンスがあります。

    このモードでは、Namespace を介してマネージド リソースを分割できます。この設定により、単一の Config Connector インスタンスで管理する必要があるリソースの量を削減し、CPU とメモリの使用量が減少します。

各モードには異なるスケーラビリティの特性と制限事項があります。

リソース上限の詳細については、Config Controller のスケーラビリティ ガイドラインをご覧ください。多数のリソースの管理については、Config Connector のベスト プラクティスをご覧ください。

次のステップ