Version 1.4. 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

Gebündeltes Load-Balancing mit Seesaw

GKE On-Prem kann in einem von drei Load-Balancing-Modi ausgeführt werden: integriert, manuell oder gebündelt. In diesem Thema erfahren Sie, wie Sie GKE lokal für die Ausführung im gebündelten Load-Balancing-Modus konfigurieren.

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

Der kombinierte Load Balancer, den GKE vor Ort bereitstellt, ist der Seesaw-Load-Balancer.

Vorteile des gebündelten Load-Balancing-Modus

Der gebündelte Load-Balancing-Modus bietet gegenüber dem manuellen Load-Balancing-Modus folgende Vorteile:

Ein einzelnes Team kann sowohl die Clustererstellung als auch die Konfiguration des Load-Balancing-Modus übernehmen. Ein Clusteradministrationsteam wäre beispielsweise nicht auf ein separates Netzwerkteam angewiesen, das den Load-Balancer vorzeitig akquirieren, ausführen und konfigurieren könnte.
GKE On-Prem konfiguriert virtuelle IP-Adressen (VIPs) automatisch auf dem Load-Balancer. Beim Erstellen des Clusters konfiguriert GKE On-Prem den Load-Balancer mit VIPs für den Kubernetes API-Server, den Ingress-Dienst und die Cluster-Add-ons. Wenn Clients Dienste vom Typ LoadBalancer erstellen, konfiguriert GKE On-Prem die Dienst-VIPs auf dem Load-Balancer.
Abhängigkeiten zwischen Organisationen, Gruppen und Administratoren werden reduziert. Insbesondere ist die Gruppe, die einen Cluster verwaltet, weniger von der Gruppe abhängig, die das Netzwerk verwaltet.

Empfohlene Versionen

Wir empfehlen Ihnen dringend, für den gebündelten Load-Balancing-Modus vSphere 6.7 und Virtual Distributed Switch (VDS) 6.6 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

Eine lokale GKE-Installation hat einen Administratorcluster und einen oder mehrere Nutzercluster. Beim gebündelten Load-Balancing-Modus empfehlen wir Ihnen dringend, dass die Cluster in separaten VLANs enthalten sind. Es ist besonders wichtig, dass sich Ihr Administratorcluster in einem eigenen VLAN befindet.

VM-Ressourcen für gebündeltes Load-Balancing bereitstellen (Seesaw)

Mit einem gebündelten Load-Balancing stellen Sie die VM-CPU- und -Speicherressourcen gemäß dem erwarteten Netzwerktraffic bereit.

Der gebündelte Load-Balancer ist nicht speicherintensiv und kann in VMs mit 1 GB Arbeitsspeicher ausgeführt werden. Für eine höhere Netzwerkpaketrate ist jedoch mehr CPU erforderlich.

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

Wenn der gebündelte Load-Balancer im Hochverfügbarkeitsmodus (High Available, HA) ausgeführt wird, wird ein aktives und ein Sicherungspaar ausgeführt, um den gesamten Traffic über eine einzige VM zu führen.

Da die tatsächlichen Anwendungsfälle variieren, müssen diese Richtlinien auf der Grundlage Ihres tatsächlichen Traffics angepasst werden. Beobachten Sie Ihre Messwerte zu CPU und Paketraten, um die erforderlichen Änderungen vorzunehmen.

Wenn Sie die CPU und den Arbeitsspeicher für Seesaw-VMs ändern müssen, folgen Sie der Anleitung zum Upgrade von Load-Balancern. Sie können dieselbe Version des gebündelten Load-Balancers verwenden und nur die Anzahl der CPUs und die Arbeitsspeicherzuweisung ändern.

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

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

Beachten Sie, dass Sie nur eine einzelne CPU in einer Nicht-Produktionsumgebung bereitstellen müssen.

Virtuelle IP-Adressen reservieren

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.

