Containernatives Load-Balancing über eigenständige zonale NEGs

Autopilot Standard

---

Auf dieser Seite erfahren Sie, wie Sie einen Kubernetes-Service erstellen, der von einer zonalen GCE_VM_IP_PORT-Netzwerk-Endpunktgruppe (NEG) in einem VPC-nativen GKE-Cluster (Google Kubernetes Engine) unterstützt wird.

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

Übersicht

Eine NEG stellt eine Gruppe von Endpunkten dar. GKE unterstützt eigenständige NEGs vom Typ GCE_VM_IP_PORT. GCE_VM_IP_PORT-NEGs unterstützen Endpunkte entweder mit der primären internen IP-Adresse der VM oder mit einer IP-Adresse aus einem ihrer Alias-IP-Bereiche.

Im Kontext eines VPC-nativen GKE-Clusters mit eigenständigen NEGs ist jeder Endpunkt eine Pod-IP-Adresse und ein Zielport. Pod-IP-Adressen stammen aus dem Alias-IP-Bereich des Knotens für Pods, der aus dem sekundären Subnetz-IP-Adressbereich des Clusters für Pods stammt.

GKE bietet einen NEG-Controller, um die Mitgliedschaft von GCE_VM_IP_PORT-NEGs zu verwalten. Sie können die von ihm erstellten NEGs als Backends zu den Backend-Diensten für Load-Balancer hinzufügen, die Sie außerhalb der GKE API konfigurieren.

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 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 eine Option, wenn von Ingress verwaltete NEGs für Ihren Anwendungsfall nicht 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 nicht in Konflikt mit containernativem Load-Balancing, die für Ingress aktiviert sind.

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 der zugehörige NEG nicht automatisch bereinigt, wenn der NEG noch von einem Backend-Dienst referenziert wird. Damit die NEG gelöscht werden kann, entfernen Sie den Verweis für die NEG aus dem Backend-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 Backend 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.

Cloud Service Mesh mit GKE verwenden

Sie können Cloud Service Mesh mit GKE verwenden. Cloud Service Mesh nutzt eigenständige NEGs, um containernatives Load-Balancing für das verwaltete Service Mesh.

Externe Proxy-Network Load Balancer mit GKE verwenden

Sie können eigenständige NEGs verwenden, um die Last mit dem externen Proxy-Network 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

Der Cluster muss VPC-nativ sein. Weitere Informationen finden Sie unter VPC-nativen Cluster erstellen.

Für den Cluster muss das Add-on HttpLoadBalancing aktiviert sein. In GKE-Clustern ist das Add-on HttpLoadBalancing standardmäßig aktiviert.

Hinweis

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

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Eigenständige NEGs verwenden

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

Sie müssen die folgenden Objekte erstellen:

• 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 Backend-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

Autopilot-Cluster sind standardmäßig VPC-nativ, sodass Sie mit Arbeitslast bereitstellen fortfahren können.

Erstellen Sie für Standardcluster einen VPC-nativen Cluster in der Zone us-central1-a:

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

Deployment erstellen

Die folgenden Beispielmanifeste geben Deployments an, die drei Instanzen eines containerisierten HTTP-Servers ausführen. Der HTTP-Server antwortet auf Anfragen mit dem Hostnamen des Anwendungsservers, dem Namen des Pods, auf dem der Server ausgeführt wird.

Wir empfehlen Ihnen, Arbeitslasten zu verwenden, bei denen Pod-Bereitschaftsfeedback zum Einsatz kommt.

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: registry.k8s.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: registry.k8s.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, indem Sie folgenden Befehl ausführen:

kubectl apply -f neg-demo-app.yaml

Service erstellen

Das folgende Manifest gibt einen Service an, wobei gilt:

• 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

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

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

In GKE-Versionen 1.18.18-gke.1200 und höher können Sie einen benutzerdefinierten Namen für NEGs angeben. GKE kann den Namen auch automatisch generieren. In früheren Versionen von GKE werden nur automatisch generierte NEG-Namen unterstützt.

