このページでは、Google Cloud のプロジェクト、クラスタ、ノードに関する Anthos clusters on bare metal リリース 1.10 の割り当てと上限について説明します。
制限事項
クラスタに関する次の上限と推奨事項に注意してください。
クラスタあたりの 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 個のノードが存在するワークロードを実行するために、Anthos clusters on bare metal をテストします。ただし、最適なパフォーマンスと信頼性を確保するために、本番環境でワークロードを実行する場合は、クラスタあたりのノード数が 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 Service と NodePort Service のポート制限
LoadBalancer Service と NodePort Service のポート上限は 2,768 です。デフォルトのポート範囲は 30000～32767 です。この上限を超えると、新しい LoadBalancer Service や NodePort 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 コンソールでの割り当ての増加に関するリクエストを送信できます。
目的の情報が見つからなかった場合は、[フィードバックを送信] ボタンをクリックして、お探しの情報をお知らせください。