次のいずれかの負荷分散モードを構成することをおすすめします。
バンドル型モードでは、GKE on VMware がロードバランサを提供して管理します。ロードバランサにライセンスを割り当てる必要はありません。必要なセットアップ作業は最小限に抑えられます。
手動モードでは、GKE on VMware は F5 BIG-IP や Citrix などのロードバランサを使用します。手動負荷分散モードでは、バンドルモードよりも多くの構成を行う必要があります。
手動ロード バランシングは、次のクラスタタイプでサポートされています。
Controlplane V2 が有効になっているユーザー クラスタ。Controlplane V2 では、ユーザー クラスタのコントロール プレーン ノードはユーザー クラスタ自体にあります。
kubeception を使用するユーザー クラスタ。kubeception という用語は、ユーザー クラスタのコントロール プレーンが管理クラスタ内の 1 つ以上のノードで実行される場合を指します。Controlplane V2 が有効になっていない場合、ユーザー クラスタは kubeception を使用します。
このページでは、手動負荷分散モードを使用する場合に必要な手順について説明します。
このトピックでは、後で使用するためにコントロール プレーン ノードとワーカーノードの IP アドレスを確保します。また、仮想 IP（VIP）の IP アドレスも確保し、nodePort 値を決定します。使用する IP アドレスと nodePort 値を選択して、スプレッドシートなどのツールに記録します。クラスタを作成する準備ができたら、管理クラスタとユーザー クラスタの構成ファイル、およびクラスタの IP ブロック ファイルに入力する IP アドレスと nodePort 値が必要になります。
ユーザー クラスタ用にロードバランサを手動で構成するときにも、IP アドレスと nodePort 値が必要になります。
ノード IP アドレスの確保
手動負荷分散モードでは、DHCP を使用できません。クラスタノードの静的 IP アドレスを指定する必要があります。管理クラスタ内のノードと、作成するすべてのユーザー クラスタ内のノードに十分なアドレスを確保する必要があります。確保するノード IP アドレスの数の詳細については、IP アドレスを計画する（コントロール プレーン V2）およびIP アドレスを計画する（kubeception）をご覧ください。
IP アドレスを構成する
確保した静的 IP アドレスを構成する場所は、クラスタタイプと、ユーザー クラスタで Controlplane V2 を有効にするかどうかによって異なります。
HA 管理クラスタ
次の表に、IP アドレスの用途と HA 管理クラスタ用に構成する場所を示します。
| 静的 IP | 構成 |
|---|---|
| コントロール プレーン ノード | network.controlPlaneIPBlock.ips セクションの管理クラスタの構成ファイル |
| 1.16 以前: アドオンノード | 管理クラスタの IP ブロック ファイル。管理クラスタの構成ファイルの network.ipMode.ipBlockFilePath フィールドにパスを追加します。 |
バージョン 1.28 以降では、新しい HA 管理クラスタにアドオンノードはありません。したがって、以前のバージョンのようにアドオンノードの IP アドレスを確保する必要はありません。
非 HA 管理クラスタ
次の表に、IP アドレスの用途と非 HA 管理クラスタ用に構成する場所を示します。
| 静的 IP | 構成 |
|---|---|
| コントロール プレーン ノード | 管理クラスタの IP ブロック ファイル。管理クラスタの構成ファイルの network.ipMode.ipBlockFilePath フィールドにパスを追加します。 |
| アドオンノード | 管理クラスタの IP ブロック ファイル |
バージョン 1.28 以降では、新しい管理クラスタはすべて、3 つのコントロール プレーン ノードを持つ高可用性（HA）クラスタである必要があります。
CP V2 ユーザー クラスタ
次の表に、IP アドレスの用途と、コントロール プレーン V2 が有効になっているユーザー クラスタ用に構成する場所を示します。
| 静的 IP | 構成 |
|---|---|
| コントロール プレーン ノード | network.controlPlaneIPBlock.ips セクションのユーザー クラスタの構成ファイル |
| ワーカーノード | ユーザー クラスタの IP ブロック ファイル。ユーザー クラスタ構成ファイルの network.ipMode.ipBlockFilePath フィールドにパスを追加します。 |
Kubeception ユーザー クラスタ
次の表に、IP アドレスの用途と、kubeception を使用するユーザー クラスタ用に構成する場所を示します。
| 静的 IP | 構成 |
|---|---|
| コントロール プレーン ノード | 管理クラスタの IP ブロック ファイル。管理クラスタの構成ファイルの network.ipMode.ipBlockFilePath フィールドにパスを追加します。 |
| ワーカーノード | ユーザー クラスタの IP ブロック ファイル。ユーザー クラスタ構成ファイルの network.ipMode.ipBlockFilePath フィールドにパスを追加します。 |
VIP の IP アドレスの確保
統合、バンドル型、手動の負荷分散モードのいずれを使用するかに関係なく、負荷分散の仮想 IP（VIP）に使用する複数の IP アドレスを確保する必要があります。この VIP により、外部クライアントは Kubernetes API サーバーとユーザー クラスタ上の内向きサービスにアクセスできます。
VIP を構成する
VIP を構成する場所はクラスタの種類によって異なります。
HA 管理クラスタ
次の表に、VIP の用途と HA 管理クラスタ用に構成する場所を示します。
| VIP | 構成 |
|---|---|
| 管理クラスタの Kubernetes API サーバーの VIP | loadBalancer.vips.controlPlaneVIP フィールドの管理クラスタ構成ファイル |
| 1.15 以下: アドオン VIP | loadBalancer.vips.addonsVIP フィールドの管理クラスタ構成ファイル |
バージョンの違いは次のとおりです。
1.16 以降では、HA 管理クラスタ用にアドオン VIP を構成する必要はありません。
1.28 以降の場合、新しい HA 管理クラスタにはアドオンノードはありません。
非 HA 管理クラスタ
次の表では、VIP の用途と、非 HA 管理クラスタ用に構成する場所を示します。
| VIP | 構成 |
|---|---|
| 管理クラスタの Kubernetes API サーバーの VIP | loadBalancer.vips.controlPlaneVIP フィールドの管理クラスタ構成ファイル |
| 1.15 以下: アドオン VIP | loadBalancer.vips.addonsVIP フィールドの管理クラスタ構成ファイル |
バージョンの違いは次のとおりです。
1.16 以降では、非 HA 管理クラスタ用にアドオン VIP を構成する必要はありません。
CP V2 ユーザー クラスタ
次の表では、VIP の用途と、コントロール プレーン V2 が有効になっているユーザー クラスタ用に構成する場所を示します。
| VIP | 構成 |
|---|---|
| ユーザー クラスタの Kubernetes API サーバーの VIP | loadBalancer.vips.controlPlaneVIP フィールドのユーザー クラスタ構成ファイル |
| ユーザー クラスタ内の内向きサービスの VIP | loadBalancer.vips.ingressVIP フィールドのユーザー クラスタ構成ファイル |
Kubeception ユーザー クラスタ
次の表では、VIP の用途と、kubeception を使用するユーザー クラスタ用に構成する場所を示します。
| VIP | 構成 |
|---|---|
| ユーザー クラスタの Kubernetes API サーバーの VIP | loadBalancer.vips.controlPlaneVIP フィールドのユーザー クラスタ構成ファイル |
| ユーザー クラスタ内の内向きサービスの VIP | loadBalancer.vips.ingressVIP フィールドのユーザー クラスタ構成ファイル |
nodePort 値を確保する
GKE on VMware では、Kubernetes API サーバーと内向きサービスは Kubernetes Services によって公開されます。手動負荷分散モードを使用する場合は、これらの Service で独自の nodePort 値を選択する必要があります。30000～32767 の範囲で値を選択します。
nodePort 値を構成する
nodePort 値を構成する場所は、ユーザー クラスタで コントロール プレーン V2 が有効になっているかどうかによって異なります。
HA 管理クラスタ
次の表に、nodePort の用途と HA 管理クラスタ用に構成する場所を示します。
nodePort |
構成 |
|---|---|
1.15 以前: nodePort（アドオンノードの場合） |
loadBalancer.manualLB.addonsNodePort フィールドの管理クラスタ構成ファイル |
バージョン 1.16 以降では、HA 管理クラスタのアドオンノードに nodePort を構成する必要はありません。
非 HA 管理クラスタ
次の表に、nodePort の値の用途と非 HA 管理クラスタ用に構成する場所を示します。
nodePort |
構成 |
|---|---|
1.16 以前: 管理クラスタの Kubernetes API サーバー用の nodePort |
1.15 以前: loadBalancer.vips.controlPlaneNodePort フィールドの管理クラスタ構成ファイル |
1.15 以前: nodePort（アドオンノードの場合） |
loadBalancer.manualLB.addonsNodePort フィールドの管理クラスタ構成ファイル |
バージョン 1.16 以降では、非 HA 管理クラスタのアドオンノードに nodePort を構成する必要はありません。
CP V2 ユーザー クラスタ
次の表では、nodePorts の用途と、コントロール プレーン V2 が有効になっているユーザー クラスタ用に構成する場所について説明します。
nodePorts |
構成 |
|---|---|
ユーザー クラスタ内の内向きサービスの HTTP nodePort |
loadBalancer.manualLB.ingressHTTPNodePort のユーザー クラスタ構成ファイル |
ユーザー クラスタ内の内向きサービスの HTTPS nodePort |
loadBalancer.manualLB.ingressHTTPSNodePort のユーザー クラスタ構成ファイル |
GKE on VMware は、Controlplane V2 が有効になっているユーザー クラスタのコントロール プレーン ノードへのロード バランシングを処理するため、コントロール プレーン VIP に nodePort を構成する必要はありません。
Kubeception ユーザー クラスタ
次の表に、nodePort 値の用途と kubeception を使用するユーザー クラスタ用に構成する場所を示します。
nodePort |
構成 |
|---|---|
ユーザー クラスタの Kubernetes API サーバー用の nodePort |
loadBalancer.manualLB.controlPlaneNodePort フィールドのユーザー クラスタ構成ファイル |
ユーザー クラスタの Konnectivity サーバー用の nodePort（Konnectivity サーバーはコントロール プレーン VIP を使用します） |
loadBalancer.manualLB.konnectivityServerNodePort フィールドのユーザー クラスタ構成ファイル |
ユーザー クラスタ内の内向きサービスの HTTP nodePort |
loadBalancer.manualLB.ingressHTTPNodePort のユーザー クラスタ構成ファイル |
ユーザー クラスタ内の内向きサービスの HTTPS nodePort |
loadBalancer.manualLB.ingressHTTPSNodePort のユーザー クラスタ構成ファイル |
クラスタ構成ファイルの例
次の例は、管理クラスタとユーザー クラスタの構成ファイルの一部を示しています。
HA 管理クラスタ
バージョン: 1.16 以降
network: controlPlaneIPBlock: netmask: "255.255.248.0" gateway: "21.0.143.254" ips: - ip: "21.0.140.226" hostname: "admin-cp-vm-1" - ip: "21.0.141.48" hostname: "admin-cp-vm-2" - ip: "21.0.141.65" hostname: "admin-cp-vm-3" loadBalancer: vips: controlPlaneVIP: "172.16.21.40" kind: ManualLBバージョン 1.15 以前では、アドオンノードに VIP と
nodeportが必要です。network: controlPlaneIPBlock: netmask: "255.255.248.0" gateway: "21.0.143.254" ips: - ip: "21.0.140.226" hostname: "admin-cp-vm-1" - ip: "21.0.141.48" hostname: "admin-cp-vm-2" - ip: "21.0.141.65" hostname: "admin-cp-vm-3" loadBalancer: vips: controlPlaneVIP: "172.16.21.40" addonsVIP: "203.0.113.4" kind: ManualLB manualLB: addonsNodePort: 31405
非 HA 管理クラスタ
バージョン: 1.16 以降
network: ipMode: type: static ipBlockFilePath: "ipblock-admin.yaml" loadBalancer: vips: controlPlaneVIP: "172.16.21.40" kind: ManualLB manualLB: controlPlaneNodePort: 30562バージョン 1.15 以前では、アドオンノードに VIP と
nodeportが必要です。network: ipMode: type: static ipBlockFilePath: "ipblock-admin.yaml" loadBalancer: vips: controlPlaneVIP: "172.16.21.40" addonsVIP: "172.16.21.41" kind: ManualLB manualLB: controlPlaneNodePort: 30562 addonsNodePort: 30563
CP V2 ユーザー クラスタ
network:
ipMode:
type: static
ipBlockFilePath: "ipblock1.yaml"
controlPlaneIPBlock:
netmask: "255.255.255.0"
gateway: "172.16.21.1"
ips:
- ip: "172.16.21.6"
hostname: "cp-vm-1"
- ip: "172.16.21.7"
hostname: "cp-vm-2"
- ip: "172.16.21.8"
hostname: "cp-vm-3"
loadBalancer:
vips:
controlPlaneVIP: "172.16.21.40"
ingressVIP: "172.16.21.30"
kind: ManualLB
manualLB:
ingressHTTPNodePort: 30243
ingressHTTPSNodePort: 30879
Kubeception ユーザー クラスタ
network:
ipMode:
type: static
ipBlockFilePath: "ipblock1.yaml"
loadBalancer:
vips:
controlPlaneVIP: "172.16.21.40"
ingressVIP: "172.16.21.30"
kind: ManualLB
manualLB:
ingressHTTPNodePort: 30243
ingressHTTPSNodePort: 30879
konnectivityServerNodePort: 30563
controlPlaneNodePort: 30562
ロードバランサの構成
ロードバランサの管理コンソールまたはツールを使用して、ロードバランサで次のマッピングを構成します。これを行う方法はロードバランサによって異なります。
HA 管理クラスタ
コントロール プレーン ノードへのトラフィック
GKE on VMware は、HA 管理クラスタのコントロール プレーン トラフィックのロード バランシングを自動的に処理します。ロードバランサでマッピングを構成する必要はありませんが、loadBalancer.vips.controlPlaneVIP フィールドに IP アドレスを指定する必要があります。
アドオンノード内のサービスへのトラフィック
1.15 以前: 以下に、アドオンノード内のサービスへのトラフィックの IP アドレスと nodePort 値へのマッピングを示します。
- （
addonsVIP:8443）->（NODE_IP_ADDRESSES:addonsNodePort）
管理クラスタ内のすべてのノード（コントロール プレーン ノードとアドオンノードの両方）にこのマッピングを追加します。
バージョン 1.16 以降では、HA 管理クラスタのアドオンノードに対してこのマッピングを構成する必要はありません。
非 HA 管理クラスタ
コントロール プレーン トラフィック
以下に、コントロール プレーン ノードの IP アドレスと nodePort 値へのマッピングを示します。
- （
controlPlaneVIP:443）->（NODE_IP_ADDRESSES:controlPlaneNodePort）
管理クラスタ内のすべてのノード（コントロール プレーン ノードとアドオンノードの両方）にこのマッピングを追加します。
アドオンノード内のサービスへのトラフィック
1.15 以前: 以下に、アドオンノードで実行されているサービスの IP アドレスと nodePort 値へのマッピングを示します。
- （
addonsVIP:8443）->（NODE_IP_ADDRESSES:addonsNodePort）
管理クラスタ内のすべてのノード（コントロール プレーン ノードとアドオンノードの両方）にこのマッピングを追加します。
バージョン 1.16 以降では、非 HA 管理クラスタのアドオンノードに対してこのマッピングを構成する必要はありません。
CP V2 ユーザー クラスタ
コントロール プレーン トラフィック
GKE on VMware は、コントロール プレーン V2 が有効になっているユーザー クラスタのコントロール プレーン トラフィックのロード バランシングを自動的に処理します。ロードバランサでマッピングを構成する必要はありませんが、loadBalancer.vips.controlPlaneVIP フィールドに IP アドレスを指定する必要があります。
データプレーン トラフィック
以下に、データプレーン トラフィックの IP アドレスと nodePort 値へのマッピングを示します。
- (
ingressVIP:80) -> (NODE_IP_ADDRESSES:ingressHTTPNodePort) - (
ingressVIP:443) -> (NODE_IP_ADDRESSES:ingressHTTPSNodePort)
ユーザー クラスタ内のすべてのノード（コントロール プレーン ノードとワーカーノードの両方）にこれらのマッピングを追加します。クラスタに NodePort が構成されているため、Kubernetes はすべてのクラスタノードで NodePort を開きます。これにより、クラスタ内のどのノードでもデータプレーン トラフィックを処理できるようになります。
マッピングを構成すると、ロードバランサは標準の HTTP ポートと HTTPS ポートで、ユーザー クラスタの Ingress VIP に構成した IP アドレスでトラフィックをリッスンします。ロードバランサは、クラスタ内の任意のノードにリクエストをルーティングします。リクエストがクラスタノードの 1 つにルーティングされると、内部 Kubernetes ネットワークが引き継いでリクエストを宛先 Pod にルーティングします。
Kubeception ユーザー クラスタ
コントロール プレーン トラフィック
以下に、コントロール プレーン トラフィックの IP アドレスと nodePort 値へのマッピングを示します。
- (
controlPlaneVIP:443) -> (NODE_IP_ADDRESSES:controlPlaneNodePort) - (
controlPlaneVIP:8132) -> (NODE_IP_ADDRESSES:konnectivityServerNodePort)
管理クラスタ内のすべてのノード（管理クラスタとユーザー クラスタのコントロール プレーン ノードの両方）にこのマッピングを追加します。
データプレーン トラフィック
以下に、データプレーン トラフィックの IP アドレスと nodePort 値へのマッピングを示します。
- (
ingressVIP:80) -> (NODE_IP_ADDRESSES:ingressHTTPNodePort) - (
ingressVIP:443) -> (NODE_IP_ADDRESSES:ingressHTTPSNodePort)
ユーザー クラスタ内のすべてのノードでこれらのマッピングを追加します。kubeception を使用するユーザー クラスタでは、クラスタ内のすべてのノードはワーカーノードになります。
障害が発生したノードへの接続のリセット（推奨）
上述の要件に加えて、バックエンド ノードの障害を検出したときにクライアント接続をリセットするようにロードバランサを構成することをおすすめします。この構成がないと、サーバー インスタンスが停止したときに Kubernetes API サーバーのクライアントが数分間応答不能になり、Kubernetes コントロール プレーンが不安定になる可能性があります。
- F5 BIG-IP でこの設定を行うには、バックエンド プールの構成ページで Action On Service Down を使用します。
- HAProxy でこの設定を行うには、バックエンド サーバー構成で on-Marked-down shutdown-sessions を使用します。
- 別のロードバランサを使用している場合は、そのドキュメントを参照して同等の設定を確認してください。
手動負荷分散のサポートを取得する
Google では、手動負荷分散モードを使用して構成されたロードバランサはサポートされません。ロードバランサに問題が発生した場合は、ロードバランサのベンダーにお問い合わせください。