Gebündeltes Load-Balancing mit Seesaw

10

Anthos-Cluster auf VMware (GKE On-Prem) können in einem von drei Load-Balancing-Modi ausgeführt werden: integriert, manuell oder gebündelt. In diesem Dokument wird erläutert, wie Sie Anthos-Cluster auf VMware konfigurieren, um den Seesaw-Load-Balancer im gebündelten Modus auszuführen.

Diese Anleitung ist vollständig. Eine kürzere Einführung in die Seesaw-Load-Balancer finden Sie unter Seesaw-Load-Balancer (Kurzanleitung).

Im gebündelten Load-Balancing-Modus stellt Anthos-Cluster auf VMware den Load-Balancer bereit und verwaltet ihn. Sie benötigen keine Lizenz für einen Load-Balancer und die Einrichtung ist einfach.

In diesem Dokument wird gezeigt, wie der Seesaw-Load-Balancer für einen Administratorcluster und einen zugehörigen Nutzercluster konfiguriert wird. Sie können den Seesaw-Load-Balancer auf einer einzelnen VM oder im Hochverfügbarkeitsmodus (High Availability, HA) mit zwei VMs ausführen. Im Hochverfügbarkeitsmodus verwendet der Seesaw-Load-Balancer das Virtual Router Redundancy Protocol (VRRP). Die beiden VMs werden als Master und Sicherung bezeichnet. Jede Seesaw-VM erhält eine virtuelle Router-ID (VRID) Ihrer Wahl.

Beispiel für eine Seesaw-Konfiguration

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

Konfiguration des Seesaw-Load-Balancers im Hochverfügbarkeitsmodus.
Seesaw-Load-Balancer-Konfiguration im Hochverfügbarkeitsmodus (zum Vergrößern klicken)

Das obige Diagramm zeigt zwei Seesaw-VMs für den Administrator- und den Nutzercluster. 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:

  • Die Master-IP-Adresse für das Seesaw-VM-Paar, das den Administratorcluster verarbeiten.

  • VIPs, die für den Kubernetes API-Server und Add-ons des Administratorclusters festgelegt wurden.

network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/admin-cluster-ipblock.yaml"
...

loadBalancer:
  seesaw:
    ipBlockFilePath: "config-folder/admin-seesaw-ipblock.yaml"
    masterIP: 172.16.20.57
  ...

  vips:
    controlPlaneVIP: "172.16.20.70"
    addonsVIP: "172.16.20.71"

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 Nutzercluster-Steuerungsebenenknotens 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

admin-seesaw-ipblock.yaml

Das folgende Beispiel zeigt eine andere IP-Blockdatei. Hier werden zwei IP-Adressen für Seesaw-VMs angegeben, die den Administratorcluster verarbeiten. Dies ist eine separate IP-Blockdatei für Load-Balancer-VMs, nicht für Clusterknoten.

blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    - ip: "172.16.20.60"
      hostname: "admin-seesaw-vm-1"
    - ip: "172.16.20.61"
      hostname: "admin-seesaw-vm-2"

user-cluster.yaml

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

  • Die Master-IP-Adresse für das Seesaw-VM-Paar, das den Nutzercluster verarbeiten.

  • VIPs, die für den Kubernetes API-Server und den Ingress-Dienst im Nutzercluster festgelegt wurden. 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.

network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/user-cluster-ipblock.yaml"
...

loadBalancer:
  seesaw:
    ipBlockFilePath: "config-folder/user-seesaw-ipblock.yaml"
    masterIP: 172.16.40.31
  ...

  vips:
    controlPlaneVIP: "172.16.20.72"
    ingressVIP: "172.16.40.100"

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

user-seesaw-ipblock.yaml

Das folgende Beispiel zeigt eine andere IP-Blockdatei. Hier werden zwei IP-Adressen für Seesaw-VMs angegeben, die den Nutzercluster verarbeiten.

blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.40.1"
    ips:
    - ip: "172.16.40.29"
      hostname: "user-seesaw-vm-1"
    - ip: "172.16.40.30"
      hostname: "user-seesaw-vm-2"

Portgruppen

In der folgenden Tabelle werden die Konfiguration der Netzwerkschnittstellen der einzelnen Seesaw-VMs und ihre verbundenen Portgruppen beschrieben, wie im vorherigen Diagramm dargestellt.

Seesaw-VMs Netzwerkschnittstelle Konfiguration der Netzwerkschnittstelle Verbundene Portgruppe
Master network-interface-1 VIPs Load-Balancer
network-interface-2 IP-Adresse, die aus der IP-Blockdatei für Seesaw-VMs übernommen wurde cluster-node
Back-up network-interface-1 Keine Konfiguration Load-Balancer
network-interface-2 IP-Adresse, die aus der IP-Blockdatei für Seesaw-VMs übernommen wurde cluster-node

Die Clusterknoten sind auch mit der cluster-node-Portgruppe verbunden.

