Version 1.9. Diese Version wird nicht mehr unterstützt. Weitere Informationen finden Sie in der Richtlinie zu unterstützten Versionen. Informationen zum Upgrade auf Version 1.10 finden Sie in der Dokumentation zu 1.10 unter Upgrade von Anthos on Bare Metal.

Verfügbare unterstützte Versionen: 1.14 | 1.13 | 1.12

Gebündeltes Load-Balancing konfigurieren

Auf dieser Seite wird beschrieben, wie Sie gebündeltes Load-Balancing für Anthos-Cluster auf Bare Metal konfigurieren können. Anthos-Cluster on Bare-Metal stellt Layer-4-Load-Balancer bereit, die entweder auf einem dedizierten Pool von Worker-Knoten oder auf denselben Knoten wie die Steuerungsebene ausgeführt werden.

Unter Load-Balancer-Übersicht finden Sie Beispiele für Load-Balancing-Topologien, die in Anthos-Cluster auf Bare Metal verfügbar sind.

Voraussetzungen

Alle Load-Balancer-Knoten müssen sich in derselben Sendedomain des Layer-3-Subnetzes befinden.
Alle VIPs müssen sich im Subnetz des Load-Balancer-Knotens befinden und über das Gateway des Subnetzes routingfähig sein.
Das Gateway des Load-Balancer-Subnetzes muss ressourcensparende ARP-Nachrichten überwachen und ARP-Pakete an die Load-Balancer-Knoten weiterleiten.

Felder für die Konfiguration

Bearbeiten Sie den Abschnitt cluster.spec.loadBalancer der Cluster-Konfigurationsdatei, um das gebündelte Load-Balancing zu konfigurieren. Informationen zu Clusterkonfigurationsdateien und Beispiele für gültige Konfigurationen finden Sie in den folgenden Hilfeartikeln:

loadBalancer.mode

Dieser Wert muss bundled sein, um das gebündelte Load-Balancing zu aktivieren.

loadBalancer.ports.controlPlaneLBPort

Dieser Wert gibt den Zielport an, der für Traffic verwendet werden soll, der an die Kubernetes-Steuerungsebene gesendet wird (die Kubernetes API-Server).

loadBalancer.vips.controlPlaneVIP

