割り当てと上限

このページでは、Google Cloud のプロジェクト、クラスタ、ノードに関する GKE on Bare Metal リリース 1.16 の割り当てと上限について説明します。

上限

以下のセクションでは、クラスタの基本的な上限について説明します。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

エンドポイントの最大数

RHEL と CentOS では、クラスタレベルの上限が 100,000 エンドポイントに設定されています。この数は、Kubernetes サービスによって参照されるすべての Pod の合計です。2 つのサービスが同じ Pod のセットを参照する場合、この状況では 2 つの別のエンドポイント セットとしてカウントされます。RHEL と CentOS 上の基礎的な nftable 実装には、この制約が存在します。これは GKE on Bare Metal の固有の制限ではありません。

対策

RHEL と CentOS の場合、対策はありません。Ubuntu システムと Debian システムの場合、大規模なクラスタでデフォルトの nftables から従来の iptables への切り替えをおすすめします。

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 コンソールでの割り当ての増加に関するリクエストを送信できます。

[割り当て] に移動

スケーリングに関する問題

このセクションでは、クラスタのスケーリング時に留意すべきいくつかの問題について説明します。

システム デーモン用に予約されたリソース

バージョン 1.14 以降では、GKE on Bare Metal は sshd や udev などのシステム デーモン用に、ノードのリソースを自動的に予約します。CPU とメモリのリソースは、システム デーモン用にノード上で予約されているため、これらのデーモンには必要なリソースがあります。デフォルトで有効になっているこの機能が利用できないと、Pod はノードのほとんどのリソースを消費して、システム デーモンがタスクを完了できなくなる可能性があります。

具体的には、GKE on Bare Metal は、システム デーモン用に各ノードに 50 ミリコア（50 mCPU）と 280 メビバイト（280 MiB）のメモリを予約しています。CPU ユニット「mCPU」は「コアの 1,000 分の 1」を表します。つまり、各ノードの 50/1000 すなわち 5% のコアはシステム デーモン用に予約されています。予約済みのリソース量は少ないため、Pod のパフォーマンスに大きな影響はありません。ただし、CPU またはメモリの使用量が割り当て量を超えると、ノード上の kubelet が Pod を強制排除する場合があります。

etcd のパフォーマンス

etcd のパフォーマンスと安定性には、ディスクの速度が重要な役割を果たします。ディスクが低速な場合は etcd のリクエストのレイテンシが増加し、クラスタの安定性に問題が発生する可能性があります。クラスタのパフォーマンスを向上させるため、GKE on Bare Metal は、別の専用の etcd インスタンスに Event オブジェクトを保存します。標準の etcd インスタンスは、データ ディレクトリとして /var/lib/etcd を使用し、クライアント リクエスト用にポート 2379 を使用します。etcd-events インスタンスは、データ ディレクトリとして /var/lib/etcd-events を使用し、クライアント リクエストにはポート 2382 を使用します。

etcd ストアにはソリッド ステート ディスク（SSD）を使用することをおすすめします。最適なパフォーマンスを得るには、/var/lib/etcd と /var/lib/etcd-events に別々のディスクをマウントします。専用ディスクを使用すると、2 つの etcd インスタンスがディスク IO を共有しなくなります。

etcd のドキュメントには、本番環境でクラスタを実行するときに最適な etcd パフォーマンスを実現するための、追加のハードウェアの最適化案が記載されています。

etcd とディスクのパフォーマンスを確認するには、Metrics Explorer で次の etcd I/O レイテンシ指標を使用します。

  • etcd_disk_backend_commit_duration_seconds: 期間は 99 パーセンタイル（p99）に対して 25 ミリ秒未満にする必要があります。
  • etcd_disk_wal_fsync_duration_seconds: 期間は 99 パーセンタイル（p99）に対して 10 ミリ秒未満にする必要があります。

etcd のパフォーマンスの詳細については、etcd の警告「エントリの適用に時間がかかりすぎた」は何を意味しますか？と etcd の警告「ハートビートの定刻での送信に失敗した」は何を意味しますか？をご覧ください。

目的の情報が見つからなかった場合は、[フィードバックを送信] をクリックして、お探しの情報をお知らせください。