Wie in der vorherigen Tabelle gezeigt, hat jede Seesaw-VM für die Administrator- und Nutzercluster zwei Netzwerkschnittstellen. Für jede Seesaw-VM sind die beiden Netzwerkschnittstellen mit zwei separaten Portgruppen verbunden:

  • Load-Balancer-Portgruppe

  • Cluster-Node-Portgruppe

Die beiden Portgruppen eines Clusters befinden sich im selben VLAN für diesen Cluster.

Seesaw-Load-Balancer einrichten

Das obige Diagramm zeigt die empfohlene Netzwerkkonfiguration für den Seesaw-Load-Balancing. Bei der Planung Ihrer eigenen Konfiguration empfehlen wir dringend, für den gebündelten Load-Balancing-Modus vSphere 6.7 oder höher und Virtual Distributed Switch (VDS) 6.6 oder höher zu verwenden.

Wenn Sie möchten, können Sie auch ältere Versionen verwenden, die Installation ist dann jedoch weniger sicher. Die verbleibenden Abschnitte in diesem Thema enthalten weitere Informationen zu den Sicherheitsvorteilen der Verwendung von vspex 6.7+ und VDS 6.6+.

VLANs planen

Beim gebündelten Load-Balancing-Modus empfehlen wir Ihnen dringend, dass die Cluster in separaten VLANs enthalten sind.

Wenn Ihr Administratorcluster sich in einem eigenen VLAN befindet, wird der Traffic der Steuerungsebene vom Traffic der Datenebene getrennt. Diese Trennung schützt die Steuerungsebenen von Administratorcluster und Nutzerclustern vor unbeabsichtigten Konfigurationsfehlern. Solche Fehler können beispielsweise zu Problemen wie einem Übertragungssturm aufgrund von Ebene-2-Schleifen im selben VLAN führen, oder zu in Konflikt stehenden IP-Adressen, die die gewünschte Trennung zwischen der Datenebene und der Steuerungsebene aufheben.

VM-Ressourcen bereitstellen

Stellen Sie für die VMs, auf denen Ihr Seesaw-Load-Balancer ausgeführt wird, CPU- und Arbeitsspeicherressourcen entsprechend dem erwarteten Netzwerktraffic bereit.

Der gebündelte Seesaw-Load-Balancer ist nicht speicherintensiv und kann in VMs mit 1 GB Arbeitsspeicher ausgeführt werden. Die CPU-Anforderung steigt jedoch, wenn die Netzwerkpaketrate zunimmt.

Die folgende Tabelle enthält Richtlinien für Speicher, CPU und Arbeitsspeicher für die Bereitstellung von Seesaw-VMs. Da die Paketrate keine typische Messung der Netzwerkleistung darstellt, zeigt die Tabelle auch Richtlinien für die maximale Anzahl aktiver Netzwerkverbindungen. Es wird angenommen, dass eine VM mit einer 10-Gbit/s-Verbindung und CPUs mit weniger als 70 % Kapazität laufen.

Wenn der Seesaw-Load-Balancer im Hochverfügbarkeitsmodus ausgeführt wird, wird ein (Master, Backup)-Paar verwendet. Dadurch wird der gesamte Traffic über eine einzelne VM geleitet. Da die tatsächlichen Anwendungsfälle variieren, müssen diese Richtlinien auf der Grundlage Ihres tatsächlichen Traffics angepasst werden. Überwachen Sie Ihre CPU- und Paketratenmesswerte, um die erforderlichen Änderungen zu ermitteln.

Informationen zum Ändern der CPU und des Arbeitsspeichers für Ihre Seesaw-VMs finden Sie unter Load-Balancer aktualisieren. Sie können dieselbe Version des Load-Balancers verwenden und die Anzahl der CPUs und die Arbeitsspeicherzuweisung ändern.

Für kleine Administratorcluster empfehlen wir 2 CPUs, für große Administratorcluster 4 CPUs.

Speicher CPU Speicher Paketrate (pps) Maximale Anzahl aktiver Verbindungen
20 GB 1 (Nicht-Produktion) 1 GB 250k 100
20 GB 2 3 GB 450k 300
20 GB 4 3 GB 850k 6.000
20 GB 6 3 GB 1,000k 10.000

VIPs und IP-Adressen reservieren

VIPs

Unabhängig vom ausgewählten Load-Balancing-Modus müssen Sie mehrere virtuelle IP-Adressen (VIPs) reservieren, die Sie für das Load-Balancing verwenden möchten. Mit diesen VIPs können externe Clients Ihre Kubernetes API-Server, Ihre Dienste für eingehenden Traffic und Ihre Add-on-Dienste erreichen.

Überlegen Sie auch, wie viele Dienste vom Typ LoadBalancer wahrscheinlich jeweils in einem bestimmten Nutzercluster aktiv sind, und reservieren Sie genügend VIPs für diese Dienste. Wenn Sie Dienste vom Typ LoadBalancer später erstellen, konfiguriert Anthos-Cluster auf VMware automatisch die Dienst-VIPs auf dem Load-Balancer.

