In diesem Dokument wird gezeigt, wie Sie GKE on VMware für die Verwendung des gebündelten Load-Balancings mit dem MetalLB-Load-Balancer konfigurieren.
In GKE on VMware 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:
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:
MetalLB-Load-Balancer
VIPs auf dem MetalLB für Kubernetes API-Server und Add-ons des Administratorclusters
network:
hostConfig:
...
ipMode:
type: "static"
ipBlockFilePath: "config-folder/admin-cluster-ipblock.yaml"
...
loadBalancer:
kind: "MetalLB"
...
vips:
controlPlaneVIP: "172.16.20.100"
addonsVIP: "172.16.20.101"
admin-cluster-ipblock.yaml
Das folgende Beispiel einer IP-Blockdatei zeigt die Angabe von IP-Adressen für die Knoten im Administratorcluster. Dazu gehören auch die Adressen des Steuerungsebenenknotens für den Nutzercluster und eine IP-Adresse, die während des Clusterupgrades verwendet werden soll.
blocks:
- netmask: "255.255.255.0"
gateway: "17.16.20.1"
ips:
- ip: 172.16.20.50
hostname: admin-vm-1
- ip: 172.16.20.51
hostname: admin-vm-2
- ip: 172.16.20.52
hostname: admin-vm-3
- ip: 172.16.20.53
hostname: admin-vm-4
- ip: 172.16.20.54
hostname: admin-vm-5
user-cluster.yaml
Das folgende Beispiel für eine Konfigurationsdatei für einen Nutzercluster zeigt die Konfiguration von:
Adresspools für den MetalLB-Controller, aus denen Dienste vom Typ
LoadBalancerausgewählt werden können und die diesen zugewiesen werden. Die Ingress-VIP befindet sich in einem dieser Pools.VIP für den Kubernetes API-Server des Nutzerclusters und die Ingress-VIP, die Sie für den Ingress-Proxy konfiguriert haben. Die Kubernetes API-Server-VIP befindet sich im Administratorcluster-Subnetz, da die Steuerungsebene für einen Nutzercluster auf einem Knoten im Administratorcluster ausgeführt wird.
Ein Knotenpool, der für die Verwendung von MetalLB aktiviert ist. MetalLB wird auf den Knoten im Nutzercluster bereitgestellt, die zu diesem Knotenpool gehören.
network:
hostConfig:
...
ipMode:
type: "static"
ipBlockFilePath: "config-folder/user-cluster-ipblock.yaml"
...
loadBalancer:
kind: MetalLB
metalLB:
addressPools:
- name: "address-pool-1"
addresses:
- "172.16.40.100/32"
- "172.16.40.101-172.16.40.112
avoidBuggyIPs: true
...
vips:
controlPlaneVIP: "172.16.20.102"
ingressVIP: "172.16.40.102"
...
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 Knoten im Nutzercluster. Dazu gehört eine IP-Adresse, die während des Clusterupgrades verwendet werden soll.
blocks:
- netmask: "255.255.255.0"
gateway: "17.16.40.1"
ips:
- ip: 172.16.40.21
hostname: user-vm-1
- ip: 172.16.40.22
hostname: user-vm-2
- ip: 172.16.40.23
hostname: user-vm-3
- ip: 172.16.40.24
hostname: user-vm-4
- ip: 172.16.40.25
hostname: user-vm-5
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.kindauf"MetalLB". - Geben Sie einen oder mehrere Adresspools für Services an. Die Ingress-VIP muss sich in einem dieser Pools befinden.
- Legen Sie
enableLoadBalancerfür mindestens einen Knotenpool in Ihrem Cluster auftruefest.
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.