Gebündeltes Load Balancing mit MetalLB

In diesem Dokument wird beschrieben, wie Sie Google Distributed Cloud für die Verwendung des gebündelten Load-Balancings mit dem MetalLB-Load-Balancer konfigurieren. Dieses Dokument richtet sich an Netzwerkspezialisten, die das Netzwerk für ihre Organisation entwerfen und erstellen sowie Netzwerkgeräte installieren, konfigurieren und unterstützen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

In der Google Distributed Cloud wird MetalLB im Layer-2-Modus ausgeführt.

Beispiel für eine MetalLB-Konfiguration

Hier sehen Sie ein Beispiel für eine Konfiguration für Cluster, auf denen der MetalLB-Load-Balancer ausgeführt wird:

Konfiguration des MetalLB-Load-Balancers
Konfiguration des MetalLB-Load-Balancers

Das obige Diagramm zeigt ein MetalLB-Deployment. MetalLB wird direkt auf den Clusterknoten ausgeführt. In diesem Beispiel befinden sich der Administratorcluster und der Nutzercluster in zwei separaten VLANs und jeder Cluster befindet sich in einem separaten Subnetz:

Cluster Subnetz
Administratorcluster 172.16.20.0/24
Nutzercluster 172.16.40.0/24

admin-cluster.yaml

Das folgende Beispiel für eine Konfigurationsdatei für einen Administratorcluster zeigt die im vorherigen Diagramm dargestellte Konfiguration:

  • Steuerungsebene mit Hochverfügbarkeit

  • MetalLB-Load-Balancer

  • VIP auf MetalLB für den Kubernetes API-Server des Administratorclusters

network:
  ...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    - ip: "172.16.20.50"
      hostname: "admin-cp-1"
    - ip: "172.16.20.51"
      hostname: "admin-cp-2"
    - ip: "172.16.20.52"
      hostname: "admin-cp-3"
loadBalancer:
  kind: "MetalLB"
  ...
  vips:
    controlPlaneVIP: "172.16.20.100"
...
adminMaster:
  cpus: 4
  memoryMB: 16384
  replicas: 3

user-cluster.yaml

Das folgende Beispiel für eine Konfigurationsdatei für einen Nutzercluster zeigt die Konfiguration von:

  • Adresspool für den MetalLB-Controller, aus denen Dienste vom Typ LoadBalancer ausgewählt werden können und die diesen zugewiesen werden. Die Ingress-VIP befindet sich in diesem Pool.

  • VIP für den Kubernetes API-Server des Nutzerclusters und die Ingress-VIP, die Sie für den Ingress-Proxy konfiguriert haben.

  • Ein Knotenpool, der für die Verwendung von MetalLB aktiviert ist. MetalLB wird auf den Knoten in diesem Knotenpool bereitgestellt.

enableControlplaneV2: true
...
network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/user-cluster-ipblock.yaml"
...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.40.1"
    ips:
    - ip: "172.16.40.21"
      hostname: "user-cp"
loadBalancer:
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.40.101-172.16.40.112
      avoidBuggyIPs: true
  ...

  vips:
    controlPlaneVIP: "172.16.20.100"
    ingressVIP: "172.16.40.101"
...
nodePools:
- name: "node-pool-1"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true

Die Konfiguration im vorherigen Beispiel gibt eine Reihe von Adressen an, die für Dienste verfügbar sind. Wenn ein Anwendungsentwickler einen Dienst vom Typ LoadBalancer im Nutzercluster erstellt, wählt der MetalLB-Controller eine IP-Adresse aus diesem Pool aus.

user-cluster-ipblock.yaml

Das folgende Beispiel einer IP-Blockdatei zeigt die Angabe von IP-Adressen für die Worker-Knoten im Nutzercluster. Dazu gehört eine zusätzliche IP-Adresse, die während des Clusterupgrades, des Updates und der automatischen Reparatur verwendet werden soll.