Dieser Wert gibt die Ziel-IP-Adresse an, die für den Traffic an die Kubernetes-Steuerungsebene (die Kubernetes API-Server) verwendet werden soll. Diese IP-Adresse muss sich im selben Layer-2-Subnetz befinden wie die Knoten, auf denen Load-Balancer ausgeführt werden. Führen Sie diese Adresse nicht im Abschnitt [address pools](#address-pools) der Konfigurationsdatei auf.

loadBalancer.vips.ingressVIP

Dieser Wert gibt die IP-Adresse an, die für Dienste hinter dem Load-Balancer für eingehenden Traffic verwendet werden soll. Dieses Feld ist in Konfigurationsdateien für Administratorcluster nicht zulässig. Diese Adresse muss im Abschnitt Adresspools der Konfiguration aufgeführt sein.

loadBalancer.addressPools

Dieser Abschnitt der Konfiguration enthält einen oder mehrere Adresspools, die im folgenden Format angegeben sind:

- name: pool-name
  avoidBuggyIPs: boolean
  manualAssign: boolean
  addresses:
  - ip-range
  - ip-range

name: Der Name des Adresspools pool-name für Ihre eigenen Organisationszwecke.
avoidBuggyIPs: (optional) true oder false. Bei true gibt der Pool IP-Adressen aus, die auf .0 und .255 enden. Einige Netzwerkhardware führt Traffic zu diesen speziellen Adressen auf. Sie können dieses Feld weglassen. Der Standardwert ist false.
manualAssign: (optional). true oder false. Bei true werden Adressen in diesem Pool nicht automatisch Kubernetes-Diensten zugewiesen. Bei true wird eine IP-Adresse in diesem Pool nur verwendet, wenn sie explizit von einem Dienst angegeben wird. Sie können dieses Feld weglassen. Der Standardwert ist "false".
Adresse: Eine Liste mit einem oder mehreren nicht überlappenden IP-Adressbereichen. ip-range kann entweder in CIDR-Notation (z. B. 198.51.100.0/24) oder in Bereichsform angegeben werden (z. B. 198.51.100.0-198.51.100.10, ohne Leerzeichen um den Bindestrich).

Die IP-Adressbereiche in der addresses-Liste dürfen sich nicht überschneiden und müssen sich im selben Subnetz wie die Knoten befinden, auf denen Load-Balancer ausgeführt werden.

loadBalancer.nodePoolSpec

In diesem Abschnitt der Konfiguration wird eine Liste von Knoten angegeben, auf denen Load-Balancer ausgeführt werden sollen. Load-Balancer-Knoten können standardmäßig reguläre Arbeitslasten ausführen. Es gibt keine spezielle Markierung auf diesen Knoten. Das folgende Beispiel zeigt einen Knotenpool mit zwei Knoten. Der erste Knoten 1.2.3.4 verwendet das Feld k8sIP, um die IP-Adresse des Knotens im Cluster anzugeben. Die Adresse 1.2.3.4 wird nur für den SSH-Zugriff verwendet.

nodePoolSpec:
  nodes:
  - address: 1.2.3.4
    k8sIP: 10.0.0.32
  - address: 10.0.0.33

Alle Knoten im Knotenpool des Load-Balancers müssen sich im selben Layer-2-Subnetz befinden wie die Load-Balancer-VIPs, die im Abschnitt loadBalancer.addressPools der Konfigurationsdatei konfiguriert wurden. Wenn für einen Knoten eine k8sIP konfiguriert ist, muss sich nur diese Adresse im selben Layer-2-Subnetz befinden wie die anderen VIPs des Load-Balancers.

Wenn nodePoolSpec nicht festgelegt ist, werden die gebündelten Load-Balancer auf den Knoten der Steuerungsebene ausgeführt. Wir empfehlen Ihnen, Load-Balancer nach Möglichkeit auf separaten Knotenpools auszuführen.

Load-Balancing auf Steuerungsebene

Der Load-Balancer stellt die virtuelle IP-Adresse (VIP) der Steuerungsebene bereit. Anthos-Cluster auf Bare-Metal führt Keepalived und HAProxy als statische Kubernetes-Pods auf den Load-Balancer-Knoten aus, um den VIP der Steuerungsebene anzukündigen. Keepalived verwendet das Virtual Router Redundancy Protocol (VRRP) auf den Load-Balancer-Knoten zur Hochverfügbarkeit.

Load-Balancing der Datenebene

Der Datenebenen-Load-Balancer gilt für alle Kubernetes-Dienste vom Typ LoadBalancer. Anthos-Cluster on Bare-Metal verwendet MetalLB, das im Layer-2-Modus ausgeführt wird, um das Load-Balancing auf Datenebene zu ermöglichen. Das Load-Balancing für die Datenebene kann nur über Anthos-Cluster auf Bare Metal-Instanzen konfiguriert werden. Ändern Sie die ConfigMap von MetalLB nicht direkt. Sie können alle Metal-Features verwenden, einschließlich der IP-Adressfreigabe für mehrere Dienste. Weitere Informationen zu dieser Funktion finden Sie in der Dokumentation zum Thema "HLK".

MetalLB führt auf einem Knoten über ein DaemonSet eine Lautsprechergruppe mit memberlist für eine hohe Verfügbarkeit aus. Für jeden Kubernetes-Dienst gibt es einen eigenen MetalLB Load-Balancer-Knoten, nicht einen für den gesamten Cluster. So wird der Traffic auf die Load-Balancer-Knoten verteilt, wenn mehrere Dienste vorhanden sind.

Die Load-Balancer der Datenebene können entweder auf Knoten der Steuerungsebene oder auf einer Teilmenge von Worker-Knoten ausgeführt werden. Durch das Zwischenspeichern der Datenebenen-Load-Balancer auf den Steuerungseben-Knoten wird die Nutzung der Steuerungsebene-Knoten erhöht. Durch das Bündeln der Knoten auf der Steuerungsebene wird jedoch auch das Risiko einer Überlastung der Steuerungsebene erhöht und das Risiko vertraulicher Informationen auf der Steuerungsebene, z. B. SSH-Schlüssel, erhöht.

Quell-IP-Adresse des Clients beibehalten

Der Dienst LoadBalancer, der mit der gebündelten Ebene-2-Load-Balancing-Lösung erstellt wurde, verwendet die Standardeinstellung Cluster für die externe Trafficrichtlinie. Diese Einstellung (spec.externalTrafficPolicy: Cluster) leitet externen Traffic an clusterweite Endpunkte weiter, verschleiert jedoch auch die IP-Adresse des Clientquellcodes.

In den folgenden Abschnitten wird beschrieben, wie Sie Ihren Cluster so konfigurieren, dass die Quell-IP-Adresse des Clients erhalten wird.

`NodePort` Dienste

Kubernetes führt eine Quellnetzwerkadressübersetzung (NAT) für NodePort-Dienste aus. Wenn Sie die Quell-IP-Adressen der Clients beibehalten möchten, setzen Sie service.spec.externalTrafficPolicy auf Local. Kubernetes führt keine Quell-NAT mehr aus. Sie müssen jedoch darauf achten, dass Pods genau auf der ausgewählten Knoten-IP ausgeführt werden.

`LoadBalancer` Dienste

Wenn Sie externalTrafficPolicy: Local in Ihren LoadBalancer-Diensten verwenden, legen Sie fest, dass Ihre Anwendungs-Pods genau auf den Load-Balancer-Knoten ausgeführt werden. Fügen Sie den Anwendungs-Pods das folgende nodeSelector hinzu, um diese Änderung vorzunehmen:

apiVersion: v1
kind: Pod
...
spec:
  nodeSelector:
      baremetal.cluster.gke.io/lbnode: "true"
...

Eingehender Traffic

Wenn Ihre Anwendungen HTTP-Dienste sind, können Sie die Sichtbarkeit der Client-IP-Adresse erreichen, indem Sie Ingress-Komponenten konfigurieren:

Öffnen Sie den istio-ingress-Dienst zum Bearbeiten:
```
kubectl edit service -n gke-system istio-ingress
```
Fügen Sie externalTrafficPolicy: Local zum spec hinzu, speichern Sie den Editor und beenden Sie ihn.
```
apiVersion: v1
kind: Service
...
spec:
...
  externalTrafficPolicy: Local
```
Öffnen Sie das Deployment istio-ingress zum Bearbeiten:
```
kubectl edit deployment -n gke-system istio-ingress
```

Fügen Sie dem Deployment den folgenden nodeSelector hinzu, speichern Sie den Editor und beenden Sie ihn.

apiVersion: apps/v1
kind: Deployment
...
spec:
  ...
  template:
    ...
    spec:
      ...
      nodeSelector:
          baremetal.cluster.gke.io/lbnode: "true"
...

Jetzt sehen alle Ihre Dienste hinter Ingress einen X-Forwarded-For-Header mit der Client-IP, wie im folgenden Beispiel:

X-Forwarded-For: 21.0.104.4