Containernatives Load-Balancing über eigenständige zonale NEGs

Auf dieser Seite erfahren Sie, wie Sie einen Kubernetes-Service erstellen, der von einer zonalen Netzwerk-Endpunktgruppe (NEG) unterstützt wird.

Informationen zu den Vorteilen, Anforderungen und Einschränkungen des containernativen Load-Balancing finden Sie unter Containernatives Load-Balancing.

Übersicht

Eine Netzwerk-Endpunktgruppe (NEG) stellt eine Gruppe von Back-Ends dar, für die ein Load-Balancer die Bereitstellung übernimmt. NEGs sind Listen mit IP-Adressen, die von einem NEG-Controller verwaltet und von Google Cloud-Load-Balancern verwendet werden. NEG-IP-Adressen können primäre oder sekundäre IP-Adressen einer VM sein, d. h. es kann sich um Pod-IP-Adressen handeln. Dadurch wird das containernative Load-Balancing aktiviert, das Traffic von einem Google Cloud-Load-Balancer direkt an Pods sendet.

Im folgenden Diagramm wird gezeigt, welche Kubernetes API-Objekte welchen Compute Engine-Objekten entsprechen.

Ingress mit NEGs

Wenn NEGs mit GKE Ingress verwendet werden, erleichtert der Ingress-Controller das Erstellen aller Aspekte des L7-Load-Balancers. Dazu gehören das Erstellen der virtuellen IP-Adresse, Weiterleitungsregeln, Systemdiagnosen, Firewallregeln usw.

Ingress ist die empfohlene Methode für den Einsatz von containernativem Load-Balancing, da es viele Features bietet, die das Verwalten von NEGs vereinfachen. Eigenständige NEGs sind dann eine Option, wenn von Ingress verwaltete NEGs nicht für Ihren Anwendungsfall geeignet sind.

Eigenständige NEGs

Wenn NEGs mit Load-Balancer bereitgestellt werden, die nicht von Ingress bereitgestellt werden, werden sie als eigenständige NEGs betrachtet. Eigenständige NEGs werden über den NEG-Controller bereitgestellt und verwaltet, aber die Weiterleitungsregeln, Systemdiagnosen und andere Load-Balancing-Objekte werden manuell bereitgestellt.

Eigenständige NEGs stehen mit containernativem Ingress-Load-Balancing nicht in Konflikt.

Die folgende Abbildung zeigt die Unterschiede bei der Bereitstellung der Load-Balancing-Objekte in den jeweiligen Szenarien:

Gehackte NEGs verhindern

Bei eigenständigen NEGs sind Sie für die Verwaltung der Lebenszyklen von NEGs und der Ressourcen für den Load-Balancer verantwortlich. NEGs können auf folgende Arten gehackt werden:

• Wenn ein GKE-Dienst gelöscht wird, wird für die zugeordnete NEG keine automatische Speicherbereinigung ausgeführt, wenn ein Back-End-Dienst weiterhin auf die NEG verweist. Damit die NEG gelöscht werden kann, entfernen Sie den Verweis für die NEG aus dem Back-End-Dienst.
• Beim Löschen eines Clusters werden eigenständige NEGs nicht gelöscht.

Anwendungsfälle für eigenständige NEGs

Für eigenständige NEGs gibt es mehrere kritische Verwendungszwecke. Sie sind sehr flexibel. Beim Ingress (egal ob mit oder ohne NEGs verwendet) verhält es sich gegensätzlich, da dieses einen bestimmten Satz von Load-Balancing-Objekten definiert, die nach bestimmten Kriterien für eine einfache Verwendung ausgewählt wurden.

Zu den Anwendungsfällen für eigenständige NEGs gehören folgende:

Heterogene Services von Containern und VMs

NEGs können sowohl VM- als auch Container-IP-Adressen enthalten. Dies bedeutet, dass eine einzelne virtuelle IP-Adresse auf ein Back-End verweisen kann, das sowohl aus Kubernetes-Arbeitslasten als auch aus Nicht-Kubernetes-Arbeitslasten besteht. Dies macht es auch möglich, vorhandene Arbeitslasten zu einem GKE-Cluster zu migrieren.

Eigenständige NEGs können auf VM-IP-Adressen verweisen, sodass Load-Balancers manuell so konfiguriert werden können, dass sie auf Back-Ends verweisen, die sowohl VMs als auch Container für dieselbe Service-VIP enthalten.

Benutzerdefinierte Ingress-Controller

Sie können einen benutzerdefinierten Ingress-Controller (oder keinen Ingress-Controller) verwenden, um Load-Balancer zu konfigurieren, die auf eigenständige NEGs abzielen.

Traffic Director mit GKE verwenden

Traffic Director mit GKE. Traffic Director verwendet eigenständige NEGs, um containernatives Load-Balancing für das verwaltete Service Mesh bereitzustellen.

TCP-Proxy-Load-Balancing mit GKE verwenden

Sie können eigenständige NEGs verwenden, um die Last mit dem TCP-Proxy-Load-Balancer, der von Kubernetes/GKE nicht nativ unterstützt wird, direkt auf Container zu verteilen.

Pod-Bereitschaft

Readiness-Gates sind ein Erweiterungs-Feature von Kubernetes, mit dem zusätzliches Feedback oder zusätzliche Signale in den PodStatus eingefügt werden können, damit der Pod in den Status "Bereit" wechseln kann. Der NEG-Controller verwaltet ein benutzerdefiniertes Readiness-Gate, damit der vollständige Netzwerkpfad vom Compute Engine-Load-Balancer zum Pod funktioniert. Die Funktionsweise von Pod-Readiness-Gates in GKE wird unter Containernatives Load-Balancing erläutert.

Wird Ingress mit NEGs verwendet, stellt es Compute Engine-Systemdiagnosen im Namen des Load-Balancers bereit und verwaltet sie. Eigenständige NEGs treffen jedoch keine Annahmen hinsichtlich Compute Engine-Systemdiagnosen, da erwartet wird, dass sie separat bereitgestellt und verwaltet werden. Compute Engine-Systemdiagnosen sollten immer zusammen mit dem Load-Balancer konfiguriert werden, um zu verhindern, dass Traffic an Back-Ends gesendet wird, die noch nicht empfangsbereit sind. Wenn der NEG kein Systemdiagnosestatus zugeordnet ist (normalerweise, weil keine Systemdiagnose konfiguriert ist), markiert der NEG-Controller den Readiness Gate-Wert des Pods dann als "True", wenn der entsprechende Endpunkt in der NEG programmiert wurde.

Voraussetzungen

Eigenständige NEGs sind in GKE 1.10 und höher verfügbar. Pod-Bereitschaftsfeedback ist für eigenständige NEGs in Version 1.16.4 und höher aktiviert.

Der Cluster muss VPC-nativ sein. Weitere Informationen finden Sie unter VPC-native Cluster mithilfe von Alias-IP-Adressen erstellen.

In Ihrem Cluster muss HTTP-Load-Balancing aktiviert sein. Für GKE-Cluster ist das HTTP-Load-Balancing standardmäßig aktiviert. Sie dürfen es nicht deaktivieren.

Vorbereitung

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Achten Sie darauf, dass die Google Kubernetes Engine API aktiviert ist.
Aktivieren Sie Google Kubernetes Engine API
• Prüfen Sie, ob das Cloud SDK installiert ist.

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

• Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
• Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

1. Führen Sie gcloud init aus und folgen Sie der Anleitung:

   gcloud init

   Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:

   gcloud init --console-only

2. Folgen Sie der Anleitung, um gcloud zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
4. Wählen Sie ein Google Cloud-Projekt aus.
5. Wählen Sie eine Compute Engine-Standardzone aus.

Hinweis: Sie können diese Standardeinstellungen in gcloud-Befehlen mit den Flags --project, --zone und --region überschreiben.

gcloud config verwenden

• Legen Sie Ihre standardmäßige Projekt-ID fest:

  gcloud config set project project-id

• Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Compute-Standardzone fest:

  gcloud config set compute/zone compute-zone

• Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Standardregion für Compute Engine fest:

  gcloud config set compute/region compute-region

• Aktualisieren Sie gcloud auf die neueste Version:

  gcloud components update