blocks:
- netmask: "255.255.255.0"
  gateway: "17.16.40.1"
  ips:
  - ip: 172.16.40.22
    hostname: user-vm-1
  - ip: 172.16.40.23
    hostname: user-vm-2
  - ip: 172.16.40.24
    hostname: user-vm-3
  - ip: 172.16.40.25
    hostname: user-vm-4
  - ip: 172.16.40.26
    hostname: user-vm-5
  - ip: 172.16.40.27
    hostname: user-vm-6

MetalLB einrichten

Firewallports öffnen

MetalLB verwendet die Go-Mitgliederlistenbibliothek, um die Leader-Auswahl zu treffen. Die memberlist-Bibliothek verwendet den TCP-Port 7946 und den UDP-Port 7946, um Informationen auszutauschen. Achten Sie darauf, dass diese Ports auf allen Load-Balancer-Knoten für eingehenden und ausgehenden Traffic zugänglich sind.

MetalLB für einen neuen Administratorcluster aktivieren

Legen Sie in der Administrator-Clusterkonfigurationsdatei loadBalancer.kind auf "MetalLB" fest:

loadBalancer:
  kind: "MetalLB"

Füllen Sie den Rest Ihrer Konfigurationsdatei für den Administratorcluster aus und erstellen Sie Ihren Administratorcluster, wie unter Administratorcluster erstellen beschrieben.

Adresspools angeben

Der MetalLB-Controller weist Diensten IP-Adressen zu. Wenn ein Anwendungsentwickler einen Dienst vom Typ LoadBalancer in einem Nutzercluster erstellt, weist der MetalLB-Controller dem Dienst automatisch eine IP-Adresse zu. Der MetalLB-Controller wählt eine IP-Adresse aus einem von Ihnen angegebenen Adresspool aus.

Damit Ihr Nutzercluster genügend IP-Adressen hat, sollten Sie die maximale Anzahl von LoadBalancer-Diensten berücksichtigen, die wahrscheinlich aktiv sind. Geben Sie dann im Abschnitt loadBalancer.metalLB.addressPools der Konfigurationsdatei des Nutzerclusters genügend IP-Adressen an.

Adressen im Pool müssen im CIDR-Format oder im Bereichsformat vorliegen. Wenn Sie eine einzelne Adresse angeben möchten, verwenden Sie ein CIDR vom Typ /32. Beispiel:

addresses:
  -   "192.0.2.0/26"
  -   "192.0.2.64-192.0.2.72"
  -   "192.0.2.75/32"

IP-Adressen ausschließen, die für andere Zwecke verwendet werden

Fügen Sie die folgenden IP-Adressen keinem Adresspool hinzu:

Nachdem der Cluster erstellt wurde, können Sie mit gkectl update cluster IP-Adresspools hinzufügen. Ob Sie die IP-Adressen in einem vorhandenen Adresspool ändern können, hängt von der Clusterversion und davon ab, ob erweiterte Cluster aktiviert sind. Weitere Informationen finden Sie unter MetalLB aktualisieren.

MetalLB für einen neuen Nutzercluster aktivieren

In der Konfigurationsdatei für den Nutzerclusters:

  • Setzen Sie loadBalancer.kind auf "MetalLB".
  • Geben Sie einen oder mehrere Adresspools für Services an. Die Ingress-VIP muss sich in einem dieser Pools befinden.

  • Legen Sie enableLoadBalancer für mindestens einen Knotenpool in Ihrem Cluster auf true fest. Wenn dieses Feld auf true gesetzt ist, kann der MetalLB-Speaker auf den Knoten im Pool ausgeführt werden. Beachten Sie, dass die Version des Load-Balancer-Knotenpools bei Upgrades mit der Clusterversion übereinstimmen muss. Versionsabweichungen werden für Load-Balancer-Knotenpools nicht unterstützt.

    Beachten Sie die folgenden Unterschiede im Verhalten des Felds enableLoadBalancer, wenn enableAdvancedCluster auf true gesetzt ist (erweiterte Cluster aktiviert): In Version 1.31 hat dieses Feld keine Auswirkungen, wenn erweiterte Cluster aktiviert sind, da der MetalLB-Speaker immer auf den Knoten der Steuerungsebene des Nutzerclusters ausgeführt wird. In Version 1.32 wurde diese Einschränkung entfernt, wenn erweiterte Cluster aktiviert sind. Sie müssen mindestens einen Knotenpool angeben, auf dem der MetalLB-Speaker ausgeführt wird.

