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.

In diesem Fall können Sie einen internen TCP/UDP-Load-Balancer einrichten. Dazu erstellen Sie eine Dienstressource mit der Annotation cloud.google.com/load-balancer-type: "Internal" und der Spezifikation type: LoadBalancer. Die Anleitung und das Beispiel unten zeigen, wie Sie dabei vorgehen.

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

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:
    cloud.google.com/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.
  • Die Annotation cloud.google.com/load-balancer-type: "Internal". Diese gibt an, dass ein interner TCP/UDP-Load-Balancer zu konfigurieren ist.
  • 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 das Google Kubernetes Engine-Menü "Arbeitslasten" auf.

    Zum Menü "Arbeitslasten"

  2. Wählen Sie im Menü die gewünschte Arbeitslast aus.

  3. Klicken Sie auf Löschen.

  4. Klicken Sie im Bestätigungsdialog 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 das Google Kubernetes Engine-Menü "Dienste" auf.

    Menü "Dienste" aufrufen

  2. Wählen Sie im Menü den gewünschten Dienst aus.

  3. Klicken Sie auf Löschen.

  4. Klicken Sie im Bestätigungsdialog auf Löschen.

Hinweise zu vorhandenen Ingress-Ressourcen

Der gleichzeitige Einsatz eines internen TCP/UDP-Load-Balancers und einer Ingress-Ressource, die den Load-Balancing-Modus UTILIZATION verwendet, ist nicht möglich. Wenn Sie sowohl eine Ingress-Ressource als auch einen internen TCP/UDP-Load-Balancer verwenden möchten, muss die Ingress-Ressource für den Load-Balancing-Modus RATE konfiguriert sein.

Wenn Ihr Cluster eine Ingress-Ressource enthält, die mit Kubernetes-Version 1.7.1 oder niedriger erstellt wurde, ist er nicht mit internen TCP/UDP-Load-Balancern kompatibel. Für die von Kubernetes-Ingress-Ressourcenobjekten erstellten BackendService-Ressourcen wurde früher kein Load-Balancing-Modus festgelegt. Die API hat standardmäßig den Load-Balancing-Modus UTILIZATION für HTTP-Load-Balancer verwendet. Allerdings können interne TCP/UDP-Load-Balancer nicht auf Instanzgruppen mit anderen Load-Balancern, die UTILIZATION verwenden, verwiesen werden.

Load-Balancing-Modus der Ingress-Ressource ermitteln

Führen Sie in Ihrem Shell- oder Terminalfenster die folgenden Befehle aus, um den Load-Balancing-Modus der Ingress-Ressource zu ermitteln:

GROUPNAME=`kubectl get configmaps ingress-uid -o jsonpath='k8s-ig--{.data.uid}' --namespace=kube-system`
gcloud compute backend-services list --format="table(name,backends[].balancingMode,backends[].group)" | grep $GROUPNAME

Diese Befehle exportieren eine Shellvariable namens GROUPNAME, die den Instanzgruppennamen des Clusters abruft. Anschließend werden die Compute Engine-backend service-Ressourcen Ihres Projekts abgefragt und die Ergebnisse anhand des Inhalts von $GROUPNAME eingegrenzt.

Die Ausgabe sieht etwa so aus:

k8s-be-31210--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...
k8s-be-32125--...  [u'RATE']       us-central1-b/instanceGroups/k8s-ig--...

Wenn die Ausgabe RATE- oder Null-Einträge zurückgibt, sind interne Load-Balancer kompatibel und keine zusätzlichen Arbeitsschritte erforderlich.

Sind in der Ausgabe mit UTILIZATION gekennzeichnete Einträge enthalten, sind die Ingress-Ressourcen nicht kompatibel.

Wenn Sie die Ingress-Ressourcen so aktualisieren möchten, dass sie mit einem internen TCP/UDP-Load-Balancer kompatibel sind, können Sie einen neuen Cluster mit Kubernetes Version 1.7.2 oder höher erstellen und Ihre Dienste anschließend zu diesem Cluster migrieren.

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.

Freigegebene IP-Adresse (Beta)

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.

  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.

    gcloud beta compute addresses create internal-10-128-2-98 \
        --region=us-central1 \
        --subnet=default \
        --addresses=10.128.2.98 \
        --purpose=SHARED_LOADBALANCER_VIP
    
  2. Speichern Sie die folgende TCP-Dienstkonfiguration in einer Datei mit dem Namen tcp-service.yaml und stellen Sie sie dann im Cluster bereit. Sie verwendet die freigegebene IP-Adresse 10.128.2.98.

    apiVersion: v1
    kind: Service
    metadata:
      name: tcp-service
      namespace: default
      annotations:
        cloud.google.com/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      loadBalancerIP: 10.128.2.98
      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 freigegebene IP-Adresse 10.128.2.98 verwendet.

    apiVersion: v1
    kind: Service
    metadata:
      name: udp-service
      namespace: default
      annotations:
        cloud.google.com/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      loadBalancerIP: 10.128.2.98
      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-Adresse 10.128.2.98 beobachten.

    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
    

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

  • Für Cluster mit Kubernetes Version 1.7.3 und früheren Versionen konnten nur interne TCP/UDP-Load-Balancer mit Subnetzen im automatischen Modus verwendet werden. Mit Kubernetes Version 1.7.4 und höheren Versionen haben Sie jedoch die Möglichkeit, neben Subnetzen im automatischen Modus auch Subnetze im benutzerdefinierten Modus für interne Load-Balancer zu verwenden.
  • Bei Clustern mit Kubernetes 1.7.X oder höher, bei denen die clusterIP unverändert bleibt, können interne TCP/UDP-Load-Balancer reservierte IP-Adressen nicht verwenden. Das Feld spec.loadBalancerIP kann trotzdem mithilfe einer nicht verwendeten IP-Adresse definiert werden, um eine bestimmte interne IP-Adresse zuzuweisen. Änderungen an Ports, Protokollen oder der Sitzungsaffinität können dazu führen, dass sich diese IP-Adressen ändern.

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 cloud.google.com/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.

In einem GKE-Cluster verweist eine interne Weiterleitungsregel auf alle Knoten im Cluster. Jeder Knoten im Cluster ist eine Back-End-VM für den internen Load-Balancer. Die maximale Anzahl von Back-End-VMs für einen internen Load-Balancer beträgt 250, unabhängig davon, wie die VMs den Instanzgruppen zugeordnet sind. Die maximale Anzahl von Knoten in einem GKE-Cluster mit einem internen Load-Balancer liegt also bei 250. Wenn Sie Autoscaling für Ihren Cluster aktiviert haben, müssen Sie dafür sorgen, dass der Cluster nicht auf mehr als 250 Knoten skaliert wird.

Weitere Informationen zu diesen Limits finden Sie unter VPC-Ressourcenkontingente.

Nächste Schritte