Vom Seesaw-Load-Balancer zu MetalLB migrieren

In diesem Dokument wird die Migration vom Seesaw-Load-Balancer zum MetalLB-Load-Balancer beschrieben.

Die Verwendung von MetalLB bietet im Vergleich zu anderen Load-Balancing-Optionen mehrere Vorteile.

Migration von Nutzerclustern

Wählen Sie in der Konfigurationsdatei des Nutzerclusters einen Knotenpool aus und legen Sie enableLoadBalancer auf true fest:

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

Aktualisieren Sie den Cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

  • USER_CLUSTER_CONFIG: der Pfad Ihrer Nutzerclusterkonfigurationsdatei.

Entfernen Sie als Nächstes die Seesaw-Abschnitte aus der Datei und fügen Sie einen MetalLB-Abschnitt hinzu.

Aktualisieren Sie dann den Cluster noch einmal:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Prüfen Sie, ob die Metallb-Komponenten ordnungsgemäß ausgeführt werden: 

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

Die Ausgabe zeigt Pods für den MetalLB-Controller und Lautsprecher. Beispiel:

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

Löschen Sie nach einer erfolgreichen Migration die bereits ausgeschalteten Seesaw-VMs für den Nutzercluster manuell. Sie finden die Seesaw-VM-Namen im Abschnitt vmnames der Datei seesaw-for-[USERCLUSTERNAME].yaml in Ihrem Konfigurationsverzeichnis.

Beispiel: Nutzercluster, statische IP-Adressen

Angenommen, Sie haben einen Nutzercluster, der statische IP-Adressen für seine Clusterknoten verwendet. Angenommen, der Cluster hat zwei Services vom Typ LoadBalancer und die externen Adressen für diese Services sind 172.16.21.41 und 172.16.21.45.

Passen Sie die Konfigurationsdatei des Nutzerclusters so an:

  • Behalten Sie den Abschnitt network.hostConfig bei.
  • Setzen Sie loadBalancer.kind auf MetalLB.
  • Entfernen Sie den Abschnitt loadBalancer.seesaw.
  • Fügen Sie einen loadBalancer.metalLB-Abschnitt hinzu.

Beispiel:

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"

Wichtige Punkte aus dem vorherigen Beispiel:

  • Auch wenn der Cluster den Seesaw-Load-Balancer nicht mehr verwendet, ist der Abschnitt network.hostConfig erforderlich, da die Clusterknoten statische IP-Adressen verwenden.

  • Der Wert von ingressVIP wird im MetalLB-Adresspool angezeigt.

  • Die externen IP-Adressen 172.16.21.41 und 172.16.21.45 für die vorhandenen Services vom Typ LoadBalancer sind im MetalLB-Adresspool enthalten.

Beispiel: Nutzercluster, DHCP

Angenommen, Sie haben einen Nutzercluster, der DHCP für seine Clusterknoten verwendet. Angenommen, der Cluster hat zwei Dienste vom Typ LoadBalancer und die externen Adressen für diese Dienste sind 172.16.21.61 und 172.16.21.65.

Passen Sie die Konfigurationsdatei des Nutzerclusters so an:

  • Entfernen Sie den Abschnitt network.hostConfig.
  • Setzen Sie loadBalancer.kind auf MetalLB.
  • Entfernen Sie den Abschnitt loadBalancer.seesaw.
  • Fügen Sie einen loadBalancer.metalLB-Abschnitt hinzu.

Beispiel:

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"

Wichtige Punkte aus dem vorherigen Beispiel:

  • Der Cluster verwendet den Seesaw-Load-Balancer nicht mehr und der Cluster verwendet keine statischen IP-Adressen für seine Clusterknoten. Der Abschnitt network.hostConfig wird daher nicht benötigt.

  • Der Wert von ingressVIP wird im MetalLB-Adresspool angezeigt.

  • Die externen IP-Adressen 172.16.21.61 und 172.16.21.65 für die vorhandenen Services vom Typ LoadBalancer sind im MetalLB-Adresspool enthalten.

