このページでは、複数の GKE クラスタで大規模なワークロードを管理する場合のベスト プラクティスについて説明します。これらのベスト プラクティスには、複数のプロジェクト間でワークロードを分散し、必要な割り当てを調整するための考慮事項が含まれます。
複数の Google Cloud プロジェクト間で GKE ワークロードを分散するためのベスト プラクティス
Google Cloud プロジェクトの構造と GKE ワークロードの分散を、ビジネス要件に基づいてより適切に定義するには、次の設計と計画の対応を検討することをおすすめします。
- クラウド リソースを管理するのベスト プラクティスに沿って、フォルダとプロジェクトに関する組織の構造の初期決定を行います。Google Cloud では、フォルダやプロジェクトなどのリソース階層要素を使用して、自分の組織の境界またはアクセス ポリシーに基づいてワークロードを分割することをおすすめします。
- プロジェクトの割り当てのためにワークロードを分割する必要があるかどうかを検討します。Google Cloud では、プロジェクトごとの割り当てを使用して共有リソースの使用を制限します。以下に説明する推奨事項に従って、大規模なワークロードに合わせてプロジェクトの割り当てを調整する必要があります。ほとんどのワークロードでは、単一のプロジェクトだけで、十分な量の必要な割り当てを確保できるはずです。つまり、複数のプロジェクト間でワークロードを分割するうえで、割り当てを主な要因とはしないでください。ワークロードをより少ない数のプロジェクトに保持することで、割り当てとワークロードの管理を簡素化できます。
- 非常に大規模なワークロード（例: 数十万以上の CPU）を実行する予定があるかどうかを検討します。該当する場合は、ワークロードを複数のプロジェクトに分割すると、クラウド リソース（CPU や GPU など）の可用性を向上できます。これが可能なのは、ゾーン仮想化の最適化された構成を使用しているためです。このような場合は、アカウント マネージャーに連絡して、特別なサポートを受け、推奨事項を入手してください。
大規模な GKE ワークロードの割り当て調整のためのベスト プラクティス
このセクションでは、GKE ワークロードで使用される Google Cloud リソースの割り当ての調整のためのガイドラインについて説明します。次のガイドラインに基づいてプロジェクトの割り当てを調整します。Google Cloud コンソールを使用して割り当てを管理する方法については、割り当てを操作するをご覧ください。
Compute Engine の割り当てとベスト プラクティス
Autopilot と Standard の両方のモードで実行されている GKE クラスタでは、Compute Engine リソースを使用してワークロードを実行します。Google Cloud によって内部管理される Kubernetes コントロール プレーン リソースとは対照的に、ワークフローで使用する Compute Engine の割り当ては管理者が管理、評価できます。
リソースと API の両方の Compute Engine の割り当ては、同じプロジェクトとリージョンでホストされているすべての GKE クラスタで共有されます。同じ割り当てが、GKE に関係のないその他の Compute Engine リソース（スタンドアロン VM インスタンスやインスタンス グループなど）とも共有されます。
デフォルトの割り当て値で数百のワーカーノードに対応でき、より大規模なワークロードの場合は調整が必要になります。ただし、プラットフォーム管理者として、Compute Engine の割り当てを積極的に調整し、GKE クラスタに十分なリソースを確保できます。また、割り当て値を評価または調整する際には、将来のリソースのニーズも考慮する必要があります。
GKE ワーカーノードで使用される Compute Engine リソースの割り当て
次の表に、GKE ワーカーノードで使用される最も一般的な Compute Engine リソースの割り当ての一覧を示します。これらの割り当ては、プロジェクトごと、およびリージョンごとに構成されます。割り当ては、ワークロードで使用される GKE ワーカーノードと GKE に関係のないその他の Compute Engine リソースを組み合わせた最大サイズに対応している必要があります。
| リソース割り当て | 説明 |
|---|---|
| CPU | すべてのクラスタのすべてのワーカーノードで使用される CPU の数。 |
| CPU のタイプ | すべてのクラスタのすべてのワーカーノードで使用される特定のタイプごとの CPU の数。 |
| VM インスタンス | すべてのワーカーノードの数。この割り当ては、CPU の数の 10 倍として自動的に計算されます。 |
| VPC ネットワークあたりのインスタンス数 | VPC ネットワークに接続されたすべてのワーカーノードの数。 |
| Persistent Disk Standard（GB） | すべてのワーカーノードにアタッチされている標準永続ブートディスクの合計サイズ。 |
| Persistent Disk SSD（GB） | すべてのワーカーノードにアタッチされている SSD 永続ブートディスクの合計サイズ。 |
| ローカル SSD（GB） | すべてのワーカーノードにアタッチされているローカル SSD エフェメラル ディスクの合計サイズ。 |
GPU、IP アドレス、プリエンプティブ リソースなど、ワークロードで必要となることがあるリソースで使用される割り当ても必ず調整してください。
Compute Engine API 呼び出しの割り当て
大規模なクラスタやスケーラブルなクラスタでは、より多くの Compute Engine API 呼び出しが必要です。GKE は、次のようなアクティビティ中に Compute Engine API 呼び出しを行います。
- コンピューティング リソースの状態の確認。
- クラスタへの新しいノードの追加または削除。
- 新しいノードプールの追加または削除。
- リソースの定期的なラベル付け。
大規模なクラスタのアーキテクチャを計画する場合は、次のようにすることをおすすめします。
- 過去の割り当て使用量を確認します。
- 割り当ては、適正なバッファを確保しながら必要に応じて調整します。開始にあたっては、次のベスト プラクティスをおすすめします。ワークロードのニーズに合わせて割り当てを調整できます。
- 割り当てはリージョンごとに構成されるため、割り当ての調整は、大規模なワークロードを実行する予定のリージョンでのみ行います。
次の表に、Compute Engine API 呼び出しの割り当ての一覧を示します。これらの割り当ては、プロジェクトごと、およびリージョンごとに個別に構成されます。割り当ては、同じプロジェクトと同じリージョンでホストされているすべての GKE クラスタで共有されます。
| API 割り当て | 説明 | ベスト プラクティス |
|---|---|---|
| リージョンごとの 1 分あたりのクエリ数 | これらの呼び出しは、GKE がさまざまなコンピューティング リソースの状態に対してさまざまなチェックを実行するために使用されます。 |
数百の動的ノードがあるプロジェクトとリージョンの場合は、この値を 3,500 に調整します。 数千の非常に動的なノードがあるプロジェクトとリージョンの場合は、この値を 6,000 に調整します。 |
| リージョンごとの 1 分あたりの読み取りリクエスト数 | これらの呼び出しは、GKE が VM インスタンス（ノード）の状態をモニタリングするために使用します。 |
数百のノードがあるプロジェクトとリージョンの場合は、この値を 12,000 に調整します。 数千のノードがあるプロジェクトとリージョンの場合は、この値を 20,000 に調整します。 |
| リージョンごとの 1 分あたりのリスト リクエスト数 | これらの呼び出しは、GKE がインスタンス グループ（ノードプール）の状態をモニタリングするために使用します。 |
数百の動的ノードがあるプロジェクトとリージョンの場合は、デフォルト値で十分であるため、変更しないでください。 数千の非常に動的なノードがあるプロジェクトとリージョンの場合は、この値を 2,500 に調整します。 |
| リージョンごとの 1 分あたりのインスタンス リスト リファラー リクエスト数 | これらの呼び出しは、GKE が実行中の VM インスタンス（ノード）に関する情報を取得するために使用します。 |
数千の非常に動的なノードがあるプロジェクトとリージョンの場合は、この値を 6,000 に調整します。 |
| リージョンごとの 1 分あたりのオペレーション読み取りリクエスト数 | これらの呼び出しは、GKE が進行中の Compute Engine API のオペレーションに関する情報を取得するために使用します。 |
数千の非常に動的なノードがあるプロジェクトとリージョンの場合は、この値を 3,000 に調整します。 |
Cloud Logging API と Cloud Monitoring API の割り当てとベスト プラクティス
クラスタの構成によっては、GKE クラスタで大規模なワークロードが実行されていると、大量の診断情報が生成されることがあります。Cloud Logging API または Cloud Monitoring API の割り当てを超えると、ロギングとモニタリングのデータが失われる場合があります。ログの詳細度を構成し、Cloud Logging API および Cloud Monitoring API の割り当てを調整して、生成された診断情報を取得することをおすすめします。Managed Service for Prometheus では、Cloud Monitoring の割り当てが使用されます。
ワークロードはそれぞれ異なるため、次のようにすることをおすすめします。
- 過去の割り当て使用量を確認します。
- 必要に応じて、割り当てを調整するか、ロギングとモニタリングの構成を調整します。予期しない問題が発生した場合には、適正なバッファを確保します。
次の表に、Cloud Logging API と Cloud Monitoring API の呼び出しの割り当ての一覧を示します。これらの割り当てはプロジェクトごとに構成され、同じプロジェクトでホストされているすべての GKE クラスタで共有されます。
| サービス | 割り当て | 説明 | ベスト プラクティス |
|---|---|---|---|
| Cloud Logging API | 1 分あたりの書き込みリクエスト数 | GKE は、Cloud Logging に保存されているログファイルにエントリを追加するときにこの割り当てを使用します。 |
ログの挿入率は、クラスタ内の Pod によって生成されたログの量によって異なります。Pod の数、アプリケーション ロギングの詳細度、ロギング構成に基づいて割り当てを増やします。 詳細については、GKE ログの管理に関する記事をご覧ください。 |
| Cloud Monitoring API | 1 分あたりの時系列取り込みリクエスト数 |
GKE は、Prometheus の指標を Cloud Monitoring に送信するときにこの割り当てを使用します。
|
この割り当てをモニタリングし、必要に応じて調整します。 詳細については、GKE の指標を管理するをご覧ください。 |
GKE ノードの割り当てとベスト プラクティス
GKE は、単一のクラスタで最大 15,000 ノードをサポートし、デフォルトの割り当ては 5,000 ノードに設定されています。この割り当ては、GKE クラスタごとに個別に設定され、その他の割り当てとしてプロジェクトごとに設定されることはありません。5,000 ノードを超えるクラスタをスケーリングする予定の場合は、次の手順で操作します。
- 5,000 ノードを超えてスケーリングするクラスタを特定します。
- スケーリング後にワークロードがクラスタの上限と GKE の割り当て内に確実に収まるようにしてください。
- スケーリングしたワークロードに対して、必要に応じて Compute Engine の割り当てを確実に増やしてください。
- クラスタの可用性タイプがリージョンで、ネットワーク分離が限定公開であることを確認します。
- サポート チケットを作成して、クラスタあたりのノード数の割り当ての増加をリクエストします。
GKE チームがお客様に連絡し、ワークロードがスケーラビリティのベスト プラクティスに従っており、1 つのクラスタで 5,000 ノードを超えるスケーリングが可能な状態であることを確認します。
大規模なワークロードのその他の制限を回避するためのベスト プラクティス
各ロケーション、各ネットワークあたりの VPC ネットワーク ピアリングを使用するクラスタ数の上限
同じ VPC ネットワークで VPC ネットワーク ピアリングを使用する限定公開クラスタは、各ロケーションに最大 75 個作成できます（ゾーンとリージョンは別々のロケーションとして扱われます）。上限を超えるクラスタを作成しようとすると、次のようなエラーにより失敗します。
CREATE operation failed. Could not trigger cluster creation:
Your network already has the maximum number of clusters: (75) in location us-central1.
GKE の限定公開クラスタでは、VPC ネットワーク ピアリングを使用して、Kubernetes API サーバー（Google が管理）と内部アドレスのみを持つプライベート ノードとの間の内部通信が提供されます。
この問題を解決するには、Private Service Connect（PSC）接続を使用するクラスタを使用します。PSC 接続を使用するクラスタでは、75 個のクラスタ制限なしで、限定公開クラスタと同じ分離が可能です。PSC に基づくクラスタは VPC ネットワーク ピアリングを使用せず、VPC ピアリング数の上限の影響を受けません。
VPC ネットワーク ピアリングの再利用で説明されている手順に沿って、クラスタが VPC ネットワーク ピアリングを使用しているかどうかを確認できます。
新しいクラスタの作成中に上限に達しないようにする手順は次のとおりです。
- クラスタの作成時に
no-enable-private-nodesパラメータを使用して PSC クラスタを作成します。 - 各ノードプールの
enable-private-nodesパラメータを使用して、ノードプールが限定公開となるように分離を構成します。 - 必要に応じて、クラスタレベルで
enable-private-endpointパラメータを使用して、コントロール プレーンの分離を構成します。詳細については、クラスタの分離を変更するをご覧ください。
または、Google Cloud サポートチームに連絡して、VPC ネットワーク ピアリングを使用する 75 個の限定公開クラスタの上限を引き上げる必要があります。このようなリクエストはケースバイケースで評価され、上限の引き上げが可能な場合は 1 桁引き上げられます。
次のステップ
- 大規模な GKE クラスタの構築に関するエピソードを確認する