Seesaw ロードバランサから MetalLB に移行する

このドキュメントでは、Seesaw ロードバランサから MetalLB ロードバランサに移行する方法について説明します。

MetalLB の使用には、他のロード バランシングのオプションと比較していくつかの利点があります。

1.28 以降: 一般提供

1.16: プレビュー

ダウンタイムに関する注意事項

移行中はワークロードでダウンタイムが発生します。SeeSaw ロードバランサは HA 管理クラスタをサポートしていないため、次の注意事項は非高可用性（非 HA）管理クラスタにのみ適用されます。

  • 管理クラスタを移行する場合:

    • controlPlaneVIP が移行されるため、kubeception ユーザー クラスタのコントロール プレーンでダウンタイムが発生します。ダウンタイムは 10 分未満ですが、ダウンタイムの長さはインフラストラクチャによって異なります。

    • 管理マスターノードは、VM に直接接続された controlPlaneVIP を使用して再作成する必要があるため、管理クラスタのコントロール プレーンでダウンタイムが発生します。ダウンタイムは 20 分未満ですが、ダウンタイムの長さはインフラストラクチャによって異なります。

  • ユーザー クラスタを移行する場合、Seesaw ロードバランサの電源がオフになってから MetalLB Pod が起動するまで VIP が停止します。このプロセスは通常 1 分ほどかかります。

ユーザー クラスタの移行

ユーザー クラスタの構成ファイルでノードプールを選択し、enableLoadBalancer を true に設定します。

nodePools:
- name: pool-1
  replicas: 3
  enableLoadBalancer: true

クラスタを更新します。

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

次のように置き換えます。

  • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

  • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス

次に、ファイルから Seesaw セクションを削除し、MetalLB セクションを追加します。

その後、クラスタをもう一度更新します。

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

MetalLB コンポーネントが正常に実行されていることを確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

出力には、MetalLB コントローラとスピーカーの Pod が表示されます。例:

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

移行が成功したら、ユーザー クラスタですでに電源がオフになっている Seesaw VM を手動で削除します。Seesaw VM 名は、構成ディレクトリの seesaw-for-[USERCLUSTERNAME].yaml ファイルの vmnames セクションにあります。

例: ユーザー クラスタ、静的 IP アドレス

クラスタノードに静的 IP アドレスを使用するユーザー クラスタがあるとします。また、クラスタに LoadBalancer タイプの 2 つの Service があり、それらの Service の外部アドレスが 172.16.21.41 と 172.16.21.45 であるとします。

ユーザー クラスタ構成ファイルを次のように調整します。

  • network.hostConfig セクションはそのままにします。
  • loadBalancer.kind を MetalLB に設定します。
  • loadBalancer.seesaw セクションを削除します。
  • loadBalancer.metalLB セクションを追加します。

例:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
    ingressVIP: "172.16.20.31"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.31/32"
      - "172.16.20.40 - 172.16.21.49"

上記の例での要点:

  • クラスタでは Seesaw ロードバランサが使用されなくなりますが、クラスタノードは静的 IP アドレスを使用するため、network.hostConfig セクションは必要です。

  • ingressVIP の値が、MetalLB のアドレスプールに表示されます。

  • 既存の LoadBalancer タイプの Service の外部 IP アドレス 172.16.21.41 と 172.16.21.45 は、MetalLB アドレスプールに含まれています。

例: kubeception ユーザー クラスタ、DHCP

クラスタノードに DHCP を使用しているユーザー クラスタがあるとします。また、クラスタに LoadBalancer タイプの 2 つの Service があり、それらの Service の外部アドレスが 172.16.21.61 と 172.16.21.65 であるとします。

ユーザー クラスタ構成ファイルを次のように調整します。

  • network.hostConfig セクションを削除します。
  • loadBalancer.kind を MetalLB に設定します。
  • loadBalancer.seesaw セクションを削除します。
  • loadBalancer.metalLB セクションを追加します。

例:

enableControlplaneV2: false
network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.50"
    ingressVIP: "172.16.20.51"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.51/32"
      - "172.16.20.60 - 172.16.21.69"

上記の例での要点:

  • クラスタでは Seesaw ロードバランサが使用されなくなり、クラスタノードはクラスタノードに静的 IP アドレスを使用しなくなります。したがって、network.hostConfig セクションは必要ありません。

  • ingressVIP の値が、MetalLB のアドレスプールに表示されます。

  • 既存の LoadBalancer タイプの Service の外部 IP アドレス 172.16.21.61 と 172.16.21.65 は、MetalLB アドレスプールに含まれています。