Knoten-IP-Adressen

Im gebündelten Load-Balancing-Modus können Sie statische IP-Adressen für Ihre Clusterknoten angeben oder Ihre Clusterknoten können die IP-Adressen von einem DHCP-Server abrufen.

Wenn Ihre Clusterknoten statische IP-Adressen haben sollen, legen Sie genügend Adressen für die Knoten im Administratorcluster und die Knoten in allen Nutzerclustern fest, die Sie erstellen möchten. Legen Sie außerdem eine zusätzliche IP-Adresse pro Cluster zur Verwendung während des Clusterupgrades fest. Informationen darüber, wie viele Knoten-IP-Adressen Sie reservieren können, erhalten Sie unter Administratorcluster erstellen.

IP-Adressen für Seesaw-VMs

Legen Sie als Nächstes für jeden Cluster, Administrator und Nutzer IP-Adressen für die VMs fest, auf denen Ihre Seesaw-Load-Balancer ausgeführt werden. Die Anzahl der Adressen, die Sie reservieren, hängt davon ab, ob Sie Hochverfügbarkeits-Seesaw-Load-Balancer (HA) oder Nicht-HA-Seesaw-Load-Balancer erstellen möchten.

Master-IP-Adressen

Legen Sie neben den IP-Adressen für die Seesaw-VMs auch eine einzelne Master-IP-Adresse für das Seesaw-VM-Paar pro Cluster fest.

Konfiguration ohne Hochverfügbarkeit (HA, High Availability)

Wenn Ihre Einrichtung keine HA-Konfiguration ist:

  • Reservieren Sie für den Administratorcluster eine IP-Adresse für eine Seesaw-VM und eine Master-IP-Adresse für den Seesaw-Load-Balancer. Beide Adressen müssen sich im selben VLAN wie die Knoten des Administratorclusters befinden.

  • Reservieren Sie für Ihren Nutzercluster eine IP-Adresse für eine Seesaw-VM und eine Master-IP-Adresse für den Seesaw-Load-Balancer. Beide Adressen müssen sich im selben VLAN befinden wie die Nutzerclusterknoten.

Portgruppen planen

Im obigen Diagramm wurden die zwei Portgruppen beschrieben, die in einer HA-Konfiguration verwendet werden, und deren Verbindungen zu den Netzwerkschnittstellen auf den Seesaw-VMs. Entscheiden Sie für einzelne Seesaw-VMs, ob die beiden Netzwerkschnittstellen mit derselben vSphere-Portgruppe oder mit separaten Portgruppen verbunden werden sollen. Wenn die Portgruppen getrennt sind, müssen sie sich im selben VLAN befinden. Es wird dringend empfohlen, zwei separate Portgruppen zu nutzen.

IP-Blockdateien erstellen

Geben Sie für jeden Cluster, Administrator und Nutzer die Adressen an, die Sie für Ihre Seesaw-VMs in einer IP-Blockdatei ausgewählt haben. Wenn Sie für Ihre Clusterknoten statische IP-Adressen verwenden möchten, müssen Sie für diese Adressen separate IP-Blockdateien erstellen.

Ihre Konfigurationsdateien ausfüllen

Bereiten Sie eine Konfigurationsdatei für Ihren Administratorcluster und eine weitere Konfigurationsdatei für Ihren Nutzercluster vor.

Legen Sie in der Konfigurationsdatei für einen bestimmten Cluster loadBalancer.kind auf "Seesaw" fest.

Füllen Sie unter loadBalancer den Abschnitt seesaw aus:

loadBalancer:
  kind: Seesaw
  seesaw:

Informationen zum Ausfüllen des Abschnitts seesaw einer Clusterkonfigurationsdatei finden Sie unter loadbalancer.seesaw (Administratorcluster) oder loadbalancer.seesaw (Nutzercluster).

Legen Sie in der Konfigurationsdatei des Administratorclusters Folgendes fest:

  • VIP für den Kubernetes API-Server des Administratorclusters
  • VIPs für die Add-ons des Administratorclusters
  • Die Master-IP-Adresse für das Seesaw-VM-Paar, das den Administratorcluster verarbeiten.

Diese VIPs müssen sich im Subnetz des Administratorclusters befinden.

Legen Sie in der Konfigurationsdatei des Nutzerclusters Folgendes fest:

  • VIP für den Kubernetes API-Server des Nutzerclusters (muss sich im Subnetz des Administratorclusters befinden)
  • Ingress-VIP im Nutzercluster
  • Die Master-IP-Adresse für das Seesaw-VM-Paar, das den Nutzercluster verarbeiten.

Die letzten beiden Adressen in der vorherigen Liste müssen sich im Subnetz des Nutzerclusters befinden.

MAC-Lernen oder promiskuitiver Modus (nur HA) aktivieren

Wenn Sie einen Nicht-HA-Seesaw-Load-Balancer einrichten, können Sie diesen Abschnitt überspringen.