Hinweis: Sie können diese Standardeinstellungen in gcloud-Befehlen mit den Flags --project, --zone und --region überschreiben.

Eigenständige NEGs verwenden

In der folgenden Anleitung wird gezeigt, wie Sie eigenständige NEGs mit einem externen HTTP-Load-Balancer in GKE verwenden.

Dazu müssen mehrere Objekte erstellt werden:

• Ein Deployment, das Pods erstellt und verwaltet.
• Ein Service, der eine NEG erstellt.
• Ein Load-Balancer, der mit der Compute Engine API erstellt wurde. Wenn Sie NEGs mit Ingress verwenden, gilt dies nicht. In diesem Fall erstellt und konfiguriert Ingress den Load-Balancer für Sie. Bei eigenständigen NEGs sind Sie dafür verantwortlich, die NEGs mit dem Back-End-Service zu verknüpfen, um die Pods mit dem Load-Balancer zu verbinden. Der Load-Balancer besteht aus mehreren Komponenten, wie im folgenden Diagramm dargestellt:

VPC-nativen Cluster erstellen

Damit containernatives Load-Balancing verwendet werden kann, müssen Sie einen Cluster mit aktivierten Alias-IP-Adressen erstellen. Auf diesen Cluster muss Folgendes zutreffen:

• Er muss in Google Kubernetes Engine Version 1.16.4 oder höher ausgeführt werden.
• Es muss ein VPC-nativer Cluster sein.
• Das HTTP-Load-Balancing-Add-on muss aktiviert sein. Für GKE-Cluster ist das HTTP-Load-Balancing standardmäßig aktiviert und darf nicht deaktiviert werden.

Mithilfe des folgenden Befehls wird in der Zone us-central1-a der Cluster neg-demo-cluster mit einem automatisch bereitgestellten Subnetzwerk erstellt:

gcloud container clusters create neg-demo-cluster \
    --enable-ip-alias \
    --create-subnetwork="" \
    --network=default \
    --zone=us-central1-a \
    --cluster-version version

Dabei muss die Cluster-version mindestens 1.16.4 sein.

Deployment erstellen

Die folgenden Manifeste legen das Deployment neg-demo-app fest, das drei Instanzen eines HTTP-Containerservers ausführt. Der HTTP-Server antwortet auf Anfragen mit dem Hostnamen des Anwendungsservers, dem Namen des Pods, auf dem der Server ausgeführt wird.

Wir empfehlen die Verwendung von Arbeitslasten, bei denen Feedback zur Pod-Bereitschaft zum Einsatz kommt, falls dies in der von Ihnen verwendeten GKE-Version verfügbar ist. Weitere Informationen finden Sie oben im Abschnitt Pod-Bereitschaft. Im Abschnitt Anforderungen finden Sie die GKE-Versionsanforderungen für die Verwendung von Feedback zur Pod-Bereitschaft. Unter Umständen müssen Sie ein Upgrade Ihres Clusters durchführen, um das Feedback zur Pod-Bereitschaft verwenden zu können.

mithilfe von Pod-Bereitschaftsfeedback

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

mithilfe von hartcodierter Verzögerung

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: k8s.gcr.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

Speichern Sie dieses Manifest als neg-demo-app.yaml und erstellen Sie dann das Deployment dadurch, dass Sie folgenden Befehl ausführen:

kubectl apply -f neg-demo-app.yaml

Service erstellen

Das folgende Manifest legt den Service neg-demo-svc fest.

• Jeder Pod mit dem Label run: neg-demo-app ist Mitglied dieses Services.
• Der Service hat ein ServicePort-Feld mit dem Port 80.
• Die Anmerkung cloud.google.com/neg gibt an, dass Port 80 einer NEG zugeordnet wird. Das optionale Feld name gibt an, dass die NEG neg-name genannt wird. Wird das Feld name weggelassen, wird automatisch ein eindeutiger Name generiert. Weitere Informationen finden Sie unter NEGs benennen.
• Für jeden Mitglieds-Pod ist ein Container erforderlich, der den TCP-Port 9376 beobachtet.

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "neg-name"}}}'
spec:
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376

Speichern Sie dieses Manifest als neg-demo-svc.yaml und erstellen Sie dann den Dienst, indem Sie folgenden Befehl ausführen:

kubectl apply -f neg-demo-svc.yaml

Eine NEG wird innerhalb weniger Minuten nach der Erstellung des Services erstellt.

Diensttypen

In diesem Beispiel wird zwar ein ClusterIP-Service verwendet, aber alle fünf Servicetypen unterstützen eigenständige NEGs. Wir empfehlen den Standardtyp ClusterIP.

NEGs benennen

Preview

Dieses Produkt oder Feature unterliegt den Nutzungsbedingungen des Pre-GA-Angebots in den Nutzungsbedingungen der Google Cloud Platform. Pre-GA-Produkte und -Features werden eventuell nur eingeschränkt unterstützt. Änderungen an Pre-GA-Produkten und -Features sind möglicherweise nicht mit anderen Pre-GA--Versionen kompatibel. Weitere Informationen finden Sie unter Beschreibungen der Startphase.

Sie können den Namen der NEG angeben oder einen Namen automatisch zuweisen lassen. Die Angabe von NEG-Namen vereinfacht spätere Schritte, da Sie die Namen der NEGs im Voraus kennen, ohne danach suchen zu müssen. Sie müssen jedoch dafür sorgen, dass NEG-Namen in einer bestimmten Region eindeutig sind, da andernfalls Fehler beim Erstellen auftreten. Automatisch generierte NEG-Namen sind immer eindeutig.

Sie können NEG-Namen nur in der GKE-Version 1.18.10-gke.600 und höher festlegen. Automatisch generierte NEG-Namen werden in früheren Versionen verwendet.

Name angeben

Verwenden Sie das Feld name in der Annotation cloud.google.com/neg des Dienstes, um einen NEG-Namen anzugeben:

cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "neg-name"}}}'

Ersetzen Sie neg-name durch den Namen der NEG. Der NEG-Name muss in seiner Region eindeutig sein.

Automatisch generierten Namen verwenden

Wenn Sie einen automatisch generierten Namen verwenden möchten, lassen Sie das Feld name weg:

cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'

Der automatisch generierte Name hat folgendes Format: k8s1-cluster-uid-namespace-service-port-random-hash

Mehreren NEGs Ports zuordnen

Ein Service kann mehr als einen Port im Blick behalten. Definitionsgemäß haben NEGs nur eine IP-Adresse und einen Port. Wenn Sie also einen Service mit mehreren Ports angeben, wird für jeden Port eine NEG erstellt.

Das Format der Anmerkung cloud.google.com/neg lautet:

cloud.google.com/neg: '{
   "exposed_ports":{
      "service-port-1":{},
      "service-port-2":{},
      "service-port-3":{},
      ...
   }'

Dabei steht service-port-n für unterschiedliche Portnummern, die auf vorhandene Serviceports des Services verweisen. Für jeden aufgeführten Serviceport erstellt der NEG-Controller eine NEG in jeder Zone, die der Cluster belegt.

NEG-Status abrufen

Verwenden Sie diesen Befehl, um die Status der Services des Clusters abzurufen:

kubectl get service neg-demo-svc -o yaml

Dieser Befehl gibt den Status der NEGs in folgendem Format aus:

cloud.google.com/neg-status: '{
   "network-endpoint-groups":{
      "service-port-1": "neg-name-1",
      "service-port-1": "neg-name-2",
      ...
   },
   "zones":["zone-1", "zone-2", ...]
}

Dabei ist jedes Element in der network-endpoint-groups-Zuordnung ein Dienstport (service-port-1) und der Name der entsprechenden verwalteten NEGs (z. B. neg-name-1). Die Liste zones enthält jede Zone (z. B. zone-1), die eine NEG enthält.

Im folgenden Beispiel sehen Sie die vollständige Ausgabe des Befehls:

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["us-central1-a", "us-central1-b"]}'
  labels:
    run: neg-demo-app
  name: neg-demo-app
  namespace: default
  selfLink: /api/v1/namespaces/default/services/neg-demo-app
  ...
