Internen Load-Balancer erstellen

Auf dieser Seite wird erläutert, wie Sie einen internen Passthrough-Netzwerk-Load-Balancer oder einen internen Load-Balancer in Google Kubernetes Engine (GKE) erstellen. Zum Erstellen eines externen Passthrough-Netzwerk-Load-Balancers sollten Sie lernen, wie Sie Dienste vom Typ LoadBalancer erstellen.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Konzepten vertraut:

• LoadBalancer-Dienst:
• LoadBalancer-Dienstparameter
• Backend-Dienst-basierter externer Passthrough-Netzwerk-Load-Balancer

Teilmengeneinstellung für internen Passthrough-Netzwerk-Load-Balancer verwenden

Interne Passthrough-Netzwerk-Load-Balancer machen die Dienste Ihres Clusters für Clients innerhalb des VPC-Netzwerks des Clusters und für Clients in Netzwerken zugänglich, die mit dem VPC-Netzwerk des Clusters verbunden sind. Clients müssen sich nicht innerhalb Ihres Clusters befinden. Ein interner Load Balancer-Dienst kann beispielsweise für VM-Instanzen (virtuelle Maschinen) im VPC-Netzwerk des Clusters zugänglich sein.

GKE-Teilmengeneinstellung verwenden

Die GKE-Teilmengeneinstellung verbessert die Skalierbarkeit interner LoadBalancer-Dienste, da sie GCE_VM_IP-Netzwerk-Endpunktgruppen (NEGs) als Back-Ends anstelle von Instanzgruppen verwendet. Wenn die GKE-Teilmengeneinstellung aktiviert ist, erstellt GKE eine NEG pro Computing-Zone pro internem LoadBalancer-Dienst. Die Mitgliedsendpunkte in der NEG sind die IP-Adressen von Knoten, die mindestens einen der Bereitstellungs-Pods des Dienstes haben. Weitere Informationen zur GKE-Teilmengeneinstellung finden Sie unter Knotengruppierung.

Anforderungen und Einschränkungen

Für die GKE-Teilmengeneinstellung gelten die folgenden Anforderungen und Einschränkungen:

• Sie können die GKE-Teileinstellungen in neuen und vorhandenen Standardclustern der GKE-Version 1.18.19-gke.1400 oder höher aktivieren. Die GKE-Teilmengeneinstellung kann nicht deaktiviert werden, nachdem sie aktiviert wurde.

• Die GKE-Teilmengeneinstellung ist in Autopilot-Clustern standardmäßig deaktiviert. Sie können sie jedoch beim Erstellen des Clusters oder später aktivieren.
• Für die GKE-Teilmengeneinstellung muss das Add-on HttpLoadBalancing aktiviert sein. Dieses Add-on ist standardmäßig aktiviert. In Autopilot-Clustern können Sie dieses erforderliche Add-on nicht deaktivieren.
• Es gelten die Kontingente für Netzwerk-Endpunktgruppen. Google Cloud erstellt eine GCE_VM_IP-NEG pro internem LoadBalancer-Dienst pro Zone.
• Es gelten Kontingente für Weiterleitungsregeln, Back-End-Dienste und Systemdiagnosen. Weitere Informationen finden Sie unter Kontingente und Limits.
• Die GKE-Teilmengeneinstellung kann nicht mit der Annotation verwendet werden, um einen Backend-Dienst für mehrere Load-Balancer freizugeben, alpha.cloud.google.com/load-balancer-backend-share.
• Sie benötigen die Google Cloud CLI-Version 345.0.0 oder höher.

Hinweis

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

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

GKE-Teilmengeneinstellung in einem neuen Standardcluster aktivieren

Sie können einen Standardcluster mit aktivierter GKE-Teilmengeneinstellung über die Google Cloud CLI, die Google Cloud Console oder Terraform erstellen. Ein Cluster, der mit aktivierter GKE-Teilmengeneinstellung erstellt wurde, verwendet immer die GKE-Teilmengeneinstellung.

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-l4-ilb-subsetting \
    --location=COMPUTE_LOCATION

  gcloud container clusters create CLUSTER_NAME \
      --cluster-version=VERSION \
      --network NETWORK_NAME \
      --subnetwork SUBNETWORK_NAME \
      --enable-l4-ilb-subsetting \
      --location=COMPUTE_LOCATION

