Internen TCP/UDP-Load-Balancer verwenden

Auf dieser Seite wird erläutert, wie Sie einen internen TCP/UDP-Load-Balancer von Compute Engine in Google Kubernetes Engine erstellen.

Übersicht

Das interne TCP/UDP-Load-Balancing macht die Dienste Ihres Clusters für Anwendungen außerhalb des Clusters zugänglich. Dabei müssen die Anwendungen dasselbe VPC-Netzwerk verwenden und sich in derselben Google Cloud-Region befinden. Angenommen, Sie haben einen Cluster in der Region us-west1 und müssen einen der Dienste für Compute Engine-VM-Instanzen zugänglich machen, die in dieser Region im selben VPC-Netzwerk ausgeführt werden.

Sie können einen internen TCP/UDP-Load-Balancer erstellen, indem Sie eine Dienstressource mit einer type: LoadBalancer-Spezifikation und einer Annotation erstellen. Die Annotation hängt von der Version des GKE-Clusters ab.

Ab GKE-Version 1.17 verwenden Sie die Annotation networking.gke.io/load-balancer-type: "Internal".

Für frühere Versionen verwenden Sie die Annotation cloud.google.com/load-balancer-type: "Internal".

Ohne internes TCP/UDP-Load-Balancing müssten Sie einen externen Load-Balancer und Firewallregeln einrichten, um die Anwendung außerhalb des Clusters zugänglich zu machen.

Das interne TCP/UDP-Load-Balancing erstellt eine interne IP-Adresse für den Dienst, der Traffic von Clients im selben VPC-Netzwerk und in derselben Compute Engine-Region empfängt. Wenn Sie den globalen Zugriff aktivieren, können Clients in jeder Region desselben VPC-Netzwerks auf den Dienst zugreifen. Darüber hinaus können Clients in einem VPC-Netzwerk, das über VPC-Netzwerk-Peering mit dem Load-Balancer verbunden ist, ebenfalls auf den Service zugreifen.

Preise

Die Abrechnung erfolgt nach dem Preismodell von Compute Engine. Weitere Informationen finden Sie unter den Preisen für Load-Balancing und Weiterleitungsregeln und im Google Cloud-Preisrechner auf der Seite für Compute Engine.

Vorbereitung

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

Deployment erstellen

Das folgende Manifest beschreibt ein Deployment, das drei Replikate einer Hello-World-Anwendung ausführt.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
spec:
  selector:
    matchLabels:
      app: hello
  replicas: 3
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: "gcr.io/google-samples/hello-app:2.0"

Der Quellcode und das Dockerfile für diese Beispielanwendung sind auf GitHub verfügbar. Da keine PORT-Umgebungsvariable angegeben ist, überwachen die Container den Standardport 8080.

Für das Deployment erstellen Sie die Datei my-deployment.yaml aus dem Manifest und führen dann den folgenden Befehl in Ihrem Shell- oder Terminalfenster aus:

kubectl apply -f my-deployment.yaml

Internen TCP-Load-Balancer erstellen

In den folgenden Abschnitten wird erläutert, wie Sie einen internen TCP-Load-Balancer mithilfe eines Dienstes erstellen.

Dienstkonfigurationsdatei schreiben

Im Folgenden sehen Sie ein Beispiel für einen Dienst, der einen internen TCP-Load-Balancer erstellt:

apiVersion: v1
kind: Service
metadata:
  name: ilb-service
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
  labels:
    app: hello
spec:
  type: LoadBalancer
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Mindestanforderungen des Dienstes

Ihr Manifest muss Folgendes enthalten:

  • Einen Namen (name) für den Dienst, in diesem Fall ilb-service.
  • Eine Anmerkung, die einen internen TCP/UDP-Load-Balancer angibt. Die Annotation hängt von der Version des GKE-Clusters ab. Ab GKE-Version 1.17 verwenden Sie die Annotation networking.gke.io/load-balancer-type: "Internal". Für frühere Versionen verwenden Sie die Annotation cloud.google.com/load-balancer-type: "Internal".
  • Das Feld type: LoadBalancer.
  • Das Feld spec: selector zur Angabe der Pods, auf die der Dienst ausgerichtet werden soll, z. B. app: hello.
  • Den port, über den der Dienst verfügbar gemacht wird, und den targetPort, den die Container überwachen.

Dienst bereitstellen

Erstellen Sie zum Einrichten des internen TCP-Load-Balancers die Datei my-service.yaml aus dem Manifest und führen Sie dann den folgenden Befehl in Ihrem Shell- oder Terminalfenster aus:

kubectl apply -f my-service.yaml

Dienst prüfen

Prüfen Sie den Dienst nach dem Deployment, um seine erfolgreiche Konfiguration zu bestätigen.

Rufen Sie detaillierte Informationen zum Dienst ab:

kubectl get service ilb-service --output yaml