GKE erstellt in jeder vom Cluster verwendeten Zone eine NEG. Die NEGs verwenden alle denselben Namen.

Name angeben

Das Angeben eines benutzerdefinierten NEG-Namens vereinfacht das Konfigurieren des Load-Balancers, da Sie den Namen und die Zonen der NEGs kennen. Benutzerdefinierte NEG-Namen müssen die folgenden Anforderungen erfüllen:

• für zonale Cluster einmalig in der Zone des Clusters oder für regionale Cluster eindeutig sein

• darf nicht mit dem Namen einer vorhandenen NEG übereinstimmen, die nicht vom GKE NEG-Controller erstellt wurde.
• darf keine Unterstriche enthalten.

Hinweis: Wenn ein Namenskonflikt auftritt, schlägt die NEG-Erstellung oder -Synchronisierung fehl. Informationen zur Fehlerbehebung finden Sie unter NEG wird nicht mit Dienst synchronisiert.

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

Automatisch generierte NEG-Namen sind immer eindeutig. 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":{},
      ...
   }
 }'

In diesem Beispiel ist jede Instanz von SERVICE_PORT_N eine eindeutige Portnummer, die auf vorhandene Dienstports des Dienstes verweist. Für jeden aufgeführten Dienstport erstellt der NEG-Controller eine NEG in jeder Zone, die der Cluster belegt.

NEG-Status abrufen

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

kubectl get service neg-demo-svc -o yaml

Die entsprechende Ausgabe sieht etwa so aus:

cloud.google.com/neg-status: '{
   "network-endpoint-groups":{
      "SERVICE_PORT_1": "NEG_NAME_1",
      "SERVICE_PORT_2": "NEG_NAME_2",
      ...
   },
   "zones":["ZONE_1", "ZONE_2", ...]
}

In dieser Ausgabe 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.

Die Ausgabe sieht in etwa so aus:

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":["ZONE_1", "ZONE_2"]}'
  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 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 Service-Ereignis gemeldet. Weitere Informationen erhalten Sie, wenn Sie das Service-Objekt abfragen:

kubectl describe service SERVICE_NAME

Ersetzen Sie SERVICE_NAME durch den Namen des 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 der GKE-Version 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 den folgenden Befehl, um die NEGs aufzulisten:

gcloud compute network-endpoint-groups list

Die entsprechende Ausgabe sieht etwa so aus:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      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 dem folgenden Befehl:

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

Ersetzen Sie NEG_NAME durch den Namen der NEG, für die Sie die einzelnen Endpunkte anzeigen möchten.

Die Ausgabe enthält drei Endpunkte, die jeweils die IP-Adresse und den Port eines Pods haben:

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

Externen Application Load Balancer an eigenständige NEGs anhängen

Sie können NEGs als Backend für einen externen Application Load Balancer verwenden. Verwenden Sie dazu die Compute Engine API.

1. Erstellen Sie eine Firewallregel. Load-Balancer müssen auf Clusterendpunkte zugreifen, um Systemdiagnosen ausführen zu können. Mit diesem Befehl wird eine Firewallregel erstellt, um den Zugriff zuzulassen:

   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 gilt:

   • NETWORK_NAME: Das Netzwerk, in dem der Cluster ausgeführt wird.
   • GKE_NODE_NETWORK_TAGS: Die Netzwerk-Tags der GKE-Knoten.

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

   gcloud compute instances describe INSTANCE_NAME
   

   Ersetzen Sie INSTANCE_NAME durch den Namen der Compute Engine-Hostinstanz der VM, auf der der GKE-Knoten ausgeführt wird. Beispielsweise werden bei der Ausgabe im vorherigen Abschnitt die Instanznamen in der Spalte INSTANCE für die GKE-Knoten angezeigt. Bei Standardclustern können Sie auch gcloud compute instances list ausführen, um alle Instanzen in Ihrem Projekt aufzulisten.

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 Backend-Dienst, der angibt, dass es sich um einen globalen externen Application 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
   

   Ersetzen Sie HOSTNAME_SERVER_VIP durch die IP-Adresse, die für den Load-Balancer verwendet werden soll. Wenn Sie --address weglassen, weist GKE automatisch eine sitzungsspezifische IP-Adresse zu. Sie können auch eine neue statische externe IP-Adresse reservieren.

