Version 1.2. Diese Version wird nicht mehr unterstützt, wie in der Supportrichtlinie für Anthos-Versionen beschrieben. Führen Sie ein Upgrade auf eine unterstützte Version durch, um die neuesten Patches und Updates für Sicherheitslücken, Kontakte und Probleme bei Anthos-Clustern in VMware (GKE On-Prem) zu erhalten. Die neueste Version finden Sie hier.

Verfügbare Versionen

Load-Balancing mit Seesaw

Auf dieser Seite wird erläutert, wie Sie den Seesaw-Load-Balancer für einen GKE On-Prem-Cluster konfigurieren.

GKE On-Prem-Cluster können in einem von zwei Load-Balancing-Modi ausgeführt werden: integriert oder manuell. Zur Verwendung des Wechselladers für die Wippe verwenden Sie den manuellen Load-Balancing-Modus .

Allgemeine Schritte für das manuelle Load-Balancing

Führen Sie vor der Konfiguration des Seesaw-Load-Balancing-Moduls die folgenden Schritte aus, die für jede manuelle Load-Balancing-Konfiguration gelten:

IP-Adressen und eine VIP für Seesaw-VMs reservieren

Reservieren Sie zwei IP-Adressen für zwei Seenaw-VMs. Sie können auch eine einzelne VIP für das Paar der Seesaw-VMs reservieren. Alle drei Adressen müssen sich im selben VLAN wie Ihre Clusterknoten befinden.

Seesaw-VMs erstellen

Erstellen Sie zwei saubere VMs in Ihrer vSphere Umgebung, um ein Seesaw-Aktiv-Passiv-Paar auszuführen. Ubuntu 18.04 und höher und Linux Kernel 4.15 werden für die Seesaw-VMs empfohlen, obwohl es auch andere Betriebssystemversionen gibt, die mit Seesaw funktionieren.

Die Anforderungen für die beiden VMs lauten so:

Jede VM hat eine NIC mit dem Namen ens192. Diese NIC wird mit der IP-Adresse der VM konfiguriert.
Jede VM verfügt über eine NIC mit dem Namen "En224". Diese Netzwerkkarte benötigt keine IP-Adresse.
Die VMs müssen sich im selben VLAN wie Ihre Clusterknoten befinden.
Die Portgruppe von enS224 muss Änderungen der MAC-Adresse und gefälschte Übertragungen zulassen. Dies liegt daran, dass die Seesaw-VMs das Virtual Router Redundancy Protocol (VRRP) verwenden. Das bedeutet, dass Seesaw die MAC-Adressen von Netzwerkschnittstellen konfigurieren muss. Insbesondere muss Seesaw die MAC-Adresse auf eine VRRP-MAC-Adresse im Format 00-00-5E-00-01-[VRID] setzen können, wobei [VIRD] eine virtuelle Router-ID für das Seesaw-Paar ist.

Sie können dies in der vSphere-Benutzeroberfläche in den Richtlinieneinstellungen der Portgruppe konfigurieren.

MAC-Adressänderungen und gefälschte Commits zulassen (zum Vergrößern klicken)

Seesaw kompilieren

Führen Sie zum Erstellen der Seesaw-Binärdateien das folgende Skript auf einer Maschine aus, auf der Golang installiert ist:

#!/bin/bash

set -e

DEST=$PWD/seesaw_files
export GOPATH=$DEST/seesaw
SEESAW=$GOPATH/src/github.com/google/seesaw

mkdir -p $GOPATH
cd $GOPATH
sudo apt -y install libnl-3-dev libnl-genl-3-dev

git clone https://github.com/google/seesaw.git $SEESAW

cd $SEESAW
GO111MODULE=on GOOS=linux GOARCH=amd64 make install

cp -r $GOPATH/bin $DEST/
mkdir -p $DEST/cfg
cp etc/seesaw/watchdog.cfg etc/systemd/system/seesaw_watchdog.service $DEST/cfg/

sudo rm -rf $GOPATH

Dadurch wird ein seesaw_files-Verzeichnis generiert, das die Wechseldatenbanken und Konfigurationsdateien enthält. Führen Sie den Befehl tree aus, um die Dateien anzuzeigen:

tree seesaw_files

Die Ausgabe zeigt die generierten Verzeichnisse und Dateien:

seesaw_files/
├── bin
│   ├── seesaw_cli
│   ├── seesaw_ecu
│   ├── seesaw_engine
│   ├── seesaw_ha
│   ├── seesaw_healthcheck
│   ├── seesaw_ncc
│   └── seesaw_watchdog
└── cfg
    ├── seesaw_watchdog.service
    └── watchdog.cfg

2 directories, 9 files

Umgebungsvariablen exportieren

Bevor Sie die Seesaw-VMs konfigurieren, müssen Sie mehrere Umgebungsvariablen exportieren.

Exportieren Sie auf jeder Seesaw-VM die folgenden Umgebungsvariablen:

