このページでは、Google Cloud のプロジェクト、クラスタ、ノードに関する GKE on Bare Metal リリース 1.28 の割り当てと上限について説明します。
上限
以下のセクションでは、クラスタの基本的な上限について説明します。GKE on Bare Metal で実行するアプリケーションを設計する際は、これらの上限を考慮してください。
管理クラスタあたりの最大ユーザー クラスタ数
管理クラスタは、ユーザー クラスタと関連するノードのライフサイクルを管理します。管理クラスタは、クラスタの作成、クラスタまたはノードのリセット、クラスタのアップグレード、クラスタの更新などの重要なユーザー クラスタ オペレーションを制御します。ユーザー クラスタ ノードの総数は、パフォーマンスと信頼性を制限する主な要因の 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 個のノードが存在するワークロードを実行するために、GKE on Bare Metal をテストします。ただし、最適なパフォーマンスと信頼性を確保するために、本番環境でワークロードを実行する場合は、クラスタあたりのノード数が 200 を超えないようにすることをおすすめします。
| クラスタタイプ | 最小ノード数 | 推奨最大ノード数 | 最大ノードの絶対数 |
|---|---|---|---|
| ユーザー、スタンドアロン、ハイブリッド | 1 | 200 | 500 |
単一ノードクラスタの場合、ノードでワークロードを実行するには node-role.kubernetes.io/master:NoSchedule taint を削除する必要があります。詳細については、Kubernetes taint と容認をご覧ください。
ノードあたりの Pod の最大数
GKE on Bare Metal は、クラスタ構成ファイルの 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 実装には、この制約が存在します。これは GKE on Bare Metal の固有の制限ではありません。
対策
RHEL の場合、対策はありません。Ubuntu システムと Debian システムの場合、大規模なクラスタでデフォルトの nftables から以前の iptables への切り替えをおすすめします。
GKE Dataplane V2
GDCV for Bare Metal は、GKE Dataplane V2 を使用します。これは、Cilium と eBPF で実装されたクラスタ データプレーンで、Kubernetes ネットワーク用に最適化されています。
GKE Dataplane V2 の NetworkPolicy 上限
GKE Dataplane V2 は Cilium を使用して Kubernetes NetworkPolicy リソースを管理します。GKE on Bare Metal クラスタには、次の上限が適用されます。
| ディメンション | サポートされる上限 |
|---|---|
| 名前空間ラベルの最大変更率 | 各名前空間について 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 によるこの制限を回避するために、代替の負荷分散メソッドを使用することをおすすめします。
クラスタの割り当て
デフォルトでは、最大 15 個のクラスタを登録できます。GKE Hub にさらにクラスタを登録するには、Google Cloud コンソールでの割り当ての増加に関するリクエストを送信できます。
スケーリング情報
このドキュメントの情報は、クラスタのスケールアップ方法の計画に関連しています。詳細については、GKE on Bare Metal クラスタをスケールアップするをご覧ください。
目的の情報が見つからなかった場合は、[フィードバックを送信] をクリックして、お探しの情報をお知らせください。