Logo: Check Point

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 Backend-Dienst
• 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 Dienste 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 Frontend-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 Backend des Backend-Dienstes my-bes hinzu:

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

Dabei gilt:

• NEG_NAME: Der Name Ihrer 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.
• NEG_ZONE: 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  ZONE_NAME      GCE_VM_IP_PORT  3

In dieser Beispielausgabe lautet der Name der NEG k8s1-70aa83a6-default-my-service-80-c9710a6f.

Einem Backend-Dienst können mehrere NEGs hinzugefügt werden. Für globale Backend-Dienste wie my-bes sind NEG-Backends in mehreren Regionen möglich, während regionale Backend-Dienste nur Backends 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, um zu prüfen, ob der eingerichtete Load-Balancer funktioniert:

• Prüfen Sie, ob die Systemdiagnose richtig konfiguriert und fehlerfrei ist.
• Greifen Sie auf die Anwendung zu und prüfen Sie deren Antwort.

Systemdiagnosen prüfen

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

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

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

Die entsprechende Ausgabe sieht etwa so aus:

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 sieht in etwa so aus:

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-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 Application Load Balancer an eigenständige NEGs anhängen

Sie können mit NEGs einen internen Application Load Balancer für Ihre Dienste konfigurieren, die in eigenständigen GKE-Pods ausgeführt werden.

Nur-Proxysubnetz konfigurieren

Das Nur-Proxy-Subnetz ist für alle regionalen internen Application Load Balancer in der Region des Load Balancers vorgesehen.

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 Backend-Instanzen werden aus einem oder mehreren anderen Subnetzbereichen als dem Nur-Proxy-Subnetz zugewiesen. Google Cloud reserviert diesen Subnetzbereich für Proxys, die von Google Cloud verwaltet werden.

Console

Wenn Sie die Google Cloud Console verwenden, können Sie das Nur-Proxy-Subnetz später erstellen.

gcloud

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

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

Ersetzen Sie COMPUTE_REGION durch die Compute Engine für das Subnetz.

API

Erstellen Sie das Nur-Proxy-Subnetz mit der Methode subnetworks.insert.

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/COMPUTE_REGION",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

Ersetzen Sie Folgendes:

• PROJECT_ID: Ihre Projekt-ID.
• COMPUTE_REGION: die Compute Engine für das Subnetz.

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 Quell-IP-Bereich für diese Regel auswählen. Sie können beispielsweise nur die IP-Bereiche des Systems angeben, 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 die TCP-Traffic auf Port 9376 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 Firewallrichtlinien auf.

   Zu den Firewall-Richtlinien

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: IPv4 ranges
   • IPv4-Quellbereiche: 0.0.0.0/0
   • Protokolle und Ports:
     • Wählen Sie Angegebene Protokolle und Ports aus.
     • Klicken Sie auf das Kästchen tcp und geben Sie den Port 22 an.

3. Klicken Sie auf Erstellen.

