Backend-Dienst-basierten externen Load-Balancer bereitstellen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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

• LoadBalancer-Dienste
• GKE-LoadBalancer-Dienstparameter

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

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

Voraussetzungen

• Das HttpLoadBalancing-Add-on muss in Ihrem Cluster aktiviert sein. Dieses Add-on ist standardmäßig aktiviert. Der Cluster kann dann Load-Balancer verwalten, die Backend-Dienste verwenden.

• Wenn Sie einen externen LoadBalancer-Dienst erstellen möchten, der einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer verwendet, muss in Ihrem GKE-Cluster Version 1.25.5 oder höher verwendet werden.

• Wenn Sie einen externen LoadBalancer-Dienst mit gewichtetem Load Balancing erstellen möchten, muss in Ihrem GKE-Cluster die Version 1.31.0-gke.1506000 oder höher verwendet werden.

• Wenn Sie einen externen LoadBalancer-Dienst erstellen möchten, der GCE_VM_IP-NEG-Backends (Network Endpoint Group) verwendet, muss Ihr GKE-Cluster die Version 1.32.2-gke.1652000 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 hinzu. Weitere Informationen finden Sie unter Nutzerverwaltete Firewallregeln für GKE-Load Balancer-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 hinzu. Weitere Informationen finden Sie unter Nutzerverwaltete Firewallregeln für GKE-Load Balancer-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 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 hinzu. Weitere Informationen finden Sie unter Nutzerverwaltete Firewallregeln für GKE-Load Balancer-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: gcr.io/google_containers/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. Stellen Sie die Beispielarbeitslast bereit, indem Sie einen externen LoadBalancer-Dienst erstellen.

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

      apiVersion: v1
      kind: Service
      metadata:
        name: store-v1-lb-svc
        annotations:
          cloud.google.com/l4-rbs: "enabled"
      spec:
        type: LoadBalancer
        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 Beispielmanifest:

   • Das Dienstmanifest muss die cloud.google.com/l4-rbs: "enabled"-Anmerkung enthalten, wenn das Manifest zum ersten Mal auf den Cluster angewendet wird. Dadurch wird GKE angewiesen, einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer zu erstellen. Backend-Dienst-basierte externe Passthrough-Network Load Balancer sind erforderlich, um Funktionen wie IPv6 und gewichtete Lastverteilung zu unterstützen.

   • GKE verwendet je nach Clusterversion entweder GCE_VM_IP-NEG-Back-Ends oder nicht verwaltete Instanzgruppen-Back-Ends. In Clustern mit Version 1.32.2-gke.1652000 verwendet der backend-dienstbasierte externe Passthrough-Network Load Balancer GCE_VM_IP-NEGs. In früheren Versionen wurden für den Backend-Dienst-basierten externen Passthrough-Network Load Balancer nicht verwaltete Instanzgruppen verwendet.

   • Wenn Sie die Annotation cloud.google.com/l4-rbs: "enabled" dem Manifest eines vorhandenen externen LoadBalancer-Dienstes hinzufügen, also nach dem Erstellen des Load Balancers, wird sie von GKE ignoriert. Externe LoadBalancer-Dienste, die ohne diese Anmerkung in ihren Manifesten erstellt wurden, verwenden zielpoolbasierte externe Passthrough-Network Load Balancer. Die Verwendung von zielpoolbasierten externen Passthrough-Network Load Balancern wird nicht empfohlen.

Gewichtetes Load Balancing aktivieren

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

1. Fügen Sie dem store-v1-lb-svc.yaml-Dienstmanifest die networking.gke.io/weighted-load-balancing: "pods-per-node"-Anmerkung hinzu und achten Sie darauf, dass auch die externalTrafficPolicy: Local so festgelegt ist:

   apiVersion: v1
   kind: Service
   metadata:
     name: store-v1-lb-svc
     annotations:
       cloud.google.com/l4-rbs: "enabled"
       networking.gke.io/weighted-load-balancing: "pods-per-node"
   spec:
     type: LoadBalancer
     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 das gewichtete Load Balancing:

