Vom Seesaw-Load Balancer zu MetalLB migrieren

In diesem Dokument wird die Migration vom Seesaw-Load Balancer zum MetalLB-Load Balancer erläutert.

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 Seesaw-VMs manuell, die bereits für den Nutzercluster ausgeschaltet sind. Sie finden die Seesaw-VM-Namen im vmnames-Abschnitt 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 seinen Clusterknoten verwendet. Wenn der Cluster z. B. zwei Dienste vom Typ LoadBalancer hätte, wären die externen Adressen für diese Dienste 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 Sie außerdem an, der Cluster hätte zwei Dienste vom Typ LoadBalancer und die externen Adressen für diese Dienste wären 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:

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 den Seesaw-Load Balancer nicht mehr. Der Cluster verwendet keine statischen IP-Adressen für seine Clusterknoten. Der network.hostConfig-Abschnitt ist also nicht erforderlich.

  • 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: Controlplane V2-Nutzercluster, DHCP

Angenommen, Sie haben einen Nutzercluster, für den Controlplane V2 aktiviert ist und für seine Worker-Knoten DHCP verwendet. Wenn der Cluster z. B. zwei Dienste vom Typ LoadBalancer hätte, wären die externen Adressen für diese Dienste 172.16.21.81 und 172.16.21.85.

Passen Sie die Konfigurationsdatei des Nutzerclusters so an:

  • Behalten Sie den network.hostconfig-Abschnitt 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 ist der network.hostConfig-Abschnitt erforderlich.

  • 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 loadBalancer.seesaw-Abschnitt.

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 Seesaw-VMs manuell, die bereits für den Administratorcluster ausgeschaltet sind. Sie finden die Seesaw-VM-Namen im vmnames-Abschnitt 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. Der Cluster verwendet keine statischen IP-Adressen für seine Clusterknoten. Der network.hostConfig-Abschnitt ist also nicht erforderlich.

Fehlerbehebung

Wenn gkectl update während der Nutzerclustermigration fehlschlägt und die Metalllb-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. Aber neu erstellte VIPs werden 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 metallb-Pods nicht im Administratorcluster ausgeführt werden, starten Sie die Seesaw-VMs des Administratorclusters manuell. Dadurch kann der Traffic zu den aktuell verwendeten VIPs der Steuerungsebene für Nutzercluster wieder funktionieren. Die VIP 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 gegebenenfalls ein Support-Ticket.