4. Klicken Sie noch einmal auf Firewallregel erstellen , um die Regel zu erstellen, die Google Cloud-Systemdiagnosen zulässt:

   • Name: fw-allow-health-check
   • Netzwerk: lb-network
   • Trafficrichtung: Eingehend
   • Aktion bei Übereinstimmung: Zulassen
   • Ziele: Angegebene Ziel-Tags
   • Ziel-Tags: load-balanced-backend
   • Quellfilter: IPv4 ranges
   • IPv4-Quellbereiche: 130.211.0.0/22 und 35.191.0.0/16
   • Protokolle und Ports:
     • Wählen Sie Angegebene Protokolle und Ports aus.
     • Klicken Sie auf das Kästchen tcp und geben Sie den Port 80 an. 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 noch einmal 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: IPv4 ranges
   • IPv4-Quellbereiche: 10.129.0.0/23
   • Protokolle und Ports:
     • Wählen Sie Angegebene Protokolle und Ports aus.
     • Klicken Sie auf das Kästchen tcp und geben Sie den Port 9376 an.

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:9376
   

API

Erstellen Sie die Firewallregel fw-allow-ssh. Stellen Sie dazu eine POST-Anfrage an die Methode firewalls.insert.

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"
}

Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

Erstellen Sie die Firewallregel fw-allow-health-check. Stellen Sie dazu eine POST-Anfrage an die Methode firewalls.insert.

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 Firewallregel fw-allow-proxies, um TCP-Traffic innerhalb des Proxy-Subnetzes für die Methode firewalls.insert zuzulassen.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/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": [
        "9376"
      ]
    }
  ],
  "direction": "INGRESS"
}

Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

Load-Balancer konfigurieren

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

Console

Load-Balancer-Typ auswählen

1. Rufen Sie in der Google Cloud Console die Seite Load-Balancer erstellen auf. Zur Seite Load-Balancer erstellen
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 als Region die Region aus, in der Sie das Subnetz erstellt haben.
3. Wählen Sie lb-network als Netzwerk aus.

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 Backend-Service konfigurieren fort.

Reservieren Sie ein Nur-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.

Backend-Dienst konfigurieren

1. Klicken Sie auf Backend-Konfiguration.
2. Wählen Sie im Menü Backend-Dienst erstellen oder auswählen die Option Backend-Dienst erstellen aus.
3. Legen Sie als Name für den Backend-Dienst l7-ilb-gke-backend-service fest.
4. Wählen Sie unter Backend-Typ Netzwerk-Endpunktgruppen aus.
5. In the New backend card of the Backends section:
   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 für Maximale Anzahl der Anfragen pro Sekunde eine maximale Rate von 5 RPS pro Endpunkt an. Google Cloud überschreitet diesen Höchstwert bei Bedarf.
   3. Klicken Sie auf Fertig.
6. Wählen Sie in der Drop-down-Liste Systemdiagnose die Option Systemdiagnose erstellen aus und geben Sie dann die folgenden Parameter an:
   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 Routingregeln. Vergewissern Sie sich, dass der l7-ilb-gke-backend-service der einzige Backend-Service für alle nicht übereinstimmenden Hosts und alle nicht übereinstimmenden Pfade ist.

Frontend konfigurieren

Klicken Sie auf Frontend-Konfiguration und führen Sie die folgenden Schritte aus:

Bei HTTP:

1. Klicken Sie auf Frontend-Konfiguration.
2. Klicken Sie auf Frontend-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 nicht von internen HTTP(S)-Load-Balancern unterstützt.

1. Klicken Sie auf Front-End-Konfiguration.
2. Klicken Sie auf Frontend-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 Anleitung.
11. Klicken Sie auf Fertig.

Konfiguration abschließen

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=COMPUTE_REGION \
       --use-serving-port
   

2. Definieren Sie den Backend-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=COMPUTE_REGION \
       --region=COMPUTE_REGION
   

3. Legen Sie die Variable DEPLOYMENT_NAME fest.

   export DEPLOYMENT_NAME=NEG_NAME
   

   Ersetzen Sie NEG_NAME durch den Namen des Clusters.

