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