割り当てと上限

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

制限事項

クラスタに関する次の上限と推奨事項に注意してください。

クラスタあたりの 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 数とクラスタあたりのノード数に関する推奨事項よりも優先されます。

クラスタあたりのノードの最大数

Anthos clusters on bare metal をテストして、最大 500 ノードのワークロードを実行します。ただし、最適なパフォーマンスと信頼性を確保するために、本番環境でワークロードを実行するときは、クラスタあたり 200 ノードを超えないようにすることをおすすめします。

クラスタタイプ 最小ノード数 推奨される最大ノード数 絶対最大ノード数
ユーザー、スタンドアロン、ハイブリッド 1 200 500

単一ノードクラスタの場合、ノードでワークロードを実行するには node-role.kubernetes.io/master:NoSchedule taint を削除する必要があります。詳細については、Kubernetes taint と容認をご覧ください。

ノードあたりの最大 Pod 数

Anthos clusters 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 実装には、この制約が存在します。これは Anthos clusters on bare metal の固有の制限ではありません。

対策

RHEL と CentOS の場合、対策はありません。Ubuntu システムと Debian システムの場合、大規模なクラスタでデフォルトの iptables から従来の 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 と NodePort Service のポート制限は 2,768 です。デフォルトのポート範囲は 30000~32767 です。この上限を超えると、新しい LoadBalancert Service や NodePort Service を作成できなくなります。また、既存の Service に新しいノードポートを追加することもできません。

次のコマンドを使用して、現在割り当てられているポートの数を確認します。

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

[割り当て] に移動

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