Wenn Sie loadBalancer.seesaw.disableVRRPMAC auf "true" gesetzt haben, können Sie diesen Abschnitt überspringen.

Wenn Sie einen HA-Seesaw-Load-Balancer einrichten undloadBalancer.seesaw.disableVRRPMAC auf false gesetzt haben, müssen Sie eine Kombination aus MAC-Lernen, gefälschten Übertragungen und promiskuitivem Modus in Ihrer Load-Balancer-Portgruppe aktivieren.

Wie Sie diese Funktionen aktivieren, hängt vom verwendeten Schalter ab:

Typ wechselnFunktionen aktivierenAuswirkungen auf die Sicherheit
vSphere 7.0 VDS Bei vSphere 7.0 mit HA müssen Sie für loadBalancer.seesaw.disableVRRPMAC den Wert true festlegen. MAC-Lernen wird nicht unterstützt.
vSphere 6.7 mit VDS 6.6

Aktivieren Sie MAC-Lernen und gefälschte Übertragungen für den Load-Balancer mit folgendem Befehl: gkectl prepare network --config [CONFIG_FILE], wobei [CONFIG_FILE] der Pfad Ihrer Clusterkonfigurationsdatei ist. Dafür benötigen Sie die Berechtigung dvPort group.Modify.

Minimal. Wenn die Portgruppe des Load-Balancers nur mit Ihren Seesaw-VMs verbunden ist, können Sie das MAC-Lernen auf Ihre vertrauenswürdigen Seesaw-VMs beschränken.

vSphere 6.5 oder

vSphere Version 6.7 mit einer VDS-Version vor 6.6

Aktivieren Sie den promiskuitiven Modus und gefälschte Übertragungen für die Portgruppe des Load-Balancers. Verwenden Sie auf der Portgruppenseite auf dem Tab Networking (Netzwerk) die vSphere Benutzeroberfläche: Edit Settings -> Security (Einstellungen bearbeiten -> Sicherheit). Alle VMs in der Portgruppe des Load-Balancers befinden sich im promiskuitiven Modus. So kann jede VM in der Portgruppe des Load-Balancers den gesamten Traffic sehen. Wenn die Portgruppe des Load-Balancers nur mit Ihren Seesaw-VMs verbunden ist, können nur die VMs den gesamten Traffic sehen.
Logischer NSX-T-Schalter Aktivieren Sie MAC-Lernen für den logischen Switch. vSphere unterstützt nicht das Erstellen von zwei logischen Switches in derselben Ebene-2-Domain. Die Seesaw-VMs und die Clusterknoten müssen sich also auf demselben logischen Switch befinden. Dies bedeutet, dass MAC-Lernen für alle Clusterknoten aktiviert ist. Ein Angreifer kann möglicherweise einen MAC-Spoof durch das Ausführen autorisierter Pods im Cluster erreichen.
vSphere-Standard-Switch Aktivieren Sie den promiskuitiven Modus und gefälschte Übertragungen für die Portgruppe des Load-Balancers. Verwenden Sie auf jedem ESXI-Host die vSphere-Benutzeroberfläche: Configure -> Virtual switches -> Standard Switch -> Edit Setting on the port group -> Security (Konfigurieren -> Virtuelle Switches -> Standard-Switch -> Einstellung für die Portgruppe bearbeiten -> Sicherheit). Alle VMs in der Portgruppe des Load-Balancers befinden sich im promiskuitiven Modus. So kann jede VM in der Portgruppe des Load-Balancers den gesamten Traffic sehen. Wenn die Portgruppe des Load-Balancers nur mit Ihren Seesaw-VMs verbunden ist, können nur die VMs den gesamten Traffic sehen.

Füllen Sie die Konfigurationsdatei des Administratorclusters aus.

Folgen Sie der Anleitung unter Administratorcluster erstellen, um das Ausfüllen der Konfigurationsdatei des Administratorclusters abzuschließen.

Preflight-Prüfungen ausführen

Führen Sie Preflight-Prüfungen für die Konfigurationsdatei des Administratorclusters aus:

gkectl check-config --config ADMIN_CLUSTER_CONFIG

Ersetzen Sie ADMIN_CLUSTER_CONFIG durch den Pfad Ihrer Konfigurationsdatei für den Administratorcluster.

Betriebssystem-Images hochladen

Laden Sie Betriebssystem-Images in Ihre vSphere-Umgebung hoch:

gkectl prepare --config ADMIN_CLUSTER_CONFIG

Load-Balancer für Ihren Administratorcluster erstellen

gkectl create loadbalancer --config [ADMIN_CLUSTER_CONFIG]

Erstellen Sie Ihren Administratorcluster:

Folgen Sie der Anleitung unter Administratorcluster erstellen, um Ihren Administratorcluster zu erstellen.

Füllen Sie die Konfigurationsdateien des Nutzerclusters aus.

Folgen Sie der Anleitung unter Nutzercluster erstellen, um das Ausfüllen der Konfigurationsdatei des Nutzerclusters abzuschließen.