spec:
  clusterIP: 10.0.14.252
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    run: neg-demo-app
  sessionAffinity: None
status:
  loadBalancer: {}

In diesem Beispiel zeigt die Anmerkung, dass der Serviceport 80 für die NEGs mit dem Namen k8s1-cca197ad-default-neg-demo-app-80-4db81e02 in den Zonen us-central1-a und us-central1-b verfügbar gemacht wurde.

NEG-Erstellung validieren

Eine NEG wird innerhalb weniger Minuten nach der Erstellung des Services erstellt. Wenn Pods vorhanden sind, die dem im Servicemanifest angegebenen Label entsprechen, enthält die NEG ab ihrem Erstellen die IP-Adressen der Pods.

Es gibt zwei Möglichkeiten, zu prüfen, ob die NEG erstellt und korrekt konfiguriert ist. In GKE 1.18.6-gke.6400 und höher speichert eine benutzerdefinierte Ressource ServiceNetworkEndpointGroup Statusinformationen zu NEGs, die vom Dienstüberwacher erstellt wurden. In vorherigen Versionen müssen Sie die NEGs direkt prüfen.

ServiceNetworkEndpointGroup-Ressource

Listen Sie die NEGs in einem Cluster auf. Rufen Sie dazu alle ServiceNetworkEndpointGroup-Ressourcen ab:

kubectl get svcneg

Überwachen Sie den Status einer NEG. Prüfen Sie dazu den Status der ServiceNetworkEndpointGroup-Ressource:

kubectl get svcneg neg-name -o yaml

Ersetzen Sie neg-name durch den Namen der einzelnen NEG, die Sie prüfen möchten.

Die Ausgabe dieses Befehls enthält einen Statusabschnitt, der Fehlermeldungen enthalten kann. Einige Fehler werden als Dienstereignis gemeldet. Weitere Details erhalten Sie, wenn Sie das Dienstobjekt abfragen:

kubectl describe service service-name

Ersetzen Sie service-name durch den Namen des entsprechenden Dienstes.

Wenn Sie bestätigen möchten, dass der NEG-Controller die NEG erfolgreich synchronisiert, prüfen Sie das Statusfeld der ServiceNetworkEndpointGroup-Ressource auf eine Bedingung mit type:Synced. Die Zeit der letzten Synchronisierung befindet sich im Feld status.lastSyncTime.

ServiceNetworkEndpointGroup-Ressourcen gibt es nur in GKE 1.18 und höher.

NEGs direkt prüfen

Prüfen Sie, ob die NEG vorhanden ist, indem Sie die NEGs in Ihrem Google Cloud-Projekt auflisten und prüfen, ob eine NEG mit dem von Ihnen erstellten Service übereinstimmt. Der Name der NEG hat folgendes Format: k8s1-cluster-uid-namespace-service-port-random-hash

Verwenden Sie diesen Befehl, um die NEGs aufzulisten:

gcloud compute network-endpoint-groups list

Die Ausgabe sieht in etwa so aus:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  us-central1-a  GCE_VM_IP_PORT  3

Diese Ausgabe zeigt, dass die SIZE der NEG 3 ist, was bedeutet, dass sie drei Endpunkte hat, die den drei Pods im Deployment entsprechen.

Identifizieren Sie die einzelnen Endpunkte mit diesem Befehl:

gcloud compute network-endpoint-groups list-network-endpoints \
    k8s1-70aa83a6-default-my-service-80-c9710a6f

Die Ausgabe zeigt drei Endpunkte, wobei jeder Endpunkt die IP-Adresse und den Port eines Pods hat:

INSTANCE                                           IP_ADDRESS  PORT
gke-standard-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.43  9376
gke-standard-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.44  9376
gke-standard-cluster-3-default-pool-4cc71a15-w9nk  10.12.2.26  9376

Load-Balancer an eigenständige NEGs anhängen

Nachdem Sie Ihre NEGs erstellt haben, können Sie diese als Back-Ends für die folgenden Arten von Load-Balancern verwenden:

• einen externen HTTP(S)-Load-Balancer
• ein internen HTTP(S)-Load-Balancer
• ein SSL-Proxy-Load-Balancer
• ein TCP-Proxy-Load-Balancer

Die folgenden Beispiele zeigen, wie das geht:

• Externen HTTP(S)-Load-Balancer an eigenständige NEGs anhängen
• Internen HTTP(S)-Load-Balancer an eigenständige NEGs anhängen

Externen HTTP(S)-Load-Balancer an eigenständige NEGs anhängen

In den folgenden Schritten wird gezeigt, wie Sie mit der Compute Engine API einen externen HTTP-Load-Balancer erstellen.

1. Erstellen Sie Firewallregeln. Load-Balancer benötigen Zugriff auf Clusterendpunkte, um Systemdiagnosen durchzuführen. Mit diesem Befehl werden Firewallregeln erstellt, die diesen Zugriff erlauben:

   gcloud compute firewall-rules create fw-allow-health-check-and-proxy \
     --network=network-name \
     --action=allow \
     --direction=ingress \
     --target-tags=gke-node-network-tags \
     --source-ranges=130.211.0.0/22,35.191.0.0/16 \
     --rules=tcp:9376

   Dabei sind gke-node-network-tags die Netzwerk-Tags der GKE-Knoten und network-name ist das Netzwerk, in dem der Cluster ausgeführt wird.

   Wenn Sie für Ihre Knoten keine benutzerdefinierten Netzwerk-Tags erstellt haben, generiert GKE die Tags automatisch. Sie können diese automatisch generierten Tags einsehen, indem Sie die Knoten mit folgendem Befehl prüfen:

   gcloud compute instances describe node-name
   

2. Erstellen Sie für den Load-Balancer eine globale virtuelle IP-Adresse:

   gcloud compute addresses create hostname-server-vip \
     --ip-version=IPV4 \
     --global

3. Erstellen Sie eine Systemdiagnose. Diese wird vom Load-Balancer verwendet, um die Aktivität einzelner Endpunkte innerhalb der NEG zu erkennen.

   gcloud compute health-checks create http http-basic-check \
     --use-serving-port

4. Erstellen Sie einen Back-End-Service, der angibt, dass es sich um einen globalen externen HTTP(S)-Load-Balancer handelt:

   gcloud compute backend-services create my-bes \
     --protocol HTTP \
     --health-checks http-basic-check \
     --global

5. Erstellen Sie eine URL-Zuordnung und einen Zielproxy für den Load-Balancer. Dieses Beispiel ist sehr einfach, da die in dieser Anleitung verwendete serve_hostname-Anwendung nur einen Endpunkt hat und keine URLs enthält.

   gcloud compute url-maps create web-map \
     --default-service my-bes

   gcloud compute target-http-proxies create http-lb-proxy \
     --url-map web-map

6. Erstellen Sie eine Weiterleitungsregel. Dadurch wird der Load-Balancer erstellt.

   gcloud compute forwarding-rules create http-forwarding-rule \
     --address=hostname-server-vip \
     --global \
     --target-http-proxy=http-lb-proxy \
     --ports=80

   hostname-server-vip ist die IP-Adresse, die für den Load-Balancer verwendet werden soll. Sie können für diesen Zweck eine neue statische externe IP-Adresse reservieren. Sie können auch die Option --address weglassen. Es wird dann automatisch eine sitzungsspezifische IP-Adresse zugewiesen.

Checkpoint

Folgende Ressourcen haben Sie bisher erstellt:

• eine externe virtuelle IP-Adresse
• Weiterleitungsregeln
• Firewallregeln
• einen Ziel-HTTP-Proxy
• eine URL-Zuordnung der Compute Engine-Systemdiagnose
• einen Back-End-Service
• eine Compute Engine-Systemdiagnose

Die Beziehung zwischen diesen Ressourcen ist im folgenden Diagramm dargestellt:

Diese Ressourcen bilden zusammen einen Load-Balancer. Im nächsten Schritt fügen Sie dem Load-Balancer Back-Ends hinzu.

