Backend-Dienst-basierten externen Load-Balancer bereitstellen

Auf dieser Seite erfahren Sie, wie Sie einen externen LoadBalancer-Dienst bereitstellen, der einen Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer erstellt. Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Konzepten vertraut:

• LoadBalancer-Services
• GKE-LoadBalancer-Dienstparameter

Weitere Informationen zu regionalen externen Passthrough-Network-Load-Balancern im Allgemeinen finden Sie unter Backend-Dienst-basierter regionaler externer Passthrough-Network-Load-Balancer.

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 dem Befehl gcloud components update ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

Voraussetzungen

• In dieser Anleitung wird spec.loadBalancerClass verwendet, um einen Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer mit GCE_VM_IP-NEG-Backends zu erstellen. Für diese Anleitung ist die GKE-Version 1.33.1-gke.1779000 oder höher erforderlich, da spec.loadBalancerClass die GKE-Version 1.33.1-gke.1779000 oder höher erfordert. Die Version 1.33.1-gke.1779000 oder höher erfüllt auch die Mindestanforderungen an die GKE-Version für NEG-Backends oder die Funktion für gewichtetes Load Balancing.

• Wenn Ihr Cluster eine ältere Version als 1.36 hat, muss das Add-on HttpLoadBalancing in Ihrem Cluster aktiviert sein. Dieses Add-on ist standardmäßig aktiviert. Weitere Informationen finden Sie unter HttpLoadBalancing-Voraussetzung.

• Wenn Sie Cloud Logging für einen externen LoadBalancer-Dienst aktivieren möchten, muss Ihr GKE-Cluster die Version 1.36.0-gke.2459000 oder höher verwenden.

• Wenn Sie BYOIP-IPv6-Adressen (Bring Your Own IP) mit einem externen LoadBalancer-Dienst mit Single-Stack-IPv6 verwenden möchten, muss Ihr GKE-Cluster die Version 1.37.1-gke.2097000 oder höher verwenden.

Cluster auswählen

Sie können einen neuen Cluster erstellen oder einen vorhandenen Cluster auswählen, der die Anforderungen erfüllt.

Neuen Cluster erstellen

Autopilot

So erstellen Sie einen neuen Autopilot-Cluster:

gcloud container clusters create-auto CLUSTER_NAME \
    --release-channel=RELEASE_CHANNEL \
    --cluster-version=VERSION \
    --location=COMPUTE_LOCATION

Ersetzen Sie Folgendes:

• CLUSTER_NAME ist der Name des neuen Clusters.
• RELEASE_CHANNEL: der Name der GKE-Release-Version für den Cluster.
• VERSION: die GKE-Version für den Cluster.
• COMPUTE_LOCATION: die Compute Engine-Region des Clusters.

Wenn Sie das automatische Erstellen von VPC-Firewallregeln für LoadBalancer-Dienste deaktivieren möchten, fügen Sie das Flag --disable-l4-lb-firewall-reconciliation ein. Weitere Informationen finden Sie unter Vom Nutzer verwaltete Firewallregeln für GKE-LoadBalancer-Dienste.

Standard

So erstellen Sie einen neuen Standardcluster:

gcloud container clusters create CLUSTER_NAME \
    --release-channel=RELEASE_CHANNEL \
    --cluster-version=VERSION \
    --location=COMPUTE_LOCATION

Ersetzen Sie Folgendes:

• CLUSTER_NAME ist der Name des neuen Clusters.
• RELEASE_CHANNEL: der Name der GKE-Release-Version für den Cluster.
• VERSION: die GKE-Version für den Cluster.
• COMPUTE_LOCATION: die Compute Engine-Region des Clusters.

Wenn Sie das automatische Erstellen von VPC-Firewallregeln für LoadBalancer-Dienste deaktivieren möchten, fügen Sie das Flag --disable-l4-lb-firewall-reconciliation ein. Weitere Informationen finden Sie unter Vom Nutzer verwaltete Firewallregeln für GKE-LoadBalancer-Dienste.

Vorhandenen Cluster aktualisieren

Verwenden Sie die gcloud CLI, um einen vorhandenen Cluster zu aktualisieren:

gcloud container clusters upgrade CLUSTER_NAME \
    --cluster-version=VERSION \
    --master \
    --location=COMPUTE_LOCATION

Ersetzen Sie Folgendes:

• CLUSTER_NAME den Namen des vorhandenen Clusters.
• VERSION: die spezifische GKE-Version, auf die Sie Ihren Cluster aktualisieren möchten. Weitere Informationen finden Sie unter Manuelles Upgrade der Steuerungsebene.
• COMPUTE_LOCATION: die Compute Engine-Region des Clusters.

Wenn Sie das automatische Erstellen von VPC-Firewallregeln für LoadBalancer-Dienste deaktivieren möchten, fügen Sie das Flag --disable-l4-lb-firewall-reconciliation ein. Weitere Informationen finden Sie unter Vom Nutzer verwaltete Firewallregeln für GKE-LoadBalancer-Dienste.

Beispielarbeitslast bereitstellen

Stellen Sie die folgende Beispielarbeitslast bereit, die die Bereitstellungs-Pods für den externen LoadBalancer-Dienst bereitstellt.

1. Speichern Sie das folgende Beispiel-Deployment als store-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: store
   spec:
     replicas: 20
     selector:
       matchLabels:
         app: store
     template:
       metadata:
         labels:
           app: store
       spec:
         containers:
         - image: registry.k8s.io/echoserver:1.10
           imagePullPolicy: Always
           name: echoserver
           ports:
             - name: http
               containerPort: 8080
           readinessProbe:
             httpGet:
               path: /healthz
               port: 8080
               scheme: HTTP
   

2. Wenden Sie das Manifest auf den Cluster an:

   kubectl apply -f store-deployment.yaml
   

3. Prüfen Sie, ob für das Deployment 20 Bereitstellungs-Pods vorhanden sind:

   kubectl get pods
   

   Die Ausgabe sieht etwa so aus:

   NAME                     READY   STATUS    RESTARTS   AGE
   store-cdb9bb4d6-s25vw      1/1     Running   0          10s
   store-cdb9bb4d6-vck6s      1/1     Running   0          10s
   ....
   

Externen LoadBalancer-Dienst erstellen

