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

このドキュメントでは、バージョン 1.16～1.29 の Seesaw ロードバランサから MetalLB ロードバランサに移行する方法について説明します。クラスタのバージョンが 1.30 以降の場合は、推奨機能へのクラスタの移行を計画するの説明に従って操作することをおすすめします。

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

1.28、1.29: GA
1.16: プレビュー

externalTrafficPolicy を確認するには、次のコマンドを実行します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

この問題についてサポートが必要な場合は、Google サポートにお問い合わせください。

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

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

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

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

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

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

ユーザー クラスタの移行

ノードプールを選択して、MetalLB で使用できるように有効にする必要があります。MetalLB は、このノードプールのノードにデプロイされます。

ユーザー クラスタの構成ファイルでノードプールを選択し、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 に変更します。必要に応じて、サポート チケットを作成してください。