このページでは、Google Cloud のプロジェクト、クラスタ、ノードに関する GKE on Bare Metal リリース 1.15 の割り当てと上限について説明します。
制限事項
クラスタに関する次の上限と推奨事項に留意してください。
クラスタあたりの 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 のリクエストのレイテンシが増加し、クラスタの安定性に問題が発生する可能性があります。etcd ストアにはソリッド ステート ディスク（SSD）を使用することをおすすめします。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 の警告「ハートビートの定刻での送信に失敗した」は何を意味しますか？をご覧ください。
目的の情報が見つからなかった場合は、[フィードバックを送信] ボタンをクリックして、お探しの情報をお知らせください。