Erweitertes Load-Balancing in GKE-Clustern

Auf dieser Seite wird beschrieben, wie Sie das erweiterte Load-Balancing für GKE-Cluster für Nutzer von verwaltetem Cloud Service Mesh (TD) mit der Kubernetes API konfigurieren. Die entsprechende Anleitung zum Konfigurieren des erweiterten Load Balancings mit derGoogle Cloud API finden Sie unter Erweitertes Load Balancing einrichten.

Mit dem erweiterten Load-Balancing können Sie:

  • Leiten Sie den Traffic für einen Dienst zonal weiter, bis die lokale Kapazität erschöpft ist.
  • Traffic an den Dienst an einem „primären“ Standort senden und bei Ausfall von genügend Endpunkten am primären Standort ein Failover an einen sekundären Standort durchführen.
  • Steuern, wann ein Failover erfolgt (basierend auf dem Prozentsatz der fehlerfreien Hosts).

Beschränkungen

  • Allgemeine Einschränkungen für die Verwendung von erweitertem Load-Balancing auf Google Cloud .
  • Diese Funktion ist nur für Nutzer von verwaltetem Cloud Service Mesh verfügbar, die Traffic Director als Steuerungsebene verwenden, und erfordert die Datenebenenversion 1.19.10-asm.22 oder höher.

  • Nicht alle Felder in GCPTrafficDistributionPolicy und GCPBackendPolicy werden für Managed Cloud Service Mesh (TD) unterstützt. Folgende Felder werden unterstützt:

    • GCPTrafficDistributionPolicy
      • ServiceLbAlgorithm
      • AutoCapacityDrain
      • FailoverConfig
    • GCPBackendPolicy
      • MaxRatePerEndpoint
      • BackendPreference

    Alle nicht aufgeführten Felder sind nicht unterstützte Felder. Eine Richtlinie, in der mindestens ein nicht unterstütztes Feld konfiguriert ist, wird in Cloud Service Mesh nicht angewendet.

  • Erweitertes Load Balancing kann nur auf Kubernetes-Dienste angewendet werden, die von Arbeitslasten unterstützt werden, die auf Google Cloudausgeführt werden. Externe Dienste oder Arbeitslasten (z. B. ServiceEntry) werden nicht unterstützt.

  • Die Load-Balancing-Richtlinien können nur auf einzelne Kubernetes-Dienste angewendet werden. Namespace- oder Mesh-weite Load-Balancing-Richtlinien werden nicht unterstützt.

  • Es wird nur die QPS-Kapazität unterstützt.

  • Es werden nur GKE-Versionen >= 1.31.1 unterstützt.

  • Erweiterte Load-Balancing-Richtlinien für Service Mesh dürfen nur auf Dienste angewendet werden, die nur Mesh-Traffic verarbeiten. Sie darf nicht auf Dienste angewendet werden, die als GKE Gateway-Back-Ends dienen. Das Trafficverhalten ist nicht definiert, wenn ein Kubernetes-Dienst, der sowohl Mesh-Traffic als auch Traffic von einem GKE-Gateway verarbeitet, ein erweitertes Load-Balancing-Trafficziel ist.

Erweitertes Load-Balancing konfigurieren

Sie können die folgenden benutzerdefinierten Ressourcen verwenden, um das erweiterte Load-Balancing in GKE zu konfigurieren. Die detaillierte Ressourcendefinition finden Sie im gke-gateway-api-Repository.

GCPTrafficDistributionPolicy

Mit GCPTrafficDistributionPolicy wird die Load-Balancing-Richtlinie auf Dienstebene für Kubernetes-Dienste konfiguriert. Sie können beispielsweise:

Wenn mehrere GCPTrafficDistributionPolicies auf denselben Dienst ausgerichtet sind, wird die älteste Richtlinie erzwungen.

GCPBackendPolicy

Mit GCPBackendPolicy werden die Eigenschaften von Dienst-Backends konfiguriert, die sich auf das Load-Balancing-Verhalten auswirken. Dazu gehören:

Wenn mehrere GCPBackendPolicys auf denselben Dienst in einem Cluster ausgerichtet sind, wird die älteste Richtlinie erzwungen.

Richtlinienstatus

Sowohl GCPTrafficDistributionPolicy als auch GCPBackendPolicy haben ein Statusfeld, das den Anhangstatus der Richtlinie angibt.

Wenn Sie beispielsweise kubectl describe gcpbackendpolicies example-policy -n example ausführen, erhalten Sie eine Ausgabe wie diese:

...
Status:
  Ancestors:
    Ancestor Ref:
      Group:
      Kind:       Service
      Name:       example-svc
      Namespace:  example
    Conditions:
      Last Transition Time:  2024-10-13T01:15:03Z
      Message:
      Observed Generation:   1
      Reason:                Attached
      Status:                True
      Type:                  Attached
    Controller Name:         gsmconfig.gke.io/controller

Vorläufige Einrichtung

Bevor Sie diese Anleitung durcharbeiten können, müssen Sie Cloud Service Mesh in einem GKE-Cluster bereitstellen.

  1. Prüfen Sie, ob die CRDs installiert sind:

    kubectl get crd

    Die Ausgabe sieht etwa so aus:

    ...
gcptrafficdistributionpolicies.networking.gke.io   2024-07-18T21:50:12Z
gcpbackendpolicies.networking.gke.io               2024-07-18T21:50:12Z
...

  2. Installieren Sie die GCPBackendPolicy-CRD, falls noch nicht geschehen:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcpbackendpolicies.yaml

  3. Installieren Sie die GCPTrafficDistributionPolicy-CRD, falls noch nicht geschehen:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcptrafficdistributionpolicies.yaml

Die Beispielrichtlinien in diesem Nutzerhandbuch beziehen sich zu Demonstrationszwecken auf den Dienst „foo“ im Namespace „foo“. Sie können den folgenden Befehl ausführen, um den Testdienst und den Namespace zu erstellen. Alternativ können Sie auch Ihren eigenen Dienst und Namespace verwenden:

kubectl apply -f - <<EOF
kind: Namespace
apiVersion: v1
metadata:
  name: foo
  labels:
    istio-injection: enabled
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: foo
  namespace: foo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test-backend
  template:
    metadata:
      labels:
        app: test-backend
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.23
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: foo
  namespace: foo
spec:
  selector:
    app: test-backend
  ports:
  - port: 8080
    targetPort: 8080
EOF

Load-Balancing-Algorithmus konfigurieren

Standardmäßig wird der Traffic zu einem Dienst gleichmäßig auf alle fehlerfreien Dienst-Back-Ends in einem Cloud Service Mesh-Service Mesh verteilt. Sie können die folgende GCPTrafficDistributionPolicy erstellen, damit der Traffic bis zur Backend-Kapazität auf die nächstgelegene Zone verteilt wird:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: lb-policy
  namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
    serviceLbAlgorithm: WATERFALL_BY_ZONE
EOF

Standardmäßig werden Dienst-Backends so behandelt, als hätten sie unbegrenzte Kapazität. Wenn in der lokalen/nächstgelegenen Zone genügend fehlerfreie Hosts vorhanden sind, wird der Traffic für einen bestimmten Clientstandort niemals außerhalb der lokalen/nächstgelegenen Zone verteilt. Optional können Sie die Kapazität Ihres Dienst-Back-Ends mit GCPBackendPolicy konfigurieren, damit eine einzelne Zone nicht überlastet wird.

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
  namespace: foo
spec:
  targetRef:
    kind: Service
    group: ""
    name: foo-backend
  default:
    maxRatePerEndpoint: 5
EOF

Failover-Verhalten anpassen

Standardmäßig wird kein Failover ausgelöst, solange ein ausreichender Prozentsatz der Hosts in den primären Back-Ends fehlerfrei ist. Weitere Informationen zu primären Backends und anderer Terminologie finden Sie in der Übersicht über das erweiterte Load-Balancing. Mit GCPTrafficDistributionPolicy können Sie den Prozentsatzschwellenwert für fehlerfreie Hosts konfigurieren, bis der Traffic von primären Back-Ends zu Failover-Back-Ends verschoben wird. Bei einem größeren Schwellenwert wird das Failover früher ausgelöst. Wenn Sie beispielsweise möchten, dass ein Failover ausgelöst wird, sobald der Prozentsatz der fehlerfreien Hosts in den primären Back-Ends unter 90% sinkt, können Sie die folgende GCPTrafficDistributionPolicy konfigurieren:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: lb-policy
  namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
   failoverConfig:
     failoverHealthThreshold: 90
EOF

Erweitertes Load Balancing in einem Multi-Cluster-Service Mesh konfigurieren

GCPTrafficDistributionPolicy und GCPBackendPolicy werden in einem Multi-Cluster-Service Mesh auf unterschiedliche Bereiche angewendet.