Preflight-Prüfungen ausführen

Führen Sie Preflight-Prüfungen für die Konfigurationsdatei des Nutzerclusters aus:

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTERE_KUBECONFIG: Pfad der Datei "kubeconfig" Ihres Administratorclusters

  • USER_CLUSTER_CONFIG: Pfad Ihrer Nutzercluster-Konfigurationsdatei

Betriebssystem-Images hochladen

Laden Sie Betriebssystem-Images in Ihre vSphere-Umgebung hoch:

gkectl prepare --config USER_CLUSTER_CONFIG

Load-Balancer für Ihren Nutzercluster erstellen

Load-Balancer für Ihren Nutzercluster erstellen:

gkectl create loadbalancer --config USER_CLUSTER_CONFIG

Erstellen Sie den Nutzercluster

Folgen Sie der Anleitung unter Nutzercluster erstellen, um Ihren Nutzercluster zu erstellen.

Leistungs- und Lasttests

Der Download-Durchsatz Ihrer Anwendung wird linear mit der Anzahl der Back-Ends skaliert. Dies liegt daran, dass die Back-Ends mithilfe von Direct Server Return Antworten direkt an die Clients senden und dabei den Load-Balancer umgehen.

Im Gegensatz dazu ist der Uploaddurchsatz Ihrer Anwendung durch die Kapazität der einen Seesaw-VM begrenzt, die das Load-Balancing ausführt.

Anwendungen variieren in der benötigten CPU- und Arbeitsspeichermenge. Daher ist es äußerst wichtig, dass Sie einen Lasttest ausführen, bevor Sie mit der Bereitstellung einer großen Anzahl von Clients beginnen.

Tests haben ergeben, dass eine einzelne Seesaw-VM mit 6 CPUs und 3 GB Arbeitsspeicher 10 GB/s (Leitungsrate) zum Hochladen von Datenverkehr mit 10 K gleichzeitigen TCP-Verbindungen verarbeiten kann. Es ist jedoch wichtig, dass Sie einen eigenen Lasttest ausführen, wenn Sie eine große Anzahl gleichzeitiger TCP-Verbindungen unterstützen möchten.

Skalierungslimits

Beim gebündelten Load-Balancing sind die Skalierungsmöglichkeiten Ihres Clusters begrenzt. Die Anzahl der Knoten in Ihrem Cluster ist begrenzt. Die Anzahl der Dienste, die auf Ihrem Load-Balancer konfiguriert werden können, ist begrenzt. Außerdem gibt es eine Beschränkung für Systemdiagnosen. Die Anzahl der Systemdiagnosen hängt sowohl von der Anzahl der Knoten als auch von der Anzahl der Dienste ab.

Ab Version 1.3.1 hängt die Anzahl der Systemdiagnosen von der Anzahl der Knoten und der Anzahl der lokalen Dienste mit Traffic ab. Ein lokaler Trafficdienst ist ein Dienst, dessen externalTrafficPolicy auf "Local" gesetzt ist.

Version 1.3.0Version 1.3.1 und höher
Maximale Dienste (S)100500
Maximale Knoten (N)100100
Maximale Systemdiagnosen S * N <= 10.000N + L * N <= 10.000, wobei L die Anzahl der lokalen Trafficdienste ist

Beispiel: In Version 1.3.1 gehen wir davon aus, dass Sie 100 Knoten und 99 lokale Dienste für Traffic haben. Dann beträgt die Anzahl der Systemdiagnosen 100 + 99 * 100 = 10.000, was innerhalb des Limits von 10.000 liegt.

Load-Balancer für einen Cluster aktualisieren

Beim Upgrade eines Clusters wird der Load-Balancer automatisch aktualisiert. Sie müssen keinen separaten Befehl ausführen, um den Load-Balancer zu aktualisieren.

Wenn Sie möchten, können Sie die CPUs oder den Arbeitsspeicher Ihrer Seesaw-VMs aktualisieren, ohne ein vollständiges Upgrade durchzuführen. Bearbeiten Sie zuerst die Werte cpus und memoryMB in Ihrer Clusterkonfigurationsdatei. Beispiel:

apiVersion: v1
bundlePath:
loadBalancer:
  kind: Seesaw
  seesaw:
    cpus: 3
    memoryMB: 3072

So aktualisieren Sie den Load-Balancer für einen Administratorcluster:

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG --admin-cluster
So aktualisieren Sie den Load-Balancer für einen Nutzercluster:
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_KUBECONFIG: Pfad der Datei "kubeconfig" Ihres Administratorclusters

  • ADMIN_CLUSTER_CONFIG: Pfad Ihrer Konfigurationsdatei für den Administratorcluster.

  • USER_CLUSTER_CONFIG: Pfad Ihrer Nutzercluster-Konfigurationsdatei

Seesaw-Logs ansehen

Der gebündelte Seesaw-Load-Balancer speichert Logdateien in den Seesaw-VMs in /var/log/seesaw/. Die wichtigste Logdatei ist seesaw_engine.INFO.

