GKE on VMware クラスタは、統合、バンドル型、手動の 3 つの負荷分散モードのいずれかで実行できます。
統合モードでは、GKE on VMware は F5 BIG-IP ロードバランサを使用します。
バンドル型モードでは、GKE on VMware がロードバランサを提供して管理します。ロードバランサにライセンスを割り当てる必要はありません。必要なセットアップ作業は最小限に抑えられます。
手動モードでは、GKE on VMware は選択したロードバランサを使用します。手動負荷分散モードでは、統合モードよりも多くの構成を行う必要があります。手動負荷分散モードで使用できるロードバランサには Citrix ロードバランサなどがあります。
手動負荷分散は、次のクラスタタイプでサポートされています。
コントロール プレーン V2 が有効になっているユーザー クラスタ。コントロール プレーン V2 では、ユーザー クラスタのコントロール プレーン ノードはユーザー クラスタ自体にあります。
kubeception を使用するユーザー クラスタ。kubeception という用語は、ユーザー クラスタのコントロール プレーンが管理クラスタ内の 1 つ以上のノードで実行される場合を指します。コントロール プレーン V2 が有効になっていない場合、ユーザー クラスタは kubeception を使用します。
このページでは、手動負荷分散モードを使用する場合に必要な手順について説明します。
このトピックでは、後で使用するためにコントロール プレーン ノードとワーカーノードの IP アドレスを確保します。また、仮想 IP（VIP）の IP アドレスも確保し、nodePort 値を決定します。使用する IP アドレスと nodePort 値を選択して、スプレッドシートなどのツールに記録します。クラスタを作成する準備ができたら、管理クラスタとユーザー クラスタの構成ファイル、およびクラスタの IP ブロック ファイルに入力する IP アドレスと nodePort 値が必要になります。
ユーザー クラスタ用にロードバランサを手動で構成するときにも、IP アドレスと nodePort 値が必要になります。1.28 以降の HA 管理クラスタではロード バランシングを構成する必要はありませんが、完全性を維持するために、このトピックでは、コントロール プレーン ノードの構成 IP アドレスと HA 管理クラスタのコントロール プレーン VIP の構成について説明します。
ノード IP アドレスの確保
手動負荷分散モードでは、DHCP を使用できません。クラスタノードの静的 IP アドレスを指定する必要があります。管理クラスタ内のノードと、作成するすべてのユーザー クラスタ内のノードに十分なアドレスを確保する必要があります。確保するノード IP アドレスの数の詳細については、IP アドレスを計画する（コントロール プレーン V2）およびIP アドレスを計画する（kubeception）をご覧ください。
IP アドレスを構成する
確保した静的 IP アドレスを構成する場所は、クラスタタイプと、ユーザー クラスタでコントロール プレーン V2 を有効にするかどうかによって異なります。
HA 管理クラスタ
次の表に、IP アドレスの用途と HA 管理クラスタ用に構成する場所を示します。
| 静的 IP | 構成 |
|---|---|
| コントロール プレーン ノード | network.controlPlaneIPBlock.ips セクションの管理クラスタの構成ファイル |
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 サーバーとユーザー クラスタ上の Ingress サービスにアクセスできます。
VIP を構成する
VIP を構成する場所はクラスタの種類によって異なります。
HA 管理クラスタ
次の表に、VIP の用途と HA 管理クラスタ用に構成する場所を示します。
| VIP | 構成 |
|---|---|
| 管理クラスタの Kubernetes API サーバーの VIP | loadBalancer.vips.controlPlaneVIP フィールドの管理クラスタ構成ファイル |
CP V2 ユーザー クラスタ
次の表では、VIP の用途と、コントロール プレーン V2 が有効になっているユーザー クラスタ用に構成する場所を示します。
| VIP | 構成 |
|---|---|
| ユーザー クラスタの Kubernetes API サーバーの VIP | loadBalancer.vips.controlPlaneVIP フィールドのユーザー クラスタ構成ファイル |
| ユーザー クラスタ内の Ingress サービスの VIP | loadBalancer.vips.ingressVIP フィールドのユーザー クラスタ構成ファイル |
Kubeception ユーザー クラスタ
次の表では、VIP の用途と、kubeception を使用するユーザー クラスタ用に構成する場所を示します。
| VIP | 構成 |
|---|---|
| ユーザー クラスタの Kubernetes API サーバーの VIP | loadBalancer.vips.controlPlaneVIP フィールドのユーザー クラスタ構成ファイル |
| ユーザー クラスタ内の Ingress サービスの VIP | loadBalancer.vips.ingressVIP フィールドのユーザー クラスタ構成ファイル |
nodePort 値を確保する
GKE on VMware では、Kubernetes API サーバーと Ingress サービスは Kubernetes Services によって公開されます。手動負荷分散モードを使用する場合は、これらの Service で独自の nodePort 値を選択する必要があります。30000～32767 の範囲で値を選択します。
nodePort 値を構成する
nodePort 値を構成する場所は、ユーザー クラスタで コントロール プレーン V2 が有効になっているかどうかによって異なります。
HA 管理クラスタ
HA 管理クラスタ用に nodePorts を構成する必要はありません。
CP V2 ユーザー クラスタ
次の表では、nodePorts の用途と、コントロール プレーン V2 が有効になっているユーザー クラスタ用に構成する場所について説明します。
nodePorts |
構成 |
|---|---|
ユーザー クラスタ内の Ingress サービスの HTTP nodePort |
loadBalancer.manualLB.ingressHTTPNodePort のユーザー クラスタの構成ファイル |
ユーザー クラスタ内の Ingress サービスの HTTPS nodePort |
loadBalancer.manualLB.ingressHTTPSNodePort のユーザー クラスタの構成ファイル |
GKE on VMware は、コントロール プレーン V2 が有効になっているユーザー クラスタのコントロール プレーン ノードへのロード バランシングを処理するため、コントロール プレーン VIP に nodePort を構成する必要はありません。
Kubeception ユーザー クラスタ
次の表に、nodePort 値の用途と kubeception を使用するユーザー クラスタ用に構成する場所を示します。
nodePort |
構成 |
|---|---|
nodePort: ユーザー クラスタの Kubernetes API サーバー |
loadBalancer.manualLB.controlPlaneNodePort フィールドのユーザー クラスタ構成ファイル |
ユーザー クラスタの Konnectivity サーバー用の nodePort（Konnectivity サーバーはコントロール プレーン VIP を使用します） |
loadBalancer.manualLB.konnectivityServerNodePort フィールドのユーザー クラスタ構成ファイル |
ユーザー クラスタ内の Ingress サービスの HTTP nodePort |
loadBalancer.manualLB.ingressHTTPNodePort のユーザー クラスタの構成ファイル |
ユーザー クラスタ内の Ingress サービスの HTTPS nodePort |
loadBalancer.manualLB.ingressHTTPSNodePort のユーザー クラスタの構成ファイル |
クラスタ構成ファイルの例
次の例は、管理クラスタとユーザー クラスタの構成ファイルの一部を示しています。
HA 管理クラスタ
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
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 アドレスを指定する必要があります。
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 では、手動負荷分散モードを使用して構成されたロードバランサはサポートされません。ロードバランサに問題が発生した場合は、ロードバランサのベンダーにお問い合わせください。