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.

In 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

Der folgende Teil einer Konfigurationsdatei eines Administratorclusters zeigt die Konfiguration aus dem vorherigen Diagramm:

  • Steuerungsebene mit Hochverfügbarkeit

  • MetalLB-Load-Balancer

  • Virtuelle IP-Adresse auf dem MetalLB for 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

Der folgende Teil einer Nutzercluster-Konfigurationsdatei zeigt die Konfiguration:

  • Adresspool für den MetalLB-Controller, der ausgewählt und den Diensten vom Typ LoadBalancer zugewiesen werden kann. Die virtuelle IP-Adresse für eingehenden Traffic befindet sich in diesem Pool.

  • Virtuelle IP-Adresse für den Kubernetes API-Server des Nutzerclusters und die virtuelle IP-Adresse für eingehenden Traffic, 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 für eine IP-Blockdatei zeigt die Festlegung von IP-Adressen für die Worker-Knoten im Nutzercluster. Dazu gehört eine zusätzliche IP-Adresse, die bei Upgrades, Updates und automatischen Reparaturen von Clustern verwendet werden kann.

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 führt eine IP-Adressverwaltung für Dienste durch. Wenn ein Anwendungsentwickler einen Dienst vom Typ LoadBalancer in einem Nutzercluster erstellt, muss er keine IP-Adresse für den Dienst manuell angeben. Stattdessen wählt der MetalLB-Controller eine IP-Adresse aus einem Adresspool aus, den Sie beim Erstellen des Clusters angeben.

Überlegen Sie, wie viele Dienste vom Typ LoadBalancer in Ihrem Nutzercluster wahrscheinlich aktiv sind. Geben Sie dann im Abschnitt loadBalancer.metalLB.addressPools der Konfigurationsdatei des Nutzerclusters genügend IP-Adressen an, um diese Dienste zu verarbeiten.

Die Ingress-VIP für Ihren Nutzercluster muss unter den Adressen liegen, die Sie in einem Adresspool angeben. Dies liegt daran, dass der Ingress-Proxy von einem Dienst vom Typ LoadBalancer verfügbar gemacht wird.

Wenn Ihre Anwendungsentwickler keine Dienste vom Typ LoadBalancer erstellen müssen, müssen Sie außer der Ingress-VIP keine anderen Adressen angeben.

Adressen 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

Wenn Sie die Adressen in einem Pool anpassen müssen, nachdem der Cluster erstellt wurde, können Sie gkectl update cluster verwenden. 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.

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 Services zuweisen soll, setzen Sie das Feld manualAssign des Pools auf true. 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_KUBECONIFG --config USER_CLUSTER_CONFIG

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.