• Im Service-Manifest wird externalTrafficPolicy: Local verwendet. 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 das gewichtete Load Balancing aktivieren, können Sie externalTrafficPolicy: Cluster in GKE verwenden. externalTrafficPolicy: Cluster deaktiviert jedoch effektiv das gewichtete Load Balancing, da das Paket nach dem Load Balancer an einen anderen Knoten weitergeleitet werden kann.

Sie können das gewichtete Load Balancing auch mit kubectl edit svc service-name für einen vorhandenen externen LoadBalancer-Dienst 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 Folgendes:

• Der vorhandene externe LoadBalancer-Dienst muss zur Erstellung eines Backend-Dienst-basierten externen Passthrough-Network Load Balancers geführt haben. Das bedeutet, dass der vorhandene externe LoadBalancer-Dienst die Annotation cloud.google.com/l4-rbs: "enabled" enthalten muss, wenn das Manifest zum ersten Mal auf den Cluster angewendet wurde.

  Wenn Sie die Annotation networking.gke.io/weighted-load-balancing: "pods-per-node" einem vorhandenen externen LoadBalancer-Dienst hinzufügen, der einen zielpoolbasierten externen Passthrough-Network Load Balancer verwendet, hat das keine Auswirkungen.

• Achten Sie beim Aktualisieren des vorhandenen Manifests für den externen LoadBalancer-Dienst darauf, externalTrafficPolicy: Local festzulegen. Wenn Sie externalTrafficPolicy: Cluster verwenden, wird das gewichtete Load Balancing effektiv deaktiviert, da das Paket nach dem Load Balancer an einen anderen Knoten weitergeleitet werden kann.

Gewichtetes Load Balancing deaktivieren

Wenn Sie neue Verbindungen unabhängig davon auf Knoten verteilen möchten, wie viele bereitstellende Pods auf jedem Knoten vorhanden sind, deaktivieren Sie das gewichtete Load Balancing, indem Sie die Anmerkung networking.gke.io/weighted-load-balancing: "pods-per-node" aus dem Dienstmanifest entfernen.

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 in 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 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 externen Passthrough-Network-Load-Balancer.
   • PORT: die zugewiesene Portnummer für den 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 seineGoogle Cloud -Ressourcen zu beschreiben:

   kubectl describe svc store-v1-lb-svc
   

   Die Ausgabe sieht etwa so aus:

   Name:                     my-service-external
   Namespace:                default
   Labels:                   <none>
   Annotations:              cloud.google.com/l4-rbs: enabled
                             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=my-app
   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 externer Passthrough-Network-Load-Balancer und seine Google Cloud 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 Anmerkungen hinzu. Jede Annotation, deren Name mit service.kubernetes.io/ beginnt, wird verwendet, um den Namen einerGoogle Cloud Ressource anzugeben, die als Teil oder zur Unterstützung des Load Balancers erstellt wurde.

     • Die Anmerkung 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 Pods, die auf jedem Knoten ausgeführt werden, auf 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 Anmerkung cloud.google.com/neg-status gibt sowohl die vom Load Balancer verwendeten NEGs als auch ihre Zonen an. Diese Anmerkung ist nur vorhanden, wenn die beiden 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, und
       • Die cloud.google.com/l4-rbs: "enabled"-Anmerkung 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 Anmerkungen zu prüfen.
     • REGION_NAME: die Google Cloud Region, in der sich der Cluster befindet. 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 Google Cloud Region, in der sich der Cluster befindet. 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. Führen Sie kubectl describe svc SERVICE_NAME aus, um diese schreibgeschützte Anmerkung zu prüfen.
     • REGION_NAME: die Google Cloud Region, in der sich der Cluster befindet. 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 Anmerkung 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. Um diese schreibgeschützte Anmerkung zu prüfen, führen Sie den Befehl kubectl describe svc SERVICE_NAME aus. Die Anmerkung enthält strukturierte Daten mit Informationen zu den NEG-Namen und ‑Zonen, die vom Load Balancer verwendet werden. Bei zonalen Clustern enthält diese Anmerkung Informationen zu einer NEG. Bei regionalen Clustern enthält diese Anmerkung Informationen zu einer NEG in jeder Zone, in der sich der Cluster befindet.
     • ZONE_NAME: die Google Cloud Zone, die die NEG enthält.

