このページでは、Google Cloud のプロジェクト、クラスタ、ノードに関する Anthos clusters on bare metal リリース 1.9 の割り当てと上限について説明します。
制限事項
クラスタに関する次の上限と推奨事項に注意してください。
クラスタあたりの 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 です。この上限を超えると、新しい LoadBalancer サービスや 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 コンソールで割り当てを増やすリクエストを送信できます。
目的の情報が見つからなかった場合は、[フィードバックを送信] ボタンをクリックして、お探しの情報をお知らせください。