Einer der hier gezeigten Vorteile eigenständiger NEGs ist, dass die Lebenszyklen des Load-Balancers und des Back-Ends voneinander völlig unabhängig sein können. Der Load-Balancer kann weiter ausgeführt werden, nachdem die Anwendung, ihre Services oder der GKE-Cluster gelöscht wurden. Sie können neue NEGs oder mehrere NEGs zum Load-Balancer hinzufügen und daraus entfernen, ohne die vorgeschalteten Load-Balancer-Objekte zu ändern.

Back-Ends zum Load-Balancer hinzufügen

Um die NEG mit dem Load-Balancer zu verbinden, verwenden Sie den Befehl gcloud compute backend-services add-backend und fügen diese als Back-End des Back-End-Dienstes my-bes hinzu:

gcloud compute backend-services add-backend my-bes --global \
   --network-endpoint-group network-endpoint-group-name \
   --network-endpoint-group-zone network-endpoint-group-zone \
   --balancing-mode RATE --max-rate-per-endpoint 5

Dabei gilt:

• network-endpoint-group-name ist der Name der Netzwerk-Endpunktgruppe. Der Name ist entweder der Name, den Sie beim Erstellen der NEG angegeben haben oder ein automatisch generierter Name. Wenn Sie keinen Namen für die NEG angegeben haben, können Sie den automatisch generierten Namen anhand der folgenden Anleitung ermitteln.
• network-endpoint-group-zone ist die Zone, in der sich die Netzwerk-Endpunktgruppe befindet. Weiter unten finden Sie eine Anleitung zum Abrufen dieses Werts.

Verwenden Sie diesen Befehl, um den Namen und den Standort der NEG abzurufen:

gcloud compute network-endpoint-groups list

Die Ausgabe sieht in etwa so aus:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  us-central1-a  GCE_VM_IP_PORT  3

In dieser Beispielausgabe lautet der Name der NEG k8s1-70aa83a6-default-my-service-80-c9710a6f und befindet sich in der Zone us-central1-a.

Einem Back-End-Service können mehrere NEGs hinzugefügt werden. Für globale Back-End-Services wie my-bes sind NEG-Back-Ends in mehreren Regionen möglich, während regionale Back-End-Services nur Back-Ends in einer einzelnen Region haben können.

Funktionieren des Load-Balancers prüfen

Hinweis: Es kann einige Minuten dauern, bis der Load-Balancer bereitgestellt wurde und sich stabilisiert hat.

Es gibt zwei Möglichkeiten, zu prüfen, ob der von Ihnen eingerichtete Load-Balancer funktioniert: Prüfen Sie, ob die Systemdiagnose richtig konfiguriert ist und meldet, dass der Load-Balancer fehlerfrei ist, oder greifen Sie auf die Anwendung zu und prüfen Sie deren Antwort.

Systemdiagnosen prüfen

Prüfen Sie, ob der Back-End-Service der Systemdiagnose und den Netzwerk-Endpunktgruppen zugeordnet ist und ob die einzelnen Endpunkte fehlerfrei sind.

Prüfen Sie mit diesem Befehl, ob der Back-End-Service mit Ihrer Systemdiagnose und Ihrer Netzwerk-Endpunktgruppe verknüpft ist:

gcloud compute backend-services describe my-bes --global

Die Ausgabe sollte in etwa so aussehen:

backends:
- balancingMode: RATE
  capacityScaler: 1.0
  group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
...
healthChecks:
- ... /healthChecks/http-basic-check
...
name: my-bes
...

Prüfen Sie als Nächstes den Status der einzelnen Endpunkte:

gcloud compute backend-services get-health my-bes --global

Der Abschnitt status: der Ausgabe sollte in etwa so aussehen:

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-standard-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-standard-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-standard-cluster-3-default-pool-4cc71a15-w9nk
    ipAddress: 10.12.2.26
    port: 50000

Auf die Anwendung zugreifen

Greifen Sie über die IP-Adresse des Load-Balancers auf die Anwendung zu, um zu prüfen, ob alles funktioniert.

Hinweis: Es dauert einige Minuten, bis der Load-Balancer vollständig programmiert ist.

Rufen Sie zuerst die virtuelle IP-Adresse des Load-Balancers ab:

gcloud compute addresses describe hostname-server-vip --global | grep "address:"

Die Ausgabe enthält eine IP-Adresse. Senden Sie als Nächstes eine Anfrage an diese IP-Adresse (in diesem Beispiel 34.98.102.37):

curl 34.98.102.37

Die Antwort der serve_hostname-Anwendung sollte neg-demo-app lauten.

Internen HTTP(S)-Load-Balancer an eigenständige NEGs anhängen

Dieser Abschnitt enthält Anweisungen zum Konfigurieren des internen HTTP(S)-Load-Balancings für die Services, die in eigenständigen GKE-Pods ausgeführt werden.

Nur-Proxysubnetz konfigurieren

Das Nur-Proxysubnetz ist für alle internen HTTP(S)-Load-Balancer in der Region des Load-Balancers vorgesehen, in diesem Beispiel us-west1.

Wichtig: Weisen Sie der Weiterleitungsregel oder den Back-Ends des Load-Balancers keine Adressen aus dem Nur-Proxysubnetz zu. Die IP-Adresse der Weiterleitungsregel und die IP-Adressen der Back-End-Instanzen werden aus einem oder mehreren anderen Subnetzbereichen zugewiesen. Google Cloud reserviert diesen Subnetzbereich für Proxys, die von Google Cloud verwaltet werden.

Console

Wenn Sie die GCP Console verwenden, können Sie das Nur-Proxy-Subnetz auch später über die Load-Balancing-UI erstellen.

gcloud

Erstellen Sie das Nur-Proxysubnetz mit dem Befehl gcloud compute networks subnets create:

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

API

Erstellen Sie das Nur-Proxysubnetz mit der Methode subnetworks.insert und ersetzen Sie project-id dabei durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/projects/project-id/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/project-id/global/networks/lb-network",
  "region": "projects/project-id/regions/us-west1",
  "purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

Firewallregeln konfigurieren

Dieses Beispiel verwendet die folgenden Firewallregeln:

• fw-allow-ssh: eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und eingehende SSH-Verbindungen an TCP-Port 22 von jeder Adresse aus ermöglicht. Sie können einen restriktiveren IP-Quellbereich für diese Regel auswählen. Geben Sie dazu beispielsweise nur die IP-Bereiche des Systems an, von dem aus Sie SSH-Sitzungen initiieren. In diesem Beispiel wird das Ziel-Tag allow-ssh verwendet, um die VMs zu identifizieren, auf welche die Firewallregel angewendet wird.

• fw-allow-health-check: eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und TCP-Traffic von den Google Cloud-Systemen für Systemdiagnosen zulässt (in 130.211.0.0/22 und 35.191.0.0/16). In diesem Beispiel wird das Ziel-Tag load-balanced-backend verwendet, um die Instanzen zu identifizieren, auf die sie angewendet werden soll.

• fw-allow-proxies: eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und TCP-Traffic über Port 80, 443 und 8000 von den verwalteten Proxys des internen HTTP(S)-Load-Balancers zulässt. In diesem Beispiel wird das Ziel-Tag load-balanced-backend verwendet, um die Instanzen zu identifizieren, auf die sie angewendet werden soll.

Ohne diese Firewallregeln blockiert die Standardregel zum Ablehnen von eingehendem Traffic den eingehenden Traffic zu den Back-End-Instanzen.

Console

1. Rufen Sie in der Google Cloud Console die Seite "Firewallregeln" auf.
   Zur Seite "Firewallregeln"
2. Klicken Sie auf Firewallregel erstellen, um die Regel zu erstellen, die eingehende SSH-Verbindungen zulässt:
   • Name: fw-allow-ssh
   • Netzwerk: lb-network
   • Trafficrichtung: Eingehend
   • Aktion bei Übereinstimmung: Zulassen
   • Ziele: Angegebene Ziel-Tags
   • Ziel-Tags: allow-ssh
   • Quellfilter: IP ranges
   • Quell-IP-Bereiche: 0.0.0.0/0
   • Protokolle und Ports:
     • Wählen Sie Angegebene Protokolle und Ports aus.
     • Prüfen Sie tcp und geben Sie 22 für die Portnummer ein.
