このページでは、非常に大規模なクラスタを計画して設計する際のベスト プラクティスについて説明します。
大規模な GKE クラスタを計画する理由
Kubernetes を含むすべてのコンピュータ システムには、アーキテクチャ上の制限があります。上限を超えるとクラスタのパフォーマンスに影響することがあり、場合によってはダウンタイムが発生することもあります。クラスタで大規模にワークロードを確実に実行するには、ベスト プラクティスに沿って推奨アクションを実行してください。
ワークロードを複数のクラスタに分割するためのおすすめの方法
ワークロードは、単一の大規模なクラスタ上で実行できます。このアプローチは、複数のクラスタよりも管理が容易で、コスト効率が高く、リソース使用率も高くなります。ただし、複数クラスタへのワークロードの分割を検討することが必要な場合があります。
- 複数クラスタのユースケースを確認して、複数のクラスタを使用するための一般的な要件とシナリオについて詳細をご覧ください。
- さらに、スケーラビリティの観点からは、クラスタが以下のセクションで説明する上限のいずれか、または GKE の割り当てのいずれかを超える可能性がある場合は、クラスタを分割してください。GKE の上限到達に関するリスクを軽減すると、ダウンタイムやその他の信頼性の問題のリスクを軽減できます。
クラスタを分割する場合は、フリート管理を使用してマルチクラスタ フリートの管理を簡素化します。
制限とおすすめの方法
アーキテクチャで大規模な GKE クラスタがサポートされるように、次の上限と関連するベスト プラクティスを確認してください。これらの上限を超えると、クラスタのパフォーマンスの低下や信頼性の問題が発生する可能性があります。
これらのベスト プラクティスは、拡張機能がインストールされていないデフォルトの Kubernetes クラスタに適用されます。Webhook やカスタム リソース定義（CRD）を使用して Kubernetes クラスタを拡張することは一般的ですが、クラスタのスケーリングが制限される可能性があります。
次の表は、主な GKE の割り当てと上限を拡張したものです。また、大規模なクラスタを対象としたオープンソースの Kubernetes の上限についても理解しておく必要があります。
表に記載されている GKE バージョンの要件は、ノードとコントロール プレーンの両方に適用されます。
| GKE の上限 | 説明 | ベスト プラクティス |
|---|---|---|
| etcd データベースのサイズ | etcd データベースの最大サイズは 6 GB です。数万のリソースを持つ非常に大規模なクラスタを実行している場合、etcd インスタンスはこの上限を超えることがあります。クラスタの使用率レベルは Google Cloud コンソールで確認できます。 | この上限を超えると、GKE によって etcd インスタンスが異常としてマークされる可能性があります。これにより、クラスタ コントロール プレーンが応答しなくなります。 この上限を超える場合は、Google Cloud サポートにお問い合わせください。 |
| タイプごとの etcd オブジェクトの合計サイズ | 指定されたリソースタイプのすべてのオブジェクトの合計サイズは 800 MB を超えないようにしてください。たとえば、750 MB の Pod インスタンスと 750 MB の Secret を作成できますが、850 MB の Secret は作成できません。800 MB を超えるオブジェクトを作成すると、Kubernetes またはカスタマイズされたコントローラで初期化に失敗し、中断が発生する可能性があります。 |
etcd に保存されている各タイプのすべてのオブジェクトの合計サイズを 800 MB 未満にしてください。これは特に、多数のサイズが大きな Secret または ConfigMap を使用するクラスタ、または大量の CRD を使用するクラスタについて該当します。 |
| GKE Dataplane V2 が有効になっていないクラスタの Service の数 | 次のいずれかの状態になると、kube-proxy で使用される iptables のパフォーマンスが低下します。
GKE Dataplane V2 を有効にすると、この上限はなくなります。 |
クラスタ内の Service 数を 10,000 未満にします。 詳細については、Service を使用したアプリケーションの公開をご覧ください。 |
| Namespace あたりの Service の数 | Service 用に生成された環境変数の数が、シェルの上限を超えることがあります。これによって起動時に Pod がクラッシュすることがあります。 |
Namespace あたりの Service の数を 5,000 未満にします。 これらの環境変数の設定を無効にできます。PodSpec の 詳細については、Service を使用したアプリケーションの公開をご覧ください。 |
| GKE Dataplane V2 が有効になっていないクラスタで、1 つの Service の背後にある Pod の数 |
すべてのノードは kube-proxy を実行します。これは、ウォッチを使用して Service の変更をモニタリングします。クラスタが大きいほど、エージェントが処理する変更関連のデータが多くなります。これは、500 ノードを超えるクラスタで特に顕著です。 エンドポイントに関する情報は別々の エンドポイント オブジェクトは引き続きコンポーネントで使用できますが、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 の間で変化します。高スループットの Logging エージェント構成をデプロイすると、この上限を 10 Mbps に引き上げることができます。この上限を超えると、ログエントリが破棄される可能性があります。 |
デフォルトの上限を超えないように Logging を構成するか、高スループットの 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 つの運用モードがあります。 各モードには異なるスケーラビリティの特性と制限事項があります。 |
各 Config Connector インスタンスには、0.1 CPU リクエストと 512 MB メモリの上限があります。そのため、大量のマネージド リソースまで適切にスケールされることはありません。Config Connector インスタンスごとに 25,000 個以下の Google Cloud リソースを配置することをおすすめします。使用するメモリの量は、リソースの種類と特定のユースケースによって異なるため、この上限は参考目的でのみ提示されているものです。 多数のマネージド リソースを管理する場合は、Namespace モードを使用して、各 Config Connector インスタンスで処理されるリソースの数を制限することをおすすめします。 Namespace モードでは、Config Connector に 500 個までの Namespace を使用することをおすすめします。各 Config Connector インスタンスは、kube-apiserver への多数のウォッチ接続を開きます。特にコントロール プレーンのアップグレード中にウォッチ接続を再初期化する必要がある場合に、これらのインスタンスの多数は GKE クラスタ コントロール プレーンに過負荷をかける場合があります。 複数の GKE クラスタを使用して、上記のとおり指定した上限に収まるように分割できないリソースの数を管理することをおすすめします。 詳細については、Config Controller のスケーラビリティ ガイドラインをご覧ください。 |