Migration des Administratorclusters

Legen Sie in der Konfigurationsdatei des Administratorclusters loadBalancer.kind auf MetalLB fest und entfernen Sie den Abschnitt loadBalancer.seesaw.

Aktualisieren Sie den Cluster:

gkectl update admin --kubeconfig  ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

  • ADMIN_CLUSTER_CONFIG: der Pfad Ihrer Administratorcluster-Konfigurationsdatei.

Prüfen Sie, ob die Metallb-Komponenten ordnungsgemäß ausgeführt werden: 

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

Die Ausgabe zeigt Pods für den MetalLB-Controller und Lautsprecher. Beispiel:

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

Löschen Sie nach einer erfolgreichen Migration die Seesaw-VMs, die bereits ausgeschaltet sind, manuell für den Administratorcluster. Sie finden die Seesaw-VM-Namen im Abschnitt vmnames der Datei seesaw-for-gke-admin.yaml in Ihrem Konfigurationsverzeichnis.

Beispiel: Administratorcluster, statische IP-Adressen

Angenommen, Sie haben einen Administratorcluster, der statische IP-Adressen für seine Clusterknoten verwendet.

Passen Sie die Konfigurationsdatei des Administratorclusters so an:

  • Behalten Sie den Abschnitt network.hostConfig bei.
  • Setzen Sie loadBalancer.kind auf MetalLB.
  • Entfernen Sie den Abschnitt loadBalancer.seesaw.

Beispiel:

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

Wichtiger Hinweis aus dem vorherigen Beispiel:

  • Auch wenn der Cluster den Seesaw-Load-Balancer nicht mehr verwendet, ist der Abschnitt network.hostConfig erforderlich, da die Clusterknoten statische IP-Adressen verwenden.

Beispiel: Administratorcluster, DHCP

Angenommen, Sie haben einen Administratorcluster, der DHCP für seine Clusterknoten verwendet.

Passen Sie die Konfigurationsdatei des Administratorclusters so an:

  • Entfernen Sie den Abschnitt network.hostConfig.
  • Setzen Sie loadBalancer.kind auf MetalLB.
  • Entfernen Sie den Abschnitt loadBalancer.seesaw.

Beispiel:

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

Wichtiger Hinweis aus dem vorherigen Beispiel:

  • Der Cluster verwendet den Seesaw-Load-Balancer nicht mehr und der Cluster verwendet keine statischen IP-Adressen für seine Clusterknoten. Der Abschnitt network.hostConfig wird daher nicht benötigt.

Fehlerbehebung

Wenn gkectl update während der Nutzerclustermigration fehlschlägt und die metallb-Pods nicht im Nutzercluster ausgeführt werden, schalten Sie die Seesaw-VMs des Nutzerclusters manuell ein. Dadurch wird der Traffic zu den aktuell verwendeten VIPs wiederhergestellt. Neu erstellte VIPs werden jedoch möglicherweise nicht von den Seesaw-VMs bereitgestellt, wenn der Pod load-balancer-seesaw nicht ausgeführt wird. Erstellen Sie in diesem Fall ein Support-Ticket.

Wenn gkectl update während der Migration des Administratorclusters fehlschlägt und die Metalllb-Pods nicht im Administratorcluster ausgeführt werden, schalten Sie die Seesaw-VMs des Administratorclusters manuell ein. Dies kann dazu führen, dass der Traffic zu aktuell verwendeten virtuellen IP-Adressen der Steuerungsebene für Nutzercluster wieder funktioniert. Die virtuelle IP-Adresse für die Steuerungsebene des Administratorclusters selbst funktioniert jedoch möglicherweise nicht. Bearbeiten Sie in diesem Fall die kubeconfig-Datei des Administratorclusters so, dass sie direkt die IP-Adresse des Knotens der Steuerungsebene des Administratorclusters verwendet.

Ändern Sie außerdem im Namespace kube-system den Diensttyp kube-apiserver von ClusterIP in LoadBalancer. Erstellen Sie bei Bedarf ein Support-Ticket.