このページでは、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 コンソールで割り当てを増やすリクエストを送信できます。
目的の情報が見つからなかった場合は、[フィードバックを送信] ボタンをクリックして、お探しの情報をお知らせください。