Bei v1.6 werden Logs, sofern Stackdriver aktiviert ist, auch in Cloud hochgeladen. Sie können sie unter der Ressource "anthos_l4lb" ansehen. Zum Deaktivieren des Log-Uploads können Sie eine SSH-Verbindung zur VM herstellen und folgenden Befehl ausführen:

sudo systemctl disable --now docker.fluent-bit.service

Informationen zu Ihren Seesaw-VMs ansehen

Sie können Informationen über Ihre Seesaw-VMs für einen Cluster von der benutzerdefinierten Ressource "SeesawGroup" abrufen.

Sehen Sie sich die benutzerdefinierte Ressource "SeesawGroup" für einen Cluster an:

kubectl --kubeconfig CLUSTER_KUBECONFIG get seesawgroups -n kube-system -o yaml

Ersetzen Sie CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Clusters.

Die Ausgabe enthält das Feld isReady, das angibt, ob die VMs für die Verarbeitung des Traffics bereit sind. Die Ausgabe zeigt auch die Namen und IP-Adressen der Seesaw-VMs an und welche VM die primäre ist:

apiVersion: seesaw.gke.io/v1alpha1
kind: SeesawGroup
metadata:
  ...
  name: seesaw-for-cluster-1
  namespace: kube-system
  ...
spec: {}
status:
  machines:
  - hostname: cluster-1-seesaw-1
    ip: 172.16.20.18
    isReady: true
    lastCheckTime: "2020-02-25T00:47:37Z"
    role: Master
  - hostname: cluster-1-seesaw-2
    ip: 172.16.20.19
    isReady: true
    lastCheckTime: "2020-02-25T00:47:37Z"
    role: Backup

Seesaw-Messwerte ansehen

Der gebündelte Seesaw-Load-Balancer liefert die folgenden Messwerte:

  • Durchsatz pro Dienst oder Knoten
  • Paketrate pro Dienst oder Knoten
  • Aktive Verbindungen pro Dienst oder Knoten
  • CPU- und Arbeitsspeichernutzung
  • Anzahl fehlerfreier Back-End-Pods pro Dienst
  • Welche VM ist die primäre und welche dient als Sicherung
  • Betriebszeit

Ab Version v1.6 werden diese Messwerte mit Stackdriver in die Cloud hochgeladen. Sie können sie unter der Monitoringressource von "anthos_l4lb" ansehen.

Sie können auch alle Monitoring- und Dashboard-Lösungen Ihrer Wahl verwenden, solange sie das Prometheus-Format unterstützen.

Load-Balancer löschen

Wenn Sie einen Cluster löschen, der gebündeltes Load-Balancing verwendet, sollten Sie auch die Seesaw-VMs für diesen Cluster löschen. Löschen Sie dazu die Seesaw-VMs in der vSphere-Benutzeroberfläche.

Alternativ können Sie gkectl delete loadbalancer ausführen.

Für einen Administratorcluster:

gkectl delete loadbalancer --config ADMIN_CLUSTER_CONFIG --seesaw-group-file GROUP_FILE

Für einen Nutzercluster:

gkectl delete loadbalancer  --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG \
    --seesaw-group-file GROUP_FILE

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_CONFIG: der Pfad Ihrer Administratorcluster-Konfigurationsdatei.

  • USER_CLUSTER_CONFIG: der Pfad Ihrer Nutzerclusterkonfigurationsdatei.

  • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

  • GROUP_FILE: der Pfad der Seesaw-Gruppendatei. Der Name der Gruppendatei hat dieses Format
    seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml.
    Beispiel: seesaw-for-gke-admin-12345.yaml.

Zustandslose verteilte NSX-T-Firewallrichtlinien zur Verwendung mit Seesaw-Load-Balancer konfigurieren

Wenn Ihre Konfiguration die zustandsorientierte verteilte NSX-T-Firewall verwendet und Sie auch den Seesaw-Load-Balancer verwenden möchten, haben Sie mehrere Optionen. Wählen Sie die Option aus, die am besten zu Ihrer Umgebung passt.

Checkliste für die NSX-Konfiguration

Bevor Sie eine der beschriebenen Abhilfeoptionen implementieren, prüfen Sie, ob die folgende NSX DFW-Konfiguration vorhanden ist:

  • Zustandsorientierte NSX-DFW-Abschnitte sind die Standardkonfiguration. Das ist wahrscheinlich das, was Sie in Ihrer Umgebung haben. Siehe Abschnitte und Firewallregeln.

  • Das Einfügen von Diensten wird manchmal mit der NSX DFW verwendet, um Dienstverkettungen und L7-Prüfungen als Teil der Partnerintegration bereitzustellen. Richtlinien für das Einfügen von Diensten sind ebenfalls standardmäßig zustandsorientiert. Lesen Sie die folgenden Informationen, um zu bestätigen, dass diese Integration in Ihrer Umgebung aktiviert ist.

Option 1: Zustandslose verteilte Firewallrichtlinie für Seesaw-Load-Balancer erstellen