NODE_IP: Die IP-Adresse der Seesaw-VM.
PEER_IP: Die IP-Adresse der anderen Seesaw-VM.
NODE_NETMASK: Die Länge des Präfixes des CIDR-Bereichs für Ihre Clusterknoten.
VIP: Die VIP, die Sie für das Seesaw-VM-Paar reserviert haben.
VRID: Die ID des virtuellen Routers, die Sie für das Seesaw-Paar verwenden möchten.

Hier ein Beispiel:

export NODE_IP=203.0.113.2
export PEER_IP=203.0.113.3
export NODE_NETMASK=25
export VIP=203.0.113.4
export VRID=128

Seesaw-VMs konfigurieren

Kopieren Sie das Verzeichnis seesaw_files in die beiden Seesaw-VMs.

Führen Sie auf jeder Seesaw-VM im Verzeichnis seesaw_files das folgende Skript aus:

# execute_seesaw.sh
#!/bin/bash
set -e

# Tools
apt -y install ipvsadm libnl-3-dev libnl-genl-3-dev

# Module
modprobe ip_vs
modprobe nf_conntrack_ipv4
modprobe dummy numdummies=1
echo "ip_vs" > /etc/modules-load.d/ip_vs.conf
echo "nf_conntrack_ipv4" > /etc/modules-load.d/nf_conntrack_ipv4.conf
echo "dummy" > /etc/modules-load.d/dummy.conf
echo "options dummy numdummies=1" > /etc/modprobe.d/dummy.conf

# dummy interface
ip link add dummy0 type dummy || true
cat > /etc/systemd/network/10-dummy0.netdev <<EOF
[NetDev]
Name=dummy0
Kind=dummy
EOF

DIR=./seesaw_files

