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

このドキュメントでは、Seesaw ロードバランサから 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 アドレスプールに含まれています。

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

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

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

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.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 アドレスプールに含まれています。

管理クラスタの移行

管理クラスタの構成ファイルで、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 に変更します。必要に応じて、サポートチケットを作成します。

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

ユーザー クラスタの移行

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

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

管理クラスタの移行

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

例: 管理クラスタ、DHCP

トラブルシューティング

ユーザークラスタの移行

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

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