Mit dieser Option können Sie die verteilte Firewall in der Umgebung aktiviert lassen und die Anthos-Infrastruktur, insbesondere die Seesaw-Load-Balancer, einer zustandslosen Richtlinie zuordnen. Berücksichtigen Sie die Unterschiede zwischen zustandslosen und zustandsorientierten Firewalls, um sicherzustellen, dass Sie den für Ihre Umgebung am besten geeigneten Typ auswählen. Weitere Informationen finden Sie in der VMware-Dokumentation unter Firewallregel in Manager-Modus hinzufügen – Verfahren 6.

So erstellen Sie eine zustandslose Firewallrichtlinie:

  1. Gehen Sie zu Inventar > Tags. Erstellen Sie ein Tag mit dem Namen seesaw.

  2. Rufen Sie Inventar > Gruppen auf. Erstellen Sie eine Gruppe mit dem Namen Seesaw.

  3. Konfigurieren Sie die Seesaw-Set-Mitglieder.

    • Klicken Sie auf Mitglieder festlegen. Konfigurieren Sie die Mitglieder mit Mitgliedschaftskriterien basierend auf dem von Ihnen erstellten seesaw-Tag. Obwohl die Verwendung von NSX-Tags generell als Best Practice von VMware betrachtet wird, erfordert diese Methode eine Automatisierung, um sie jedes Mal festzulegen, wenn sich die Umgebung ändert, z. B. wenn Sie die Anthos-Cluster in Ihrer Umgebung aktualisieren oder ihre Größe anpassen. In diesem Fall funktioniert eine Richtlinie, die auf einigen anderen Mitgliedschaftskriterien basiert, möglicherweise besser. Sie können auch andere dynamische Mitgliedschaftsoptionen verwenden, z. B. VM-Namen (einschließlich regulärer Ausdrücke), Segmente und Segmentports. Weitere Informationen zu Gruppenmitgliedschaftskriterien finden Sie unter Gruppe hinzufügen.
  4. Gehen Sie zu Sicherheit > Verteilte Firewall. Erstellen Sie einen Abschnitt namens Anthos.

  5. Klicken Sie rechts oben auf das Zahnradsymbol und stellen Sie den Schieberegler Zustandsorientiert auf Nein ein.

  6. Fügen Sie dem Abschnitt Regeln hinzu. Es wird empfohlen, mindestens zwei symmetrische Regeln hinzuzufügen. Beispiel:

    Source: Seesaw Group, Destination: Any, Applied to: Seesaw Group
    Source: Any, Destination: Seesaw Group, Applied to: Seesaw Group
    

  7. Veröffentlichen Sie die Änderungen und prüfen Sie die Vorgänge.

Der zustandslose Abschnitt muss in die NSX DFW-Tabelle eingefügt werden, sodass er Vorrang vor anderen Abschnitten hat, die denselben Traffic möglicherweise zustandsorientiert zulassen, sodass die zustandslosen Regeln maskiert werden. Achten Sie darauf, dass der zustandslose Abschnitt am spezifischsten ist und anderen Richtlinien vorangestellt wird, die möglicherweise eine Überschneidung verursachen.

Obwohl dies nicht obligatorisch ist, können Sie eine Gruppe mit allen Anthos-VMs erstellen, die ein grobes Mitgliedschaftskriterien wie das Segment-Tag verwendet. Das bedeutet, dass alle VMs, die mit einem bestimmten NSX-Netzwerk verbunden sind, in der Gruppe enthalten sind. Sie können diese Gruppe dann in Ihrer zustandslosen Richtlinie verwenden.

Option 2: Seesaw-VMs zur Ausschlussliste für verteilte Firewalls hinzufügen

Mit dieser Option können Sie VMs vollständig von der verteilten Firewall-Prüfung ausschließen, ohne den NSX DFW zu deaktivieren. Weitere Informationen finden Sie unter Firewall-Ausschlussliste verwalten.

  1. Gehen Sie zu Sicherheit > Verteilte Firewall. Wählen Sie Aktionen > Ausschlussliste aus.

  2. Wählen Sie die Seesaw-Gruppe oder die Gruppe aus, die alle Anthos-VMs enthält.

Problembehebung

SSH-Verbindung zu einer Seesaw-VM herstellen

Gelegentlich möchten Sie möglicherweise eine SSH-Verbindung zu einer Seesaw-VM zur Fehlerbehebung oder Fehlerbehebung herstellen.

SSH-Schlüssel abrufen