Sie müssen eine Gruppe von VIPs für Ihren Administratorcluster und eine Reihe von VIPs für jeden Nutzercluster reservieren, den Sie erstellen möchten. Für einen bestimmten Cluster müssen sich diese VIPs im selben VLAN wie die Clusterknoten und die Seesaw-VMs für diesen Cluster befinden.

Eine Anleitung zum Reservieren von VIPs finden Sie unter Virtuelle IP-Adressen reservieren.

Knoten-IP-Adressen reservieren

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. Weitere Informationen dazu, wie viele Knoten-IP-Adressen entfernt werden sollen, finden Sie unter Statische IP-Adressen konfigurieren.

IP-Adressen für Seesaw-VMs reservieren

Legen Sie als Nächstes 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-Load-Balancer (HA) oder Nicht-HA-Seesaw-Load-Balancer erstellen möchten.

Fall 1: HA-Seesaw-Load-Balancer

Legen Sie für Ihren Administratorcluster zwei IP-Adressen für zwei verschiedene VMs fest. Legen Sie auch für Ihren Administratorcluster eine einzelne primäre IP-Adresse für das Paar von Seesaw-VMs fest. Alle drei Adressen müssen sich im selben VLAN befinden wie die Knoten des Administratorclusters.

Legen Sie für jeden Nutzercluster, den Sie erstellen möchten, zwei IP-Adressen für ein Paar von Seesaw-VMs fest. Legen Sie außerdem für jeden Nutzercluster eine einzelne primäre IP für das Paar von Seesaw-VMs fest. Für einen bestimmten Nutzercluster müssen sich alle drei Adressen im selben VLAN wie die Knoten des Nutzerclusters befinden.

Fall 2: Nicht-HA-Seesaw-Load-Balancer

Legen Sie für Ihren Administratorcluster eine IP-Adresse für eine Seesaw-VM bereit. Legen Sie auch für Ihren Administratorcluster eine primäre IP für den Seesaw-Load-Balancer fest. Beide Adressen müssen sich im selben VLAN wie die Knoten des Administratorclusters befinden.

Legen Sie für jeden Nutzercluster, den Sie erstellen möchten, eine IP-Adresse für eine Seesaw-VM fest. Legen Sie außerdem für jeden Nutzercluster eine primäre IP für den Seesaw-Load-Balancer fest. Beide Adressen müssen sich im selben VLAN befinden wie die Nutzerclusterknoten.

Portgruppen planen

Jede Ihrer Seesaw-VMs hat zwei Netzwerkschnittstellen. Eine dieser Netzwerkschnittstellen ist mit Dienst-VIPs konfiguriert. Die andere Netzwerkschnittstelle wird mit der IP-Adresse der VM selbst konfiguriert.

Bei einer einzelnen Seesaw-VM können die beiden Netzwerkschnittstellen mit derselben vSphere-Portgruppe oder mit separaten Portgruppen verbunden werden. Wenn die Portgruppen getrennt sind, müssen sie sich im selben VLAN befinden.

Dieses Thema bezieht sich auf zwei Portgruppen:

Portgruppe des Load-Balancers: Bei einer Seesaw-VM ist die mit Dienst-VIPs konfigurierte Netzwerkschnittstelle mit dieser Portgruppe verbunden.
Portgruppe des Clusterknotens: Bei einer Seesaw-VM ist die Netzwerkschnittstelle, die mit der IP-Adresse der VM selbst konfiguriert ist, mit dieser Portgruppe verbunden. Ihre lokalen GKE-Clusterknoten sind ebenfalls mit dieser Portgruppe verbunden.

Die Portgruppe des Load-Balancers und die Portgruppe des Clusterknotens können identisch sein. Wir empfehlen jedoch dringend, dass sie separat sind.

Hostkonfigurationsdateien erstellen