In der Ausgabe sehen Sie unter status.loadBalancer.ingress die IP-Adresse des internen Load-Balancers. Dieser Wert unterscheidet sich vom Wert für clusterIP. In diesem Beispiel lautet die IP-Adresse des Load-Balancers 10.128.15.193:

apiVersion: v1
kind: Service
metadata:
  ...
  labels:
    app: hello
  name: ilb-service
  ...
spec:
  clusterIP: 10.0.9.121
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 30835
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: hello
  sessionAffinity: None
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 10.128.15.193

Jeder Pod mit dem Label app: hello ist Mitglied dieses Dienstes. Diese Pods können die endgültigen Empfänger von Anfragen sein, die an Ihren internen Load-Balancer gesendet werden.

Clients rufen den Dienst über die loadBalancer-IP-Adresse und den im Feld port des Dienstmanifests angegebenen TCP-Port auf. Die Anfrage wird an einen der Mitglieds-Pods an dem TCP-Port weitergeleitet, der im Feld targetPort angegeben ist. Für das obige Beispiel ruft ein Client den Dienst unter 10.128.15.193 über TCP-Port 80 auf. Die Anfrage wird über TCP-Port 8080 an einen der Mitglieds-Pods weitergeleitet. Beachten Sie, dass der Mitglieds-Pod einen den Port 8080 überwachenden Container benötigt.

Der nodePort-Wert 30835 ist für Ihren internen Load-Balancer irrelevant.

Weiterleitungsregel des Load-Balancers ansehen

Ein interner Load-Balancer wird als Weiterleitungsregel implementiert. Die Weiterleitungsregel hat einen Back-End-Dienst mit einer Instanzgruppe.

Die Adresse des internen Load-Balancers im vorherigen Beispiel (10.128.15.193) ist mit der Adresse der Weiterleitungsregel identisch. Zum Aufrufen der Weiterleitungsregel, die den internen Load-Balancer implementiert, listen Sie zuerst alle Weiterleitungsregeln in Ihrem Projekt auf:

gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"

Suchen Sie dann in der Ausgabe nach der Weiterleitungsregel, die dieselbe Adresse wie Ihr interner Load-Balancer hat, in diesem Beispiel also 10.128.15.193.

NAME                          ... IP_ADDRESS  ... TARGET
...
aae3e263abe0911e9b32a42010a80008  10.128.15.193   us-central1/backendServices/aae3e263abe0911e9b32a42010a80008

Die Ausgabe zeigt den zugehörigen Back-End-Dienst, der in diesem Beispiel ae3e263abe0911e9b32a42010a80008 lautet.

Beschreiben Sie den Back-End-Dienst:

gcloud compute backend-services describe aae3e263abe0911e9b32a42010a80008 --region us-central1

Die Ausgabe zeigt die zugehörige Instanzgruppe, die in diesem Beispiel k8s-ig--2328fa39f4dc1b75 lautet:

backends:
- balancingMode: CONNECTION
  group: .../us-central1-a/instanceGroups/k8s-ig--2328fa39f4dc1b75
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...

So funktioniert die Dienstabstraktion

Wenn die Weiterleitungsregel ein Paket verarbeitet, wird dieses Paket an einen der Clusterknoten weitergeleitet. Wenn das Paket den Clusterknoten erreicht, lauten die Adressen und der Port wie folgt:

IP-Adresse des Ziels Weiterleitungsregel, in diesem Beispiel 10.128.15.193
TCP-Port des Ziels Dienst-port-Feld 80 in diesem Beispiel

Beachten Sie, dass die Weiterleitungsregel, also der interne Load-Balancer, die Ziel-IP-Adresse oder den Zielport nicht ändert. Stattdessen wird das Paket von iptables-Regeln im Clusterknoten an einen geeigneten Pod weitergeleitet. Die iptables-Regeln ändern die Ziel-IP-Adresse in eine Pod-IP-Adresse und den Zielport in den targetPort-Wert des Dienstes, der in diesem Beispiel 8080 lautet.

Internen TCP-Load-Balancer prüfen

Stellen Sie eine SSH-Verbindung zu einer VM-Instanz her und führen Sie den folgenden Befehl aus:

curl load-balancer-ip

Dabei ist load-balancer-ip Ihre LoadBalancer Ingress-IP-Adresse.

Die Antwort zeigt die Ausgabe von hello-app:

Hello, world!
Version: 2.0.0
Hostname: hello-app-77b45987f7-pw54n

Wenn Sie den Befehl von außerhalb desselben VPC-Netzwerks oder außerhalb derselben Region ausführen, tritt ein Zeitüberschreitungsfehler auf. Wenn Sie den globalen Zugriff konfigurieren, können Clients in jeder Region im selben VPC-Netzwerk auf den Load-Balancer zugreifen.

Bereinigen

Sie können das Deployment und den Dienst mit kubectl delete oder der Cloud Console löschen.

kubectl

Deployment löschen

Führen Sie zum Löschen des Deployments den folgenden Befehl aus:

kubectl delete deployment hello-app

Dienst löschen

