手動ロード バランシング モードの有効化

次のいずれかのロード バランシング モードを構成することをおすすめします。

  • バンドルモードでは、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 値が必要になります。

ノード IP アドレスの確保

手動負荷分散モードでは、DHCP を使用できません。クラスタノードの静的 IP アドレスを指定する必要があります。管理クラスタ内のノードと、作成するすべてのユーザー クラスタ内のノードに十分なアドレスを確保する必要があります。確保するノード IP アドレスの数の詳細については、IP アドレスを計画する（Controlplane 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 アドレスの用途と、Controlplane 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 の用途と、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 ユーザー クラスタ

次の表では、nodePorts の用途と、Controlplane V2 が有効になっているユーザー クラスタ用に構成する場所について説明します。

nodePorts 構成
ユーザー クラスタの Ingress サービスの HTTP nodePort loadBalancer.manualLB.ingressHTTPNodePort のユーザー クラスタ構成ファイル
ユーザー クラスタの Ingress サービスの HTTPS nodePort loadBalancer.manualLB.ingressHTTPSNodePort のユーザー クラスタ構成ファイル

Google Distributed Cloud は、Controlplane V2 が有効になっているユーザー クラスタのコントロール プレーン ノードへのロード バランシングを処理するため、コントロール プレーン VIP に nodePort を構成する必要はありません。

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 アドレスを指定する必要があります。

アドオンノード内のサービスへのトラフィック

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 は、Controlplane 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 では、手動負荷分散モードを使用して構成されたロードバランサはサポートされません。ロードバランサに問題が発生した場合は、ロードバランサのベンダーにお問い合わせください。

次のステップ