Geben Sie für jeden Cluster, den Sie erstellen möchten, die Adressen an, die Sie für Ihre Seesaw-VMs in einer hostconfig-Datei ausgewählt haben. Diese hostconfig-Datei ist für Ihre Load-Balancer-VMs und nicht für Ihre Clusterknoten bestimmt. Wenn Sie für Ihre Clusterknoten statische IP-Adressen verwenden möchten, müssen Sie für diese Adressen eine separate hostconfig-Datei erstellen. Hier sehen Sie ein Beispiel für eine hostconfig-Datei, die zwei IP-Adressen für Seesaw-VMs angibt:

hostconfig:
  dns: "110.116.232"
  tod: "192.138.210.214"
  otherdns:
  - "8.8.8.8"
  - "8.8.4.4"
  othertod:
  - "ntp.ubuntu.com"
  searchdomainsfordns:
  - "my.local.com"
blocks:
  - netmask: "255.255.255.0"
    gateway: "172.16.20.1"
    ips:
    - ip: "172.16.20.18"
      hostname: "seesaw-vm"

Ihre Konfigurationsdateien eingeben

Bereiten Sie für jeden Cluster eine Konfigurationsdatei vor: Administratorcluster und Nutzercluster.

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

Füllen Sie für jeden Cluster in Ihrer Konfigurationsdatei den Abschnitt seesaw im Abschnitt "loadBalancer" aus.

loadBalancer:
  kind: Seesaw
  seesaw:
    ipBlockFilePath::
    vrid:
    masterIP:
    cpus:
    memoryMB:
    vCenter:
      networkName:
    enableha:
    antiAffinityGroups:
      enabled:

`seesaw.ipBlockFilePath`

String. Legen Sie hier den Pfad der hostconfig-Datei für Ihre Seesaw-VMs fest. Beispiel:

loadBalancer:
  seesaw:
    ipBlockFilePath: "admin-seesaw-hostconfig.yaml"

`seesaw.vird`

Integer. Die virtuelle Router-ID Ihrer Seesaw-VM. Diese Kennung muss in einem VLAN einmalig sein. Gültiger Bereich ist 1 – 255. Beispiel:

loadBalancer:
  seesaw:
    vrid: 125

`seesaw.masterIP`

String. Die primäre IP von Seesaw. Beispiel:

loadBalancer:
  seesaw:
    masterIP: 172.16.20.21

`seesaw.cpus`

Integer. Die Anzahl der CPUs für Ihre Seesaw-VM. Beispiel:

loadBalancer:
  seesaw:
    cpus: 4

`seesaw.memoryMB`

Integer. Die Anzahl der Megabyte des Arbeitsspeichers für Ihre Seesaw-VM. Beispiel:

loadBalancer:
  seesaw:
    memoryMB: 3072

`seesaw.vCenter.networkName`

String. Der Name des Netzwerks, das Ihre Seesaw-VMs enthält. Wenn nicht festgelegt, wird dasselbe Netzwerk wie der Cluster verwendet. Beispiel:

loadBalancer:
  seesaw:
    vCenter:
      networkName: "my-seesaw-network"

`seesaw.enableHA`

Boolescher Wert. Wenn Sie einen hochverfügbaren Seesaw-Load-Balancer erstellen möchten, legen Sie für dieses Feld true fest. Andernfalls legen Sie false fest. Beispiel:

loadBalancer:
  seesaw:
    enableHA: true

Wenn Sie enableha auf true setzen, müssen Sie MAC-Lernen aktivieren.

`seesaw.antiAffinityGroups.enabled`

Wenn Sie eine Anti-Affinitätsregel auf Ihre Seesaw-VMs anwenden möchten, setzen Sie den Wert von seesaw.antiAffinityGroups.enabled auf true. Setzen Sie andernfalls den Wert auf false. Der Standardwert ist true. Der empfohlene Wert ist true, damit Ihre Seesaw-VMs nach Möglichkeit auf verschiedenen physischen Hosts platziert werden. Beispiel:

loadBalancer:
  seesaw
    antiAffinityGroups:
      enabled: true

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 einen Seesaw-Load-Balancer mit Hochverfügbarkeit einrichten, 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 wechseln	Funktionen aktivieren	Auswirkungen auf die Sicherheit
vSphere 6.7 mit VDS 6.6	MAC-Lernen aktivieren und gefälschte Übertragungen für Ihren Load-Balancer ausführen. Führen Sie dazu folgenden Befehl aus: `gkectl prepare network --config [CONFIG_FILE]`, wobei `[CONFIG_FILE]` der Pfad Ihrer GKE-Standardkonfigurationsdatei 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.

Preflight-Prüfung für die Konfigurationsdatei ausführen

Nachdem Sie die Hostkonfigurationsdateien und die Konfigurationsdatei des GKE On-Prem-Administratorclusters erstellt haben, führen Sie eine Preflight-Prüfung für die Konfigurationsdatei aus:

gkectl check-config --config [ADMIN_CONFIG_FILE]

Dabei ist [ADMIN_CONFIG_FILE] der Pfad der Konfigurationsdatei des GKE On-Prem-Administratorclusters.

Für die Konfigurationsdatei des Nutzerclusters müssen Sie die kubeconfig-Datei des Administratorclusters in den Befehl einschließen:

gkectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] check-config --config [USER_CONFIG_FILE]

Dabei ist [ADMIN_CLUSTER_KUBECONFIG] der Pfad der kubeconfig-Datei Ihres Administratorclusters.

Wenn die Preflight-Prüfung fehlschlägt, nehmen Sie bei Bedarf Anpassungen an Ihrer lokalen GKE-Konfigurationsdatei und Ihren hostconfig-Dateien vor. Führen Sie dann die Preflight-Prüfung noch einmal aus.

Betriebssystem-Images hochladen

Führen Sie den folgenden Befehl aus, um Betriebssystem-Images in Ihre vSphere Umgebung hochzuladen:

gkectl prepare --config [ADMIN_CONFIG_FILE]

Dabei ist [ADMIN_CONFIG_FILE] der Pfad der Konfigurationsdatei des GKE On-Prem-Administratorclusters.

Administratorcluster erstellen, der das gebündelte Load-Balancing verwendet

Erstellen und konfigurieren Sie die VMs für den Load-Balancer des Administratorclusters:

gkectl create loadbalancer --config [CONFIG_FILE]

Dabei ist [CONFIG_FILE] der Pfad Ihrer lokalen GKE-Konfigurationsdatei für den Administratorcluster.

Erstellen Sie den Administratorcluster:

gkectl create admin --config [CONFIG_FILE]

Dabei ist [CONFIG_FILE] der Pfad der Konfigurationsdatei des GKE On-Prem-Administratorclusters.

Nutzercluster erstellen, der den gebündelten Load-Balancer verwendet

Erstellen und konfigurieren Sie die VMs für den Load-Balancer des Nutzerclusters:

gkectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] create loadbalancer --config [CONFIG_FILE]

Nutzercluster erstellen:

gkectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] create cluster --config [CONFIG_FILE]

Dabei ist [ADMIN_CLUSTER_KUBECONFIG] der Pfad der kubeconfig-Datei für Ihren Administratorcluster und [CONFIG_FILE] der Pfad Ihrer GKE On-Prem-Nutzercluster-Konfigurationsdatei

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.0	Version 1.3.1 und höher
Maximale Dienste (S)	100	500
Maximale Knoten (N)	100	100
Maximale Systemdiagnosen	S * N <= 10.000	N + 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 den Administratorcluster aktualisieren

Ab Version 1.4 werden Load-Balancer zusammen mit dem Cluster aktualisiert. Sie müssen keinen anderen Befehl ausführen, um Load-Balancer separat zu aktualisieren. Sie können aber weiterhin gkectl upgrade loadbalancer unten verwenden, um einige Parameter zu aktualisieren.

