このページでは、Kubernetes のスケーラビリティの上限に近づいているワークロードに対応するために、Anthos clusters on VMware（GKE On-Prem）を作成、構成、運用するためのベスト プラクティスについて説明します。
クラスタ名のルール
Google Cloud プロジェクトごと: * 各ユーザー クラスタは、単一の Google Cloud プロジェクト内にあるすべての管理クラスタ全体で一意の名前を付けている必要があります。
スケーラビリティの上限
Anthos clusters on VMware でアプリケーションを設計する際には、次の制限事項を考慮してください。
各管理クラスタは、バンドル型負荷分散モード（Seesaw）または統合負荷分散モード（F5）を使用して、高可用性（HA）クラスタと非 HA ユーザー クラスタの両方を含む最大 100 個のユーザー クラスタをサポートします。
各ユーザー クラスタがサポートする最大数は次のとおりです。
バンドル型負荷分散モード（Seesaw）を使用する 500 ノード、または統合負荷分散モード（F5）を使用する 250 ノード
15,000 個の Pod
バンドル型負荷分散モード（Seesaw）を使用する 500 の負荷分散 サービス、または統合負荷分散モード（F5）を使用する 250 の負荷分散サービス。
各ノードには、最大 110 個の Pod を作成できます（各 Pod は 1～2 個のコンテナで構成）。これには、アドオン システム サービスで実行される Pod も含まれます。
上限について
Anthos clusters on VMware は大規模な統合サーフェスを備えた複雑なシステムであるため、クラスタのスケーラビリティには多くの関連ディメンションが含まれます。たとえば、Anthos clusters on VMware は、ノード、Pod、Service の数によってスケーリングできます。同時に複数のディメンションを拡張すると、たとえ小さなクラスタであっても問題を発生させる可能性があります。たとえば、500 ノードクラスタでノードあたり 110 Pod のスケジュールを設定すると、Pod 数、ノードあたりの Pod 数、ノードの数が過剰に増加する可能性があります。
詳細は、Kubernetes スケーラビリティのしきい値をご覧ください。
また、スケーラビリティの上限には、クラスタが実行されている vSphere の構成とハードウェアも影響します。これらの上限が検証された環境は、実際の環境とは異なる可能性が高いといえます。したがって、前提となる環境が制限要因となる場合、正確な数字を再現することはできません。
スケーリングに関する対策
管理クラスタまたはユーザー クラスタをスケーリングする際には、次の要件と制限事項を確認してください。
CPU、メモリ、ストレージの要件
それぞれの個別の VM の CPU、RAM、ストレージの要件をご覧ください。
ディスク I/O とネットワーク I/O の要件
データ集約型のワークロードと特定のコントロール プレーン コンポーネントは、ディスクとネットワークの I/O レイテンシから影響を受けます。たとえば、数十個のノードと数千個の Pod を持つクラスタで etcd のパフォーマンスと安定性を確保するには、通常、500 シーケンシャル IOPS（標準的なローカル SSD や高パフォーマンスの仮想ブロック デバイスなど）が必要です。
ノード IP アドレス
各 Anthos clusters on VMware ノードには、DHCP または静的に割り当てられた IP アドレスが必要です。
たとえば、50 ノードの非 HA ユーザー クラスタ 1 つと、250 ノードの HA ユーザー クラスタ 1 つを設定するには、設定段階で 308 個の IP アドレスが必要です。
その IP アドレスの内訳を、次の表に示します。
| ノードタイプ | IP アドレスの数 |
|---|---|
| 管理クラスタのコントロール プレーン VM | 1 |
| 管理クラスタのアドオンノード VM | 3 |
| ユーザー クラスタ 1（非 HA）のコントロール プレーン VM | 1 |
| ユーザー クラスタ 1 のノード VM | 50 |
| ユーザー クラスタ 2（HA）のコントロール プレーン VM | 3 |
| ユーザー クラスタ 2 のノード VM | 250 |
| 合計 | 308 |
管理クラスタでの多数のユーザー クラスタの実行
管理クラスタで多くのユーザー クラスタを実行する準備ができたら、管理クラスタの作成時に次の手順を行います。
管理クラスタの Pod CIDR ブロック
Pod CIDR ブロックは、管理クラスタ内のすべての Pod の CIDR ブロックです。これは、admin-cluster.yaml の network.podCIDR フィールドを介して構成されます。
この範囲から、より小さい /24 ブロックが各ノードに割り当てられます。N 個のノードを持つ管理クラスタが必要な場合は、N 個の /24 ブロックをサポートするうえで十分な大きさが、このブロックにあることを確認します。
次の表は、さまざまな Pod CIDR ブロックサイズでサポートされるノードの最大数を示しています。
| Pod CIDR ブロックサイズ | サポートされるノードの最大数 |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
管理クラスタのデフォルトの Pod CIDR ブロックは 192.168.0.0/16 で、これは 256 ノードをサポートします。
HA ユーザー クラスタが 100 個ある管理クラスタ（各ユーザー クラスタに 3 つのコントロール プレーン ノード）には、1 つの管理クラスタ コントロール プレーン ノード、2 つの管理クラスタ アドオンノード、300 のユーザー クラスタ コントロール プレーン ノードがあります。ノードの総数は 303（256 より上）です。したがって、最大 100 個の HA ユーザー クラスタをサポートするには、Pod CIDR ブロックを /15 に更新する必要があります。
Pod CIDR ブロックを構成するには、管理クラスタの構成ファイルで network.podCIDR フィールドを設定します。
管理クラスタの Service CIDR ブロック
Service CIDR ブロックは、管理クラスタ内のすべての Service の CIDR ブロックです。これは、admin-cluster.yaml の network.serviceCIDR フィールドを介して構成されます。
次の表に、さまざまな Service CIDR ブロックサイズでサポートされる Service の最大数を示します。
| Service CIDR ブロックサイズ | サポートされる Service の最大数 |
|---|---|
| /24 | 256 |
| /23 | 512 |
| /22 | 1,024 |
デフォルト値は 10.96.232.0/24 で、256 Service がサポートされます。
ユーザー クラスタは 6 つの Service を使用し、管理クラスタのコントロール プレーンは 14 の Service を使用します。したがって、100 個のユーザー クラスタを実行するには、/22 範囲を使用するように管理クラスタの Service CIDR ブロックを変更する必要があります。
Cloud Logging と Cloud Monitoring
Cloud Logging と Cloud Monitoring は、リソースのトラッキングに役立ちます。
管理クラスタにデプロイされたロギングとモニタリングのコンポーネントの CPU とメモリ使用量は、ユーザー クラスタの数によって決まります。
次の表では、多数のユーザー クラスタの実行に必要な管理クラスタノードの CPU とメモリの量を示します。
| ユーザー クラスタの数 | 管理クラスタノードの CPU | 管理クラスタノードのメモリ |
|---|---|---|
| 0～10 | 4 個の CPU | 16 GB |
| 11～20 | 4 個の CPU | 32 GB |
| 20～100 | 4 個の CPU | 90GB |
たとえば、2 つの管理クラスタノードがあり、それぞれに 4 個の CPU と 16 GB のメモリがある場合、0～10 個のユーザー クラスタを実行できます。20 個を超えるユーザー クラスタを作成するには、まず管理クラスタノードのメモリを 16 GB から 90 GB にサイズ変更する必要があります。
管理クラスタのアドオンノードのメモリを変更するには、次の手順で MachineDeployment 構成を編集します。
次のコマンドを実行します。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG edit machinedeployment gke-admin-node
ここで、ADMIN_CLUSTER_KUBECONFIG は管理クラスタの kubeconfig ファイルのパスです。
spec.template.spec.providerSpec.value.machineVariables.memoryフィールドを32768に変更します。編集内容を保存します。管理クラスタノードは、32 GB のメモリで再作成されます。
GKE Hub
デフォルトでは、最大 15 個のユーザー クラスタを登録できます。
GKE Hub にさらにクラスタを登録するには、Google Cloud Console で割り当てを増やすリクエストを送信できます。
[Go to Quotas](https://console.cloud.google.com/apis/api/gkehub.googleapis.com/quotas){: target="console"
class="button button-primary" track-type="quotas" track-name="consoleLink" track-metadata-end-goal="modifyQuota"}
ユーザー クラスタで多数のノードと Pod を実行する
ユーザー クラスタで多くのノードと Pod を実行する準備をするときは、ユーザー クラスタを作成するときに次の手順を行います。
ユーザー クラスタの Pod CIDR ブロック
Pod CIDR ブロックは、ユーザー クラスタ内のすべての Pod の CIDR ブロックです。これは、user-cluster.yaml の network.podCIDR フィールドを介して構成されます。
この範囲から、各ノードにより小さな /24 ブロックが割り当てられます。N 個のノードを持つ管理クラスタが必要な場合は、N 個の /24 ブロックをサポートするうえで十分な大きさが、このブロックにあることを確認する必要があります。
次の表は、さまざまな Pod CIDR ブロックサイズでサポートされるノードの最大数を示しています。
| Pod CIDR ブロックサイズ | サポートされるノードの最大数 |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
デフォルトの Pod CIDR ブロックは 192.168.0.0/16 です。これは 256 ノードをサポートします。たとえば、500 ノードを持つクラスタを作成するには、ユーザー クラスタの Pod CIDR ブロックを変更して /15 範囲を使用する必要があります。
ユーザー クラスタの Service CIDR ブロック
Service CIDR ブロックは、ユーザー クラスタ内のすべての Service の CIDR ブロックです。これは、user-cluster.yaml の network.serviceCIDR フィールドを介して構成されます。
次の表に、さまざまな Service CIDR ブロックサイズでサポートされる Service の最大数を示します。
| Service CIDR ブロックサイズ | サポートされる Service の最大数 |
|---|---|
| /21 | 2,048 |
| /20 | 4,096 |
| /19 | 8,192 |
| /18 | 16,384 |
デフォルト値は 10.96.0.0/20 で、4,096 Service がサポートされます。デフォルトの Service CIDR ブロックを使用すると、ユーザー クラスタ内でサポートされている Anthos clusters on VMware の LoadBalancer タイプの Service の最大数である 500 個の Service でクラスタを作成できます。
ユーザー クラスタのコントロール プレーン ノード
ユーザー クラスタのコントロール プレーン コンポーネントのメモリ使用量は、ユーザー クラスタ内のノード数に応じて変わります。
次の表では、ユーザー クラスタのサイズに応じて、ユーザー クラスタ コントロール プレーン ノードに必要な CPU とメモリを示します。
| ユーザー クラスタノードの数 | コントロール プレーン ノードの CPU | コントロール プレーン ノードのメモリ |
|---|---|---|
| 0～20 | 3 個の CPU | 5 GB |
| 21～75 | 3 個の CPU | 6 GB |
| 76～250 | 4 個の CPU | 8 GB |
| 251～500 | 4 個の CPU | 16 GB |
たとえば、1 つのユーザー クラスタに 250 個を超えるノードを作成するには、16 GB 以上のメモリを備えたユーザー クラスタ コントロール プレーン ノードを使用する必要があります。
ユーザー クラスタ コントロール プレーン ノードの仕様は、user-cluster.yaml の masterNode フィールドを介して変更できます。
Dataplane V2
Dataplane V2 を使用する 500 ノードのユーザー クラスタの場合、ユーザー クラスタのコントロール プレーン ノードには 120 GB のメモリと 32 個の CPU コアを使用することをおすすめします。
Cloud Logging と Cloud Monitoring
Cloud Logging と Cloud Monitoring は、リソースのトラッキングに役立ちます。
ユーザー クラスタにデプロイされているクラスタ エージェントの CPU とメモリ使用量は、ユーザー クラスタ内のノードと Pod の数によって決まります。
prometheus-server、stackdriver-prometheus-sidecar、などの Cloud Logging と Monitoring のコンポーネントでは、ノード数と Pod の数に基づいて CPU とメモリリソースの使用量が変わります。クラスタをスケールアップする前に、これらのコンポーネントの推定平均使用量に従ってリソース リクエストと上限を設定してください。次の表に、各コンポーネントの平均使用量の推定値を示します。
| ノード数 | コンテナ名 | 推定 CPU 使用量 | 推定メモリ使用量 | ||
|---|---|---|---|---|---|
| 0 Pod / ノード | 30 Pod / ノード | 0 Pod / ノード | 30 Pod / ノード | ||
| 3～50 | prometheus-server | 100m | 390m | 650M | 1.3G |
| stackdriver-prometheus-sidecar | 100m | 340m | 1.5G | 1.6G | |
| 51～100 | prometheus-server | 160m | 500m | 1.8G | 5.5G |
| stackdriver-prometheus-sidecar | 200m | 500m | 1.9G | 5.7G | |
| 101～250 | prometheus-server | 400m | 2500m | 6.5G | 16G |
| stackdriver-prometheus-sidecar | 400m | 1300m | 7.5G | 12G | |
| 250 ～ 500 | prometheus-server | 1200m | 2600m | 22G | 25G |
| stackdriver-prometheus-sidecar | 400m | 2250m | 65G | 78G | |
Cloud Logging と Cloud Monitoring のコンポーネントをスケジュールするために十分なノード数を確保します。これを行う方法の一つは、まず小さなクラスタを作成し、上の表に従い Cloud Logging と Cloud Monitoring のコンポーネント リソースを編集して、コンポーネントに対応するノードプールを作成することです。その後、クラスタをより大きなサイズに徐々にスケールアップします。
モニタリングとロギングのコンポーネントにちょうどよい大きさのノードプールを維持すると、ノードプールに他の Pod のスケジュールが設定されることを防止できます。これを行うには、次の taints をノードプールに追加する必要があります。
taints:
- effect: NoSchedule
key: node-role.gke.io/observability
これにより、他のコンポーネントがノードプールでスケジュールされなくなり、モニタリング コンポーネントのリソース消費が原因でユーザー ワークロードが強制排除されることを防止します。
ロードバランサ
このセクションで説明する Service は、LoadBalancer タイプの Kubernetes Service を指します。
クラスタ内のノード数と、ロードバランサで構成できる Service の数には上限があります。
バンドル型負荷分散（Seesaw）の場合は、ヘルスチェックの数にも上限があります。ヘルスチェックの数は、ノード数と、トラフィック ローカル Service の数によって異なります。トラフィック ローカル Service とは、externalTrafficPolicy が Local に設定された Service です。
次の表では、バンドル型負荷分散（Seesaw）と統合型負荷分散（F5）の Service、ノード、ヘルスチェックの最大数を示します。
| バンドル型負荷分散（Seesaw） | 統合型負荷分散（F5） | |
|---|---|---|
| 最大 Service 数 | 500 | 250 2 |
| 最大ノード数 | 500 | 250 2 |
| 最大ヘルスチェック数 | N + (L * N) <= 10,000、ここで、N はノード数、L はトラフィック ローカル Service の数 1 | なし 2 |
1 たとえば、100 個のノードと 99 個のトラフィック ローカル Service があるとします。この場合、ヘルスチェックの数は 100 + 99 × 100 = 10,000 となります。これは上限 10,000 の範囲内です。
2 詳細については、F5 にお問い合わせください。この数は、F5 ハードウェアのモデル番号、仮想インスタンスの CPU / メモリ、ライセンスなどの要因に左右されます。
システム コンポーネントの自動スケーリング
Anthos clusters on VMware は、ユーザー クラスタ内のシステム コンポーネントをノードの数に応じて自動的に調整します。構成を変更する必要はありません。このセクションの情報は、リソース計画に使用できます。
Anthos clusters on VMware では、addon-resizer を使用して次のシステム コンポーネントの CPU リクエストとメモリ リクエスト / 制限をスケーリングして、垂直方向のスケーリングを自動的に行います。
kube-state-metrics は、クラスタ ワーカーノードで実行される Deployment で、Kubernetes API サーバーをリッスンしてオブジェクトの状態に関する指標を生成します。CPU とメモリのリクエストと上限は、ノード数に基づきます。
次の表に、クラスタ内のノード数に対する、システムで設定されるリソースのリクエスト / 上限を示します。
ノード数 おおよそ 1 の CPU リクエスト / 上限（ミリ） おおよそ 1 のメモリ リクエスト / 上限（Mi） 3～5 105 110 6 ～ 500 100 + num_nodes 100 + (2 * num_nodes) 1 スケーリング時のコンポーネントの再起動数を減らすために ±5% のマージンが設定されます。
たとえば、ノード数が 50 のクラスタでは、CPU リクエスト / 上限が 150m / 150m に設定され、メモリ リクエスト / 上限が 200Mi / 200Mi に設定されます。ノード数が 250 のクラスタでは、CPU のリクエスト / 上限は 350m/350m に設定され、メモリのリクエスト / 制限は 600Mi に設定されます。
metrics-server は、クラスタ ワーカーノードで実行されるデプロイで、Kubernetes の組み込み自動スケーリング パイプラインで使用されます。CPU とメモリのリクエストと上限は、ノード数に基づきます。
Anthos clusters on VMware は、次のシステム コンポーネントのレプリカの数をスケーリングして、管理クラスタとユーザー クラスタの両方で水平方向のスケーリングを自動的に実行します。
kube-dns は、Anthos clusters on VMware でサービス ディスカバリに使用される DNS ソリューションです。これは、ユーザー クラスタ ワーカーノードで Deployment として動作します。Anthos clusters on VMware は、クラスタ内のノードと CPU コアの数に応じてレプリカの数を自動的にスケーリングします。16 個のノードまたは 256 個のコアが追加、削除されるたびに、1 つのレプリカが増減します。
N個のノードとC個のコアを含むクラスタが存在する場合は、max(N/16, C/256)個のレプリカを想定できます。calico-typha は、Anthos clusters on VMware で Pod ネットワークをサポートするコンポーネントです。これは、ユーザー クラスタ ワーカーノードで Deployment として動作します。Anthos clusters on VMware では、クラスタ内のノード数に応じて Calico-typh レプリカの数を自動的にスケーリングします。
ノード数（N） calico-typha レプリカの数 N = 1 1 1 < N < 200 2 N >= 200 3 以上 ingress-gateway / istio-pilot は、クラスタ Ingress をサポートするためのコンポーネントであり、ユーザー クラスタ ワーカーノードで Deployment として動作します。Ingress のゲートウェイが処理するトラフィックの量に応じて、Anthos clusters on VMware は水平 Pod オートスケーラーを使用し、CPU 使用量に基づいてレプリカの数をスケーリングします（最小で 2 つのレプリカ、最大で 5 つのレプリカ）。
konnectivity ネットワーク プロキシ（KNP）は、ユーザー クラスタのコントロール プレーン ノードからの下り（外向き）用の TCP レベルのプロキシを提供します。このプロキシは、ユーザー クラスタノードを宛先とするユーザーの kube-apiserver 下り（外向き）トラフィックをトンネリングします。Konnectivity エージェントは、ユーザー クラスタ ワーカーノードで Deployment として動作します。Anthos clusters on VMware では、クラスタ内のノード数に応じて konnectivity エージェント レプリカの数が自動的に調整されます。
ノード数（N） konnectivity エージェント レプリカの数 1 <= N <= 6 N 6 < N < 10 6 10 <= N < 100 8 N >= 100 12 以上
おすすめの方法
このセクションでは、リソースのスケーリングに関するベスト プラクティスについて説明します。
クラスタを段階的にスケーリングする
Kubernetes ノードの作成では、ノード OS イメージ テンプレートを新しいディスク ファイルにクローン作成する必要があります。これは、I/O 集約型 vSphere オペレーションです。クローン作成オペレーションとワークロードの I/O オペレーションの間に I/O の分離はありません。同時に作成されたノードの数が多すぎると、クローン作成オペレーションの完了に時間がかかり、クラスタと既存のワークロードのパフォーマンスと安定性に影響する可能性があります。
vSphere リソースに応じてクラスタが段階的にスケーリングされるようにします。たとえば、クラスタのサイズを 3 から 500 に拡大するには、150、350、500 と、段階的にスケーリングすることを検討してください。こうすることで、vSphere インフラストラクチャの負荷が軽減されます。
etcd ディスクの I/O パフォーマンスを最適化する
etcd は、Kubernetes ですべてのクラスタデータのバックアップ保存先として使用される Key-Value ストアです。その性能と安定性は、クラスタの健全性にとって不可欠であり、ディスクとネットワークの I/O レイテンシの影響を受けます。
次の推奨事項に従って、コントロール プレーン VM に使用される vSphere データストアの I/O パフォーマンスを最適化します。
- etcd のハードウェア要件に従います。
- SSD またはオール フラッシュ ストレージを使用します。
数百ミリ秒のレイテンシは、ディスクまたはネットワーク I/O にボトルネックが存在することを示しており、異常なクラスタの原因になる可能性があります。etcd の次の I/O レイテンシ指標をモニタリングし、アラートのしきい値も設定します。
etcd_disk_backend_commit_duration_secondsetcd_disk_wal_fsync_duration_seconds
ノード ブートディスクの I/O パフォーマンスを最適化する
Pod では、一時ファイルの保存などの内部オペレーションに、エフェメラル ストレージを使用します。エフェメラル ストレージは、コンテナの書き込み可能なレイヤ、ログ ディレクトリ、emptyDir ボリュームによって消費されます。エファメラル ストレージは、Anthos clusters on VMware ノードのファイルシステムから取得されます。このシステムは、ノードのブートディスクにサポートされています。
Kubernetes ノードではストレージ I/O が分離されていないため、エフェメラル ストレージ上で非常に高い I/O を消費するアプリケーションは、Kubelet や Docker デーモンなどのシステム コンポーネントのリソースを枯渇させることでノードを不安定にする可能性があります。
ブートディスクをプロビジョニングするデータストアの I/O パフォーマンス特性で、アプリケーションでのエフェメラル ストレージとロギング トラフィックの使用に適したパフォーマンスが得られるようにします。
物理リソースの競合をモニタリングする
vCPU と pCPU の比率とメモリの過剰な使用に注意してください。物理ホストでの最適化されていない比率やメモリの競合は、VM のパフォーマンス低下につながることがあります。ホストレベルで物理リソースの使用量をモニタリングし、大規模なクラスタを実行するために十分なリソースを割り当てる必要があります。