Füllen Sie den Rest der Konfigurationsdatei des Nutzerclusters aus und erstellen Sie den Nutzercluster, wie unter Nutzercluster erstellen beschrieben.

Manuelle Zuweisung von Dienstadressen

Wenn der MetalLB-Controller IP-Adressen aus einem bestimmten Pool nicht automatisch Diensten zuweisen soll, legen Sie für das Feld manualAssign des Pools true fest. Anschließend können Entwickler einen Service vom Typ LoadBalancer erstellen und eine der Adressen manuell aus dem Pool angeben. Beispiel:

loadBalancer:
  metalLB:
    addressPools:
    - name: "my-address-pool-2"
      addresses:
      - "192.0.2.73-192.0.2.80"
      manualAssign: true

Fehlerhafte IP-Adressen vermeiden

Wenn Sie das Feld avoidBuggyIPs eines Adresspools auf true setzen, verwendet der MetalLB-Controller keine Adressen aus dem Pool, die auf .0 oder .255 enden. Dadurch wird verhindert, dass fehlerhafte Geräte versehentlich Traffic löschen, der an diese speziellen IP-Adressen gesendet wird. Beispiel:

loadBalancer:
  metalLB:
    addressPools:
    - name: "my-address-pool-1"
      addresses:
      - "192.0.2.0/24"
      avoidBuggyIPs: true

Service vom Typ LoadBalancer erstellen

Im Folgenden finden Sie zwei Manifeste: eines für ein Deployments und eines für einen Service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      greeting: hello
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
    spec:
      containers:
      - name: hello
        image: gcr.io/google-samples/hello-app:2.0
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    greeting: hello
  ports:
  - name: metal-lb-example-port
    protocol: TCP
    port: 60000
    targetPort: 8080

Beachten Sie, dass im Servicemanifest keine externe IP-Adresse angegeben ist. Der MetalLB-Controller wählt eine externe IP-Adresse aus dem Adresspool aus, den Sie in der Nutzercluster-Konfigurationsdatei angegeben haben.

Speichern Sie die Manifeste in einer Datei mit dem Namen my-dep-svc.yaml. Erstellen Sie dann die Deployment- und Serviceobjekte:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-dep-svc.yaml

Lassen Sie den Service anzeigen:

kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get service my-service --output wide

Die Ausgabe zeigt die externe IP-Adresse, die dem Service automatisch zugewiesen wurde. Beispiel:

NAME         TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)           AGE   SELECTOR
my-service   LoadBalancer   10.96.2.166   192.0.2.2   60000:31914/TCP   28s

Prüfen Sie, ob die zugewiesene externe IP-Adresse aus dem Adresspool stammt, den Sie in der Nutzercluster-Konfigurationsdatei angegeben haben. Beispielsweise befindet sich 192.0.2.2 in diesem Adresspool:

metalLB:
  addressPools:
  - name: "address-pool-1"
    addresses:
     - "192.0.2.0/24"
     - "198.51.100.1-198.51.100.3"

Rufen Sie den Service auf:

curl EXTERNAL_IP_ADDRESS:60000

In der Ausgabe wird die Meldung Hello, world! angezeigt:

Hello, world!
Version: 2.0.0

MetalLB aktualisieren

Nachdem Sie den Cluster erstellt haben, können Sie die MetalLB-Adresspools und das Feld enableLoadBalancer in Ihren Knotenpools aktualisieren. Nehmen Sie die gewünschten Änderungen in der Nutzercluster-Konfigurationsdatei vor und rufen Sie dann gkectl update cluster auf:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Wenn erweiterte Cluster aktiviert sind, können Sie die IP-Adressen eines vorhandenen Adresspools nicht ändern. Das Hinzufügen, Entfernen und Neuanordnen von IP-Adressen wird nicht unterstützt. Ab Version 1.33 sind alle neuen Cluster erweiterte Cluster. Wenn Sie IP-Adressen hinzufügen möchten, fügen Sie einen neuen Adresspool mit den neuen IP-Adressen hinzu und lassen Sie die vorhandenen Adresspools unverändert. Mit der folgenden Konfiguration wird beispielsweise address-pool-2 hinzugefügt und address-pool-1 bleibt unverändert:

loadBalancer:
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.40.101-172.16.40.112"
      avoidBuggyIPs: true
    - name: "address-pool-2"
      addresses:
      - "172.16.40.121-172.16.40.130"
      avoidBuggyIPs: true

Der MetalLB-Controller kann IP-Adressen aus jedem Adresspool zuweisen, für den manualAssign nicht auf true festgelegt ist. Ein neuer Adresspool erhöht also die Kapazität. Wenn Sie das Verhalten für die neuen IP-Adressen beibehalten möchten, legen Sie für manualAssign und avoidBuggyIPs im neuen Adresspool dieselben Werte wie im vorhandenen Adresspool fest.

Weitere Informationen dazu, welche Änderungen in den einzelnen Versionen unterstützt werden, finden Sie im Feld addresses in der Referenz zur Konfigurationsdatei für Nutzercluster.

MetalLB-Pods und ConfigMap

Der MetalLB-Controller wird als Deployment ausgeführt und der MetalLB-Speaker wird als DaemonSet auf Knoten in Pools ausgeführt, in denen enableLoadBalancer auf true gesetzt ist. Der MetalLB-Controller verwaltet die IP-Adressen, die Services zugewiesen sind. Der MetalLB-Speaker wählt Leader aus und kündigt Service-VIPs an.

So können Sie alle MetalLB-Pods aufrufen:

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

Sie können die Logs aus den MetalLB-Pods zur Fehlerbehebung verwenden.

Die MetalLB-Konfiguration wird in einer ConfigMap in einem Format gespeichert, das MetalLB bekannt ist. Ändern Sie die ConfigMap nicht direkt. Verwenden Sie stattdessen gkectl update cluster wie oben beschrieben. So rufen Sie die ConfigMap für die Fehlerbehebung auf:

kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get configmap metallb-config --namespace kube-system

Vorteile von MetalLB

  • MetalLB wird direkt auf Ihren Clusterknoten ausgeführt, sodass keine zusätzlichen VMs erforderlich sind.

  • Der MetalLB-Controller führt eine IP-Adressverwaltung für Services durch, sodass Sie nicht für jeden Service manuell eine IP-Adresse auswählen müssen.

  • Aktive Instanzen von MetalLB für verschiedene Services können auf verschiedenen Knoten ausgeführt werden.

  • Sie können eine IP-Adresse für verschiedene Services freigeben.

MetalLB im Vergleich zu F5 BIG-IP und Seesaw

  • VIPs müssen sich im selben Subnetz wie die Clusterknoten befinden. Dies ist auch eine Anforderung für Seesaw, jedoch nicht für F5 BIG-IP.

  • Es gibt keine Messwerte für den Traffic.

  • Es gibt keine problemlosen Failover. Vorhandene Verbindungen werden während eines Failovers zurückgesetzt.

  • Externer Traffic zu den Pods eines bestimmten Services wird über einen einzelnen Knoten geleitet, auf dem der MetalLB-Speaker ausgeführt wird. Das bedeutet, dass die Client-IP-Adresse für Container, die im Pod ausgeführt werden, normalerweise nicht sichtbar ist.

  • Cisco Application Centric Infrastructure (ACI) mit Dataplane IP Learning ist nicht mit Seesaw- und MetalLB-Load-Balancern kompatibel. Wir empfehlen, das manuelle Load Balancing zu verwenden oder Dataplane IP Learning zu deaktivieren, wenn Sie Seesaw oder MetalLB als Load Balancer verwenden. Außerdem befindet sich Seesaw im Wartungsmodus. Ab Google Distributed Cloud-Version 1.32 sind Upgrades für Cluster, die Seesaw verwenden, blockiert. Sie müssen Cluster zu empfohlenen Features migrieren, bevor Sie ein Upgrade auf 1.32 durchführen.