Sie können CPUs und Arbeitsspeicher für Ihre Seesaw-VMs aktualisieren. Erstellen Sie eine neue Konfigurationsdatei wie im folgenden Beispiel und legen Sie CPUs und Arbeitsspeicher für Ihre Seesaw-VMs fest. Wenn Sie sie leer lassen, bleiben sie unverändert. Wenn "bundlePath" festgelegt ist, wird der Load-Balancer auf den im Bundle angegebenen Typ aktualisiert.

Beispiel:

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

Führen Sie dann den folgenden Befehl aus, um den Load-Balancer zu aktualisieren:

gkectl upgrade loadbalancer --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [CLUSTER_CONFIG] --admin-cluster

Dabei gilt:

[ADMIN_CLUSTER_KUBECONFIG] ist die kubeconfig-Datei für Ihren Administratorcluster.
[CLUSTER_CONFIG] ist die von Ihnen erstellte Konfigurationsdatei.

Während der Aktualisierung eines Load-Balancers kommt es zu einer Ausfallzeit. Wenn für den Load-Balancer Hochverfügbarkeit aktiviert ist, beträgt die maximale Ausfallzeit zwei Sekunden.

Load-Balancer für einen Nutzercluster aktualisieren

Sie können CPUs und Arbeitsspeicher für Ihre Seesaw-VMs aktualisieren. Erstellen Sie eine neue Konfigurationsdatei wie im folgenden Beispiel und legen Sie CPUs und Arbeitsspeicher für Ihre Seesaw-VMs fest. Wenn Sie sie leer lassen, bleiben sie unverändert. Wenn gkeOnPremVersion festgelegt ist, wird der Load-Balancer auf den von dieser Version angegebenen Load-Balancer aktualisiert.

Beispiel:

apiVersion: v1
kind: UserCluster
name: cluster-1
gkeOnPremVersion:
loadBalancer:
  kind: Seesaw
  seesaw:
    cpus: 4
    memoryMB: 3072

Führen Sie dann den folgenden Befehl aus, um den Load-Balancer zu aktualisieren:

gkectl upgrade loadbalancer --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [CLUSTER_CONFIG] --name=[CLUSTER_NAME]

Dabei gilt:

[ADMIN_CLUSTER_KUBECONFIG] ist die kubeconfig-Datei für Ihren Administratorcluster.
[CLUSTER_CONFIG] ist die von Ihnen erstellte Konfigurationsdatei.
[CLUSTER_NAME] ist der Name des Clusters, der aktualisiert wird.

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.

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

Dabei ist [CLUSTER_KUBECONFIG] der Pfad der kubeconfig-Datei für den Cluster.

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

Sie können alle Monitoring- und Dashboard-Lösungen Ihrer Wahl verwenden, sofern diese das Prometheus-Format unterstützen. Eine Möglichkeit ist die Verwendung der Prometheus- und Grafana-Add-ons, die in GKE On-Prem eingebunden sind.

Eingebundene Add-ons für Prometheus und Grafana verwenden

Aktivieren Sie Prometheus und Grafana für Ihren Cluster.

Im nächsten Schritt erstellen Sie ein Dienstobjekt und ein Endpunkt-Objekt, damit das Prometheus-Add-on Ihre Seesaw-VMs kennt.

Speichern Sie die folgende Konfiguration als seesaw-metrics.yaml. Die Konfiguration enthält ein Dienstmanifest und ein Endpunkt-Manifest:

apiVersion: v1
kind: Service
metadata:
   name: seesaw-metrics
    annotations:
      monitoring.gke.io/scrape: 'true'
      monitoring.gke.io/scheme: 'https'
      monitoring.gke.io/tls_config: 'seesaw-ca'
spec:
    type: ClusterIP
    clusterIP: "None"
    ports:
    - name: metrics
      port: 20257
      protocol: TCP
      targetPort: 20257