Führen Sie zum Löschen des Dienstes den folgenden Befehl aus:

kubectl delete service ilb-service

Console

Deployment löschen

Führen Sie zum Löschen des Deployments die folgenden Schritte aus:

  1. Rufen Sie in der Cloud Console die Seite Arbeitslasten auf.

    Zu "Arbeitslasten"

  2. Wählen Sie das Deployment aus, das Sie löschen möchten, und klicken Sie auf Löschen.

  3. Klicken Sie zur Bestätigung auf das Kästchen neben Horizontales Pod-Autoscaling löschen, das mit der ausgewählten Bereitstellung verknüpft ist, und klicken Sie dann auf Löschen.

Dienst löschen

Führen Sie zum Löschen des Dienstes die folgenden Schritte aus:

  1. Rufen Sie in der Cloud Console die Seite Dienste & Ingress auf.

    Zu "Dienste & Ingress"

  2. Wählen Sie den zu löschenden Dienst aus und klicken Sie auf Löschen.

  3. Wenn Sie zur Bestätigung aufgefordert werden, klicken Sie auf Löschen.

Teilmengeneinstellung für internen TCP/UDP-Load-Balancer verwenden

Die Teilmengeneinstellung für internen Load-Balancer für GKE verbessert die Skalierbarkeit des internen TCP/UDP-Load-Balancers, indem Back-Ends in kleinere, sich überschneidende Gruppen partitioniert werden. Mit der Teilmengeneinstellung können Sie interne TCP/UDP-Load-Balancer für Cluster mit mehr als 250 Knoten konfigurieren.

Sie können die Teilmengeneinstellung aktivieren, wenn Sie einen Cluster erstellen oder einen vorhandenen Cluster bearbeiten.

Architektur

Die Teilmengeneinstellung wirkt sich auf die Bereitstellung des internen TCP/UDP-Load-Balancers aus. Ohne die Teilmengeneinstellung platziert der GKE-Controller alle Knoten eines Clusters in eine oder mehrere zonal nicht verwaltete Instanzgruppe, die von allen internen Load-Balancern im GKE-Cluster gemeinsam verwendet werden. Beispielsweise verwenden alle internen TCP/UDP-Load-Balancer in einem GKE-Cluster mit 40 Knoten dieselben 40 Knoten wie Back-Ends.

Bei der Untereinstellung des internen TCP/UDP-Load-Balancers platziert der GKE-Controller Knoten in GCE_VM_IP zonal network endpoint groups (NEGs). Im Unterschied zu Instanzgruppen können Knoten Mitglieder von mehr als einer zonalen NEG sein. Jede der zonalen NEGs kann von einem internen TCP/UDP-Load-Balancer referenziert werden. Der GKE-Controller erstellt eine NEG für jeden Dienst mit einer Teilmenge der GKE-Knoten als Mitglieder. Beispiel: Ein GKE-Cluster mit 40 Knoten kann einen internen TCP/UDP-Load-Balancer mit 25 Knoten in einer zonalen Back-End-NEG und einem anderen internen TCP/UDP-Load-Balancer mit 25 Knoten in einem anderen zonalen Back-End haben.

Das folgende Diagramm zeigt zwei verschiedene Dienste in einem Cluster, bei dem die Teilmengeneinstellung des internen TCP/UDP-Load-Balancers aktiviert ist. Für jeden Dienst werden zwei Pods auf drei Knoten geplant. Google Cloud erstellt für jeden Dienst eine GCE_VM_IP-NEG. Der GKE-Controller wählt einen Teil der Knoten im Cluster als Mitglieder der NEG aus und verwendet die IP-Adresse jedes ausgewählten Knotens als Endpunkte.

Virtuelle IP-Adressen des Knotens, die als Endpunkte für Dienste verwendet werden, wenn Teilmengeneinstellungen festgelegt werden.
Diagramm: Beispiel für Teilmengeneinstellung in einem Cluster mit Diensten.

Auswahl der Teilmenge des Back-End-Knotens

Wenn Sie die Teilmengeneinstellung für einen Cluster aktivieren, legt der GKE-Controller automatisch fest, wie Knoten in Teilmengen unterteilt werden sollen. Sie können den Wert Lokal oder Cluster für externalTrafficPolicy verwenden. Die Auswahl des Back-End-Knotenteils unterscheidet sich jedoch für jeden Wert.

  • externalTrafficPolicy: Cluster: Clientanfragen werden an die Knoten-IP-Adresse gesendet und an einen Back-End-Pod verteilt. Der Back-End-Pod kann sich auf demselben oder einem anderen Knoten befinden. Der GKE-Controller wählt eine zufällige Teilmenge von 25 Knoten aus. Diese Verteilung verhindert Single Points of Failure. Wenn Back-End-Pods auf mehr als 25 Knoten gehostet werden, empfangen diese Pods weiterhin Traffic. Der eingehende Traffic geht jedoch über maximal 25 Knoten, die Bestandteil der Teilmenge sind, in den Cluster ein. Wenn der Cluster weniger als 25 Knoten hat, gehören diese alle zur Teilmenge.

  • externalTrafficPolicy: Lokal: Clientanfragen werden an die Knoten-IP-Adresse gesendet und Load-Balancing erfolgt nur auf Back-End-Pods, die auf demselben Knoten ausgeführt werden. In diesem Fall enthält die Teilmenge der Back-End-Knoten nur Knoten, auf denen einer der Dienstobjekt-Pods gehostet wird. Die Teilmengengröße ist die Anzahl der Knoten, die Pods von diesem Dienst hosten, bis zu maximal 250 Knoten. Planen Sie diese Dienste über maximal 250 Knoten, da keine zusätzlichen Knoten Traffic vom Load-Balancer empfangen.