例: Controlplane V2 ユーザー クラスタ、DHCP

Controlplane V2 が有効で、ワーカーノードに DHCP を使用しているユーザー クラスタがあるとします。また、クラスタに LoadBalancer タイプの 2 つの Service があり、それらの Service の外部アドレスが 172.16.21.81 と 172.16.21.85 であるとします。

ユーザー クラスタ構成ファイルを次のように調整します。

  • network.hostconfig セクションはそのままにします。
  • loadBalancer.kind を MetalLB に設定します。
  • loadBalancer.seesaw セクションを削除します。
  • loadBalancer.metalLB セクションを追加します。

例:

enableControlplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.70"
    ingressVIP: "172.16.20.71"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.71/32"
      - "172.16.20.80 - 172.16.21.89"

上記の例での要点:

  • クラスタではワーカーノードに静的 IP アドレスが使用されなくなりますが、コントロール プレーン ノードには静的 IP アドレスが使用されます。そのため、network.hostConfig セクションが必要です。

  • ingressVIP の値が、MetalLB のアドレスプールに表示されます。

  • 既存の LoadBalancer タイプの Service の外部 IP アドレス 172.16.21.81 と 172.16.21.85 は、MetalLB アドレスプールに含まれています。

管理クラスタの移行

管理クラスタの構成ファイルで、loadBalancer.kind を MetalLB に設定し、loadBalancer.seesaw セクションを削除します。

クラスタを更新します。

gkectl update admin --kubeconfig  ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

次のように置き換えます。

  • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス

  • ADMIN_CLUSTER_CONFIG: 管理クラスタの構成ファイルのパス

MetalLB コンポーネントが正常に実行されていることを確認します。

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

出力には、MetalLB コントローラとスピーカーの Pod が表示されます。例:

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

移行が成功したら、管理クラスタですでに電源がオフになっている Seesaw VM を手動で削除します。Seesaw VM 名は、構成ディレクトリの seesaw-for-gke-admin.yaml ファイルの vmnames セクションにあります。

例: 管理クラスタ、静的 IP アドレス

クラスタノードに静的 IP アドレスを使用する管理クラスタがあるとします。

管理クラスタの構成ファイルを次のように調整します。

  • network.hostConfig セクションはそのままにします。
  • loadBalancer.kind を MetalLB に設定します。
  • loadBalancer.seesaw セクションを削除します。

例:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072

上記の例での要点:

  • クラスタでは Seesaw ロードバランサが使用されなくなりますが、クラスタノードは静的 IP アドレスを使用するため、network.hostConfig セクションは必要です。

例: 管理クラスタ、DHCP

クラスタノードに DHCP を使用する管理クラスタがあるとします。

管理クラスタの構成ファイルを次のように調整します。

  • network.hostConfig セクションを削除します。
  • loadBalancer.kind を MetalLB に設定します。
  • loadBalancer.seesaw セクションを削除します。

例:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072

上記の例での要点:

  • クラスタでは Seesaw ロードバランサが使用されなくなり、クラスタノードはクラスタノードに静的 IP アドレスを使用しなくなります。したがって、network.hostConfig セクションは必要ありません。

トラブルシューティング

ユーザー クラスタの移行中に gkectl update が失敗し、metallb Pod がユーザー クラスタで実行されていない場合は、ユーザー クラスタの Seesaw VM を手動でオンにします。これにより、現在使用されている VIP へのトラフィックが再確立されます。ただし、load-balancer-seesaw Pod が実行されていない場合、新しく作成された VIP は Seesaw VM からサービスを提供されない可能性があります。その場合は、サポート チケットを作成してください。

管理クラスタの移行中に gkectl update が失敗し、metallb Pod が管理クラスタで実行されていない場合は、管理クラスタの Seesaw VM の電源を入れます。これにより、現在使用されているコントロール プレーン VIP へのトラフィックが許可され、ユーザー クラスタが再び機能する可能性があります。ただし、管理クラスタのコントロール プレーン自体の VIP は機能しない可能性があります。その場合は、管理クラスタの kubeconfig ファイルを編集して、管理クラスタのコントロール プレーン ノードの IP アドレスを直接使用するようにします。

また、kube-system Namespace で、kube-apiserver Service タイプを ClusterIP から LoadBalancer に変更します。必要に応じて、サポート チケットを作成してください。