1. Beispielarbeitslast durch Erstellen eines externen LoadBalancer-Dienstes verfügbar machen.

   1. Speichern Sie das folgende Dienstmanifest als store-v1-lb-svc.yaml:

      apiVersion: v1
      kind: Service
      metadata:
        name: store-v1-lb-svc
      spec:
        type: LoadBalancer
        loadBalancerClass: networking.gke.io/l4-regional-external
        selector:
          app: store
        ports:
        - name: tcp-port
          protocol: TCP
          port: 8080
          targetPort: 8080
      

   2. Wenden Sie das Manifest auf den Cluster an:

      kubectl apply -f store-v1-lb-svc.yaml
      

   Beachten Sie die folgenden Punkte zu diesem Beispielmanifest:

   • Wenn auf Ihrem Cluster GKE 1.33.1-gke.1779000 bis 1.36 ausgeführt wird, müssen Sie das Feld spec.loadBalancerClass auf den Wert networking.gke.io/l4-regional-external setzen, wenn das Manifest zum ersten Mal auf den Cluster angewendet wird. Dieses Feld weist GKE an, einen Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer zu erstellen. In GKE 1.37 und höher ist diese Konfiguration das Standardverhalten und das Feld ist nicht erforderlich. Backend-Dienst-basierte regionale externe Passthrough-Network Load Balancer sind erforderlich, um Features wie IPv6-Traffic und gewichtetes Load Balancing zu unterstützen.

   • Die GKE verwendet je nach Clusterversion entweder GCE_VM_IP-NEG-Backends oder nicht verwaltete Instanzgruppen-Backends. In Clustern mit Version 1.32.2-gke.1652000 verwendet der Backend-Dienst-basierte regionale externe Passthrough-Network-Load-Balancer GCE_VM_IP-NEGs. In früheren Versionen verwendet der Backend-Dienst-basierte regionale externe Passthrough-Network-Load-Balancer nicht verwaltete Instanzgruppen.

   • Dieses spec.loadBalancerClass-Feld ist unveränderlich und muss beim Erstellen des Dienstes festgelegt werden. Da dieses Feld unveränderlich ist, können Sie es im Manifest eines vorhandenen LoadBalancer-Dienstes nicht hinzufügen oder ändern. Jeder Versuch, dies zu tun, führt zu einem Fehler und die Dienstaktualisierung schlägt fehl.

   • Wenn Sie einen Single-Stack-IPv6-Dienst in einem Dual-Stack-Cluster erstellen möchten, setzen Sie den Wert des Felds spec.ipFamilyPolicy auf SingleStack und den Wert des Felds spec.ipFamilies auf IPv6. In einem Single-Stack-IPv6-Cluster sind dies die Standardwerte und Sie können sie weglassen. Weitere Informationen finden Sie unter IPv6-LoadBalancer-Dienste.

Externen LoadBalancer-Dienst in einem Single-Stack-IPv6-Cluster erstellen

Wenn Sie einen externen Single-Stack-IPv6-LoadBalancer-Dienst in einem Single-Stack-IPv6-Cluster oder einem Dual-Stack-Cluster erstellen, hängt das vom Load Balancer verwendete Subnetz davon ab, ob das Knoten-Subnetz Ihres Clusters einen IPv6-Zugriffstyp EXTERNAL oder INTERNAL verwendet. In einem Dual-Stack-Cluster müssen Sie den Wert des Felds spec.ipFamilyPolicy auf SingleStack und den Wert des Felds spec.ipFamilies auf IPv6 festlegen. In einem Single-Stack-IPv6-Cluster sind dies die Standardwerte und Sie können sie weglassen. Externe IPv6-LoadBalancer-Dienste verwenden immer einen Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer in der Premium-Stufe. In den folgenden Beispielen wird das Feld spec.loadBalancerClass explizit auf networking.gke.io/l4-regional-external gesetzt, obwohl diese Load Balancer-Variante in GKE-Version 1.37 und höher die Standardeinstellung ist:

• Cluster mit externen Knoten (Zugriffstyp EXTERNAL GUA): Wenn Ihre Clusterknoten in einem externen Subnetzwerk mit Global Unicast Addresses (GUA) ausgeführt werden, verwendet der externe Load Balancer automatisch das vorhandene Knotensubnetzwerk. Erstellen Sie den Dienst ohne benutzerdefinierte Subnetzannotationen:

  apiVersion: v1
  kind: Service
  metadata:
    name: ext-ipv6-svc
  spec:
    type: LoadBalancer
    loadBalancerClass: networking.gke.io/l4-regional-external
    ipFamilyPolicy: SingleStack
    ipFamilies:
    - IPv6
    selector:
      app: store
    ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
  

• Cluster mit internen Knoten (INTERNAL-ULA-Zugriffstyp): Wenn Ihre Clusterknoten in einem internen Subnetzwerk mit eindeutigen lokalen Unicast-Adressen (ULA) ausgeführt werden, kann ein externer Load Balancer dieses Subnetzwerk nicht direkt verwenden. Sie müssen ein dediziertes externes (EXTERNAL) IPv6-Subnetz bereitstellen und es mit der Annotation networking.gke.io/load-balancer-subnet in Ihrem Dienst referenzieren:

  1. Erstellen Sie ein dediziertes externes IPv6-Subnetzwerk:

     gcloud compute networks subnets create SUBNET_NAME \
         --stack-type=ipv6_only \
         --ipv6-access-type=EXTERNAL \
         --network=NETWORK_NAME \
         --region=COMPUTE_REGION
     

     Ersetzen Sie Folgendes:

     • SUBNET_NAME: Der Name des zu erstellenden Subnetzes.
     • NETWORK_NAME: der Name des VPC-Netzwerks, in dem Sie dieses Subnetz erstellen.
     • COMPUTE_REGION: die Compute Engine-Region für das Subnetz.

  2. Erstellen Sie den Dienst, der in der Annotation networking.gke.io/load-balancer-subnet auf den Namen Ihres dedizierten Subnetzwerks verweist:

     apiVersion: v1
     kind: Service
     metadata:
       name: ext-ipv6-svc
       annotations:
         networking.gke.io/load-balancer-subnet: SUBNET_NAME
     spec:
       type: LoadBalancer
       loadBalancerClass: networking.gke.io/l4-regional-external
       ipFamilyPolicy: SingleStack
       ipFamilies:
       - IPv6
       selector:
         app: store
       ports:
       - protocol: TCP
         port: 8080
         targetPort: 8080
     

1. Prüfen Sie die zugewiesene Dienst-IP-Adresse:

   kubectl get svc ext-ipv6-svc
   

   Die Ausgabe bestätigt, dass die Spalten CLUSTER-IP und EXTERNAL-IP (eine öffentliche GUA-Adresse) ausgefüllt sind:

   NAME           TYPE           CLUSTER-IP                          EXTERNAL-IP                      PORT(S)        AGE
   ext-ipv6-svc   LoadBalancer   2600:2d00:0:4:1a1e:d3b3:de4d:c401   2600:1900:4000:2714:8000:0:0:0   80:31114/TCP   51s
   