Anforderungen und Einschränkungen

Die Teilmengeneinstellung für GKE hat folgende Anforderungen und Einschränkungen:

  • Sie können die Teilmengeneinstellungen in neuen und vorhandenen Clustern ab GKE-Version 1.18.19-gke.1400 aktivieren.
  • Für den Cluster sollte das HttpLoadBalancing-Add-on aktiviert sein. Dieses Add-on ist standardmäßig aktiviert. Ein Cluster, der dieses Add-on deaktiviert hat, kann keine Untereinstellung verwenden.
  • Cloud SDK in der Version 345.0.0 und höher.
  • Teilmengeneinstellungen können nicht mit Autopilot-Clustern verwendet werden.
  • Es gelten die Kontingente für Netzwerk-Endpunktgruppen. Google Cloud erstellt 1 NEG pro internen TCP/UDP-Load-Balancer pro Zone.
  • Es gelten Kontingente für Weiterleitungsregeln, Back-End-Dienste und andere Netzwerkressourcen.
  • Diese Teilmengeneinstellungen können nach der Aktivierung in einem Cluster nicht mehr deaktiviert werden.
  • Diese Teilmengeneinstellung kann nicht mit der Annotation zum Freigeben von Back-End-Diensten verwendet werden, alpha.cloud.google.com/load-balancer-backend-share.

Teilmengeneinstellung für internen Load-Balancer in einem neuen Cluster aktivieren

Sie können einen Cluster mit der untergeordneten Einstellung des internen Load-Balancers mit dem gcloud-Befehlszeilentool oder der Cloud Console erstellen:

Console

  1. Rufen Sie in der Cloud Console die Seite Google Kubernetes Engine auf:

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie auf Erstellen.

  3. Konfigurieren Sie den Cluster wie gewünscht.

  4. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

  5. Wählen Sie das Kästchen Teilmengeneinstellung für interne L4-Load-Balancer aktivieren aus.

  6. Klicken Sie auf Erstellen.

gcloud

gcloud container clusters create CLUSTER_NAME \
  --cluster-version VERSION \
  --enable-l4-ilb-subsetting
  {--zone ZONE_NAME | --region REGION_NAME}

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: durch den Namen des neuen Clusters.
  • VERSION: die GKE-Version, die mindestens 1.18.19-gke.1400 sein muss. Sie können auch die Option --release-channel verwenden, um eine Release-Version auszuwählen. Die Release-Version muss die Standardversion 1.18.19-gke.1400 oder höher haben.
  • ZONE_NAME oder REGION_NAME: der Standort für den Cluster. Diese Argumente schließen sich gegenseitig aus. Weitere Informationen finden Sie unter Clustertypen.

Teilmengeneinstellung für internen Load-Balancer in einem vorhandenen Cluster aktivieren

Sie können die Teilmengeneinstellung für den internen Load-Balancer eines vorhandenen Clusters mit dem gcloud-Tool oder der Google Cloud Console aktivieren. Sie können die Teilmengeneinstellung für den internen Load-Balancer nicht mehr deaktivieren, nachdem Sie sie in einem Cluster aktiviert haben.

Console

  1. Rufen Sie in der Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

  3. Klicken Sie unter Netzwerk neben dem Feld Teilmengeneinstellung für interne L4-Load-Balancer auf Teilmengeneinstellung für interne L4-Load-Balancer aktivieren

  4. Wählen Sie das Kästchen Teilmengeneinstellung für interne L4-Load-Balancer aktivieren aus.

  5. Klicken Sie auf Änderungen speichern.

gcloud

gcloud container clusters update CLUSTER_NAME \
  --enable-l4-ilb-subsetting

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des Clusters.

Teilmengeneinstellung für internen Load-Balancer prüfen