4. Fügen Sie dem Backend-Dienst NEG-Backends 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=COMPUTE_ZONE-b \
       --region=COMPUTE_REGION \
       --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=COMPUTE_REGION
   

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=COMPUTE_REGION \
       --region=COMPUTE_REGION
   

   Bei HTTPS:

   Informationen zum Erstellen von SSL-Zertifikatressourcen finden Sie unter SSL-Zertifikate. Von Google verwaltete Zertifikate werden 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=COMPUTE_REGION
   

   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=COMPUTE_REGION \
       --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=COMPUTE_REGION \
       --target-http-proxy=l7-ilb-gke-proxy \
       --target-http-proxy-region=COMPUTE_REGION
   

   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=COMPUTE_REGION \
       --target-https-proxy=l7-ilb-gke-proxy \
       --target-https-proxy-region=COMPUTE_REGION
   

API

Erstellen Sie die Systemdiagnose. Stellen Sie dazu eine POST-Anfrage an die Methode regionHealthChecks.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks

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

Ersetzen Sie PROJECT_ID durch die Projekt-ID.

Erstellen Sie den regionalen Backend-Dienst. Stellen Sie dazu eine POST-Anfrage an die Methode regionBackendServices.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices

{
  "name": "l7-ilb-gke-backend-service",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/networkEndpointGroups/NEG_NAME",
      "balancingMode": "RATE",
      "maxRatePerEndpoint": 5
    }
  ],
  "healthChecks": [
    "projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks/l7-ilb-gke-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

Dabei gilt:

• PROJECT_ID: die Projekt-ID.
• NEG_NAME: Der Name der NEG.

Erstellen Sie die URL-Zuordnung mit einer POST-Anfrage an die Methode regionUrlMaps.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/urlMaps

{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices/l7-ilb-gke-backend-service"
}

Ersetzen Sie PROJECT_ID durch die Projekt-ID.

Erstellen Sie den HTTP-Zielproxy. Stellen Sie dazu eine POST-Anfrage an die Methode regionTargetHttpProxies.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxy

{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-gke-map",
  "region": "COMPUTE_REGION"
}

Ersetzen Sie PROJECT_ID durch die Projekt-ID.

Erstellen Sie die Weiterleitungsregel. Stellen Sie dazu eine POST-Anfrage an die Methode forwardingRules.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/forwardingRules

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

Ersetzen Sie PROJECT_ID durch die Projekt-ID.

Test

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

gcloud compute instances create l7-ilb-client \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=COMPUTE_ZONE \
    --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 Application Load Balancer erreichbar sind und der Traffic ausgeglichen auf die Endpunkte in der NEG verteilt wird.

Stellen Sie eine SSH-Verbindung zu jeder Clientinstanz her:

gcloud compute ssh l7-ilb-client \
    --zone=COMPUTE_ZONE-b

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

curl 10.1.2.199

Führen Sie für HTTPS-Tests den folgenden Befehl aus:

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

Das Flag -k bewirkt, dass curlcurl 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 Backend-Dienst

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 Backend 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 vorherige Beispiel, das einen externen HTTP-Load-Balancer verwendet.

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

Wenn Sie in einem Backend-Dienst eine NEG als Backend verwenden, müssen auch alle anderen Backends in diesem Dienst NEGs sein. Sie können in einem Backend-Dienst nicht sowohl Instanzgruppen als auch NEGs als Backends 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=COMPUTE_ZONE \
       --network=NETWORK \
       --subnet=SUBNET \
       --image-project=cos-cloud \
       --image-family=cos-stable --tags=vm-neg-tag
   

   Dabei gilt:

   • COMPUTE_ZONE: Der Name der Zone.
   • NETWORK: Der Name des Netzwerks.
   • SUBNET: Der Name des Subnetzes, das dem Netzwerk zugeordnet ist.

2. Stellen Sie eine Anwendung auf der VM bereit:

   gcloud compute ssh vm1 \
       --zone=COMPUTE_ZONE \
       --command="docker run -d --rm --network=host registry.k8s.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=COMPUTE_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=COMPUTE_ZONE
   

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

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

   Ersetzen Sie VM_PRIMARY_IP durch die primäre IP-Adresse der VM.

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

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

7. Hängen Sie die NEG mit dem gleichen Befehl, den Sie zum Hinzufügen eines Container-Backends verwendet haben, an den Backend-Dienst an:

   gcloud compute backend-services add-backend my-bes
       --global \
       --network-endpoint-group vm-neg \
       --network-endpoint-group-zone COMPUTE_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-Backend und das vorhandene Container-Backend 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 Backend-Dienste

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 Backend 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-Backend im selben Backend-Dienst wie das Container-Backend verwendet wurde. In diesem Beispiel wird jene VM wiederverwendet.

Da die Container- und VM-Endpunkte in separaten Backend-Diensten gruppiert sind, werden sie als unterschiedliche Dienste 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 Backend-Service entsprechen.

Das folgende Diagramm zeigt die im vorherigen Abschnitt beschriebene Architektur:

1. Erstellen Sie für die VM einen neuen Backend-Dienst:

   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 Backend-Dienst an:

   gcloud compute backend-services add-backend my-vm-bes \
       --global \
       --network-endpoint-group vm-neg \
       --network-endpoint-group-zone COMPUTE_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-Backend-Dienst 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-Backend-Dienst 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-Backend sendet:

   curl -H "HOST:vm.example.com" VIRTUAL_IP
   

   Ersetzen Sie VIRTUAL_IP durch die virtuelle IP-Adresse.

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 Netzwerkdiensten wie Cloud Service Mesh und dem 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

In diesem Abschnitt werden Schritte zur Fehlerbehebung von häufigen Problemen beschrieben, die bei eigenständigen NEGs auftreten können.

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 Ressource svcneg für den Dienst vorhanden ist. Falls ja, prüfen Sie die Bedingung Initialized 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. Verwenden Sie dazu das Google Cloud CLI oder rufen Sie die getHealth API im backendService oder die listEndpoints API in der NEG auf, wobei Sie den Parameter "showHealth" auf SHOW einstellen.

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 Backend-Dienst auf die NEG verweist. Weitere Informationen finden Sie unter Geleakte NEGs verhindern.
• Wenn Sie Version 1.18 oder höher verwenden, können Sie in der ServiceNetworkEndpointGroup-Ressource mithilfe des Verfahrens zur Dienstablehnung nach Events suchen.
• Prüfen Sie, ob die NEG noch von einem Dienst benötigt wird. Prüfen Sie die Ressource svcneg für den Dienst, der der NEG entspricht, und überprüfen Sie, ob eine Dienstannotation vorhanden ist.

NEG wird nicht mit Dienst synchronisiert

Symptom: Erwartete (Pod-IP)-Endpunkte sind in der NEG nicht vorhanden, werden nicht synchronisiert oder sind der Fehler Failed to sync NEG_NAME (will not retry): neg name NEG_NAME is already in use, found a custom named neg with an empty description

Mögliche Lösung:

Wenn Sie die GKE-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.

Wenn Sie GKE 1.19.9 oder höher verwenden, prüfen Sie, ob eine NEG vorhanden ist, deren Name und Zone mit dem Namen und der Zone der NEG übereinstimmen, die der GKE-NEG-Controller erstellen muss. Beispielsweise kann eine NEG mit dem Namen, den der NEG-Controller verwenden muss, mit der gcloud CLI oder der Google Cloud Console in der Zone des Clusters (oder einer der Zonen des Clusters) erstellt worden sein. In diesem Fall müssen Sie die vorhandene NEG löschen, bevor der NEG-Controller seine Endpunkte synchronisieren kann. Erstellung und Mitgliedschaft eigenständiger NEGs ist für die Verwaltung durch den NEG-Controller konzipiert.

Nächste Schritte

• Übersicht über zonale Netzwerk-Endpunktgruppen
• Backend-Dienste
• Systemdiagnosen erstellen
• Zielproxys verwenden
• Weiterleitungsregeln verwenden