このページでは、Google Cloud のプロジェクト、クラスタ、ノードに関するベアメタルの Google Distributed Cloud（ソフトウェアのみ）の割り当てと上限について説明します。
上限
以降のセクションでは、クラスタの基本的な上限について説明します。Google Distributed Cloud で実行するアプリケーションを設計する際は、これらの上限を考慮してください。
管理クラスタあたりの最大ユーザー クラスタ数
管理クラスタは、ユーザー クラスタとそれに関連付けられたノードのライフサイクルを管理します。管理クラスタは、クラスタの作成、クラスタまたはノードのリセット、クラスタのアップグレード、クラスタの更新など、重要なユーザー クラスタ操作を制御します。ユーザー クラスタ ノードの合計数は、パフォーマンスと信頼性を制限する主な要因の 1 つです。
継続的なテストに基づいて、管理クラスタは、最大 100 ユーザー クラスタ、それぞれ 10 ノードで合計 1,000 ノードを確実にサポートできます。
ユーザー クラスタあたりの Pod の最大数
ユーザー クラスタあたりの Pod 数は 15,000 以下に制限することをおすすめします。たとえば、クラスタに 200 個のノードが存在する場合は、ノードあたりの Pod 数を 75 以下に制限する必要があります。同様に、ノードあたり 110 の Pod を実行する場合は、クラスタ内のノード数を 136 以下に制限する必要があります。次の表に、推奨される構成と推奨されない構成の例を示します。
| ノードあたりのポッド数 | クラスタあたりのノード数 | クラスタあたりの Pod 数 | 結果 |
|---|---|---|---|
| 110 | 200 | 22,000 | 過剰な Pod 数（非推奨） |
| 110 | 136 | 14,960 | 上限内 |
| 100 | 150 | 15,000 | 上限内 |
| 75 | 200 | 15,000 | 上限内 |
以下の各セクションでは、ユーザー クラスタあたりの Pod の最大数に関する推奨事項が、ノードあたりの Pod 数とユーザー クラスタあたりのノード数に関する推奨事項よりも優先されます。
ユーザー クラスタあたりのノードの最大数
最大 500 個のノードが存在するワークロードを実行するために、Google Distributed Cloud をテストしています。ただし、最適なパフォーマンスと信頼性を確保するために、本番環境でワークロードを実行する場合は、クラスタあたりのノード数が 200 を超えないようにすることをおすすめします。
| クラスタタイプ | 最小ノード数 | 推奨される最大ノード数 | 最大ノードの絶対数 |
|---|---|---|---|
| ユーザー、スタンドアロン、またはハイブリッド | 1 | 200 | 500 |
単一ノードクラスタの場合、ノードでワークロードを実行するには node-role.kubernetes.io/master:NoSchedule taint を削除する必要があります。詳細については、Kubernetes taint と容認をご覧ください。
ノードあたりの Pod の最大数
Google Distributed Cloud は、クラスタ構成ファイルの nodeConfig.PodDensity.MaxPodsPerNode 設定で、ノードあたりの最大 Pod 数の構成をサポートしています。次の表に、アドオン サービスを実行する Pod を含む、MaxPodsPerNode でサポートされている最小値と最大値を示します。
| クラスタタイプ | 最小許容値 | 推奨される最大値 | 最大許容値 |
|---|---|---|---|
| すべての HA クラスタと非 HA ユーザー クラスタ | 32 | 110 | 250 |
| その他のすべての非 HA クラスタ | 64 | 110 | 250 |
エンドポイントの最大数
Red Hat Enterprise Linux（RHEL）では、100,000 エンドポイントのクラスタレベルの上限があります。この数は、Kubernetes サービスによって参照されるすべての Pod の合計です。2 つのサービスが同じ Pod のセットを参照する場合、この状況では 2 つの別のエンドポイント セットとしてカウントされます。RHEL 上の基礎的な nftable 実装には、この制約が発生します。Google Distributed Cloud の固有の制限ではありません
対策
RHEL の場合、対策はありません。Ubuntu システムと Debian システムの場合、大規模なクラスタでデフォルトの nftables から以前の iptables への切り替えをおすすめします。
GKE Dataplane V2
Google Distributed Cloud は、GKE Dataplane V2 を使用します。これは、Cilium とeBPF で実装されたクラスタ データプレーンで、Kubernetes ネットワーク用に最適化されています。
GKE Dataplane V2 の NetworkPolicy の上限
GKE Dataplane V2 は、Cilium を使用して Kubernetes NetworkPolicy リソースを管理します。クラスタには次の上限が適用されます。
| ディメンション | サポートされている上限 |
|---|---|
| 名前空間ラベルの最大変更率 | 各名前空間について 1 時間に最大 1 回の変更。
ほとんどの場合、この上限は不要です。変更が頻繁（たとえば、1 秒ごと）に発生しないか、または Cilium ID（一意のラベルセット）の数が上限に近くない場合、すべてを許可するネットワーク ポリシーが適用された 16,000 個のラベルセット、またはクラスタごとに 65,535 個のラベルセット。 |
| クラスタあたりの Service エンドポイントの最大数 | 100,000 エンドポイントがテスト済みで推奨される上限です。Service エンドポイントのハードコードされた上限は 262,000 です。 |
| ネットワーク ポリシーとルールの最大数 | 最大 40,000 個のネットワーク ポリシーと 80,000 個のルール。たとえば、ルールが 2 つずつ含まれるネットワーク ポリシーを 40,000 個指定できます。また、ルールが 4 つずつ含まれるネットワーク ポリシーを 20,000 個指定できます。 |
| ネットワーク ポリシーの最大変更レート | 1 秒あたり最大 20 件の変更（作成または削除）。 |
| 一意の Pod ラベルセットの最大数 | 65,535（216-1）。これは Cilium セキュリティ ID の制限です。 |
| ポリシー セレクタによって選択される一意の Pod ラベルセットの最大数 | 16,000（固定の eBPF マップサイズ）。特定のポリシー セレクタ マップエントリは、セキュリティ ID、ポート、プロトコルで構成されます。 |
GKE Dataplane V2 eBPF の上限
Dataplane V2 の BPF lbmap におけるエントリの最大数は 65,536 です。次の領域が増大すると、エントリの総数が増加する可能性があります。
- サービスの数
- サービスあたりのポートの数
- サービスあたりのバックエンドの数
クラスタによって使用される実際のエントリ数をモニタリングして、上限を超えないようにすることをおすすめします。現在のエントリを取得するには、次のコマンドを使用します。
kubectl get po -n kube-system -l k8s-app=cilium | cut -d " " -f1 | grep anetd | head -n1 | \
xargs -I % kubectl -n kube-system exec % -- cilium bpf lb list | wc -l
また、独自のモニタリング パイプラインを使用して anetd DaemonSet から指標を収集することをおすすめします。次の条件をモニタリングして、エントリ数が問題の原因になっている場合を特定します。
cilium_bpf_map_ops_total{map_name="lb4_services_v2",operation="update",outcome="fail" } > 0
cilium_bpf_map_ops_total{map_name="lb4_backends_v2",operation="update",outcome="fail" } > 0
LoadBalancer と NodePort Service のポート制限
LoadBalancer Service と NodePort Service のポート上限は 2,768 です。デフォルトのポート範囲は 30000～32767 です。この上限を超えると、新しい LoadBalancer Service または NodePort Service を作成できなくなります。また、既存のサービスに新しいノードポートを追加することもできません。
デフォルトでは、Kubernetes はタイプ LoadBalancer の Service にノードポートを割り当てます。これらの割り当てでは、クラスタに割り当てられた 2,768 個の使用可能なノードポートを短期間で使い切る可能性があります。ノードポートを節約するには、LoadBalancer Service 仕様で allocateLoadBalancerNodePorts フィールドを false に設定して、ロードバランサ ノードポートの割り当てを無効にします。この設定により、Kubernetes はノードポートを LoadBalancer Service に割り当てなくなります。詳細については、Kubernetes ドキュメントのロードバランサの NodePort 割り当ての無効化をご覧ください。
割り当てられているポートの数を確認するには、次のコマンドを使用します。
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
バンドル型ロードバランサ ノード接続の上限
バンドル型ロード バランシング（MetalLB）に使用される各ノードで許可される接続数は、28,000 です。これらの接続のデフォルトにおけるエフェメラル ポート範囲は 32768～60999 です。接続の上限を超えると、LoadBalancer Service へのリクエストが失敗する可能性があります。
かなりの数の接続を処理できるロードバランサ サービス（Ingress など）を公開する必要がある場合は、MetalLB によるこの制限を回避するために、代替の負荷分散メソッドを使用することをおすすめします。
クラスタの割り当て
デフォルトでは、フリートごとに最大 250 個のクラスタをグローバル メンバーシップで登録できます。GKE Hub にさらにクラスタを登録するには、Google Cloud コンソールで割り当て引き上げのリクエストを送信できます。
メンバーシップ設定に基づくクラスタの割り当ての詳細については、数量に基づく割り当てをご覧ください。
スケーリング情報
このドキュメントの情報は、クラスタをスケールアップする方法の計画に関連しています。詳細については、Google Distributed Cloud クラスタをスケールアップするをご覧ください。
目的の情報が見つからなかった場合は、[フィードバックを送信] ボタンをクリックして、お探しの情報をお知らせください。