Wenn Sie den Cluster bereits erstellt haben, führen Sie die folgenden Schritte aus, um den SSH-Schlüssel abzurufen:

  1. Rufen Sie das Secret seesaw-ssh aus dem Cluster ab. Rufen Sie den SSH-Schlüssel des Secret ab und führen Sie eine Base64-Decodierung durch. Speichern Sie den decodierten Schlüssel in einer temporären Datei:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get -n  kube-system secret seesaw-ssh -o \
    jsonpath='{@.data.seesaw_ssh}' | base64 -d | base64 -d > /tmp/seesaw-ssh-key
    

    Ersetzen Sie CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Clusters.

  2. Legen Sie die entsprechenden Berechtigungen für die Schlüsseldatei fest:

    chmod 0600 /tmp/seesaw-ssh-key

    Wenn Sie den Cluster bereits erstellt haben, führen Sie die folgenden Schritte aus, um den SSH-Schlüssel abzurufen:

  3. Suchen Sie die Datei mit dem Namen seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml.

    Die Datei wird als Gruppendatei bezeichnet und befindet sich neben config.yaml.

    Außerdem wird mit gkectl create loadbalancer der Speicherort der Gruppendatei ausgegeben.

  4. Ermitteln Sie in der Datei den Wert credentials.ssh.privateKey und führen Sie eine base64-Decodierung durch. Speichern Sie den decodierten Schlüssel in einer temporären Datei:

    cat seesaw-for-CLUSTER_NAME-IDENTIFIER.yaml  | grep privatekey | sed 's/    privatekey: //g' \
    | base64 -d > /tmp/seesaw-ssh-key
    
  5. Legen Sie die entsprechenden Berechtigungen für die Schlüsseldatei fest:

    chmod 0600 /tmp/seesaw-ssh-key
    

Jetzt können Sie eine SSH-Verbindung zur Seesaw-VM herstellen:

ssh -i /tmp/seesaw-ssh-key ubuntu@SEESAW_IP

Ersetzen Sie SEESAW_IP durch die IP-Adresse der Seesaw-VM.

Snapshots abrufen

Sie können Snapshots für Seesaw-VMs mit dem Befehl gkectl diagnose snapshot zusammen mit dem Flag --scenario erfassen.

Wenn Sie --scenario auf all oder all-with-logs setzen, enthält die Ausgabe Seesaw-Snapshots zusammen mit anderen Snapshots.

Wenn Sie --scenario auf seesaw setzen, enthält die Ausgabe nur Seesaw-Snapshots.

Beispiele:

gkectl diagnose snapshot --kubeconfig ADMIN_CLUSTER_KUBECONFIG --scenario seesaw

gkectl diagnose snapshot --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster-name CLUSTER_NAME --scenario seesaw

gkectl diagnose snapshot --seesaw-group-file GROUP_FILE --scenario seesaw

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

  • GROUP_FILE: der Pfad der Gruppendatei für den Cluster.

Seesaw-VM aus fehlerhaftem Zustand neu erstellen

Wenn eine Seesaw-VM versehentlich gelöscht wird, können Sie die VM mit dem Befehl gkectl upgrade loadbalancer mit den Flags --no-diff und --force neu erstellen. Dadurch werden alle Seesaw-VMs in Ihrem Cluster unabhängig vom Existenz- oder Systemstatus neu erstellt. Wenn sich der Load-Balancer im Hochverfügbarkeitsmodus befindet und nur eine von zwei VMs gelöscht wird, werden mit diesem Befehl beide VMs neu erstellt.

Führen Sie beispielsweise den folgenden Befehl aus, um den Seesaw-Load-Balancer im Administratorcluster neu zu erstellen:

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff --force

Führen Sie den folgenden Befehl aus, um den Seesaw-Load-Balancer im Nutzercluster neu zu erstellen:

gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG --no-diff --force

Ersetzen Sie Folgendes:

  • ADMIN_CLUSTER_KUBECONFIG: Pfad der Datei "kubeconfig" Ihres Administratorclusters

  • ADMIN_CLUSTER_CONFIG: Pfad Ihrer Konfigurationsdatei für den Administratorcluster.

  • USER_CLUSTER_CONFIG: Pfad Ihrer Nutzercluster-Konfigurationsdatei

Bekannte Probleme

Cisco ACI funktioniert nicht mit Direct Server Return (DSR)

Seesaw wird im DSR-Modus ausgeführt und funktioniert aufgrund des IP-Lernens auf Datenebene standardmäßig nicht in Cisco ACI. Eine mögliche Problemumgehung über die Anwendungs-Endpunktgruppe finden Sie hier.

Citrix Netscaler funktioniert nicht mit Direct Server Return (DSR)

Wenn Sie den Netscaler-Load-Balancer vor Seesaw ausführen, muss die MAC-basierte Weiterleitung (MBF) deaktiviert werden. Weitere Informationen finden Sie in der Citrix-Dokumentation

Das Upgrade des Seesaw-Load-Balancers funktioniert in einigen Fällen nicht

Wenn Sie versuchen, einen Cluster von 1.8.0 zu aktualisieren oder gkectl upgrade loadbalancer verwenden, um einige Parameter Ihres Seesaw-Load-Balancers in der Version 1.8.0 zu aktualisieren, funktioniert dies weder im DHCP- noch im IPAM-Modus. Warten Sie auf eine angekündigte Lösung in einer künftigen Version, bevor Sie ein Upgrade ausführen.