---
kind: Endpoints
apiVersion: v1
metadata:
  name: seesaw-metrics
subsets:
 - addresses:
     - ip: [SEESAW_VM1_IP]
     - ip: [SEESAW_VM2_IP]
   ports:
     - name: metrics
       port: 20257

Dabei gilt:

[SEESAW_VM1_IP] ist die IP-Adresse einer Ihrer Seesaw-VMs.
[SEESAW_VM2_IP] ist die IP-Adresse Ihrer anderen Seesaw-VM.

Erstellen Sie die Dienst- und Endpunktobjekte:

kubectl --kubeconfig [CLUSTER_KUBECONFIG] apply seesaw-metrics.yaml

Jetzt können Sie Grafana-Dashboards und -Diagramme erstellen, um die Messwerte anzuzeigen.

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 ab Version 1.4.2 gkectl ausführen und Konfigurationsdateien übergeben, um den gebündelten Load-Balancer und dessen Gruppendatei zu löschen.

Führen Sie für Administratorcluster den folgenden Befehl aus:

gkectl delete loadbalancer --config [ADMIN_CONFIG_FILE] --seesaw-group-file [GROUP_FILE]

Führen Sie für Nutzercluster den folgenden Befehl aus:

gkectl delete loadbalancer --config [CLUSTER_CONFIG_FILE] --seesaw-group-file [GROUP_FILE] --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

Dabei gilt:

[ADMIN_CONFIG_FILE] ist die Konfigurationsdatei für den Administratorcluster
[CLUSTER_CONFIG_FILE] ist die Konfigurationsdatei für den Nutzercluster
[ADMIN_CLUSTER_KUBECONFIG] ist die Administratordatei kubeconfig.
[GROUP_FILE] ist die Seesaw-Gruppendatei. Der Name der Gruppendatei hat das Format seesaw-for-[CLUSTER_NAME]-[IDENTIFIER].yaml.

Versionen vor 1.4.2

In Versionen vor 1.4.2 können Sie alternativ diesen Befehl ausführen, wodurch die Seesaw-VMs und die Seesaw-Gruppendatei gelöscht werden:

gkectl delete loadbalancer --config vsphere.yaml --seesaw-group-file [GROUP_FILE]

Dabei gilt:

[GROUP_FILE] ist die Seesaw-Gruppendatei. Die Gruppendatei befindet sich auf Ihrer Admin-Workstation neben config.yaml. Der Name der Gruppendatei hat das Format seesaw-for-[CLUSTER_NAME]-[IDENTIFIER].yaml.
vsphere.yaml ist eine Datei mit den folgenden Informationen zu Ihrem vCenter-Server:

vcenter:
  credentials:
    address:
    username:
    password:
  datacenter:
  cacertpath:

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:

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
```
Dabei ist [CLUSTER_KUBECONFIG] die kubeconfig-Datei für Ihren Cluster.
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:

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.
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
```
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]

Dabei ist [SEESAW_IP] 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

Dabei ist [ADMIN_CLUSTER_KUBECONFIG] die Datei "kubeconfig" für Ihren Administratorcluster.

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

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

Dabei ist [GROUP_FILE] der Pfad der Gruppendatei für den Cluster, z. B. seesaw-for-gke-admin-xxxxxx.yaml.

Bekannte Probleme

Aktualisierung des Load-Balancers von v1.3.x nicht möglich

Wenn antiaffinitygroups für einen Seesaw-Load-Balancer deaktiviert ist, schlägt das Upgrade des Load-Balancers von v1.3.x auf v1.3.x+ mit folgendem Fehler fehl:

Aktualisierte SeesawGroup ist ungültig: SeesawConfig ist ungültig: AntiAffinityGroups muss auf den Standardwert gesetzt werden, wenn der Nutzer sie nicht angibt.

In v1.4 wurde das Problem behoben, sodass Sie v1.3.x+ überspringen und auf v1.4 aktualisieren können.