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 erfolgreich 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 deaktivierten 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 Dienste vom Typ LoadBalancer und die externen Adressen für diese Dienste lauten 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 Dienste vom Typ LoadBalancer sind im MetalLB-Adresspool enthalten.

Beispiel: kubeception-Nutzercluster, DHCP

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

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:

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"

Wichtige Punkte aus dem vorherigen Beispiel:

  • Der Cluster verwendet nicht mehr den Seesaw-Load-Balancer und der Cluster verwendet keine statischen IP-Adressen für seine Clusterknoten. Daher wird der Abschnitt network.hostConfig 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 Dienste vom Typ LoadBalancer sind im MetalLB-Adresspool enthalten.

Beispiel: Nutzercluster der Steuerungsebene V2, DHCP

Angenommen, Sie haben einen Nutzercluster, für den Steuerungsebene V2 aktiviert ist und DHCP für seine Worker-Knoten verwendet. Angenommen, der Cluster hat zwei Dienste vom Typ LoadBalancer und die externen Adressen für diese Dienste lauten 172.16.21.81 und 172.16.21.85.

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:

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"

Wichtige Punkte aus dem vorherigen Beispiel:

  • Der Cluster verwendet keine statischen IP-Adressen mehr für die Worker-Knoten, sondern statische IP-Adressen für die Knoten der Steuerungsebene. Daher wird der Abschnitt network.hostConfig benötigt.

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

  • Die externen IP-Adressen 172.16.21.81 und 172.16.21.85 für die vorhandenen Dienste 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 erfolgreich 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 bereits deaktivierten Seesaw-VMs für den Administratorcluster manuell. 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

Wichtigster Punkt 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

Wichtigster Punkt aus dem vorherigen Beispiel:

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

Fehlerbehebung

Wenn gkectl update während der Migration des Nutzerclusters 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 load-balancer-seesaw-Pod 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 Metallb-Pods nicht im Administratorcluster ausgeführt werden, schalten Sie die Seesaw-VMs des Administratorclusters manuell ein. Dadurch kann der Traffic zu den aktuell verwendeten virtuellen IP-Adressen der Steuerungsebene für Nutzercluster möglicherweise wieder ausgeführt werden. 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, um die IP-Adresse des Knotens der Steuerungsebene des Administratorclusters direkt zu verwenden.

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