resource "google_container_cluster" "default" {
  name               = "gke-standard-regional-cluster"
  location           = "us-central1"
  initial_node_count = 1

  enable_l4_ilb_subsetting = true

  # Set `deletion_protection` to `true` will ensure that one cannot
  # accidentally delete this instance by use of Terraform.
  deletion_protection = false
}

GKE-Teilmengeneinstellung in einem vorhandenen Standardcluster aktivieren

Sie können die GKE-Teilmengeneinstellung für einen vorhandenen Standardcluster mit der gcloud CLI oder der Google Cloud Console aktivieren. Sie können die GKE-Teilmengeneinstellung nicht deaktivieren, nachdem Sie sie aktiviert haben.

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

Interne LoadBalancer-Dienste werden durch die Aktivierung der GKE-Teilmengeneinstellung nicht beeinträchtigt. Wenn Sie vorhandene interne LoadBalancer-Dienste migrieren möchten, um Backend-Dienste mit GCE_VM_IP-NEGs als Backends zu verwenden, müssen Sie ein Ersatzdienstmanifest bereitstellen. Weitere Informationen finden Sie unter Knotengruppierung in der Dokumentation zu LoadBalancer-Dienstkonzepten.

Arbeitslast bereitstellen

Das folgende Manifest beschreibt eine Bereitstellung, die ein Container-Image einer Beispielwebanwendung ausführt:

1. 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: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f ilb-deployment.yaml
   

Internen LoadBalancer-Dienst erstellen

Im folgenden Beispiel wird ein interner LoadBalancer-Dienst mit dem TCP-Port 80 erstellt. GKE stellt einen internen Passthrough-Netzwerk-Load-Balancer bereit, dessen Weiterleitungsregel Port 80 verwendet, der Traffic aber an Backend-Pods auf Port 8080 weiterleitet:

1. 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: 80
       targetPort: 8080
   

   Ihr Manifest muss Folgendes enthalten:

   • Einen Namen (name) für den internen LoadBalancer-Dienst, in diesem Fall ilb-svc.
   • Eine Anmerkung, die angibt, dass ein interner LoadBalancer-Dienst erforderlich ist. Ab GKE-Version 1.17 verwenden Sie die Annotation networking.gke.io/load-balancer-type: "Internal", wie im Beispielmanifest gezeigt. Bei älteren Versionen verwenden Sie stattdessen 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.
   • Port-Informationen:
     • port steht für den Zielport, über den die Weiterleitungsregel des internen Passthrough-Netzwerk-Load-Balancers Pakete empfängt.
     • Der targetPort muss mit einem containerPort übereinstimmen, der auf jedem Bereitstellungs-Pod definiert ist.
     • Die Werte port und targetPort müssen nicht identisch sein. Knoten führen immer Ziel-NAT aus, wobei die IP-Adresse der Weiterleitungsregel des Ziel-Load-Balancers und port in eine Ziel-Pod-IP-Adresse und targetPort geändert werden. Weitere Informationen finden Sie in der Dokumentation zu LoadBalancer-Dienstkonzepten unter Zielnetzwerkadressübersetzung auf Knoten.

   Ihr Manifest kann Folgendes enthalten:

   • spec.ipFamilyPolicy und ipFamilies, um zu definieren, wie GKE dem Dienst IP-Adressen zuweist. GKE unterstützt entweder Single-Stack-IP-LoadBalancer- (nur IPv4 oder IPv6) oder Dual-Stack-IP-LoadBalancer-Dienste. Ein Dual-Stack-LoadBalancer-Dienst wird mit zwei separaten internen Passthrough-Netzwerk-Load-Balancer-Weiterleitungsregeln implementiert: eine für IPv4-Traffic und eine für IPv6-Traffic. Der GKE-Dual-Stack-LoadBalancer-Dienst ist in Version 1.29 oder höher verfügbar. Weitere Informationen finden Sie unter IPv4/IPv6-Dual-Stack-Dienste.

   Weitere Informationen finden Sie unter LoadBalancer-Dienstparameter.

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f ilb-svc.yaml
   

