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. Informationen zum Erstellen eines externen Passthrough-Network-Load-Balancers finden Sie unter Dienste vom Typ LoadBalancer erstellen.

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

Internen Passthrough-Network Load Balancer verwenden

Interne Passthrough-Network-Load-Balancer machen die Dienste Ihres Clusters für Clients im VPC-Netzwerk des Clusters und für Clients in Netzwerken zugänglich, die mit dem VPC-Netzwerk des Clusters verbunden sind. Clients im VPC-Netzwerk Ihres Clusters können Knoten oder Pods Ihres Clusters oder VMs außerhalb Ihres Clusters sein. Weitere Informationen zur Konnektivität von Clients in verbundenen Netzwerken finden Sie unter Interne Passthrough-Network Load Balancer und verbundene Netzwerke.

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.

Der externalTrafficPolicy des Dienstes steuert die Knotenmitgliedschaft in den GCE_VM_IP-NEG-Back-Ends. Weitere Informationen finden Sie unter Knotenmitgliedschaft in GCE_VM_IP-NEG-Backends.

Zonale Affinität verwenden

Wenn Sie die zonale Affinität in einem internen Passthrough-Network Load Balancer aktivieren, leitet GKE Traffic, der aus einer Zone stammt, an Knoten und Pods in derselben Zone weiter. Wenn es in der Zone keine fehlerfreien Pods gibt, leitet GKE den Traffic an eine andere Zone weiter. Diese Implementierung ist für Latenz und Kosten optimiert.

Wenn Sie die zonale Affinität in einem GKE-Cluster aktivieren möchten, muss die GKE-Teilmengeneinstellung aktiviert sein.

Anforderungen und Einschränkungen

Im Folgenden finden Sie die Anforderungen und Einschränkungen für interne Load-Balancer.

Voraussetzungen

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 aktivieren, nachdem Sie den Cluster erstellt haben.
  • 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.

Für die zonale Affinität gelten die folgenden Anforderungen:

  • Sie können die zonale Affinität in neuen und vorhandenen Clustern ab GKE-Version 1.33.3-gke.1392000 aktivieren.
  • Die GKE-Teilmengeneinstellung muss aktiviert sein.
  • Das Add-on HttpLoadBalancing muss für Ihren Cluster aktiviert sein. Dieses Add-on ist standardmäßig aktiviert und ermöglicht dem Cluster, Load-Balancer zu verwalten, die Backend-Dienste verwenden.
  • Sie müssen spec.trafficDistribution: PreferClose in das LoadBalancer-Dienstmanifest aufnehmen.

Im LoadBalancer-Dienstmanifest kann entweder externalTrafficPolicy: Local oder externalTrafficPolicy: Cluster verwendet werden.

Beschränkungen

Interne Passthrough-Network-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.
  • Interne UDP-Load-Balancer unterstützen die Verwendung von sessionAffinity: ClientIP nicht.

Hinweise

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 diesen Task 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 dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
  • Prüfen Sie, ob Sie einen vorhandenen Autopilot- oder Standardcluster haben. Informationen zum Erstellen eines neuen Clusters finden Sie unter Autopilot-Cluster erstellen.

GKE-Teilmengeneinstellung in einem Cluster aktivieren

Sie können die GKE-Teilmengeneinstellung für einen vorhandenen Cluster 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, damit Backend-Dienste mit GCE_VM_IP-NEGs als Backends verwendet werden, müssen Sie ein Ersatzdienstmanifest bereitstellen. Weitere Informationen finden Sie in der Dokumentation zu LoadBalancer-Dienstkonzepten unter Knotengruppierung.

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

  1. Optional: Automatisches Erstellen von VPC-Firewallregeln deaktivieren:

    GKE erstellt automatisch VPC-Firewallregeln, um Traffic zu Ihrem internen Load-Balancer zuzulassen. Sie haben jedoch die Möglichkeit, die automatische Erstellung von VPC-Firewallregeln zu deaktivieren und Firewallregeln selbst zu verwalten. Sie können VPC-Firewallregeln nur deaktivieren, wenn Sie die GKE-Teileinstellung für Ihren internen LoadBalancer-Dienst aktiviert haben. Die Verwaltung von VPC-Firewallregeln ist jedoch optional und Sie können sich auf die automatischen Regeln verlassen.

    Bevor Sie das automatische Erstellen von VPC-Firewallregeln deaktivieren, müssen Sie Zulassungsregeln definieren, die es ermöglichen, dass Traffic Ihren Load Balancer und Ihre Anwendungs-Pods erreicht.

    Weitere Informationen zum Verwalten von VPC-Firewallregeln finden Sie unter Automatisches Erstellen von Firewallregeln verwalten. Informationen zum Deaktivieren des automatischen Erstellens von Firewallregeln finden Sie unter Von Nutzern verwaltete Firewallregeln für GKE LoadBalancer-Dienste.

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

    1. Speichern Sie das Manifest als ilb-svc.yaml:

      apiVersion: v1