Führen Sie die folgenden Schritte aus, um zu prüfen, ob die Teilmengeneinstellung des internen Load-Balancers für Ihren Cluster ordnungsgemäß funktioniert:

  1. Stellen Sie eine Arbeitslast bereit.

    Das folgende Manifest beschreibt eine Bereitstellung, die ein Container-Image einer Beispielwebanwendung ausführt: Speichern Sie das Manifest als ilb-deployment.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ilb-deployment
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: ilb-deployment
      template:
        metadata:
          labels:
            app: ilb-deployment
        spec:
          containers:
          - name: hello-app
            image: gcr.io/google-samples/hello-app:1.0
    
  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f ilb-deployment.yaml
    
  3. Erstellen Sie einen Dienst.

    Das folgende Manifest beschreibt einen Dienst, der einen internen Load-Balancer über TCP-Port 8080 erstellt. Speichern Sie das Manifest als ilb-svc.yaml:

    apiVersion: v1
    kind: Service
    metadata:
      name: ilb-svc
      annotations:
        networking.gke.io/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      externalTrafficPolicy: Cluster
      selector:
        app: ilb-deployment
      ports:
      - name: tcp-port
        protocol: TCP
        port: 8080
        targetPort: 8080
    
  4. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f ilb-svc.yaml
    
  5. Untersuchen Sie den Dienst.

    kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
    

    Die Ausgabe sieht etwa so aus:

    {"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["us-central1-c"]}
    

    Die Antwort zeigt an, dass GKE eine Netzwerk-Endpunktgruppe mit dem Namen k8s2-knlc4c77-default-ilb-svc-ua5ugas0 erstellt hat. Diese Annotation ist in Diensten vom Typ LoadBalancer vorhanden, die die GKE-Teilmengeneinstellung verwenden und nicht in Diensten enthalten sind, die keine Teilmengeneinstellung verwenden.

Fehlerbehebung

Verwenden Sie den folgenden Befehl, um die Liste der Knoten in einem Teil eines Dienstes zu ermitteln:

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
  --zone ZONE

Ersetzen Sie Folgendes:

  • NEG_NAME: durch den Namen der vom GKE-Controller erstellten Netzwerk-Endpunktgruppe.
  • ZONE: durch die Zone der Netzwerk-Endpunktgruppe, die verwendet werden soll.

Verwenden Sie den folgenden Befehl, um die Liste der fehlerfreien Knoten für einen internen TCP/UDP-Load-Balancer zu ermitteln:

gcloud compute backend-services get-health SERVICE_NAME \
  --region REGION

Ersetzen Sie Folgendes:

  • SERVICE_NAME: der Name des Back-End-Dienstes. Dieser Wert entspricht dem Namen der vom GKE-Controller erstellten Netzwerk-Endpunktgruppe.
  • REGION: die Region des Back-End-Dienstes, in dem der Vorgang ausgeführt werden soll.

Bekannte Probleme

Zeitüberschreitung der Verbindung alle 10 Minuten

Bei internen LoadBalancer-Diensten, die mit der Einstellung "Subset" erstellt wurden, können Trafficunterbrechungen etwa alle 10 Minuten auftreten. Dieser Fehler wurde in den folgenden Versionen behoben:

  • 1.18.19-gke.1700 und höher
  • 1.19.10-gke.1000 und höher
  • 1.20.6-gke.1000 und höher

Dienstparameter

Weitere Informationen zu den konfigurierbaren Load-Balancer-Parametern finden Sie unter TCP/UDP-Load-Balancing konfigurieren. Darüber hinaus unterstützen interne LoadBalancer-Dienste die folgenden zusätzlichen Parameter:

Option Beschreibung Dienstfeld Unterstützung für GKE-Version
Load-Balancer-Subnetz Gibt an, aus welchem Subnetz der Load-Balancer automatisch eine IP-Adresse bereitstellen soll metadata:annotations: networking.gke.io/internal-load-balancer-subnet Beta in GKE 1.17+ und 1.12.8-gke.10+
GA in GKE 1.17.9-gke.600+
Globaler Zugriff Ermöglicht den Zugriff auf die TCP/UDP-Load-Balancer-VIP durch Clients in mehreren GCP-Regionen metadata:annotations: networking.gke.io/internal-load-balancer-allow-global-access Beta in GKE 1.16 und höher
allgemein verfügbar in GKE 1.17.9-gke.600 und höher

Load-Balancer-Subnetz

Standardmäßig stellt GKE einen internen TCP/UDP-Load-Balancer mithilfe des Knotensubnetzbereichs bereit. Das Subnetz kann mithilfe der Annotation networking.gke.io/internal-load-balancer-subnet pro Dienst vom Nutzer angegeben werden. Dies ist nützlich, um die internen IP-Adressen des Load-Balancers getrennt von Knoten-IP-Adressen mit einer Firewall zu schützen oder dasselbe Dienstsubnetz für mehrere GKE-Cluster freizugeben. Dieser Parameter ist nur für die internen TCP/UDP-LoadBalancer-Dienste relevant.

Das Subnetz muss vorhanden sein, bevor die Dienstressource darauf verweist, da GKE den Lebenszyklus des Subnetzes selbst nicht verwaltet. Außerdem muss sich das Subnetz in derselben VPC und Region wie der GKE-Cluster befinden. In diesem Schritt wird es "out of band" von GKE erstellt:

gcloud compute networks subnets create gke-vip-subnet \
    --network=default \
    --range=10.23.0.0/24 \
    --region=us-central1

Die folgende Dienstdefinition verwendet das internal-load-balancer-subnet, um das Subnetz namentlich zu referenzieren. Standardmäßig wird automatisch eine verfügbare IP-Adresse aus dem Subnetz ausgewählt. Sie können die loadBalancerIP auch angeben, sie muss aber Teil des referenzierten Subnetzes sein.

Es gibt mehrere Möglichkeiten, um dieses interne Load-Balancer-Subnetz für verschiedene Anwendungsfälle freizugeben:

  • Mehrere Subnetze für Dienstgruppen im selben Cluster
  • Ein einzelnes Subnetz für alle Dienste in einem Cluster
  • Ein einzelnes Subnetz, das von mehreren Clustern und Diensten gemeinsam genutzt wird
apiVersion: v1
kind: Service
metadata:
  name: ilb-service
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
    networking.gke.io/internal-load-balancer-subnet: "gke-vip-subnet"
  labels:
    app: hello
spec:
  type: LoadBalancer
  loadBalancerIP: 10.23.0.15
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Globaler Zugriff

Der globale Zugriff ist ein optionaler Parameter für interne LoadBalancer-Dienste, mit dem Clients aus jeder Region in Ihrem VPC-Netzwerk auf den internen TCP/UDP-Load-Balancer zugreifen können. Ohne globalen Zugriff muss sich der Traffic von Clients in Ihrem VPC-Netzwerk in derselben Region wie der Load-Balancer befinden. Mit globalem Zugriff können Clients in jeder Region auf den Load-Balancer zugreifen. Back-End-Instanzen müssen sich weiterhin in derselben Region wie der Load-Balancer befinden.

Der globale Zugriff wird pro Dienst mithilfe der folgenden Anmerkung aktiviert: networking.gke.io/internal-load-balancer-allow-global-access: "true".

Der globale Zugriff wird für Legacy-Netzwerke nicht unterstützt. Bei der regionsübergreifenden Verwendung des globalen Zugriffs fallen die regulären Kosten für interregionalen Traffic an. Weitere Informationen zu den Netzwerkpreisen für ausgehenden Traffic zwischen Regionen finden Sie unter Netzwerkpreise. Globaler Zugriff ist in der Betaversion von GKE-Clustern 1.16 und höher und 1.17.9-gke.600 und höher verfügbar.

Bei lokalen Clients können Clients mit dem globalen Zugriff über Cloud VPN oder Cloud Interconnect (VLAN) auf den Load-Balancer in einer beliebigen Region zugreifen. Weitere Informationen finden Sie unter Cloud VPN und Cloud Interconnect verwenden.

Freigegebene IP-Adresse

Der interne TCP/UDP-Load-Balancer ermöglicht die gemeinsame Nutzung einer virtuellen IP-Adresse durch mehrere Weiterleitungsregeln. Dies ist nützlich, um die Anzahl von gleichzeitigen Ports auf derselben IP-Adresse zu erhöhen oder UDP- und TCP-Traffic auf derselben IP-Adresse zu akzeptieren. Pro IP-Adresse sind bis zu 50 freigegebene Ports möglich. Freigegebene IP-Adressen werden nativ auf GKE-Clustern mit internen LoadBalancer-Diensten unterstützt. Bei der Bereitstellung wird im Feld loadBalancerIP des Dienstes angegeben, welche IP-Adresse von den Diensten gemeinsam genutzt werden soll.

Beschränkungen

Eine für mehrere Load-Balancer freigegebene IP-Adresse hat die folgenden Beschränkungen und Funktionen:

  • Jeder Dienst oder jede Weiterleitungsregel kann maximal fünf Ports haben.
  • Maximal zehn Dienste (Weiterleitungsregeln) können eine IP-Adresse gemeinsam nutzen. Dies bedeutet maximal 50 Ports pro freigegebener IP.
  • Protokoll- oder Port-Tupel dürfen sich nicht zwischen Diensten mit derselben IP-Adresse überschneiden.
  • Eine Kombination aus reinen TCP- und UDP-Diensten wird auf derselben freigegebenen IP-Adresse unterstützt. Sie können jedoch nicht sowohl TCP- als auch UDP-Ports im selben Dienst verfügbar machen.

Freigegebene IP-Adresse aktivieren

So aktivieren Sie interne LoadBalancer-Dienste für die Freigabe einer gemeinsamen IP-Adresse:

  1. Erstellen Sie mit --purpose SHARED_LOADBALANCER_VIP eine statische interne IP-Adresse. Eine IP-Adresse muss zu diesem Zweck erstellt werden, damit sie freigegeben werden kann. Wenn Sie die statische interne IP-Adresse in einer freigegebenen VPC erstellen, müssen Sie die IP-Adresse im selben Dienstprojekt erstellen wie die Instanz, die die IP-Adresse verwendet, auch wenn der Wert der IP-Adresse aus dem Bereich der verfügbaren IPs in einem ausgewählten gemeinsamen Subnetz des freigegebenen VPC-Netzwerks stammt. Weitere Informationen finden Sie auf der Seite Freigegebene VPC bereitstellen unter Statische interne IP-Adresse reservieren.

  2. Stellen Sie bis zu zehn interne LoadBalancer-Dienste mit dieser statischen IP-Adresse im Feld loadBalancerIP bereit. Die internen TCP/UDP-Load-Balancer werden vom GKE-Dienst-Controller abgeglichen und mit derselben Front-End-IP bereitgestellt.

Im folgenden Beispiel wird gezeigt, wie auf diese Weise mehrere TCP- und UDP-Ports für dieselbe IP-Adresse des internen Load-Balancers unterstützt werden.

  1. Erstellen Sie eine statische IP-Adresse in derselben Region wie Ihr GKE-Cluster. Das Subnetz muss mit dem Subnetz übereinstimmen, das der Load-Balancer verwendet. Dies ist standardmäßig dasselbe Subnetz, das von den IP-Adressen der GKE-Clusterknoten genutzt wird.

    Wenn sich der Cluster und das VPC-Netzwerk im selben Projekt befinden:

    gcloud compute addresses create IP_ADDR_NAME \
        --project PROJECT_ID \
        --subnet SUBNET \
        --address= IP_ADDRESS \
        --region REGION \
        --purpose SHARED_LOADBALANCER_VIP
    

    Wenn sich Ihr Cluster in einem Dienstprojekt einer freigegebenen VPC befindet, aber ein freigegebenes VPC-Netzwerk in einem Hostprojekt verwendet:

    gcloud compute addresses create IP_ADDR_NAME \
        --project SERVICE_PROJECT_ID \
        --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET \
        --address= IP_ADDRESS \
        --region REGION \
        --purpose SHARED_LOADBALANCER_VIP
    

    Ersetzen Sie Folgendes:

    • IP_ADDR_NAME ist der Name des IP-Adressobjekts.
    • SERVICE_PROJECT_ID ist die ID des Dienstprojekts.
    • PROJECT_ID ist die ID Ihres Projekts (einzelnes Projekt).
    • HOST_PROJECT_ID ist die ID des freigegebenen VPC-Hostprojekts.
    • REGION ist die Region, die das freigegebene Subnetz enthält.
    • ADDRESS ist eine nicht verwendete interne IP-Adresse aus dem primären IP-Adressbereich des ausgewählten Subnetzes. Wenn Sie keine IP-Adresse angeben, wählt Google Cloud eine nicht verwendete interne IP-Adresse aus dem primären IP-Adressbereich des ausgewählten Subnetzes aus. Führen Sie gcloud compute addresses describe aus, um eine automatisch ausgewählte Adresse zu ermitteln.
    • SUBNET ist der Name des freigegebenen Subnetzes.
  2. Speichern Sie die folgende TCP-Dienstkonfiguration in einer Datei mit dem Namen tcp-service.yaml und stellen Sie sie dann im Cluster bereit. Ersetzen Sie IP_ADDRESS durch die IP-Adresse, die Sie im vorherigen Schritt ausgewählt haben.

    apiVersion: v1
    kind: Service
    metadata:
      name: tcp-service
      namespace: default
      annotations:
        networking.gke.io/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      loadBalancerIP: IP_ADDRESS
      selector:
        app: myapp
      ports:
      - name: 8001-to-8001
        protocol: TCP
        port: 8001
        targetPort: 8001
      - name: 8002-to-8002
        protocol: TCP
        port: 8002
        targetPort: 8002
      - name: 8003-to-8003
        protocol: TCP
        port: 8003
        targetPort: 8003
      - name: 8004-to-8004
        protocol: TCP
        port: 8004
        targetPort: 8004
      - name: 8005-to-8005
        protocol: TCP
        port: 8005
        targetPort: 8005
    
  3. Wenden Sie diese Dienstdefinition auf Ihren Cluster an:

    kubectl apply -f tcp-service.yaml
    
  4. Speichern Sie die folgende UDP-Dienstkonfiguration in einer Datei mit dem Namen udp-service.yaml und stellen Sie sie dann bereit. Außerdem wird die IP_ADDRESS verwendet, die Sie im vorherigen Schritt angegeben haben.

    apiVersion: v1
    kind: Service
    metadata:
      name: udp-service
      namespace: default
      annotations:
        networking.gke.io/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      loadBalancerIP: IP_ADDRESS
      selector:
        app: my-udp-app
      ports:
      - name: 9001-to-9001
        protocol: UDP
        port: 9001
        targetPort: 9001
      - name: 9002-to-9002
        protocol: UDP
        port: 9002
        targetPort: 9002
    
  5. Wenden Sie diese Datei auf Ihren Cluster an:

    kubectl apply -f udp-service.yaml
    
  6. Prüfen Sie, ob die VIP von den Weiterleitungsregeln des Load-Balancers gemeinsam genutzt wird. Listen Sie sie dazu auf und filtern Sie nach der statischen IP-Adresse. Dies zeigt, dass es eine UDP- und eine TCP-Weiterleitungsregel gibt, die jeweils sieben verschiedene Ports auf der freigegebenen IP_ADDRESS beobachten, die in diesem Beispiel 10.128.2.98 ist.

    gcloud compute forwarding-rules list | grep 10.128.2.98
    ab4d8205d655f4353a5cff5b224a0dde                         us-west1   10.128.2.98     UDP          us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde
    acd6eeaa00a35419c9530caeb6540435                         us-west1   10.128.2.98     TCP          us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435
    

Alle Ports

Interne Weiterleitungsregeln unterstützen bis zu fünf Ports pro Weiterleitungsregel oder einen optionalen Parameter --ports=ALL, der alle Ports in der Weiterleitungsregel weiterleitet.

Voraussetzungen

Für alle Ports in GKE gelten die folgenden Anforderungen und Einschränkungen:

  • Wird nur unterstützt, wenn --enable-l4-ilb-subsetting aktiviert ist.
  • Wird nur für interne Load-Balancer-Dienste unterstützt.
  • Unterstützt eine beliebige Anzahl von Ports in maximal 100 zusammenhängenden Portbereichen.

Der GKE-Controller aktiviert automatisch alle Ports in der Weiterleitungsregel, wenn ein Dienst mehr als fünf Ports hat. Das folgende Dienstmanifest enthält beispielsweise sechs Ports, die in zwei zusammenhängenden Bereichen konfiguriert sind:

apiVersion: v1
kind: Service
metadata:
  name: all-ports
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 8081
    targetPort: 8081
    name: 8081-to-8081
    protocol: TCP
  - port: 8082
    targetPort: 8082
    name: 8082-to-8082
    protocol: TCP
  - port: 8083
    targetPort: 8083
    name: 8083-to-8083
    protocol: TCP
  - port: 9001
    targetPort: 9001
    name: 9001-to-9001
    protocol: TCP
  - port: 9002
    targetPort: 9002
    name: 9002-to-9002
    protocol: TCP
  - port: 9003
    targetPort: 9003
    name: 9003-to-9003
    protocol: TCP

Der GKE-Controller aktiviert alle Ports in der Weiterleitungsregel, da der Dienst mehr als fünf Ports hat. Der GKE-Controller erstellt jedoch nur Firewallports für die im Dienst angegebenen Ports. Alle anderen Regeln werden von VPC-Firewalls blockiert.

Einschränkungen für interne TCP/UDP-Load-Balancer

  • Für Cluster mit Kubernetes Version 1.7.4 und höher können Sie zusätzlich zu Subnetzen im automatischen Modus interne Load-Balancer mit Subnetzen im benutzerdefinierten Modus verwenden.
  • Cluster, auf denen Kubernetes Version 1.7.X und höher ausgeführt wird, unterstützen die Verwendung einer reservierten IP-Adresse für den internen TCP/UDP-Load-Balancer, wenn Sie die reservierte IP-Adresse mit dem Flag --purpose, auf SHARED_LOADBALANCER_VIP gesetzt, erstellen. Eine schrittweise Anleitung finden Sie unter Freigegebene IP-Adresse aktivieren. GKE behält die IP-Adresse eines internen TCP/UDP-Load-Balancers nur bei, wenn der Dienst auf eine interne IP-Adresse mit diesem Zweck verweist. Andernfalls kann GKE die IP-Adresse des Load-Balancers (spec.loadBalancerIP) ändern, wenn der Dienst aktualisiert wird (z. B. wenn sich Ports ändern).
  • Auch wenn sich die IP-Adresse des Load-Balancers ändert (siehe vorherigen Punkt), bleibt spec.clusterIP konstant.

Einschränkungen für interne UDP-Load-Balancer

  • Interne UDP-Load-Balancer unterstützen die Verwendung von sessionAffinity: ClientIP nicht.

Limits

Ein Kubernetes-Dienst mit type: LoadBalancer und der Anmerkung networking.gke.io/load-balancer-type: Internal erstellt einen internen Load-Balancer, der auf den Kubernetes-Dienst ausgerichtet ist. Die Anzahl dieser Dienste ist durch die Anzahl der internen Weiterleitungsregeln begrenzt, die Sie in einem VPC-Netzwerk erstellen können. Weitere Informationen finden Sie unter den Limits pro Netzwerk.

Die maximale Anzahl von Knoten in einem GKE-Cluster mit einem internen Load-Balancer beträgt 250. Aktivieren Sie die Teilmengeneinstellung für den internen Load-Balancer, um diese Einschränkung zu entfernen. Wenn Sie Autoscaling für Ihren Cluster aktiviert haben, müssen Sie dafür sorgen, dass der Cluster auf maximal 250 Knoten skaliert wird.

Weitere Informationen zu VPC-Limits finden Sie unter Kontingente und Limits.

Nächste Schritte