次のいずれかのロード バランシング モードを構成することをおすすめします。
バンドルモードでは、Google Distributed Cloud がロードバランサを提供して管理します。ロードバランサにライセンスを割り当てる必要はありません。必要なセットアップ作業は最小限に抑えられます。
手動モードでは、Google Distributed Cloud は 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 の値が必要になります。
コントロール プレーン用に別の種類のロードバランサを構成する
バージョン 1.32 以降では、高度なクラスタが有効になっている場合、新しいクラスタの作成時に、コントロール プレーン用に別の種類のロードバランサを構成できます。詳しくは以下をご覧ください。
- 管理クラスタ:
adminMaster.controlPlaneLoadBalancer - ユーザー クラスタ:
masterNode.controlPlaneLoadBalancer
ノード IP アドレスを確保する
手動ロード バランシング モードでは、DHCP を使用できません。クラスタノードの静的 IP アドレスを指定する必要があります。管理クラスタ内のノードと、作成するすべてのユーザー クラスタ内のノードに十分なアドレスを確保する必要があります。確保するノード IP アドレスの数の詳細については、IP アドレスを計画する（Controlplane V2）および IP アドレスを計画する（kubeception）をご覧ください。
IP アドレスを構成する
確保した静的 IP アドレスを構成する場所は、クラスタタイプと、ユーザー クラスタで Controlplane V2 を有効にするかどうかによって異なります。
HA 管理クラスタ
次の表に、IP アドレスの用途と HA 管理クラスタ用に構成する場所を示します。
| 静的 IP | 構成 |
|---|---|
| コントロール プレーン ノード | クラスタでトポロジ ドメインを使用する場合は、管理クラスタの IP ブロック ファイルに IP アドレスを追加し、管理クラスタ構成ファイルの クラスタでトポロジ ドメインを使用しない場合は、管理クラスタ構成ファイルの |
| 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 アドレスの用途と、Controlplane V2 が有効になっているユーザー クラスタ用に構成する場所を示します。
| 静的 IP | 構成 |
|---|---|
| コントロール プレーン ノード | クラスタでトポロジ ドメインを使用する場合は、ユーザー クラスタの IP ブロック ファイルに IP アドレスを追加し、ユーザー クラスタ構成ファイルの クラスタでトポロジ ドメインを使用しない場合は、ユーザー クラスタ構成ファイルの |
| ワーカーノード | ユーザー クラスタの IP ブロック ファイル。ユーザー クラスタ構成ファイルの network.ipMode.ipBlockFilePath フィールドにパスを追加します。 |
kubeception ユーザー クラスタ
次の表に、IP アドレスの用途と、kubeception を使用するユーザー クラスタ用に構成する場所を示します。
| 静的 IP | 構成 |
|---|---|
| コントロール プレーン ノード | 管理クラスタの IP ブロック ファイル。管理クラスタ構成ファイルの network.ipMode.ipBlockFilePath フィールドにパスを追加します。 |
| ワーカーノード | ユーザー クラスタの IP ブロック ファイル。ユーザー クラスタ構成ファイルの network.ipMode.ipBlockFilePath フィールドにパスを追加します。 |
バージョン 1.30 以降では、新しいユーザー クラスタに Controlplane V2 が必要です。
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 の用途と、Controlplane 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 の値を確保する
Google Distributed Cloud では、Kubernetes API サーバーと Ingress サービスが Kubernetes Service によって公開されます。手動ロード バランシング モードを使用する場合は、これらの Service の独自の NodePort の値を選択する必要があります。30000～32767 の範囲で値を選択します。
NodePort の値を構成する
NodePort の値を構成する場所は、ユーザー クラスタで ControlPlane 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 ユーザー クラスタ
次の表に、NodePort の用途と Controlplane V2 が有効になっているユーザー クラスタ用に構成する場所を示します。バージョン 1.30 以降では、上り（内向き）NodePort の値を構成する必要はありません。
nodePorts |
構成 |
|---|---|
ユーザー クラスタの Ingress サービスの HTTP nodePort |
ユーザー クラスタ構成ファイルの loadBalancer.manualLB.ingressHTTPNodePort |
ユーザー クラスタの Ingress サービスの HTTPS nodePort |
ユーザー クラスタ構成ファイルの loadBalancer.manualLB.ingressHTTPSNodePort |
kubeception ユーザー クラスタ
次の表に、NodePort の値の用途と kubeception を使用するユーザー クラスタ用に構成する場所を示します。
nodePort |
構成 |
|---|---|
ユーザー クラスタの Kubernetes API サーバー用の nodePort |
ユーザー クラスタ構成ファイルの loadBalancer.manualLB.controlPlaneNodePort フィールド |
ユーザー クラスタの Konnectivity サーバー用の nodePort（Konnectivity サーバーはコントロール プレーン VIP を使用） |
ユーザー クラスタ構成ファイルの loadBalancer.manualLB.konnectivityServerNodePort フィールド |
ユーザー クラスタの Ingress サービスの HTTP nodePort |
ユーザー クラスタ構成ファイルの loadBalancer.manualLB.ingressHTTPNodePort |
ユーザー クラスタの Ingress サービスの 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 管理クラスタ
コントロール プレーン ノードへのトラフィック
構成する必要があるマッピングは、管理クラスタの作成時に高度なクラスタを有効にするかどうかによって異なります。
高度なクラスタが有効になっていない場合、Google Distributed Cloud は HA 管理クラスタのコントロール プレーン トラフィックのロード バランシングを自動的に処理します。ロードバランサでマッピングを構成する必要はありませんが、
loadBalancer.vips.controlPlaneVIPフィールドに IP アドレスを指定する必要があります。高度なクラスタが有効になっている場合は、ロードバランサを次のように構成する必要があります。
loadBalancer.vips.controlPlaneVIPフィールドに IP アドレスを指定します。次のマッピングを構成します。
- (
controlPlaneVIP:443) -> (CONTROL_PLANE_NODE_IP_ADDRESSES:6433)
- (
バックエンドのヘルスチェックが正しく構成されていることを確認します。ヘルスチェックでは HTTPS を使用し、ポート
6443で/readyzエンドポイントをチェックする必要があります。ノードが正常な状態であると判断するには、ヘルスチェックで、このエンドポイントがステータス コード200を返すことを確認する必要があります。
アドオンノード内のサービスへのトラフィック
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 ユーザー クラスタ
コントロール プレーン トラフィック
構成する必要があるマッピングは、ユーザー クラスタの作成時に高度なクラスタを有効にするかどうかによって異なります。
高度なクラスタが有効になっていない場合、Google Distributed Cloud はユーザー クラスタのコントロール プレーン トラフィックのロード バランシングを自動的に処理します。ロードバランサでマッピングを構成する必要はありませんが、
loadBalancer.vips.controlPlaneVIPフィールドに IP アドレスを指定する必要があります。高度なクラスタが有効になっている場合は、ロードバランサを次のように構成する必要があります。
loadBalancer.vips.controlPlaneVIPフィールドに IP アドレスを指定します。次のマッピングを構成します。
- (
controlPlaneVIP:443) -> (CONTROL_PLANE_NODE_IP_ADDRESSES:6433)
- (
バックエンドのヘルスチェックが正しく構成されていることを確認します。ヘルスチェックでは HTTPS を使用し、ポート
6443で/readyzエンドポイントをチェックする必要があります。ノードが正常な状態であると判断するには、ヘルスチェックで、このエンドポイントがステータス コード200を返すことを確認する必要があります。
データプレーン トラフィック
構成する必要があるマッピングは、ユーザー クラスタの作成時に高度なクラスタを有効にするかどうかによって異なります。
高度なクラスタが有効になっていない場合は、クラスタを作成する前に次の操作を行います。
ユーザー クラスタ構成ファイルで、
loadBalancer.vips.ingressVIP、loadBalancer.manualLB.ingressHTTPNodePort、loadBalancer.manualLB.ingressHTTPSNodePortを構成します。ロードバランサで、各上り（内向き）NodePort の IP アドレスとポートのマッピングを構成します。
- (
ingressVIP:80) -> (NODE_IP_ADDRESSES:ingressHTTPNodePort) - (
ingressVIP:443) -> (NODE_IP_ADDRESSES:ingressHTTPSNodePort)
- (
高度なクラスタが有効になっている場合は、次の操作を行います。
クラスタを作成する前に、ユーザー クラスタ構成ファイルで
loadBalancer.vips.ingressVIPを構成します。高度なクラスタが有効になっている場合、各上り（内向き）NodePort の値は影響しないため、構成する必要はありません。クラスタを作成したら、各上り（内向き）NodePort の値を取得します。
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n gke-system get service istio-ingress -oyamlService 仕様のポート セクションで HTTP と HTTPS を探し、NodePort の値を書き留めます。
ロードバランサで、各上り（内向き）NodePort の IP アドレスとポートのマッピングを構成します。
- (
ingressVIP:80) -> (NODE_IP_ADDRESSES:ingressHTTPNodePort) - (
ingressVIP:443) -> (NODE_IP_ADDRESSES:ingressHTTPSNodePort)
- (
どちらの場合も、ユーザー クラスタ内のすべてのコントロール プレーン ノードとワーカーノードにこれらのマッピングを追加します。クラスタに NodePort が構成されているため、Kubernetes はすべてのクラスタノードで NodePort を開きます。この構成により、クラスタ内のどのノードでもデータプレーン トラフィックを処理できるようになります。
マッピングを構成すると、ロードバランサは標準の HTTP ポートと HTTPS ポートで、ユーザー クラスタの Ingress VIP に構成した IP アドレスのトラフィックをリッスンします。ロードバランサは、クラスタ内の任意のノードにリクエストをルーティングします。リクエストがいずれかのクラスタノードにルーティングされると、内部 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 では、手動負荷分散モードを使用して構成されたロードバランサはサポートされません。ロードバランサに問題が発生した場合は、ロードバランサのベンダーにお問い合わせください。