Weitere Informationen finden Sie unter IPv6-LoadBalancer-Dienste.

Eigene IPv6-Adressen verwenden (BYOIPv6)

In GKE-Version 1.37.1-gke.2097000 und höher können Sie einen externen LoadBalancer-Dienst mit Single-Stack-IPv6 so konfigurieren, dass eigene IPv6-Adressen (BYOIPv6) aus einem regionalen IPv6-Subpräfix eines PDP (Public Delegated Prefix) im EXTERNAL_IPV6_FORWARDING_RULE_CREATION-Modus verwendet werden.

Bevor Sie den Dienst erstellen, müssen die folgenden Anforderungen erfüllt sein:

• Auf Ihrem Cluster wird die GKE-Version 1.37.1-gke.2097000 oder höher ausgeführt. Der Cluster kann ein Einzel-Stack-IPv6- oder ein Dual-Stack-Cluster sein (der Dienst muss in beiden Fällen ein Einzel-Stack-IPv6-Dienst sein) und das Subnetz des Clusters kann entweder den IPv6-Zugriffstyp INTERNAL oder EXTERNAL haben. Ein externer IPv6-Subnetzbereich ist nicht erforderlich, da der Adressbereich aus dem öffentlichen delegierten Präfix stammt.
• Sie haben ein regionales IPv6-Subpräfix im Modus EXTERNAL_IPV6_FORWARDING_RULE_CREATION mit einer zuweisbaren Präfixlänge von /96 und dem Status ANNOUNCED in derselben Region wie Ihr Cluster. Eine Anleitung dazu finden Sie unter IPv6-Unterpräfixe erstellen.

• Der GKE-Dienst-Agent (service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com) hat die Rolle „Compute Public-IP-Administrator“ (roles/compute.publicIpAdmin) für das Projekt, zu dem das öffentlich delegierte Präfix gehört. Führen Sie den folgenden Befehl aus, um die Rolle zuzuweisen:

  gcloud projects add-iam-policy-binding PDP_PROJECT_ID \
      --member="serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com" \
      --role="roles/compute.publicIpAdmin"
  

  Ersetzen Sie Folgendes:

  • PDP_PROJECT_ID: die ID des Projekts, zu dem das öffentlich delegierte Präfix gehört.
  • PROJECT_NUMBER: die Projektnummer des Projekts, das Ihren Cluster enthält.

• Der Dienst ist ein Single-Stack-IPv6-Dienst (spec.ipFamilyPolicy: SingleStack und spec.ipFamilies: ["IPv6"]), der das Feld spec.loadBalancerClass auf networking.gke.io/l4-regional-external setzt und die Premium-Stufe verwendet. Dual-Stack-Dienste, IPv4-Dienste und die Standard-Stufe werden mit BYOIPv6 nicht unterstützt.

• Der Dienst enthält nicht die Annotation networking.gke.io/load-balancer-subnet, die nicht mit der Annotation networking.gke.io/ip-collection-v6 kombiniert werden kann.

Wählen Sie aus, ob Sie einen sitzungsspezifischen externen BYOIPv6-Adressbereich zuweisen oder einen reservierten statischen externen BYOIPv6-Adressbereich verwenden möchten:

• Sitzungsspezifischer externer BYOIPv6-Adressbereich: Fügen Sie Ihrem Dienstmanifest die Annotation networking.gke.io/ip-collection-v6 hinzu und legen Sie sie auf die vollständige Ressourcen-URL oder den partiellen Ressourcenpfad Ihres regionalen Subpräfixes fest:

  apiVersion: v1
  kind: Service
  metadata:
    name: ext-byoipv6-svc
    annotations:
      networking.gke.io/ip-collection-v6: "projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME"
  spec:
    type: LoadBalancer
    loadBalancerClass: networking.gke.io/l4-regional-external
    ipFamilyPolicy: SingleStack
    ipFamilies:
    - IPv6
    selector:
      app: store
    ports:
    - name: tcp-port
      protocol: TCP
      port: 80
      targetPort: 8080
  

  Ersetzen Sie Folgendes:

  • PROJECT_ID: die ID des Projekts, das das Unterpräfix enthält.
  • REGION: Die Region Ihres Clusters.
  • SUB_PREFIX_NAME: der Name Ihres regionalen Unterpräfixes im EXTERNAL_IPV6_FORWARDING_RULE_CREATION-Modus.

  Wenn Sie die Annotation networking.gke.io/ip-collection-v6 später ändern, erstellt GKE die IPv6-Weiterleitungsregel mit einer neuen Adresse aus dem neuen Präfix neu. Dadurch wird der Traffic zum Dienst kurzzeitig unterbrochen. Wenn Sie die Annotation entfernen, wird der Dienst auf eine von Google bereitgestellte Adresse aus einem Subnetz mit einem externen IPv6-Bereich zurückgesetzt. Wenn das Subnetz Ihres Clusters einen internen IPv6-Bereich hat, fügen Sie gleichzeitig die Annotation networking.gke.io/load-balancer-subnet hinzu.

• Statischer externer BYOIPv6-Adressbereich: Reservieren Sie einen regionalen statischen externen /96-IPv6-Adressbereich aus dem Subpräfix und verweisen Sie mit der Annotation networking.gke.io/load-balancer-ip-addresses darauf:

  1. Erstellen Sie einen regionalen statischen externen IPv6-Adressbereich aus Ihrem Subpräfix:

     gcloud compute addresses create STATIC_BYOIPV6_NAME \
         --region=REGION \
         --ip-version=IPV6 \
         --endpoint-type=NETLB \
         --ip-collection=projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME
     

     Ersetzen Sie Folgendes:

     • STATIC_BYOIPV6_NAME: ein Name für die statische IPv6-Adressressource.
     • REGION: Die Region Ihres Clusters.
     • PROJECT_ID: die ID des Projekts, das das Unterpräfix enthält.
     • SUB_PREFIX_NAME: der Name Ihres regionalen Unterpräfixes im EXTERNAL_IPV6_FORWARDING_RULE_CREATION-Modus.

     Die Annotation networking.gke.io/ip-collection-v6 ist optional, wenn Sie einen statischen externen BYOIPv6-Adressbereich verwenden. Wenn Sie diese Annotation festlegen, muss sie auf dasselbe Unterpräfix verweisen, aus dem Sie den Adressbereich reserviert haben.

  2. Verweisen Sie in Ihrem Dienstmanifest auf den Ressourcennamen der reservierten statischen IPv6-Adresse:

     apiVersion: v1
     kind: Service
     metadata:
       name: ext-static-byoipv6-svc
       annotations:
         networking.gke.io/load-balancer-ip-addresses: STATIC_BYOIPV6_NAME
     spec:
       type: LoadBalancer
       loadBalancerClass: networking.gke.io/l4-regional-external
       ipFamilyPolicy: SingleStack
       ipFamilies:
       - IPv6
       selector:
         app: store
       ports:
       - name: tcp-port
         protocol: TCP
         port: 80
         targetPort: 8080
     