3. Klicken Sie auf Erstellen.
4. Klicken Sie ein zweites Mal auf Firewallregel erstellen, um die Regel zum Zulassen von Google Cloud-Systemdiagnosen zu erstellen:
   • Name: fw-allow-health-check
   • Netzwerk: lb-network
   • Trafficrichtung: Eingehend
   • Aktion bei Übereinstimmung: Zulassen
   • Ziele: Angegebene Ziel-Tags
   • Ziel-Tags: load-balanced-backend
   • Quellfilter: IP ranges
   • Quell-IP-Bereiche: 130.211.0.0/22 und 35.191.0.0/16
   • Protokolle und Ports:
     • Wählen Sie Angegebene Protokolle und Ports aus.
     • Prüfen Sie tcp und geben Sie 80 ein.
       Sie sollten diese Regeln nur auf Protokolle und Ports beschränken, die mit den von Ihren Systemdiagnosen verwendeten übereinstimmen. Wenn Sie tcp:80 für das Protokoll und den Port verwenden, kann Google Cloud Ihre VMs über HTTP an Port 80 kontaktieren, aber nicht über HTTPS an Port 443.
5. Klicken Sie auf Erstellen.
6. Klicken Sie ein drittes Mal auf Firewallregel erstellen, um die Regel zu erstellen, die Verbindungen von den Proxyservern des Load-Balancers zu den Back-Ends zulässt:
   • Name: fw-allow-proxies
   • Netzwerk: lb-network
   • Trafficrichtung: Eingehend
   • Aktion bei Übereinstimmung: Zulassen
   • Ziele: Angegebene Ziel-Tags
   • Ziel-Tags: load-balanced-backend
   • Quellfilter: IP ranges
   • Quell-IP-Bereiche: 10.129.0.0/23
   • Protokolle und Ports:
     • Wählen Sie Angegebene Protokolle und Ports aus.
     • Prüfen Sie tcp und geben Sie 80, 443, 8000 für die Portnummern ein.
7. Klicken Sie auf Erstellen.

gcloud

1. Erstellen Sie die Firewallregel fw-allow-ssh, um SSH-Verbindungen zu VMs mit dem Netzwerk-Tag allow-ssh zu ermöglichen. Wenn Sie source-ranges weglassen, bezieht Google Cloud die Regel auf jede Quelle.

   gcloud compute firewall-rules create fw-allow-ssh \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-ssh \
       --rules=tcp:22
   

2. Erstellen Sie die Regel fw-allow-health-check, um Google Cloud-Systemdiagnosen zuzulassen. In diesem Beispiel wird der gesamte TCP-Traffic von Systemdiagnosetests zugelassen. Sie können jedoch Ihren Anforderungen entsprechend eine kleinere Gruppe von Ports konfigurieren:

   gcloud compute firewall-rules create fw-allow-health-check \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=load-balanced-backend \
       --rules=tcp
   

3. Erstellen Sie die Regel fw-allow-proxies, um Verbindungen von den Proxys des internen HTTP(S)-Load-Balancers zu Ihren Back-Ends zuzulassen.

   gcloud compute firewall-rules create fw-allow-proxies \
     --network=lb-network \
     --action=allow \
     --direction=ingress \
     --source-ranges=10.129.0.0/23 \
     --target-tags=load-balanced-backend \
     --rules=tcp:80,tcp:443,tcp:8000
   

API

Erstellen Sie die Firewallregel fw-allow-ssh, indem Sie eine POST-Anfrage an die Methode firewalls.insert senden und dabei project-id durch Ihre Projekt-ID ersetzen.

POST https://compute.googleapis.com/compute/v1/projects/project-id/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

Erstellen Sie die Firewallregel fw-allow-health-check, indem Sie eine POST-Anfrage an die Methode firewalls.insert senden und dabei project-id durch Ihre Projekt-ID ersetzen.

POST https://compute.googleapis.com/compute/v1/projects/project-id/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

Erstellen Sie die fw-allow-proxies-Firewallregel, um TCP-Traffic im Proxy-Subnetz mit der Methode firewalls.insert zuzulassen. Ersetzen Sie dabei project-id durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/{project}/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "80"
      ]
    },
  {
      "IPProtocol": "tcp",
      "ports": [
        "443"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "8000"
      ]
    }
  ],
  "direction": "INGRESS"
}

Load-Balancer konfigurieren

Verwenden Sie für die IP-Adresse der Weiterleitungsregel ein Back-End-Subnetz. Wenn Sie das Nur-Proxy-Subnetz verwenden, schlägt das Erstellen der Weiterleitungsregel fehl.

Console

Load-Balancer-Typ auswählen

1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
   Zur Seite „Load-Balancing“
2. Klicken Sie unter HTTP(S)-Load-Balancing auf Konfiguration starten.
3. Wählen Sie Nur zwischen meinen VMs aus. Diese Einstellung bedeutet, dass der Load-Balancer intern ist.
4. Klicken Sie auf Weiter.

Load-Balancer vorbereiten

1. Geben Sie l7-ilb-gke-map als Name für den Load-Balancer ein.
2. Wählen Sie us-west1 als Region aus.
3. Wählen Sie lb-network als Netzwerk aus.
4. Lassen Sie das Fenster geöffnet, um fortzufahren.

Nur-Proxy-Subnetz reservieren

Hinweis: Wenn Sie bereits entsprechend dieser Anleitung ein Nur-Proxysubnetz reserviert haben, wird die Schaltfläche Subnetz reservieren nicht angezeigt. Überspringen Sie dann diesen Abschnitt und fahren Sie mit den Schritten im Abschnitt Back-End-Service konfigurieren fort.

Reservieren Sie beim internen HTTP-Load-Balancing ein Proxy-Subnetz:

1. Klicken Sie auf Subnetz reservieren.
2. Geben Sie im Feld Name proxy-only-subnet ein.
3. Geben Sie 10.129.0.0/23 als IP-Adressbereich ein.
4. Klicken Sie auf Hinzufügen.

Back-End-Service konfigurieren

1. Klicken Sie auf Back-End-Konfiguration.
2. Wählen Sie im Menü Back-End-Service erstellen oder auswählen die Option Back-End-Service erstellen aus.
3. Legen Sie als Name für den Back-End-Service l7-ilb-gke-backend-service fest.
4. Wählen Sie unter Back-End-Typ Netzwerk-Endpunktgruppen aus.
5. Gehen Sie auf der Karte Neues Back-End des Abschnitts Back-Ends folgendermaßen vor:
   1. Legen Sie die Netzwerk-Endpunktgruppe auf die NEG fest, die von GKE erstellt wurde. Informationen zum Abrufen des NEG-Namens finden Sie unter NEG-Erstellung validieren.
   2. Geben Sie eine maximale Rate von 5 RPS pro Endpunkt ein. Google Cloud überschreitet diesen Höchstwert bei Bedarf.
   3. Klicken Sie auf Fertig.
6. Wählen Sie im Abschnitt Systemdiagnose die Option Systemdiagnose erstellen mit den folgenden Parametern aus:
   1. Name: l7-ilb-gke-basic-check
   2. Protokoll: HTTP
   3. Portspezifikation: Bereitstellungsport
   4. Klicken Sie auf Speichern und Fortfahren.
7. Klicken Sie auf Erstellen.

URL-Zuordnung konfigurieren

1. Klicken Sie auf Host- und Pfadregeln. Vergewissern Sie sich, dass der l7-ilb-gke-backend-service der einzige Back-End-Service für alle nicht übereinstimmenden Hosts und alle nicht übereinstimmenden Pfade ist.

Front-End konfigurieren

Bei HTTP:

1. Klicken Sie auf Front-End-Konfiguration.
2. Klicken Sie auf Front-End-IP und Port hinzufügen.
3. Legen Sie als Name l7-ilb-gke-forwarding-rule fest.
4. Legen Sie als Protokoll HTTP fest.
5. Legen Sie als Subnetz backend-subnet fest.
6. Wählen Sie unter Interne IP-Adresse die Option Statische interne IP-Adresse reservieren aus.
7. Geben Sie im angezeigten Feld die folgenden Informationen ein:
   1. Name: l7-ilb-gke-ip
   2. Wählen Sie im Abschnitt Statische IP-Adresse die Option Selbst auswählen aus.
   3. Geben Sie im Abschnitt Benutzerdefinierte IP-Adresse 10.1.2.199 ein.
   4. Klicken Sie auf Reservieren.
