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.

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. Beispielsweise kann ein interner LoadBalancer-Dienst für VM-Instanzen zugänglich sein, die sich im VPC-Netzwerk des Clusters befinden.

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 der 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 immer aktiviert.
  • 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, Backend-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 oder die Google Cloud Console erstellen. Ein Cluster, der mit aktivierter GKE-Teilmengeneinstellung erstellt wurde, verwendet immer die GKE-Teilmengeneinstellung.

Console

  1. Rufen Sie in der Google 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 \
    --location=COMPUTE_LOCATION

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.
  • COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.

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.

Console

  1. Rufen Sie in der Google 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.

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 Ersatz-Dienstmanifest 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 8080 erstellt. GKE stellt einen internen Passthrough-Netzwerk-Load-Balancer bereit, dessen Weiterleitungsregel Port 8080 verwendet:

  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: 8080
    targetPort: 8080

    Ihr Manifest muss Folgendes enthalten:

    • Einen name für den internen LoadBalancer-Dienst, in diesem Fall ilb-svc.
    • Eine Anmerkung, die angibt, dass Sie einen internen LoadBalancer-Dienst benötigen. Ab GKE-Version 1.17 verwenden Sie die Annotation networking.gke.io/load-balancer-type: "Internal" wie im Beispielmanifest zu sehen. Verwenden Sie für frühere Versionen 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 zum LoadBalancer-Service unter Destination Network Address Translation für 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 Parameter des LoadBalancer-Dienstes.

  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":8080,"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: 8080
    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 nach dem Empfang eines Knotens weitergeleitet werden, 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

Dabei gilt:

  • 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

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

Deployment löschen

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

kubectl delete deployment ilb-deployment

Dienst löschen

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

kubectl delete service ilb-svc

Console

Deployment löschen

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

  1. Öffnen Sie in der Google Cloud Console die Seite Arbeitslasten.

    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 Google Cloud Console die Seite Dienste und 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.

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:

  • 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.
  • Für jede Weiterleitungsregel mit derselben IP-Adresse muss eine eindeutige Kombination aus Protokollen und Ports verwendet werden. Daher muss jeder interne LoadBalancer-Dienst einen eindeutigen Satz von 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