Externen LoadBalancer-Dienst löschen

Verwenden Sie den folgenden Befehl, um den Beispiel-externen LoadBalancer-Dienst 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 mit der cloud.google.com/l4-rbs: "enabled"-Anmerkung erstellen Backend-Dienst-basierte externe Passthrough-Network Load Balancer, die je nach GKE-Version des Clusters entweder GCE_VM_IP-NEG-Backends (Network Endpoint Group) oder Instanzgruppen-Backends verwenden:

• Wenn das Dienstmanifest auf einen Cluster angewendet wurde, auf dem GKE 1.32.2-gke.1652000 oder höher ausgeführt wird, verwendet der resultierende externe Passthrough-Network Load Balancer GCE_VM_IP-NEG-Backends (Network Endpoint Group).

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

Weitere Informationen finden Sie unter Knotengruppierung im Abschnitt zu LoadBalancer-Diensten.

Sie können einen neuen externen LoadBalancer-Dienst erstellen, der von einem Backend-Dienst-basierten 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 externer Passthrough-Network Load Balancer mit Instanzgruppen-Backends
• Zielpool-basierter externer Passthrough-Network Load Balancer

So wechseln Sie zu einem Backend-Dienst-basierten externen Passthrough-Network Load Balancer mit GCE_VM_IP-NEG-Backends:

1. Führen Sie gegebenenfalls ein Upgrade Ihres Clusters auf die GKE-Version 1.32.2-gke.1652000 oder höher aus.

2. Geben Sie den externen LoadBalancer-Dienst an, den Sie zu einem Backend-Dienst-basierten externen Passthrough-Network Load Balancer mit GCE_VM_IP-NEG-Backends wechseln 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 Load Balancer-Dienstes.

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

   Notieren Sie sich in der Befehlsausgabe die externe IPv4-Adresse, die vom vorhandenen Load Balancer in der Spalte EXTERNAL-IP verwendet wird.

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

   • Am besten haben Sie das ursprüngliche Dienstmanifest, das Sie in der Vergangenheit auf den Cluster angewendet haben. Sie können sie beispielsweise in einem Repository für die Versionskontrolle speichern.

   • Wenn Sie das ursprüngliche Dienstmanifest nicht haben:

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

       kubectl get svc SERVICE_NAME -n SERVICE_NAMESPACE -o yaml
       

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

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

   • Das Manifest muss die cloud.google.com/l4-rbs: "enabled"-Anmerkung enthalten. Wenn Sie von einem zielpoolbasierten externen Passthrough-Network Load Balancer migrieren, muss die Anmerkung hinzugefügt werden.

   Notieren Sie sich den lokalen Pfad, der die Datei „Service Manifest“ enthält. Im Rest dieses Verfahrens wird der Pfad als MANIFEST_FILE_PATH bezeichnet.

4. Konfigurieren Sie eine Ressource für eine statische externe IPv4-Adresse, 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. Sie wird im zweiten Schritt dieses Verfahrens ermittelt.

5. Prüfen Sie, ob die Ressource für die statische externe IPv4-Adresse 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 Dienstmanifestdatei MANIFEST_FILE_PATH die folgende Anmerkung hinzu:

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

   Weitere Informationen zu dieser Anmerkung 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 Ressource für die statische IPv4-Adresse frei.

   gcloud compute addresses delete IP_ADDRESS_NAME --region=CLUSTER_REGION
   

Fehlerbehebung

In diesem Abschnitt wird ein Problem beschrieben, das beim Konfigurieren des gewichteten Load Balancings auftreten kann.

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

Wenn Sie externalTrafficPolicy: Local nicht festlegen, wenn Sie das gewichtete Load Balancing aktivieren, 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.

Um das gewichtete Load Balancing effektiv zu aktivieren, müssen Sie externalTrafficPolicy: Local festlegen.

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.