mkdir -p /var/log/seesaw
mkdir -p /etc/seesaw
mkdir -p /usr/local/seesaw
cp $DIR/bin/* /usr/local/seesaw/
chmod a+x /usr/local/seesaw/*
cp $DIR/cfg/watchdog.cfg /etc/seesaw

cat > /etc/seesaw/seesaw.cfg <<EOF
[cluster]
anycast_enabled = false
name = bundled-seesaw-onprem
node_ipv4 = $NODE_IP
peer_ipv4 = $PEER_IP
vip_ipv4 = $VIP
vrid = $VRID

[config_server]
primary = 127.0.0.1

[interface]
node = ens192
lb = ens224
EOF

cat > /etc/seesaw/cluster.pb <<EOF
seesaw_vip: <
  fqdn: "seesaw-vip."
  ipv4: "$VIP/$NODE_NETMASK"
  status: PRODUCTION
>
node: <
  fqdn: "node.$NODE_IP."
  ipv4: "$NODE_IP/$NODE_NETMASK"
>
node: <
  fqdn: "node.$PEER_IP."
  ipv4: "$PEER_IP/$NODE_NETMASK"
>
EOF

cp $DIR/cfg/seesaw_watchdog.service /etc/systemd/system
systemctl --system daemon-reload

Seesaw neukonfigurieren

In der folgenden Konfiguration werden IP-Adressen für Ihre Clusterknoten angegeben. Außerdem werden VIPs für Ihre Steuerungsebenen und Ingress-Controller angegeben. In der vorliegenden Konfiguration gibt die Konfiguration folgende Adressen an:

100.115.222.143 ist der VIP für die Administrator-Steuerungsebene.
100.115.222.144 ist der VIP für den Administratorcluster-Ingress-Controller.
100.115.222.146 ist der VIP für die Nutzer-Steuerungsebene.
100.115.222.145 ist der VIP für den Ingress-Controller des Nutzerclusters.
Die Knotenadressen des Administratorclusters lauten 100.115.222.163, 100.115.222.164, 100.115.222.165 und 100.115.222.166.
Die Knotenadresse des Nutzerclusters lautet 100.115.222.167, 100.115.222.168 und 100.115.222.169.

Bearbeiten Sie die Konfiguration so, dass sie die VIPs und IP-Adressen enthält, die Sie für Ihre Administrator- und Nutzercluster ausgewählt haben. Fügen Sie dann auf jeder Seesaw-VM die Konfiguration an /etc/seesaw/cluster.pb an:

Beachten Sie, dass die Steuerungsebene des Nutzerclusters als Dienst im Administratorcluster implementiert ist. Die Knoten-IP-Adressen unter user-1-control-plane sind also die Adressen der Administratorclusterknoten.

vserver: <
  name: "admin-control-plane"
  entry_address: <
    fqdn: "admin-control-plane"
    ipv4: "100.115.222.143/32"
  >
  rp: "cloudysanfrancisco@gmail.com"
  vserver_entry: <
    protocol: TCP
    port: 443
    scheduler: WLC
    mode: DSR
    healthcheck: <
      type: HTTP
      port: 10256
      mode: PLAIN
      proxy: false
      tls_verify: false
      send: "/healthz"
    >
  >
  backend: <
    host: <
      fqdn: "admin-1"
      ipv4: "100.115.222.163/32"
    >
  >
  backend: <
    host: <
      fqdn: "admin-2"
      ipv4: "100.115.222.164/32"
    >
  >
  backend: <
    host: <
      fqdn: "admin-3"
      ipv4: "100.115.222.165/32"
    >
  >
  backend: <
    host: <
      fqdn: "admin-4"
      ipv4: "100.115.222.166/32"
    >
  >
>
vserver: <
  name: "admin-ingress-controller"
  entry_address: <
    fqdn: "admin-ingress-controller"
    ipv4: "100.115.222.144/32"
  >
  rp: "cloudysanfrancisco@gmail.com"
  vserver_entry: <
    protocol: TCP
    port: 80
    scheduler: WLC
    mode: DSR
    healthcheck: <
      type: HTTP
      port: 10256
      mode: PLAIN
      proxy: false
      tls_verify: false
      send: "/healthz"
    >
  >
  vserver_entry: <
    protocol: TCP
    port: 443
    scheduler: WLC
    mode: DSR
    healthcheck: <
      type: HTTP
      port: 10256
      mode: PLAIN
      proxy: false
      tls_verify: false
      send: "/healthz"
    >
  >
  backend: <
    host: <
      fqdn: "admin-1"
      ipv4: "100.115.222.163/32"
    >
  >
  backend: <
    host: <
      fqdn: "admin-2"
      ipv4: "100.115.222.164/32"
    >
  >
  backend: <
    host: <
      fqdn: "admin-3"
      ipv4: "100.115.222.165/32"
    >
  >
  backend: <
    host: <
      fqdn: "admin-4"
      ipv4: "100.115.222.166/32"
    >
  >
>
vserver: <
  name: "user-1-control-plane"
  entry_address: <
    fqdn: "user-1-control-plane"
    ipv4: "100.115.222.146/32"
  >
  rp: "cloudysanfrancisco@gmail.com"
  vserver_entry: <
    protocol: TCP
    port: 443
    scheduler: WLC
    mode: DSR
    healthcheck: <
      type: HTTP
      port: 10256
      mode: PLAIN
      proxy: false
      tls_verify: false
      send: "/healthz"
    >
  >
  backend: <
    host: <
      fqdn: "admin-1"
      ipv4: "100.115.222.163/32"
    >
  >
  backend: <
    host: <
      fqdn: "admin-2"
      ipv4: "100.115.222.164/32"
    >
  >
  backend: <
    host: <
      fqdn: "admin-3"
      ipv4: "100.115.222.165/32"
    >
  >
  backend: <
    host: <
      fqdn: "admin-4"
      ipv4: "100.115.222.166/32"
    >
  >
>
vserver: <
  name: "user-1-ingress-controller"
  entry_address: <
    fqdn: "user-1-ingress-controller"
    ipv4: "100.115.222.145/32"
  >
  rp: "cloudysanfrancisco@gmail.com"
  vserver_entry: <
    protocol: TCP
    port: 80
    scheduler: WLC
    mode: DSR
    healthcheck: <
      type: HTTP
      port: 10256
      mode: PLAIN
      proxy: false
      tls_verify: false
      send: "/healthz"
    >
  >
  vserver_entry: <
    protocol: TCP
    port: 443
    scheduler: WLC
    mode: DSR
    healthcheck: <
      type: HTTP
      port: 10256
      mode: PLAIN
      proxy: false
      tls_verify: false
      send: "/healthz"
    >
  >
  backend: <
    host: <
      fqdn: "user-1"
      ipv4: "100.115.222.167/32"
    >
  >
  backend: <
    host: <
      fqdn: "user-2"
      ipv4: "100.115.222.168/32"
    >
  >
  backend: <
    host: <
      fqdn: "user-3"
      ipv4: "100.115.222.169/32"
    >
  >
>

Seesaw-Dienst starten

Führen Sie auf jeder Seesaw-VM den folgenden Befehl aus:

systemctl --now enable seesaw_watchdog.service

Seesaw wird jetzt auf beiden Seesaw-VMs ausgeführt. Sie können die Logs unter /var/log/seesaw/ prüfen.

Cluster-Konfigurationsdatei ändern

Bevor Sie einen Cluster erstellen, generieren Sie eine Cluster-Konfigurationsdatei. Füllen Sie die Clusterkonfigurationsdatei wie unter Konfigurationsdatei ändern beschrieben aus.

Setzen Sie insbesondere lbmode auf "Manuell". Füllen Sie auch die Felder manuallbspec und vips unter admincluster und usercluster aus. Beispiel:

admincluster:

  manuallbspec:
    ingresshttpnodeport: 32527
    ingresshttpsnodeport: 30139
    controlplanenodeport: 30968

  vips:
    controlplanevip: "100.115.222.143"
    ingressvip: "100.115.222.144"

usercluster:

  manuallbspec:
    ingresshttpnodeport: 30243
    ingresshttpsnodeport: 30879
    controlplanenodeport: 30562

  vips:
    controlplanevip: "100.115.222.146"
    ingressvip: "100.115.222.145"

lbmode: "Manual"

Bekannte Probleme

Derzeit unterstützt die Validierung des Load-Balancers von gkectl Seesaw nicht und kann Fehler zurückgeben. Wenn Sie Cluster installieren oder aktualisieren, die die Wippe verwenden, übergeben Sie das Flag --skip-validation-load-balancer.

Weitere Informationen finden Sie unter Fehlerbehebung.