このページでは、Kubernetes のスケーラビリティの上限に近づいているワークロードに対応できるように、GKE on VMware クラスタを作成、構成、運用するためのベスト プラクティスについて説明します。
クラスタ名のルール
各 Google Cloud プロジェクト:
- 各ユーザー クラスタに、単一の Google Cloud プロジェクト内のすべての管理者クラスタ内で一意の名前を付ける必要があります。
スケーラビリティの上限
GKE on VMware でアプリケーションを設計する際は、次の上限を考慮してください。
各管理クラスタは、バンドル型負荷分散モード（Seesaw）またはMetalLBまたは統合負荷分散モード（F5）を使用して、高可用性（HA）クラスタと非 HA ユーザー クラスタの両方を含む最大 100 個のユーザー クラスタをサポートします。
各ユーザー クラスタがサポートする最大数は次のとおりです。
バンドル型負荷分散モード（Seesaw または MetalLB）を使用する場合は 500 ノード、統合負荷分散モード（F5）を使用する場合は 250 ノード
15,000 個の Pod
バンドル型負荷分散モード（Seesaw）を使用する 500 の負荷分散 サービス、またはMetalLBまたは統合負荷分散モード（F5）を使用する 250 の負荷分散サービス。
各ノードには、最大 110 個の Pod を作成できます（各 Pod は 1～2 個のコンテナで構成）。これには、アドオン システム サービスで実行される Pod も含まれます。
上限について
GKE on VMware は、大規模な統合サーフェスを備えた複雑なシステムであるため、クラスタのスケーラビリティには多くの要素が相互に関連します。たとえば、GKE 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 アドレス
GKE on VMware ノードには、DHCP または静的に割り当てられた IP アドレスが 1 つ必要です。
たとえば、50 ノードの非 HA ユーザー クラスタ 1 つと、250 ノードの HA ユーザー クラスタ 1 つを設定するには、設定段階で 307 個の IP アドレスが必要です。
その IP アドレスの内訳を、次の表に示します。
| ノードタイプ | IP アドレスの数 |
|---|---|
| 管理クラスタのコントロール プレーン VM | 3 |
| ユーザー クラスタ 1（非 HA）のコントロール プレーン VM | 1 |
| ユーザー クラスタ 1 のワーカーノード VM | 50 |
| ユーザー クラスタ 2（HA）のコントロール プレーン VM | 3 |
| ユーザー クラスタ 2 のワーカーノード VM | 250 |
| 合計 | 307 |
管理クラスタでの多数のユーザー クラスタの実行
管理クラスタで多くのユーザー クラスタを実行する準備ができたら、管理クラスタの作成時に次の手順を行います。
管理クラスタの Pod CIDR ブロック
Pod CIDR ブロックは、管理クラスタ内のすべての Pod の CIDR ブロックです。これは、admin-cluster.yaml の network.podCIDR フィールドを介して構成されます。
この範囲から、より小さい /24 ブロックが各ノードに割り当てられます。すべてのユーザー クラスタで Controlplane V2 が有効になっている場合、管理クラスタには 3 つのノードしかなく、多数の Pod IP アドレスを使用できます。ただし、Controlplane V2 ではなく kubeception を使用するユーザー クラスタを作成するたびに、1 つまたは 3 つのノードが管理クラスタに追加されます。
各高可用性（HA）kubeception ユーザー クラスタは、管理クラスタに 3 つのノードを追加します。
HA kubeception 以外の各ユーザー クラスタは、管理クラスタにノードを 1 つ追加します。
N 個のノードを持つ管理クラスタが必要な場合は、N 個の /24 ブロックをサポートする十分な大きさの Pod CIDR ブロックが必要です。
次の表は、さまざまな Pod CIDR ブロックサイズでサポートされるノードの最大数を示しています。
| Pod CIDR ブロックサイズ | サポートされるノードの最大数 |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
管理クラスタのデフォルトの Pod CIDR ブロックは 192.168.0.0/16 で、これは 256 ノードをサポートします。
HA kubeception ユーザー クラスタが 100 個ある管理クラスタには、3 つの管理クラスタ コントロールプレーン ノードと 300 のユーザー クラスタ コントロールプレーン ノードがあります。ノードの総数は 303 です（256 より多い）。したがって、最大 100 個の HA kubeception ユーザー クラスタをサポートするには、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 がサポートされます。
各 kubeception ユーザー クラスタは 6 つの Service を使用し、管理クラスタのコントロール プレーンは 14 の Service を使用します。したがって、100 個の kubeception ユーザー クラスタを実行するには、/22 範囲を使用するように管理クラスタの Service CIDR ブロックを変更する必要があります。
Cloud Logging と Cloud Monitoring
Cloud Logging と Cloud Monitoring は、リソースのトラッキングに役立ちます。
管理クラスタにデプロイされたロギングとモニタリングのコンポーネントの CPU とメモリ使用量は、kubeception ユーザー クラスタの数によって決まります。
次の表では、多数の kubeception ユーザー クラスタを実行するために必要な管理クラスタノードの CPU とメモリの量を示します。
| kubeception ユーザー クラスタの数 | 管理クラスタノードの 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 個の kubeception ユーザー クラスタを実行できます。20 個を超える kubeception ユーザー クラスタを作成するには、まず管理クラスタノードのメモリを 16 GB から 90 GB にサイズ変更する必要があります。
GKE Hub
デフォルトでは、最大 15 個のユーザー クラスタを登録できます。
GKE Hub にさらにクラスタを登録するには、Google Cloud コンソールでの割り当ての増加に関するリクエストを送信できます。
ユーザー クラスタで多数のノードと 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 |
ユーザー クラスタのコントロール プレーン ノード
ユーザー クラスタのコントロール プレーン コンポーネントのメモリ使用量は、ユーザー クラスタ内のノード数に応じて変わります。
次の表では、ユーザー クラスタのサイズに応じて、ユーザー クラスタのコントロールプレーン ノードに必要な 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 / メモリ、ライセンスなどの要因に左右されます。
システム コンポーネントの自動スケーリング
GKE on VMware は、ユーザー クラスタ内のシステム コンポーネントをノードの数に応じて自動的に調整します。構成を変更する必要はありません。このセクションの情報は、リソース計画に使用できます。
GKE 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 とメモリのリクエストと上限は、ノード数に基づきます。
GKE on VMware は、次のシステム コンポーネントのレプリカの数をスケーリングして、管理クラスタとユーザー クラスタの両方で水平方向のスケーリングを自動的に実行します。
kube-dns は、GKE on VMware でサービス ディスカバリに使用される DNS ソリューションです。これは、ユーザー クラスタ ワーカーノードで Deployment として動作します。GKE on VMware では、クラスタ内のノードと CPU コアの数に応じてレプリカの数を自動的にスケーリングします。16 個のノードまたは 256 個のコアが追加、削除されるたびに、1 つのレプリカが増減します。
N個のノードとC個のコアを含むクラスタが存在する場合は、max(N/16, C/256)個のレプリカを想定できます。calico-typha は、GKE on VMware で Pod ネットワーキングをサポートするコンポーネントです。これは、ユーザー クラスタ ワーカーノードで Deployment として動作します。GKE on VMware では、クラスタ内のノード数に応じて Calico-typh レプリカの数を自動的にスケーリングします。
ノード数（N） calico-typha レプリカの数 N = 1 1 1 < N < 200 2 N >= 200 3 以上 Istio ingress-gateway は、クラスタ Ingress をサポートするためのコンポーネントであり、ユーザー クラスタ ワーカーノードで Deployment として動作します。ingress-gateway が処理するトラフィックの量に応じて、GKE on VMware では、HorizontalPodAutoscaler を使用して、レプリカの数を CPU 使用量に基づいて 2～5 の範囲でスケーリングします。
konnectivity ネットワーク プロキシ（KNP）は、ユーザー クラスタのコントロール プレーン ノードからの下り（外向き）用の TCP レベルのプロキシを提供します。このプロキシは、ユーザー クラスタノードを宛先とするユーザーの kube-apiserver 下り（外向き）トラフィックをトンネリングします。Konnectivity エージェントは、ユーザー クラスタ ワーカーノードで Deployment として動作します。GKE 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 ボリュームによって消費されます。このストレージは、GKE on VMware ノードのファイル システムに基づくものであり、ノードのブートディスクを基盤としています。
Kubernetes ノードではストレージ I/O が分離されていないため、エフェメラル ストレージ上で非常に高い I/O を消費するアプリケーションは、Kubelet や Docker デーモンなどのシステム コンポーネントのリソースを枯渇させることでノードを不安定にする可能性があります。
ブートディスクをプロビジョニングするデータストアの I/O パフォーマンス特性で、アプリケーションでのエフェメラル ストレージとロギング トラフィックの使用に適したパフォーマンスが得られるようにします。
物理リソースの競合をモニタリングする
vCPU と pCPU の比率とメモリの過剰な使用に注意してください。物理ホストでの最適化されていない比率やメモリの競合は、VM のパフォーマンス低下につながることがあります。ホストレベルで物理リソースの使用量をモニタリングし、大規模なクラスタを実行するために十分なリソースを割り当てる必要があります。