Wenn eine GCPTrafficDistributionPolicy auf einen Multi-Cluster-Service ausgerichtet ist, wird das Load-Balancing-Verhalten auf Service-Ebene für alle Cluster definiert. Für einen bestimmten Multi-Cluster-Dienst muss nur eine GCPTrafficDistributionPolicy erstellt werden. Wenn Sie die Istio API zum Konfigurieren Ihres Service Mesh verwenden, können Sie GCPTrafficDistributionPolicy in einem beliebigen Cluster in der Flotte erstellen. Sie können den Richtlinienstatus einer Richtlinie prüfen, um festzustellen, ob sie mit einer anderen Richtlinie in Konflikt steht.

Wenn eine GCPBackendPolicy auf einen Multi-Cluster-Dienst ausgerichtet ist, werden Einstellungen auf Back-End-Ebene (z. B. Kapazität pro Pod) für die Back-End-Pods definiert, die vom Targeting-Dienst im lokalen Cluster ausgewählt werden. Für denselben Multi-Cluster-Dienst können in verschiedenen Clustern unterschiedliche Einstellungen auf Back-End-Ebene definiert werden.

Im folgenden Beispiel wird in Cluster A eine GCPTrafficDistributionPolicy erstellt, um den Load-Balancing-Algorithmus zu definieren, der in der gesamten Flotte verwendet werden soll. GCPBackendPolicies sind in jedem Cluster vorhanden. Mit beiden GCPBackendPolicy-Konfigurationen wird eine Kapazität von 10 QPS pro Pod für die Backend-Pods in ihrem lokalen Cluster konfiguriert, während mit der GCPBackendPolicy in Cluster A die Backend-Pods in Cluster A als bevorzugtes Backend konfiguriert werden.

Zusammen konfigurieren diese Richtlinien das Load-Balancing-Verhalten für In-Mesh-Traffic, der an den Dienst „foo“ gesendet wird:

  • Traffic von überall wird bevorzugt an Back-Ends in Cluster A gesendet, bis Back-End-Pods in Cluster A 10 Anfragen pro Sekunde pro Pod verarbeiten müssen.
    • Dieses Verhalten wird hauptsächlich durch die GCPBackendPolicy definiert, in der backendPreference in Cluster A auf PREFERRED festgelegt ist.
  • Traffic, der die konfigurierte Kapazität der Back-Ends in Cluster A überschreitet, wird mit dem Algorithmus WATERFALL_BY_ZONE an Cluster B weitergeleitet. Eine detailliertere Beschreibung der bevorzugten Backends finden Sie unter Erweitertes Load-Balancing – Übersicht.
    • Dieses Verhalten wird hauptsächlich durch die GCPTrafficDistributionPolicy definiert, die den Algorithmus in Cluster A definiert, und durch die GCPBackendPolicy, die die Backend-Kapazität in Cluster A und B definiert.

Erweitertes Load-Balancing für Multi-Cluster-Service Mesh

In Istio werden reguläre Kubernetes-Dienste implizit zu „Multi-Cluster-Diensten“, wenn es mehrere Cluster im Service Mesh gibt und der Dienst clusterübergreifend erstellt wird. Die folgende GCPTrafficDistributionPolicy ist zwar auf den regulären Kubernetes-Service „foo“ ausgerichtet, gilt aber für den Multi-Cluster-Service „foo“, der aus entsprechenden Arbeitslasten in zwei Clustern besteht.

  1. Erstellen Sie die GCPTrafficDistributionPolicy für Cluster A:

    kubectl apply --context cluster-a-context -f - <<EOF
kind: GCPTrafficDistributionPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-traffic-distribution-policy
namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
    serviceLbAlgorithm: WATERFALL_BY_ZONE

EOF

  2. Erstellen Sie die GCPBackendPolicy für Cluster A:

    kubectl apply --context cluster-a-context -f - <<EOF
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-backend-policy
namespace: foo
spec:
  default:
    maxRatePerEndpoint: 100
    backendPreference: PREFERRED
  targetRef:
    group: ""
    kind: Service
    name: foo-service
EOF

  3. Erstellen Sie die GCPBackendPolicy für Cluster B:

    kubectl apply --context cluster-b-context -f - <<EOF
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
name: foo-backend-policy
namespace: foo
spec:
  default:
    maxRatePerEndpoint: 10
  targetRef:
    group: ""
    kind: Service
    name: foo-service
EOF

Weitere Informationen