8. Legen Sie als Port 80 fest.
9. Klicken Sie auf Fertig.

Bei HTTPS:

Wenn Sie HTTPS zwischen dem Client und dem Load-Balancer verwenden, benötigen Sie eine oder mehrere SSL-Zertifikatsressourcen, um den Proxy zu konfigurieren. Informationen zum Erstellen von SSL-Zertifikatressourcen finden Sie unter SSL-Zertifikate. Von Google verwaltete Zertifikate werden derzeit nicht von internen HTTP(S)-Load-Balancern unterstützt.

1. Klicken Sie auf Front-End-Konfiguration.
2. Klicken Sie auf Front-End-IP und Port hinzufügen.
3. Geben Sie im Feld Name l7-ilb-gke-forwarding-rule ein.
4. Wählen Sie im Feld Protokoll die Option HTTPS (includes HTTP/2) aus.
5. Legen Sie als Subnetz backend-subnet fest.
6. Wählen Sie unter Interne IP-Adresse die Option Statische interne IP-Adresse reservieren aus.
7. Geben Sie im angezeigten Feld die folgenden Informationen ein:
   1. Name: l7-ilb-gke-ip
   2. Wählen Sie im Abschnitt Statische IP-Adresse die Option Selbst auswählen aus.
   3. Geben Sie im Abschnitt Benutzerdefinierte IP-Adresse 10.1.2.199 ein.
   4. Klicken Sie auf Reservieren.
8. Achten Sie darauf, dass der Port auf 443 festgelegt ist, um HTTPS-Traffic zuzulassen.
9. Klicken Sie auf die Drop-down-Liste Zertifikat.
   1. Wenn Sie bereits eine selbstverwaltete SSL-Zertifikatressource haben, die Sie als primäres SSL-Zertifikat verwenden möchten, wählen Sie es aus dem Drop-down-Menü aus.
   2. Wählen Sie andernfalls Neues Zertifikat erstellen aus.
      1. Geben Sie l7-ilb-cert als Name ein.
      2. Laden Sie in den entsprechenden Feldern Ihre PEM-formatierten Dateien hoch:
         • Public-Key-Zertifikat
         • Zertifikatskette
         • Privater Schlüssel
      3. Klicken Sie auf Erstellen.
10. So fügen Sie zusätzlich zur primären SSL-Zertifikatsressource weitere Zertifikatsressourcen hinzu:
    1. Klicken Sie auf Zertifikat hinzufügen.
    2. Wählen Sie ein Zertifikat in der Liste Zertifikate aus oder klicken Sie auf Neues Zertifikat erstellen und befolgen Sie die obige Anleitung.
11. Klicken Sie auf Fertig.

Konfiguration abschließen

1. Klicken Sie auf Erstellen.

gcloud

1. Definieren Sie die HTTP-Systemdiagnose mit dem Befehl gcloud compute health-checks create http.

   gcloud compute health-checks create http l7-ilb-gke-basic-check \
      --region=us-west1 \
      --use-serving-port
   

2. Definieren Sie den Back-End-Dienst mit dem Befehl gcloud compute backend-services create.

   gcloud compute backend-services create l7-ilb-gke-backend-service \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --protocol=HTTP \
     --health-checks=l7-ilb-gke-basic-check \
     --health-checks-region=us-west1 \
     --region=us-west1
   

3. Legen Sie die Variable DEPLOYMENT_NAME fest.

   export DEPLOYMENT_NAME=neg-name
   

   Dabei ist neg-name der Name der NEG.

4. Fügen Sie dem Back-End-Dienst NEG-Back-Ends mit dem Befehl gcloud compute backend-services add-backend hinzu.

   gcloud compute backend-services add-backend l7-ilb-gke-backend-service \
      --network-endpoint-group=$DEPLOYMENT_NAME \
      --network-endpoint-group-zone=us-west1-b \
      --region=us-west1 \
      --balancing-mode=RATE \
      --max-rate-per-endpoint=5
   

5. Erstellen Sie die URL-Zuordnung mit dem Befehl gcloud compute url-maps create.

   gcloud compute url-maps create l7-ilb-gke-map \
     --default-service=l7-ilb-gke-backend-service \
     --region=us-west1
   

6. Erstellen Sie den Zielproxy.

   Bei HTTP:

   Verwenden Sie den Befehl gcloud compute target-http-proxies create.

   gcloud compute target-http-proxies create l7-ilb-gke-proxy \
     --url-map=l7-ilb-gke-map \
     --url-map-region=us-west1 \
     --region=us-west1
   

   Bei HTTPS:

   Informationen zum Erstellen von SSL-Zertifikatressourcen finden Sie unter SSL-Zertifikate. Von Google verwaltete Zertifikate werden derzeit nicht von internen HTTP(S)-Load-Balancern unterstützt.

   Weisen Sie Ihre Dateipfade den entsprechenden Variablennamen zu.

   export LB_CERT=path to PEM-formatted file
   

   export LB_PRIVATE_KEY=path to PEM-formatted file
   

   Erstellen Sie mit dem Befehl gcloud compute ssl-certificates create ein regionales SSL-Zertifikat.

   gcloud compute ssl-certificates create

   gcloud compute ssl-certificates create l7-ilb-cert \
     --certificate=$LB_CERT \
     --private-key=$LB_PRIVATE_KEY \
     --region=us-west1
   

   Verwenden Sie das regionale SSL-Zertifikat, um einen Zielproxy mit dem Befehl gcloud compute target-https-proxies create zu erstellen.

   gcloud compute target-https-proxies create l7-ilb-gke-proxy \
     --url-map=l7-ilb-gke-map \
     --region=us-west1 \
     --ssl-certificates=l7-ilb-cert
   

7. Erstellen Sie die Weiterleitungsregel.

   Bei benutzerdefinierten Netzwerken müssen Sie in der Weiterleitungsregel auf das Subnetz verweisen. Achten Sie darauf, dass dies das VM-Subnetz und nicht das Proxy-Subnetz ist.

   Bei HTTP:

   Verwenden Sie den Befehl gcloud compute forwarding-rules create mit den richtigen Flags.

   gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=lb-network \
     --subnet=backend-subnet \
     --address=10.1.2.199 \
     --ports=80 \
     --region=us-west1 \
     --target-http-proxy=l7-ilb-gke-proxy \
     --target-http-proxy-region=us-west1
   

   Bei HTTPS:

   Verwenden Sie den Befehl gcloud compute forwarding-rules create mit den richtigen Flags.

   gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network=lb-network \
     --subnet=backend-subnet \
     --address=10.1.2.199 \
     --ports=443 \
     --region=us-west1 \
     --target-https-proxy=l7-ilb-gke-proxy \
     --target-https-proxy-region=us-west1
   

API

Erstellen Sie die Systemdiagnose durch Stellen einer POST-Anfrage an die Methode regionHealthChecks.insert. Ersetzen Sie dabei project-id durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/healthChecks

{
   "name": "l7-ilb-gke-basic-check",
   "type": "HTTP",
   "httpHealthCheck": {
     "portSpecification": "USE_SERVING_PORT"
   }
}

Erstellen Sie den regionalen Back-End-Service durch Stellen einer POST-Anfrage an die Methode regionBackendServices.insert. Ersetzen Sie dabei project-id durch Ihre Projekt-ID und neg-name durch den Namen der von Ihnen erstellten NEG.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices

{
  "name": "l7-ilb-gke-backend-service",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-b/networkEndpointGroups/neg-name",
      "balancingMode": "RATE",
      "maxRatePerEndpoint": 5
    }
  ],
  "healthChecks": [
    "projects/project-id/regions/us-west1/healthChecks/l7-ilb-gke-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

Erstellen Sie die URL-Zuordnung durch Stellen einer POST-Anfrage an die Methode regionUrlMaps.insert. Ersetzen Sie dabei project-id durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/urlMaps

{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/project-id/regions/us-west1/backendServices/l7-ilb-gke-backend-service"
}

Erstellen Sie den Ziel-HTTP-Proxy durch Stellen einer POST-Anfrage an die Methode regionTargetHttpProxies.insert. Ersetzen Sie dabei project-id durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/targetHttpProxy

{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/project-id/global/urlMaps/l7-ilb-gke-map",
  "region": "us-west1"
}

Erstellen Sie die Firewallregel POST, indem Sie eine -Anfrage an die Methode forwardingRules.insertproject-id senden und dabei durch Ihre Projekt-ID ersetzen.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/us-west1/forwardingRules

{
  "name": "l7-ilb-gke-forwarding-rule",
  "IPAddress": "10.1.2.199",
  "IPProtocol": "TCP",
  "portRange": "80-80",
  "target": "projects/project-id/regions/us-west1/targetHttpProxies/l7-ilb-gke-proxy",
  "loadBalancingScheme": "INTERNAL_MANAGED",
  "subnetwork": "projects/project-id/regions/us-west1/subnetworks/backend-subnet",
  "network": "projects/project-id/global/networks/lb-network",
  "networkTier": "PREMIUM",
}

Test

VM-Instanz in der Zone zum Testen der Konnektivität erstellen

gcloud compute instances create l7-ilb-client-us-west1-b \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=us-west1-b \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=l7-ilb-client,allow-ssh

Melden Sie sich bei der Clientinstanz an, damit HTTP(S)-Services auf den Back-Ends über die IP-Adresse der Weiterleitungsregel des internen HTTP(S)-Load-Balancers erreichbar sind und der Traffic ausgeglichen auf die Endpunkte in der NEG verteilt wird.

Stellen Sie über SSH eine Verbindung zu jeder Clientinstanz her.

gcloud compute ssh l7-ilb-client-us-west1-b \
    --zone=us-west1-b

Prüfen Sie, ob die IP-Adresse ihren Hostnamen bereitstellt.

curl 10.1.2.199

Ersetzen Sie für HTTPS-Tests curl durch:

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443

Das Flag -k bewirkt, dass curl die Zertifikatsvalidierung überspringt.

Führen Sie 100 Anfragen aus und prüfen Sie, ob ein Load-Balancing stattfindet.

Bei HTTP:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl --silent 10.1.2.199)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Bei HTTPS:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Heterogene Services (VMs und Container) implementieren

Load-Balancer können Front-Ends für gemischte Kubernetes-Arbeitslasten und Nicht-Kubernetes-Arbeitslasten sein. Es könnte sich um einen Teil einer Migration von VMs zu Containern oder einer permanenten Architektur handeln, die von einem freigegebenen Load-Balancer profitiert. Dies kann durch Erstellen von Load-Balancern erreicht werden, die auf verschiedene Arten von Back-Ends abzielen, einschließlich eigenständiger NEGs.

VMs und Container im selben Back-End-Service

In diesem Beispiel wird gezeigt, wie Sie eine NEG erstellen, die auf eine vorhandene VM verweist, die eine Arbeitslast ausführt, und wie Sie diese NEG als weiteres Back-End eines vorhandenen backendService hinzufügen. Auf diese Weise wird durch einen einzigen Load-Balancer ein Lastenausgleich zwischen VMs und GKE-Containern durchgeführt.

Dieses Beispiel erweitert das obige Beispiel, das einen externen HTTP-Load-Balancer verwendet.

Da alle Endpunkte durch denselben backendService gruppiert werden, werden die VM- und die Containerendpunkte als derselbe Service betrachtet. Dies bedeutet, dass der Host/Pfad-Abgleich alle Back-Ends anhand der URL-Zuordnungsregeln identisch behandelt.

Wenn Sie in einem Back-End-Service eine NEG als Back-End verwenden, müssen auch alle anderen Back-Ends in diesem Service NEGs sein. Sie können in einem Back-End-Service nicht sowohl Instanzgruppen als auch NEGs als Back-Ends verwenden. Außerdem können Container und VMs nicht als Endpunkte in derselben NEG vorhanden sein, sodass sie immer mit separaten NEGs konfiguriert werden müssen.

1. Stellen Sie eine VM mit dem folgenden Befehl in Compute Engine bereit:

   gcloud compute instances create vm1 --zone zone --network=network \
    --subnet=subnet --image-project=cos-cloud \
    --image-family=cos-stable --tags=vm-neg-tag

2. Stellen Sie eine Anwendung auf der VM bereit:

   gcloud compute ssh vm1 --zone=${ZONE} --command="docker run -d --rm --network=host \
    k8s.gcr.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"

   Mit diesem Befehl wird auf der VM dieselbe Beispielanwendung wie im vorherigen Beispiel bereitgestellt. Der Einfachheit halber wird die Anwendung als Docker-Container ausgeführt. Dies ist jedoch nicht unbedingt erforderlich. Der Befehl iptables ist erforderlich, um Firewallzugriff auf den ausgeführten Container zuzulassen.

3. Prüfen Sie, ob die Anwendung auf Port 9376 Traffic bereitstellt und meldet, dass sie auf vm1 ausgeführt wird:

   gcloud compute ssh vm1 --zone=zone --command="curl -s localhost:9376"

   Der Server sollte mit vm1 antworten.

4. Erstellen Sie eine NEG zum Verwenden mit dem VM-Endpunkt. Container und VMs können zwar beide NEG-Endpunkte sein, aber eine einzelne NEG kann nicht sowohl VM- als auch Container-Endpunkte haben.

   gcloud compute network-endpoint-groups create vm-neg \
   --subnet=subnet --zone=zone

5. Hängen Sie den VM-Endpunkt an die NEG an:

   gcloud compute network-endpoint-groups update vm-neg --zone=zone \
    --add-endpoint="instance=vm1,ip=vm-primary-ip,port=9376"

6. Bestätigen Sie, dass die NEG den VM-Endpunkt hat:

   gcloud compute network-endpoint-groups list-network-endpoints vm-neg --zone zone

7. Hängen Sie die NEG mit dem gleichen Befehl, den Sie zum Hinzufügen eines Container-Back-Ends verwendet haben, an den Back-End-Service an:

   gcloud compute backend-services add-backend my-bes --global \
    --network-endpoint-group vm-neg \
    --network-endpoint-group-zone zone \
    --balancing-mode RATE --max-rate-per-endpoint 10

8. Öffnen Sie die Firewall, um die Systemdiagnose der VM zuzulassen:

   gcloud compute firewall-rules create fw-allow-health-check-to-vm1 \
   --network=network \
   --action=allow \
   --direction=ingress \
   --target-tags=vm-neg-tag \
   --source-ranges=130.211.0.0/22,35.191.0.0/16 \
   --rules=tcp:9376
   

9. Prüfen Sie, ob der Load-Balancer Traffic an das neue vm1-Back-End und das vorhandene Container-Back-End weiterleitet, indem Sie Test-Traffic senden:

   for i in `seq 1 100`; do curl ${VIP};echo; done

   Sie sollten Antworten von den Container- (neg-demo-app) und VM-Endpunkten (vm1) sehen.

VMs und Container für verschiedene Back-End-Services

In diesem Beispiel wird gezeigt, wie Sie eine NEG erstellen, die auf eine vorhandene VM verweist, die eine Arbeitslast ausführt, und wie Sie diese NEG einem neuen backendService als Back-End hinzufügen. Dies ist nützlich, wenn die Container und VMs unterschiedliche Services sind, aber denselben L7-Load-Balancer verwenden müssen, z. B. wenn die Services dieselbe IP-Adresse oder denselben Domainnamen haben.

Dieses Beispiel erweitert das vorherige Beispiel, bei dem ein VM-Back-End im selben Back-End-Service wie das Container-Back-End verwendet wurde. In diesem Beispiel wird jene VM wiederverwendet.

Da die Container- und VM-Endpunkte in separaten backendServices gruppiert sind, werden sie als unterschiedliche Services betrachtet. Dies bedeutet, dass die URL-Zuordnung Back-Ends abgleicht und den Traffic basierend auf dem Hostnamen an die VM oder den Container weiterleitet.

