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.

Kubernetes-Services entsprechen Compute Engine-Netzwerk-Endpunktgruppen, während Kubernetes-Pods Compute Engine-Netzwerkendpunkten entsprechen. Dies wird von der NEG-Controller-Komponente der Steuerungsebene verwaltet.

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:

Bei eigenständigen NEGs und von Ingress verwalteten NEGs verwaltet der NEG-Controller auf der GKE-Steuerungsebene die NEG- und Netzwerk-Endpunktobjekte. Bei eigenständigen NEGs werden alle anderen Komponenten vom Nutzer verwaltet, wie in den vorherigen Abschnitten erläutert.

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

Sie können Traffic Director mit GKE verwenden. 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.

Hinweis

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

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 für zonale Cluster oder eine Region für regionale oder Autopilot-Cluster aus.

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 Standardzone für Compute Engine fest:
    gcloud config set compute/zone COMPUTE_ZONE
  • Wenn Sie mit Autopilot oder regionalen Clustern arbeiten, legen Sie die Compute-Standardregion fest:
    gcloud config set compute/region COMPUTE_REGION
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update

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:

Diagramm: Die Komponenten eines Load-Balancers sind eine Weiterleitungsregel, ein Ziel-HTTP-Proxy, eine URL-Zuordnung, eine Systemdiagnose und ein Back-End-Service. Dadurch wird der Traffic an eine NEG weitergeleitet, die Pod-IP-Adressen enthält.

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

Ersetzen Sie VERSION durch die Versionsnummer des Clusters. Die Version muss 1.6.4 oder höher 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, indem 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

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

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 Folgendes gewährleisten:

  • NEG-Namen sind für eine bestimmte Region eindeutig.
  • Die NEG wurde nicht bereits außerhalb des Ingress-Controllers erstellt.

Andernfalls schlagen die NEG-Erstellung und die Synchronisierung fehl. Weitere Informationen finden Sie unter NEG wird nicht mit Dienst synchronisiert. 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":{},
      ...
   }
 }'

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 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_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.

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 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 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 \
    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-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

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

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

    Ersetzen Sie HOSTNAME_SERVER_VIP durch 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-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 Front-End-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 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  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-Dienste wie my-bes sind NEG-Back-Ends in mehreren Regionen möglich, während regionale Back-End-Dienste nur Back-Ends in einer einzelnen Region haben können.

Funktionieren des Load-Balancers prüfen

Es gibt zwei Möglichkeiten, um zu prüfen, ob der eingerichtete Load-Balancer funktioniert:

  1. Prüfen Sie, ob die Systemdiagnose richtig konfiguriert und fehlerfrei ist.
  2. 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.

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 Dienste, 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.

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-Proxy-Subnetz mit der Methode subnetworks.insert.

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

Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

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

Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

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

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
    

    Ersetzen Sie NEG_NAME durch den Namen des Clusters.

  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. Stellen Sie dazu eine POST-Anfrage an die Methode regionHealthChecks.insert.

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

Ersetzen Sie PROJECT_ID durch die Projekt-ID.

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

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/us-west1/urlMaps
{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/PROJECT_ID/regions/us-west1/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/us-west1/targetHttpProxy
{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/project-id/global/urlMaps/l7-ilb-gke-map",
  "region": "us-west1"
}

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

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

Diagramm: Diagramm der oben beschriebenen Architektur. Der zuvor erstellte Load-Balancer verweist auf zwei NEGs, die zuvor erstellte NEG für Container und eine neue NEG, die die IP-Adresse einer VM enthält.

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

    Dabei gilt:

    • 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=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"

    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=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 Back-End-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 Back-End-Service entsprechen.

Das folgende Diagramm zeigt die oben beschriebene Architektur:

Diagramm: Die Architektur verfügt über zwei NEGs, eine für den in Container implementierten Service und eine für den in VMs implementierten Service. Für jede NEG gibt es ein Back-End-Dienstobjekt. Das URL-Zuordnungsobjekt leitet den Traffic basierend auf der angeforderten URL an den richtigen Back-End-Service weiter.

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

    Ersetzen Sie VIRTUAL_IP durch die virtuelle IP-Adresse.

Einschränkungen von eigenständigen NEGs

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 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 dafür gcloud oder rufen Sie die getHealth API für backendService oder die listEndpoints API auf der NEG auf, wobei der Parameter „showHealth” auf SHOW gesetzt ist.

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 Geleakte 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 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 Endpunkte sind nicht vorhanden, die NEG wird nicht synchronisiert oder 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 NEG noch nicht außerhalb des Ingress-Controllers erstellt wurde. Wenn die NEG zuvor über gcloud oder die Cloud Console erstellt wurde, löschen Sie die NEG. Der Ingress-Controller wird sie dann automatisch neu erstellen. Dadurch kann die Synchronisierung fortgesetzt werden.

Nächste Schritte