Weitere Informationen finden Sie unter Eigene IPv6-Adressen verwenden (BYOIPv6).

Gewichtetes Load Balancing aktivieren

Wenn Sie neue Verbindungen proportional auf Knoten verteilen möchten, je nachdem, wie viele bereitstellende, bereite und nicht-terminierende Pods auf jedem Knoten vorhanden sind, aktivieren Sie das gewichtete Load Balancing, indem Sie die Annotation networking.gke.io/weighted-load-balancing: "pods-per-node" zum Dienstmanifest hinzufügen.

1. Fügen Sie die Annotation networking.gke.io/weighted-load-balancing: "pods-per-node" dem Dienstmanifest store-v1-lb-svc.yaml hinzu und legen Sie den Wert externalTrafficPolicy: Local fest, sodass er so aussieht:

   apiVersion: v1
   kind: Service
   metadata:
     name: store-v1-lb-svc
     annotations:
       networking.gke.io/weighted-load-balancing: "pods-per-node"
   spec:
     type: LoadBalancer
     loadBalancerClass: networking.gke.io/l4-regional-external
     externalTrafficPolicy: Local
     selector:
       app: store
     ports:
     - name: tcp-port
       protocol: TCP
       port: 8080
       targetPort: 8080
   

2. Wenden Sie das Manifest auf den Cluster an:

   kubectl apply -f store-v1-lb-svc.yaml
   

Beachten Sie Folgendes zu diesem Beispiel für gewichtetes Load Balancing:

• Das Dienstmanifest verwendet externalTrafficPolicy: Local. Wenn Sie das gewichtete Load Balancing nicht aktivieren müssen, können Sie auch externalTrafficPolicy: Cluster verwenden. Ausführliche Informationen dazu, wie mit externalTrafficPolicy die Knotengruppierung definiert wird, welche Knoten ihre Load-Balancer-Systemdiagnosen bestehen und wie Pakete verarbeitet werden, finden Sie unter Konzepte des LoadBalancer-Dienstes.

• Wenn Sie gewichtetes Load Balancing aktivieren, verhindert die GKE nicht, dass Sie externalTrafficPolicy: Cluster verwenden. externalTrafficPolicy: Cluster deaktiviert jedoch effektiv das gewichtete Load Balancing, da das Paket nach dem Load Balancer möglicherweise an einen anderen Knoten weitergeleitet wird.

Sie können das gewichtete Load Balancing auch für einen vorhandenen externen LoadBalancer-Dienst mit kubectl edit svc service-name aktivieren. Mit dem Befehl kubectl edit wird das Dienstmanifest des vorhandenen Load Balancers in Ihrem konfigurierten Texteditor geöffnet. Dort können Sie das Manifest ändern und die Änderungen speichern. Beachten Sie beim Bearbeiten eines vorhandenen externen LoadBalancer-Dienstes die folgenden Punkte:

• Der vorhandene externe LoadBalancer-Dienst muss zur Erstellung eines Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancers geführt haben. Bei Clustern mit GKE-Versionen vor 1.37 bedeutet diese Anforderung, dass der vorhandene externe LoadBalancer-Dienst das Feld spec.loadBalancerClass auf networking.gke.io/l4-regional-external gesetzt haben muss, als das Manifest zum ersten Mal auf den Cluster angewendet wurde.

  Das Hinzufügen der Annotation networking.gke.io/weighted-load-balancing: "pods-per-node" zu einem vorhandenen externen LoadBalancer-Dienst, der einen zielpoolbasierten regionalen externen Passthrough-Network Load Balancer verwendet, hat keine Auswirkungen.

• Achten Sie beim Aktualisieren des vorhandenen externen LoadBalancer-Dienstmanifests darauf, den Wert externalTrafficPolicy: Local festzulegen. Wenn Sie externalTrafficPolicy: Cluster verwenden, wird das gewichtete Load Balancing effektiv deaktiviert, da das Paket nach dem Load Balancer möglicherweise an einen anderen Knoten weitergeleitet wird.

Gewichtetes Load Balancing deaktivieren

Wenn Sie neue Verbindungen unabhängig von der Anzahl der bereitstellenden Pods auf jedem Knoten verteilen möchten, deaktivieren Sie das gewichtete Load Balancing, indem Sie die Annotation networking.gke.io/weighted-load-balancing: "pods-per-node" aus dem Dienstmanifest entfernen.

Logging für Backend-Dienste aktivieren

Sie können Logs für einen Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer aktivieren, deaktivieren und aufrufen.

Sie konfigurieren Cloud Logging, indem Sie eine benutzerdefinierte L4LBConfig-Ressource erstellen, in der Ihre Logging-Einstellungen angegeben sind. Die L4LBConfig-Ressource ist im Dienstmanifest mit einem Kubernetes-Dienst verknüpft. Nachdem Sie das Manifest angewendet haben, konfiguriert der GKE-Controller das Logging für den Backend-Dienst. Wenn Sie keine L4LBConfig-Ressource mit dem Dienst verknüpfen, verwaltet der Controller die Logging-Konfiguration nicht mehr und belässt den Backend-Dienst im letzten bekannten Zustand. Weitere Informationen finden Sie unter Informationen zum Coast-Verhalten.

Sie können folgende Felder konfigurieren:

• enabled: Wenn dieser Wert auf true gesetzt ist, wird das Logging für diesen Dienst aktiviert und Logs sind in Cloud Logging verfügbar. Andernfalls ist das Logging für diesen Dienst deaktiviert.
• sampleRate: Gibt einen Wert zwischen 0 und 1,000,000 (Standard) an, wobei 0 bedeutet, dass keine Pakete protokolliert werden, und 1,000,000 bedeutet, dass 100 % der Pakete protokolliert werden. Das Feld sampleRate ist optional und nur relevant, wenn der Wert des Felds enable auf true gesetzt ist.
• optionalMode: Steuert, welche optionalen Metadatenfelder in den generierten Logs für den Load Balancer enthalten sind. Das Feld akzeptiert einen der folgenden Stringwerte:
  • EXCLUDE_ALL_OPTIONAL: Standardeinstellung, wenn optionalMode nicht angegeben ist. Wenn diese Option festgelegt ist, sind keine optionalen Felder in den Logs enthalten. Dies ist das prägnanteste Logformat.
  • INCLUDE_ALL_OPTIONAL: Aktiviert das Logging für alle verfügbaren optionalen Felder und liefert die detailliertesten Logeinträge.
  • CUSTOM: Gibt eine benutzerdefinierte Liste optionaler Felder an, die in den Logs enthalten sind. Im Modus CUSTOM müssen Sie außerdem den Parameter optionalFields verwenden, um eine durch Kommas getrennte Liste der gewünschten Felder anzugeben.
• optionalFields: kommagetrennter String mit Feldnamen. Definiert die genauen optionalen Metadatenfelder, die in den generierten Logs enthalten sein sollen. Dieses Feld wird nur verwendet, wenn optionalMode auf CUSTOM gesetzt ist. Andernfalls werden alle Werte ignoriert.

Erstellen Sie zum Konfigurieren von Cloud Logging die L4LBConfig-Ressource im selben Namespace wie Ihre Service-Ressource. Im folgenden L4LBConfig-Beispielmanifest wird Cloud Logging aktiviert und die Abtastrate auf 50 % der Anfragen für einen bestimmten Load-Balancer-Dienst festgelegt.

1. Speichern Sie das folgende Manifest als svc-l4lb-config.yaml:

   apiVersion: networking.gke.io/v1
   kind: L4LBConfig
   metadata:
     name: svc-l4lb-config
     namespace: default
   spec:
     logging:
       enabled: true # must be included
       sampleRate: 500000
       optionalMode: "INCLUDE_ALL_OPTIONAL"
   

2. Wenden Sie das L4LBConfig-Manifest auf Ihren Cluster an:

   kubectl apply -f svc-l4lb-config.yaml
   

3. Fügen Sie dem store-v1-lb-svc.yaml-Dienstmanifest die Annotation networking.gke.io/l4lb-config hinzu:

   apiVersion: v1
   kind: Service
   metadata:
     name: store-v1-lb-svc
     annotations:
       cloud.google.com/l4-rbs: "enabled"
       networking.gke.io/l4lb-config: "svc-l4lb-config"
   spec:
     type: LoadBalancer
     selector:
       app: store
     ports:
       - name: tcp-port
         protocol: TCP
         port: 8080
         targetPort: 8080
   

4. Wenden Sie das Dienstmanifest auf Ihren Cluster an:

   kubectl apply -f store-v1-lb-svc.yaml
   

Externen LoadBalancer-Dienst und seine Komponenten überprüfen

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

   kubectl get svc store-v1-lb-svc
   

   Die Ausgabe sieht etwa so aus:

   NAME               TYPE           CLUSTER-IP        EXTERNAL-IP     PORT(S)          AGE
   store-v1-lb-svc   LoadBalancer   10.44.196.160     35.193.28.231   8080:32466/TCP   11m
   

   GKE hat EXTERNAL_IP für den regionalen externen Passthrough-Network-Load-Balancer zugewiesen.