Das folgende Diagramm zeigt, wie eine einzelne virtuelle IP-Adresse zwei Hostnamen entspricht, die wiederum einem container- und einem VM-basierten Back-End-Service entsprechen.

Das folgende Diagramm zeigt die oben beschriebene Architektur:

1. Erstellen Sie für die VM einen neuen Back-End-Service:

   gcloud compute backend-services create my-vm-bes \
     --protocol HTTP \
     --health-checks http-basic-check \
     --global

2. Hängen Sie die NEG für die VM (vm-neg) an den Back-End-Service an:

   gcloud compute backend-services add-backend my-vm-bes --global \
    --network-endpoint-group vm-neg \
    --network-endpoint-group-zone zone \
    --balancing-mode RATE --max-rate-per-endpoint 10

3. Fügen Sie der URL-Zuordnung eine Hostregel hinzu, um Anfragen für den Host container.example.com an den Container-Back-End-Service weiterzuleiten:

   gcloud compute url-maps add-path-matcher web-map \
     --path-matcher-name=container-path --default-service=my-bes \
     --new-hosts=container.example.com --global
   

4. Fügen Sie der URL-Zuordnung eine weitere Hostregel hinzu, um Anfragen für den Host vm.example.com an den VM-Back-End-Service weiterzuleiten:

   gcloud compute url-maps add-path-matcher web-map \
     --path-matcher-name=vm-path --default-service=my-vm-bes \
     --new-hosts=vm.example.com --global
   

   Hinweis: Es dauert einige Minuten, bis der Load-Balancer vollständig programmiert ist.

5. Prüfen Sie, ob der Load-Balancer Traffic basierend auf dem angeforderten Pfad an das VM-Back-End sendet:

   curl -H "HOST:vm.example.com" virtual-ip

Einschränkungen von eigenständigen NEGs

• Fehler bei der Anmerkungsprüfung werden dem Nutzer über Kubernetes-Ereignisse angezeigt.
• Die Einschränkungen von NEGs gelten auch für eigenständige NEGs.
• Eigenständige NEGs funktionieren nicht mit Legacy-Netzwerken.
• Eigenständige NEGs können nur mit kompatiblen Netzwerkservices wie Traffic Director und den kompatiblen Load-Balancer-Typen verwendet werden.

Preise

Weitere Informationen zu den Preisen des Load-Balancers finden Sie auf der Preisseite im Abschnitt zum Load-Balancing. Für NEGs fallen keine zusätzlichen Gebühren an.

Fehlerbehebung

Keine eigenständige NEG konfiguriert

Problem: Es wird keine NEG erstellt.

Mögliche Lösung:

• Prüfen Sie die mit dem Service verknüpften Ereignisse und suchen Sie nach Fehlermeldungen.
• Prüfen Sie, ob die eigenständige NEG-Anmerkung im korrekten JSON-Format vorliegt und die freigegebenen Ports mit den vorhandenen Ports in der Servicespezifikation übereinstimmen.
• Sehen Sie sich die NEG-Statusanmerkung an und prüfen Sie, ob die erwarteten Serviceports entsprechende NEGs haben.
• Prüfen Sie mit dem Befehl gcloud compute network-endpoint-groups list, ob die NEGs in den erwarteten Zonen erstellt wurden.
• Wenn Sie die GKE-Version 1.18 oder höher verwenden, prüfen Sie, ob die SvcNeg-Ressource für den Dienst vorhanden ist. Falls ja, prüfen Sie die Bedingung Initialiazed auf Fehlerinformationen.
• Wenn Sie benutzerdefinierte NEG-Namen verwenden, müssen alle NEG-Namen in ihrer Region eindeutig sein.

Traffic erreicht die Endpunkte nicht

Problem: 502-Fehler oder abgelehnte Verbindungen

Mögliche Lösung:

• Nach der Konfiguration des Services sind neue Endpunkte in der Regel erreichbar, sobald sie der NEG zugeordnet wurden, vorausgesetzt, sie reagieren auf Systemdiagnosen.
• Wenn der Traffic die Endpunkte nach Ablauf dieser Zeit immer noch nicht erreicht, was zu einem Fehlercode 502 für HTTP(S)-Load-Balancing führt oder dazu, dass Verbindungen für TCP/SSL-Load-Balancer abgelehnt werden, prüfen Sie Folgendes:
  • Prüfen Sie, ob die Firewallregeln eingehenden TCP-Traffic an Ihre Endpunkte in den Bereichen 130.211.0.0/22 und 35.191.0.0/16 zulassen.
  • Prüfen Sie, ob die Endpunkte fehlerfrei sind, indem Sie gcloud verwenden oder die API getHealth für BackendService oder die listEndpoints API für die NEG aufrufen und dabei den Parameter "showHealth" auf SHOW setzen.

Einführung wurde angehalten

Problem: Das Einführen eines aktualisierten Deployments wird angehalten und die Anzahl der Replikate, die auf dem neuesten Stand sind, stimmt nicht mit der gewünschten Anzahl von Replikaten überein.

Mögliche Lösung:

Die Systemdiagnosen des Deployments können nicht ausgeführt werden. Möglicherweise ist das Container-Image fehlerhaft oder die Systemdiagnose falsch konfiguriert. Mit dem rollierenden Ersetzen der Pods wird gewartet, bis das Pod-Readiness-Gate des neu gestarteten Pods den Status "True" aufweist. Dies geschieht nur, wenn der Pod auf Load-Balancer-Systemdiagnosen reagiert. Wenn der Pod nicht reagiert oder die Systemdiagnose falsch konfiguriert ist, können die Bedingungen des Readiness-Gates nicht erfüllt werden und das Rollout kann nicht fortgesetzt werden.

• Wenn Sie kubectl ab Version 1.13 verwenden, können Sie den Status der Readiness-Gates eines Pods mit dem folgenden Befehl prüfen:

  kubectl get my-Pod -o wide

  Prüfen Sie die Spalte READINESS GATES.

  Diese Spalte ist in kubectl 1.12 und niedrigeren Versionen nicht vorhanden. Ein Pod, für den der Status READY angegeben wird, weist möglicherweise ein fehlgeschlagenes Readiness-Gate auf. Verwenden Sie den folgenden Befehl, um dies zu prüfen:

  kubectl get my-pod -o yaml

  Die Readiness-Gates und der Status der einzelnen Gates werden in der Ausgabe aufgeführt.

• Prüfen Sie, ob das in der Pod-Spezifikation Ihres Deployments genannte Container-Image richtig funktioniert und auf Systemdiagnosen reagieren kann.

• Prüfen Sie, ob die Systemdiagnosen korrekt konfiguriert sind.

NEG wird nicht automatisch bereinigt.

Symptom: Eine NEG, die gelöscht werden sollte, ist weiterhin vorhanden.

Mögliche Lösung:

• Die NEG wird nicht automatisch bereinigt, wenn ein Back-End-Dienst auf die NEG verweist. Weitere Informationen finden Sie unter Gehackte NEGs verhindern.
• Wenn Sie Version 1.18 oder höher verwenden, können Sie mit dieser Anleitung nach Ereignissen in der ServiceNetworkEndpointGroup-Ressource suchen.
• Prüfen Sie, ob die NEG noch von einem Dienst benötigt wird. Prüfen Sie die svcneg-Ressource auf den Dienst, der der NEG entspricht, und prüfen Sie, ob eine Dienstannotation vorhanden ist.

NEG wird nicht mit Dienst synchronisiert

Symptom: Die erwarteten Endpunkte sind nicht vorhanden oder die NEG scheint nicht synchronisiert zu sein

Mögliche Lösung:

Wenn Sie Version 1.18 oder höher verwenden, prüfen Sie die svcneg-Ressource auf Informationen:

• Prüfen Sie den Wert status.lastSyncTime, um festzustellen, ob die NEG kürzlich synchronisiert wurde.
• Prüfen Sie die Synced-Bedingung auf Fehler, die in der letzten Synchronisierung aufgetreten sind.

Nächste Schritte

• HTTP(S)-Load-Balancing-Konzepte
• Übersicht über zonale Netzwerk-Endpunktgruppen
• Back-End-Services
• Systemdiagnosen erstellen
• Zielproxys verwenden
• Weiterleitungsregeln verwenden