3. Rufen Sie detaillierte Informationen zum Dienst ab:

   kubectl get service ilb-svc --output yaml
   

   Die Ausgabe sieht etwa so aus:

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       cloud.google.com/neg: '{"ingress":true}'
       cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}'
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}}
       networking.gke.io/load-balancer-type: Internal
       service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw
       service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc
       service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
     creationTimestamp: "2022-07-22T17:26:04Z"
     finalizers:
     - gke.networking.io/l4-ilb-v2
     - service.kubernetes.io/load-balancer-cleanup
     name: ilb-svc
     namespace: default
     resourceVersion: "51666"
     uid: d7a1a865-7972-44e1-aa9e-db5be23d6567
   spec:
     allocateLoadBalancerNodePorts: true
     clusterIP: 10.88.2.141
     clusterIPs:
     - 10.88.2.141
     externalTrafficPolicy: Cluster
     internalTrafficPolicy: Cluster
     ipFamilies:
     - IPv4
     ipFamilyPolicy: SingleStack
     ports:
     - name: tcp-port
       nodePort: 30521
       port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       app: ilb-deployment
     sessionAffinity: None
     type: LoadBalancer
   status:
     loadBalancer:
       ingress:
       - ip: 10.128.15.245
   

   Die Ausgabe hat die folgenden Attribute:

   • Die IP-Adresse der Weiterleitungsregel des internen Passthrough-Netzwerk-Load-Balancers ist in status.loadBalancer.ingress enthalten. Diese IP-Adresse unterscheidet sich vom clusterIP-Wert. In diesem Beispiel lautet die IP-Adresse der Weiterleitungsregel des Load Balancers 10.128.15.245.
   • Jeder Pod mit dem Label app: ilb-deployment ist ein Bereitstellungs-Pod für diesen Dienst. Dies sind die Pods, die Pakete empfangen, die vom internen Passthrough-Netzwerk-Load-Balancer weitergeleitet werden.
   • Clients rufen den Dienst über die loadBalancer-IP-Adresse und den im Feld port des Dienstmanifests angegebenen TCP-Zielport auf. Ausführliche Informationen dazu, wie Pakete weitergeleitet werden, nachdem sie von einem Knoten empfangen wurden, finden Sie unter Paketverarbeitung.
   • GKE hat dem Dienst einen nodePort zugewiesen. In diesem Beispiel wird Port 30521 zugewiesen. Der nodePort ist für den internen Passthrough-Netzwerk-Load-Balancer nicht relevant.

4. Prüfen Sie die Endpunktgruppe des Dienstnetzwerks:

   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":["ZONE_NAME"]}
   

   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, die keine Teilmengeneinstellung verwenden.

Komponenten des internen Passthrough-Netzwerk-Load-Balancers prüfen

Die IP-Adresse der Weiterleitungsregel des internen Passthrough-Netzwerk-Load-Balancers ist 10.128.15.245 in dem Beispiel aus dem Abschnitt Internen LoadBalancer-Dienst erstellen. Sie können mit der Google Cloud CLI sehen, dass diese Weiterleitungsregel in der Liste der Weiterleitungsregeln im Projekt des Clusters enthalten ist:

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

Die Ausgabe enthält die relevante Weiterleitungsregel für den internen Passthrough-Netzwerk-Load-Balancer, die IP-Adresse und den Backend-Dienst, auf den die Weiterleitungsregel verweist (in diesem Beispiel k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r).

NAME                          ... IP_ADDRESS  ... TARGET
...
k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r   10.128.15.245   ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r

Sie können den Backend-Dienst des Load-Balancers mithilfe der Google Cloud CLI beschreiben:

gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION

Ersetzen Sie COMPUTE_REGION durch die Compute-Region des Backend-Dienstes.

Die Ausgabe enthält die Backend-GCE_VM_IP-NEG oder die NEGs für den Dienst (in diesem Beispiel k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r):

backends:
- balancingMode: CONNECTION
  group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...

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

Ersetzen Sie Folgendes:

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

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

gcloud compute backend-services get-health SERVICE_NAME \
    --region=COMPUTE_REGION

Ersetzen Sie Folgendes:

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

Konnektivität zum internen Passthrough-Netzwerk-Load-Balancer testen

Stellen Sie eine SSH-Verbindung zu einer VM-Instanz im selben VPC-Netzwerk und in derselben Region wie der Cluster her und führen Sie dann den folgenden Befehl aus:

curl LOAD_BALANCER_IP:80

Ersetzen Sie LOAD_BALANCER_IP durch die IP-Adresse der Weiterleitungsregel des Load Balancers.

Die Antwort zeigt die Ausgabe von ilb-deployment:

Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n

Auf den internen Passthrough-Netzwerk-Load-Balancer kann nur innerhalb desselben VPC-Netzwerks (oder eines verbundenen Netzwerks) zugegriffen werden. Standardmäßig ist bei der Weiterleitungsregel des Load Balancers der globale Zugriff deaktiviert, sodass sich Client-VMs, Cloud VPN-Tunnel oder Cloud Interconnect-Anhänge (VLANs) in derselben Region befinden müssen wie der interne Passthrough-Netzwerk-Load-Balancer. Zur Unterstützung von Clients in allen Regionen können Sie den globalen Zugriff auf die Weiterleitungsregel des Load Balancers aktivieren. Dazu nehmen Sie die Annotation globalen Zugriff in das Dienstmanifest auf.

Internen LoadBalancer-Dienst und Load-Balancer-Ressourcen löschen

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

kubectl delete deployment ilb-deployment

kubectl delete service ilb-svc

Freigegebene IP-Adresse

Der interne Passthrough-Netzwerk-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:

• Jede Weiterleitungsregel kann bis zu fünf Ports haben (fortlaufende oder nicht fortlaufende). Sie kann auch so konfiguriert werden, dass Traffic an allen Ports abgeglichen und weitergeleitet wird. Wenn für einen internen LoadBalancer-Dienst mehr als fünf Ports definiert sind, wird die Weiterleitungsregel automatisch so festgelegt, dass sie allen Ports entspricht.
• Maximal zehn Dienste (Weiterleitungsregeln) können eine IP-Adresse gemeinsam nutzen. Dies bedeutet maximal 50 Ports pro freigegebener IP.
• Jede Weiterleitungsregel, die dieselbe IP-Adresse verwendet, muss eine eindeutige Kombination aus Protokollen und Ports verwenden. Daher muss jeder interne LoadBalancer-Dienst eine eindeutige Kombination aus Protokollen und Ports verwenden.
• 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 Passthrough-Netzwerk-Load-Balancer werden vom GKE-Dienst-Controller abgeglichen und mit derselben Frontend-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 \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_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/COMPUTE_REGION/subnetworks/SUBNET \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_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 ID des freigegebenen VPC-Hostprojekts.
   • COMPUTE_REGION: Die Computing-Region, die das freigegebene Subnetz enthält.
   • IP_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
   

Einschränkungen und Limits

Einschränkungen für interne Passthrough-Netzwerk-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 Passthrough-Netzwerk-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 Passthrough-Netzwerk-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.

Bekannte Probleme

Zeitüberschreitung der Verbindung alle 10 Minuten

Interne LoadBalancer-Dienste, die mit Teileinstellung erstellt werden, können etwa alle 10 Minuten Trafficunterbrechungen beobachten. 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

Fehler beim Erstellen des Load-Balancers in der Standardstufe

Wenn Sie einen internen Passthrough-Netzwerk-Load-Balancer in einem Projekt erstellen, in dem die Standardnetzwerkstufe des Projekts auf Standard gesetzt ist, wird die folgende Fehlermeldung angezeigt:

Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest

Konfigurieren Sie die Standardnetzwerkstufe des Projekts auf Premium, um dieses Problem in GKE-Versionen vor 1.23.3-gke.900 zu beheben.

Dieses Problem wird in GKE-Versionen ab 1.23.3-gke.900 behoben, wenn die GKE-Teileinstellung aktiviert ist.

Der GKE-Controller erstellt interne Passthrough-Netzwerk-Load-Balancer in der Premium-Netzwerkstufe, auch wenn die Standard-Netzwerkstufe des Projekts auf Standard eingestellt ist.

Nächste Schritte

• Netzwerkübersicht
• Mehr über Compute Engine-Load-Balancer erfahren
• VPC-nativen Cluster erstellen
• Fehlerbehebung beim Load-Balancing in GKE.

• Mehr über den IP-Masquerade-Agent erfahren

• Autorisierte Netzwerke für Masterzugriff erstellen