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

重要: 移行プロセスでは、LoadBalancer タイプの Kubernetes Service のユーザー クラスタ内のすべての VIP へのネットワーク接続が 2 ～ 10 分間停止します 移行が完了すると、接続が再び機能するようになります。

移行が成功したら、ユーザー クラスタのすでに電源がオフになっている 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

重要: 移行プロセスでは、LoadBalancer タイプの Kubernetes Service の管理者 クラスタ内のすべての VIP へのネットワーク接続が 2 ～ 10 分間停止します 移行が完了すると、接続が再び機能するようになります。

移行が成功したら、管理クラスタのすでに電源がオフになっている 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 名前空間で、kube-apiserver Service タイプを ClusterIP から LoadBalancer に変更します。必要に応じて、サポート チケットを作成してください。