kind: Service
metadata:
  name: ilb-svc
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # Evenly route external traffic to all endpoints.
  externalTrafficPolicy: Cluster
  # Prioritize routing traffic to endpoints that are in the same zone.
  trafficDistribution: PreferClose
  selector:
    app: ilb-deployment
  # Forward traffic from TCP port 80 to port 8080 in backend Pods.
  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 Annotation, 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 gezeigt. 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 zu LoadBalancer-Dienstkonzepten unter Destination Network Address Translation on nodes.

      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.

      • spec.trafficDistribution, um zu definieren, wie GKE eingehenden Traffic weiterleitet (Vorschau). Wenn Sie dieses Feld auf PreferClose festlegen, leitet GKE Traffic, der aus einer Zone stammt, an Knoten und Pods in derselben Zone weiter. Wenn es in der Zone keine fehlerfreien Pods gibt, leitet GKE den Traffic an eine andere Zone weiter. Wenn Sie dieses Feld angeben, muss GKE-Subsetting aktiviert sein.

      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
    # Kubernetes automatically allocates a port on the node during the
    # process of implementing a Service of type LoadBalancer.
    nodePort: 30521
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: ilb-deployment
  sessionAffinity: None
  trafficDistribution: PreferClose
  type: LoadBalancer
status:
  # IP address of the load balancer forwarding rule.
  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

In diesem Abschnitt erfahren Sie, wie Sie die wichtigsten Komponenten Ihres internen Passthrough-Network Load Balancers prüfen.

  • Prüfen Sie, ob Ihr Dienst ausgeführt wird:

    kubectl get service SERVICE_NAME --output yaml

    Ersetzen Sie SERVICE_NAME durch den Namen des Dienstmanifests.

    Wenn Sie die zonale Affinität aktiviert haben, enthält die Ausgabe den Parameter spec.trafficDistribution mit dem Feld, das auf PreferClose gesetzt ist.

  • Prüfen Sie die IP-Adresse der Weiterleitungsregel des internen Passthrough-Network Load Balancers. Die IP-Adresse der Weiterleitungsregel des internen Passthrough-Network Load Balancers ist 10.128.15.245 im Beispiel im Abschnitt Internen LoadBalancer-Dienst erstellen. Prüfen Sie mit der Google Cloud CLI, ob 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

  • Beschreiben Sie den Backend-Dienst des Load-Balancers mit der Google Cloud CLI:

    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.

    Wenn Sie die zonale Affinität aktiviert haben:

    • Das Feld networkPassThroughLbTrafficPolicy.zonalAffinity.spillover sollte auf ZONAL_AFFINITY_SPILL_CROSS_ZONE gesetzt sein.
    • Das Feld networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio sollte auf 0 gesetzt oder nicht enthalten sein.

    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
networkPassThroughLbTrafficPolicy:
  zonalAffinity:
    spillover: ZONAL_AFFINITY_SPILL_CROSS_ZONE
protocol: TCP
...

    Wenn Sie die zonale Affinität deaktiviert haben, sollte das Feld networkPassThroughLbTrafficPolicy.zonalAffinity.spillover auf ZONAL_AFFINITY_DISABLED gesetzt oder nicht enthalten sein. Die zonale Affinität wird automatisch deaktiviert, wenn Ihr Cluster eine Version vor 1.33.3-gke.1392000 verwendet.

  • Liste der Knoten in einem Teil eines Dienstes 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.

  • Liste der fehlerfreien Knoten für einen internen Passthrough-Network Load Balancer 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

Führen Sie den folgenden Befehl in derselben Region wie der Cluster 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-Network-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-Network-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 globaler 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 derGoogle 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. Rufen Sie in der Google 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 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:

  • Jede Weiterleitungsregel kann bis zu fünf Ports (fortlaufend oder nicht fortlaufend) haben oder 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 mit allen Ports übereinstimmt.
  • Maximal zehn Dienste (Weiterleitungsregeln) können eine IP-Adresse gemeinsam nutzen. Dies bedeutet maximal 50 Ports pro freigegebener IP.
  • Für jede Weiterleitungsregel, die dieselbe IP-Adresse verwendet, muss eine eindeutige Kombination aus Protokollen und Ports verwendet werden. 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
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # Use an IP address that you create.
  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
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # Use the same IP address that you used for the TCP Service.
  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

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