2. Testen Sie die Verbindung zum Load-Balancer:

   curl EXTERNAL_IP:PORT
   

   Ersetzen Sie Folgendes:

   • EXTERNAL_IP: die zugewiesene IP-Adresse für den regionalen externen Passthrough-Network-Load-Balancer.
   • PORT: die zugewiesene Portnummer für den regionalen externen Passthrough-Network-Load-Balancer.

   Die Ausgabe sieht etwa so aus:

   Hostname: store-v1-lb-svc-cdb9bb4d6-hflxd
   
   Pod Information:
     -no pod information available-
   
   Server values:
     server_version=nginx: 1.13.3 - lua: 10008
   
   Request Information:
     client_address=10.128.0.50
     method=GET
     real path=/
     query=
     request_version=1.1
     request_scheme=http
     request_uri=EXTERNAL_IP
   
   Request Headers:
     accept=*/*
     host=EXTERNAL_IP
     user-agent=curl/7.81.0
   
   Request Body:
     -no body in request-
   
   

3. Prüfen Sie Ihren LoadBalancer-Dienst und die zugehörigen Annotationen, um seineCloud de Confiance -Ressourcen zu beschreiben:

   kubectl describe svc store-v1-lb-svc
   

   Die Ausgabe sieht etwa so aus:

   Name:                     store-v1-lb-svc
   Namespace:                default
   Labels:                   <none>
   Annotations:              cloud.google.com/neg-status: {"network_endpoint_groups":{"0":"k8s2-qvveq1d8-default-my-service-ext-5s55db85"},"zones":["us-central1-c"]} #This annotation appears in the output only if the service uses NEG backends.
                             networking.gke.io/weighted-load-balancing: pods-per-node #This annotation appears in the output only if weighted load balancing is enabled.
                             service.kubernetes.io/backend-service: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                             service.kubernetes.io/firewall-rule: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                             service.kubernetes.io/firewall-rule-for-hc: k8s2-qvveq1d8-default-my-service-ext-5s55db85-fw
                             service.kubernetes.io/healthcheck: k8s2-qvveq1d8-default-my-service-ext-5s55db85
                             service.kubernetes.io/tcp-forwarding-rule: a808124abf8ce406ca51ab3d4e7d0b7d
   Selector:                 app=store
   Type:                     LoadBalancer
   IP Family Policy:         SingleStack
   IP Families:              IPv4
   IP:                       10.18.102.23
   IPs:                      10.18.102.23
   LoadBalancer Ingress:     35.184.160.229
   Port:                     tcp-port  8080/TCP
   TargetPort:               8080/TCP
   NodePort:                 tcp-port  31864/TCP
   Endpoints:                10.20.1.28:8080,10.20.1.29:8080
   Session Affinity:         None
   External Traffic Policy:  Local
   HealthCheck NodePort:     30394
   
   Events:
     Type    Reason                Age                    From                     Message
     ----    ------                ----                   ----                     -------
     Normal  ADD                   4m55s                  loadbalancer-controller  default/my-service-ext
   

   Es gibt mehrere Felder, die angeben, dass ein Backend-Dienst-basierter regionaler externer Passthrough-Network-Load-Balancer und seine Cloud de Confiance -Ressourcen erfolgreich erstellt wurden:

   • Events-Feld. Dieses Feld ist leer, wenn der LoadBalancer-Dienst und seine Ressourcen erfolgreich erstellt wurden. Ein Fehler ist hier aufgeführt.

   • Liste aktivierter Annotations: GKE fügt dem Dienstmanifest die folgende Liste schreibgeschützter Annotationen hinzu. Jede Annotation, deren Name mit service.kubernetes.io/ beginnt, wird verwendet, um den Namen einerCloud de Confiance -Ressource anzugeben, die als Teil oder zur Unterstützung des Load Balancers erstellt wurde.

     • Die Annotation networking.gke.io/weighted-load-balancing: pods-per-node gibt an, dass gewichtetes Load Balancing angewendet wurde und der Load Balancer den Traffic basierend auf der Anzahl der auf jedem Knoten ausgeführten Pods auf die Backend-Pods verteilt.
     • Die Annotation service.kubernetes.io/backend-service gibt den Namen des Backend-Dienstes des Load Balancers an.
     • Die Annotation service.kubernetes.io/healthcheck gibt den Namen der Load-Balancer-Systemdiagnose an, die vom Backend-Dienst verwendet wird.
     • Die Annotation service.kubernetes.io/tcp-forwarding-rule oder service.kubernetes.io/udp-forwarding-rule gibt den Namen der Weiterleitungsregel des Load Balancers an.
     • Die Anmerkung service.kubernetes.io/firewall-rule gibt den Namen der Firewallregel an, die Traffic zu den Clusterknoten zulässt. Die Quellbereiche für diese Firewallregel können mit spec.loadBalancerSourceRanges[] angepasst werden. Weitere Informationen zu Firewallregeln für LoadBalancer-Dienste finden Sie unter Firewallregeln und Zulassungslisten für Quell-IP-Adressen.
     • Die Annotation service.kubernetes.io/firewall-rule-for-hc gibt den Namen der Firewallregel an, die für Systemdiagnosen des Load Balancers erforderlich ist.

     • Die Annotation cloud.google.com/neg-status gibt sowohl die NEGs an, die vom Load Balancer verwendet werden, als auch deren Zonen. Diese Annotation ist nur vorhanden, wenn beide der folgenden Bedingungen erfüllt sind:

       • Auf dem Cluster wurde die GKE-Version 1.32.2-gke.1652000 oder höher ausgeführt, als das Manifest auf den Cluster angewendet wurde.
       • Das Feld spec.loadBalancerClass, das auf den Wert networking.gke.io/l4-regional-external festgelegt wurde, war im Dienstmanifest vorhanden, als es auf den Cluster angewendet wurde.

4. Prüfen Sie, ob Load-Balancer-Ressourcen und Firewallregeln für den externen LoadBalancer-Dienst erstellt wurden:

   • Führen Sie den folgenden Befehl aus, um die Weiterleitungsregel aufzurufen:

       gcloud compute forwarding-rules describe FWD_RULE_NAME \
         --region=REGION_NAME
     

     Ersetzen Sie Folgendes:

     • FWD_RULE_NAME: der Name der Weiterleitungsregel, der durch die schreibgeschützten Annotationen service.kubernetes.io/tcp-forwarding-rule oder service.kubernetes.io/udp-forwarding-rule bereitgestellt wird. Führen Sie kubectl describe svc SERVICE_NAME aus, um diese Annotationen zu prüfen.
     • REGION_NAME: die Cloud de Confiance -Region, die den Cluster enthält. Bei zonalen Clustern enthält die Region die vom Cluster verwendete Zone.

   • Führen Sie den folgenden Befehl aus, um den Backend-Dienst anzuzeigen:

     gcloud compute backend-services describe BACKEND_SERVICE_NAME \
       --region=REGION_NAME
     

     Ersetzen Sie Folgendes:

     • BACKEND_SERVICE_NAME: der Name des Backend-Dienstes, der von der schreibgeschützten Annotation service.kubernetes.io/backend-service bereitgestellt wird. Um diese schreibgeschützte Annotation zu prüfen, führen Sie kubectl describe svc SERVICE_NAME aus.
     • REGION_NAME: die Cloud de Confiance -Region, die den Cluster enthält. Bei zonalen Clustern enthält die Region die vom Cluster verwendete Zone.

   • Führen Sie den folgenden Befehl aus, um die Systemdiagnose des Load-Balancers anzeigen zu lassen:

     gcloud compute health-checks describe HEALTH_CHECK_NAME \
       --region=REGION_NAME
     

     Ersetzen Sie Folgendes:

     • HEALTH_CHECK_NAME: der Name der Systemdiagnose des Load Balancers. Der Name der Systemdiagnose wird durch die schreibgeschützte Annotation service.kubernetes.io/healthcheck bereitgestellt. Um diese schreibgeschützte Annotation zu prüfen, führen Sie kubectl describe svc SERVICE_NAME aus.
     • REGION_NAME: die Cloud de Confiance -Region, die den Cluster enthält. Bei zonalen Clustern enthält die Region die vom Cluster verwendete Zone.

   • Führen Sie die folgenden Befehle aus, um die Firewall-Regeln anzeigen zu lassen:

     gcloud compute firewall-rules describe FIREWALL_RULE_NAME
     

     gcloud compute firewall-rules describe HEALTH_CHECK_FIREWALL_RULE_NAME
     

     Ersetzen Sie Folgendes:

     • FIREWALL_RULE_NAME: der Name der Firewallregel, die Traffic zum Load Balancer zulässt. Der Name dieser Firewallregel wird von der schreibgeschützten Annotation service.kubernetes.io/firewall-rule bereitgestellt. Um diese schreibgeschützte Annotation zu prüfen, führen Sie kubectl describe svc SERVICE_NAME aus.
     • HEALTH_CHECK_FIREWALL_RULE_NAME: der Name der Firewallregel, die Systemdiagnosen der Back-Ends des Load Balancers (die Knoten des Clusters) zulässt. Der Name dieser Firewallregel wird von der schreibgeschützten Annotation service.kubernetes.io/firewall-rule-for-hc bereitgestellt. Um diese schreibgeschützte Annotation zu prüfen, führen Sie kubectl describe svc SERVICE_NAME aus.

   • Führen Sie den folgenden Befehl aus, um die NEGs des Load Balancers aufzurufen:

     gcloud compute network-endpoint-groups describe NEG_NAME \
       --zone=ZONE_NAME
     

     Ersetzen Sie Folgendes:

     • NEG_NAME: der Name der NEG des Load Balancers. Der Name der NEG wird durch die schreibgeschützte Annotation cloud.google.com/neg-status bereitgestellt. Führen Sie den Befehl kubectl describe svc SERVICE_NAME aus, um diese schreibgeschützte Annotation zu prüfen. Die Annotation enthält strukturierte Daten mit Informationen zu den NEG-Namen und -Zonen, die vom Load Balancer verwendet werden. Bei zonalen Clustern enthält diese Annotation Informationen zu einer NEG. Bei regionalen Clustern enthält diese Annotation Informationen zu einer NEG in jeder Zone, in der sich der Cluster befindet.
     • ZONE_NAME: die Cloud de Confiance Zone, die die NEG enthält.

5. Prüfen Sie, ob Cloud Logging für den Backend-Dienst aktiviert wurde:

   kubectl get svc SERVICE_NAME --output yaml
   

   Ersetzen Sie Folgendes:

   • SERVICE_NAME: Der Name des Backend-Dienstes.

   Prüfen Sie in der Ausgabe, ob das Feld Status.Conditions die Werte Type: LoggingConfigManaged und Reason: Reconciled enthält.

Externen LoadBalancer-Dienst löschen

Verwenden Sie den folgenden Befehl, um den externen LoadBalancer-Beispieldienst store-v1-lb-svc zu löschen:

kubectl delete service store-v1-lb-svc

GKE entfernt automatisch alle Load-Balancer-Ressourcen, die für den externen LoadBalancer-Dienst erstellt wurden.

Zu GCE_VM_IP-NEG-Back-Ends migrieren

Externe LoadBalancer-Dienste erstellen Backend-Dienst-basierte regionale externe Passthrough-Network Load Balancer, wenn sie in GKE 1.37 oder höher erstellt werden, den Wert networking.gke.io/l4-regional-external für das Feld spec.loadBalancerClass angeben oder die Annotation cloud.google.com/l4-rbs: "enabled" enthalten. Je nach GKE-Version des Clusters verwendet GKE entweder GCE_VM_IP-Netzwerk-Endpunktgruppen oder nicht verwaltete Instanzgruppen als Backends:

• Wenn das Dienstmanifest auf einen Cluster mit GKE-Version 1.32.2-gke.1652000 oder höher angewendet wurde, verwendet der resultierende regionale externe Passthrough-Network-Load-Balancer GCE_VM_IP-NEG-Backends (Netzwerk-Endpunktgruppe).

• Wenn das Dienstmanifest auf einen Cluster angewendet wurde, auf dem eine frühere GKE-Version ausgeführt wird, verwendet der resultierende regionale externe Passthrough-Network-Load-Balancer nicht verwaltete Instanzgruppen-Backends.

Weitere Informationen finden Sie unter Knotengruppierung in „Informationen zu LoadBalancer-Diensten“.

Sie können einen neuen externen LoadBalancer-Dienst erstellen, der von einem Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer unterstützt wird, der GCE_VM_IP-NEG-Backends verwendet, wenn Ihr vorhandener Dienst einen der folgenden Load Balancer verwendet:

• Ein Backend-Dienst-basierter regionaler externer Passthrough-Network-Load-Balancer mit Instanzgruppen-Backends
• Zielpoolbasierter regionaler externer Passthrough-Network Load Balancer

So behalten Sie eine externe IPv4-Adresse bei, wenn Sie zu einem Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer wechseln, der GCE_VM_IP-NEG-Backends verwendet (für externe IPv6-LoadBalancer-Dienste ist diese Migration nicht erforderlich):

1. Falls noch nicht geschehen, aktualisieren Sie Ihren Cluster auf die GKE-Version 1.32.2-gke.1652000 oder höher.

2. Identifizieren Sie den externen LoadBalancer-Dienst, den Sie auf einen Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancer mit GCE_VM_IP-NEG-Backends umstellen möchten. Beschreiben Sie den Dienst mit dem folgenden Befehl:

   kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
   

   Ersetzen Sie Folgendes:

   • SERVICE_NAME: der Name des vorhandenen externen LoadBalancer-Dienstes.

   • SERVICE_NAMESPACE: der Namespace des vorhandenen externen LoadBalancer-Dienstes.

   Notieren Sie sich in der Befehlsausgabe die externe IPv4-Adresse des Load Balancers, die nach LoadBalancer Ingress aufgeführt ist.

3. Rufen Sie das Dienstmanifest für den vorhandenen LoadBalancer-Dienst ab:

   • Am besten ist es, wenn Sie das ursprüngliche Dienstmanifest haben, das Sie in der Vergangenheit auf den Cluster angewendet haben. Sie können diese beispielsweise in einem Quellcode-Repository speichern.

   • Wenn Sie das ursprüngliche Dienstmanifest nicht haben:

     • Führen Sie den folgenden Befehl aus, um eine YAML-Kopie des Dienstmanifests abzurufen, das die aktuelle Implementierung des Load Balancers darstellt:

       kubectl get svc SERVICE_NAME -n SERVICE_NAMESPACE -o yaml
       

     • Kopieren Sie das YAML-Manifest in einen Texteditor. Entfernen Sie das Attribut status und die folgenden metadata-Attribute:

       • Alle folgenden Annotationen:
         • Die Annotation kubectl.kubernetes.io/last-applied-configuration
         • Alle Annotationen, die mit service.kubernetes.io beginnen
       • creationTimestamp
       • finalizers
       • resourceVersion
       • uid

   • Achten Sie darauf, dass das Manifest das Feld spec.loadBalancerClass mit dem Wert networking.gke.io/l4-regional-external enthält. Wenn Sie von einem zielpoolbasierten regionalen externen Passthrough-Network-Load-Balancer migrieren, muss das Feld hinzugefügt werden.

   Speichern Sie die Manifestdatei und notieren Sie sich den Speicherort. Im weiteren Verlauf dieses Verfahrens wird der Pfad, unter dem Sie das Manifest gespeichert haben, als MANIFEST_FILE_PATH bezeichnet.

4. Konfigurieren Sie eine statische externe IPv4-Adressressource, die die vom vorhandenen Load Balancer verwendete externe IPv4-Adresse enthält:

   gcloud compute addresses create IP_ADDRESS_NAME --region=CLUSTER_REGION --addresses LB_EXTERNAL_IP
   

   Ersetzen Sie Folgendes:

   • IP_ADDRESS_NAME: der Name der statischen externen IP-Adresse. Der Name muss den Namenskonventionen für Compute Engine-Ressourcen entsprechen.

   • CLUSTER_REGION: Die Region, die den Cluster enthält. Bei zonalen Clustern ist dies die Region, die die Zone des Clusters enthält.

   • LB_EXTERNAL_IP: die externe IPv4-Adresse, die vom aktuellen Load Balancer verwendet wird, wie im zweiten Schritt dieses Verfahrens ermittelt.

5. Prüfen Sie, ob die statische externe IPv4-Adressressource erstellt wurde:

   gcloud compute addresses describe IP_ADDRESS_NAME --region=CLUSTER_REGION
   

   Ersetzen Sie die Variablen wie im vorherigen Schritt angegeben.

6. Löschen Sie den vorhandenen Dienst:

   kubectl delete svc SERVICE_NAME -n SERVICE_NAMESPACE
   

7. Fügen Sie der Manifestdatei des Dienstes MANIFEST_FILE_PATH die folgende Annotation hinzu:

   networking.gke.io/load-balancer-ip-addresses: IP_ADDRESS_NAME
   

   Weitere Informationen zu dieser Annotation finden Sie unter Statische IP-Adressen in den Parametern des LoadBalancer-Dienstes.

8. Wenden Sie das aktualisierte Dienstmanifest auf den Cluster an:

   kubectl apply -f MANIFEST_FILE_PATH
   

9. (Optional) Geben Sie die statische IPv4-Adressressource frei.

   gcloud compute addresses delete IP_ADDRESS_NAME --region=CLUSTER_REGION
   

Fehlerbehebung

In diesem Abschnitt werden Probleme beschrieben, die bei der Konfiguration eines Backend-Dienst-basierten externen LoadBalancer-Dienstes auftreten können.

Falsche Richtlinie für externen Traffic für gewichtetes Load Balancing

Wenn Sie den Wert externalTrafficPolicy: Local beim Aktivieren des gewichteten Load-Balancings nicht festlegen, erhalten Sie möglicherweise ein Warnereignis, wenn Sie den Dienst mit dem folgenden Befehl beschreiben:

kubectl describe svc store-v1-lb-svc`

Events:
  Type     Reason                   Age      From                     Message
  ----     ------                   ----     ----                     -------
  Warning  UnsupportedConfiguration 4m55s    loadbalancer-controller  Weighted load balancing by pods-per-node has no effect with External Traffic Policy: Cluster.

Damit das gewichtete Load Balancing effektiv aktiviert werden kann, müssen Sie den Wert externalTrafficPolicy: Local festlegen.

Fehler beim Erstellen eines IPv6-Load-Balancers in der Standardstufe

Wenn ein externer IPv6-LoadBalancer-Dienst ein SyncExternalLoadBalancerFailed-Ereignis mit der Meldung Network tier Standard is not supported for IPv6 External Load Balancer anzeigt, entfernen Sie die Annotation cloud.google.com/network-tier: Standard aus dem Dienstmanifest. Externe IPv6-LoadBalancer-Dienste werden nur in der Premium-Stufe unterstützt.

Fehler beim Konfigurieren von BYOIPv6-Adressen (Bring your own IPv6)

Wenn Sie Bring your own IPv6 (BYOIPv6) für einen externen LoadBalancer-Dienst konfigurieren, werden möglicherweise SyncExternalLoadBalancerFailed-Warnereignisse angezeigt, wenn Sie den Befehl kubectl describe service SERVICE_NAME ausführen. Die Ereignisnachricht beginnt mit Error ensuring Resource for L4 External LoadBalancer, err:, gefolgt von einem der folgenden Fehler:

• networking.gke.io/ip-collection-v6 is currently only supported for IPv6-only Services: Achten Sie darauf, dass in Ihrem Dienstmanifest spec.ipFamilyPolicy: SingleStack und spec.ipFamilies: ["IPv6"] angegeben sind.
• static IPv6 address "ADDRESS_NAME" is a BYOIP address from IP collection "SUB_PREFIX", which is currently only supported for IPv6-only Services: Achten Sie darauf, dass in Ihrem Dienstmanifest spec.ipFamilyPolicy: SingleStack und spec.ipFamilies: ["IPv6"] angegeben sind. Dieser Fehler weist darauf hin, dass der Dienst Dual-Stack oder IPv4 ist, aber auf eine statische BYOIPv6-Adresse verweist.
• cannot specify both networking.gke.io/load-balancer-subnet ("SUBNET") and networking.gke.io/ip-collection-v6 ("SUB_PREFIX") for LoadBalancer: Entfernen Sie die Annotation networking.gke.io/load-balancer-subnet aus dem Dienstmanifest, wenn Sie die Annotation networking.gke.io/ip-collection-v6 verwenden.
• invalid networking.gke.io/ip-collection-v6 "VALUE": expected projects/PROJECT/regions/REGION/publicDelegatedPrefixes/NAME oder invalid networking.gke.io/ip-collection-v6 "VALUE": the public delegated prefix must be in the cluster region REGION: Legen Sie die Annotation auf die vollständige Ressourcen-URL oder den partiellen Ressourcenpfad (projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME) eines Subpräfixes in derselben Region wie Ihr Cluster fest. Ein reiner Subpräfixname wird nicht akzeptiert.
• reserved address ("ADDRESS_NAME") is not valid, err: ipCollection mismatch, expected "SUB_PREFIX_A", actual: "SUB_PREFIX_B": Achten Sie darauf, dass die Annotation networking.gke.io/ip-collection-v6 mit dem öffentlich delegierten Präfix übereinstimmt, das Sie zum Reservieren der statischen IPv6-Adresse verwendet haben, oder lassen Sie die Annotation networking.gke.io/ip-collection-v6 weg, wenn Sie die Annotation networking.gke.io/load-balancer-ip-addresses verwenden.
• googleapi: Error 403: Required 'compute.publicDelegatedPrefixes.use' permission for 'SUB_PREFIX', forbidden: Gewährt dem GKE-Dienst-Agent (service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com) im Projekt, das das öffentliche delegierte Präfix besitzt, die Rolle „Compute Public IP Admin“ (roles/compute.publicIpAdmin). GKE benötigt diese Berechtigung jedes Mal, wenn der Dienst synchronisiert wird. Entfernen Sie die Rolle also nicht, nachdem GKE den Dienst erstellt hat.

Nächste Schritte

• Eine allgemeine Übersicht über Load-Balancer-Dienste finden Sie unter LoadBalancer-Dienste.
• Eine Beschreibung der Parameter für den Load-Balancer-Dienst finden Sie unter Parameter des LoadBalancer-Dienstes.
• Fehlerbehebung beim Load-Balancing in GKE.