Bilanciamento del carico avanzato sui cluster GKE

Questa pagina mostra come configurare il bilanciamento del carico avanzato sui cluster GKE per gli utenti di Cloud Service Mesh (TD) gestito utilizzando l'API Kubernetes. Per la guida utente corrispondente per configurare il bilanciamento del carico avanzato utilizzando l'APIGoogle Cloud , consulta Configurare il bilanciamento del carico avanzato.

Puoi utilizzare il bilanciamento del carico avanzato per:

  • Mantieni il traffico in una zona di servizio finché la capacità locale non è esaurita.
  • Invia il traffico al servizio in una località "principale" con failover a una località secondaria quando un numero sufficiente di endpoint nella località principale non è più integro.
  • Controlla quando avviene il failover (in base alla percentuale di host integri).

Limitazioni

  • Limitazioni generali relative all'utilizzo del bilanciamento del carico avanzato su Google Cloud apply.
  • Questa funzionalità è disponibile solo per gli utenti di Cloud Service Mesh gestito che utilizzano Traffic Director come control plane e richiede la versione del data plane 1.19.10-asm.22 o successive.
  • Non tutti i campi di GCPTrafficDistributionPolicy e GCPBackendPolicy sono supportati per managedCloud Service Mesh (TD). I campi supportati sono i seguenti:

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

    Tutti i campi non elencati non sono supportati e una policy con almeno un campo non supportato configurato non ha effetto in Cloud Service Mesh .

  • Il bilanciamento del carico avanzato può essere applicato solo ai servizi Kubernetes supportati da carichi di lavoro in esecuzione su Google Cloud. Non sono supportati servizi o workload esterni (ad esempio ServiceEntry).

  • I criteri di bilanciamento del carico possono essere applicati solo ai singoli servizi Kubernetes. Le policy di bilanciamento del carico a livello di spazio dei nomi/mesh non sono supportate.

  • È supportata solo la capacità QPS.

  • Sono supportate solo le versioni di GKE >= 1.31.1.

  • Le policy di bilanciamento del carico avanzato del service mesh devono essere applicate solo ai servizi che gestiscono solo il traffico mesh. Non deve essere applicato ai servizi che fungono da backend di GKE Gateway. I comportamenti del traffico non sono definiti quando un bilanciamento del carico avanzato ha come target un servizio Kubernetes che gestisce sia il traffico mesh sia il traffico proveniente da un gateway GKE.

Configura il bilanciamento del carico avanzato

Puoi utilizzare le seguenti risorse personalizzate per configurare il bilanciamento del carico avanzato su GKE. Puoi trovare la definizione dettagliata della risorsa nel repository gke-gateway-api.

GCPTrafficDistributionPolicy

GCPTrafficDistributionPolicy configura la policy di bilanciamento del carico a livello di servizio per i servizi Kubernetes. Ti consente di:

Se più GCPTrafficDistributionPolicies hanno come target lo stesso servizio, verrà applicato il criterio meno recente.

GCPBackendPolicy

GCPBackendPolicy configura le proprietà dei backend di servizio che influiscono sul comportamento del bilanciamento del carico, tra cui:

Se più GCPBackendPolicy hanno come target lo stesso servizio in un cluster, verrà applicata la policy più vecchia.

Stato del criterio

Sia GCPTrafficDistributionPolicy che GCPBackendPolicy hanno un campo di stato che indica lo stato di collegamento della policy.

Ad esempio, l'esecuzione di kubectl describe gcpbackendpolicies example-policy -n example produrrà un output simile a:

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

Configurazione preliminare

Prima di poter completare questa guida, devi provisionare Cloud Service Mesh su un cluster GKE.

  1. Controlla che i CRD siano installati:

    kubectl get crd
    

    L'output è simile al seguente:

    ...
    gcptrafficdistributionpolicies.networking.gke.io   2024-07-18T21:50:12Z
    gcpbackendpolicies.networking.gke.io               2024-07-18T21:50:12Z
    ...
    
  2. Installa la CRD GCPBackendPolicy se non è già installata:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcpbackendpolicies.yaml
    
  3. Installa il CRD GCPTrafficDistributionPolicy se non è già installato:

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

Le norme di esempio in questa guida per l'utente hanno come target il servizio foo nello spazio dei nomi foo a scopo dimostrativo. Puoi eseguire il seguente comando per creare il servizio e lo spazio dei nomi di test oppure, se preferisci, puoi utilizzare il tuo servizio e il tuo spazio dei nomi:

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

Configurazione dell'algoritmo di bilanciamento del carico

Per impostazione predefinita, il traffico verso un servizio viene distribuito uniformemente a ogni backend del servizio integro in un mesh di servizi Cloud Service Mesh. Puoi creare il seguente GCPTrafficDistributionPolicy in modo che il traffico venga distribuito alla zona più vicina fino alla capacità del backend:

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

Per impostazione predefinita, i backend di servizio vengono trattati come se avessero una capacità infinita. Quando ci sono host integri sufficienti nella zona locale/più vicina, il traffico non verrà mai distribuito al di fuori della zona locale/più vicina per una determinata località client. Puoi configurare facoltativamente la capacità del backend del servizio utilizzando GCPBackendPolicy in modo che una singola zona non venga sovraccaricata.

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

Ottimizzazione del comportamento di failover

Per impostazione predefinita, il failover non viene attivato finché una percentuale sufficiente di host è integra nei backend primari. Per saperne di più sui backend principali e su altri termini, consulta la panoramica del bilanciamento del carico avanzato. GCPTrafficDistributionPolicy ti consente di configurare la soglia della percentuale di host integri fino a quando il traffico non viene spostato dai backend primari ai backend di failover. Il failover viene attivato prima con una soglia più ampia. Ad esempio, se vuoi che il failover venga attivato non appena la percentuale di host integri scende al di sotto del 90% nei backend primari, puoi configurare il seguente GCPTrafficDistributionPolicy:

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

Configurazione del bilanciamento del carico avanzato in un mesh di servizi multicluster

GCPTrafficDistributionPolicy e GCPBackendPolicy vengono applicati a ambiti diversi in un mesh di servizi multicluster.

Quando un oggetto GCPTrafficDistributionPolicy ha come target un servizio multi-cluster, definisce il comportamento di bilanciamento del carico a livello di servizio in tutti i cluster. Per un determinato servizio multi-cluster deve essere creata una sola GCPTrafficDistributionPolicy. Se utilizzi l'API Istio per configurare il mesh di servizi, puoi creare GCPTrafficDistributionPolicy in qualsiasi cluster del parco progetti. Puoi verificare se una norma è in conflitto con un'altra esaminando il relativo stato della norma.

Quando un GCPBackendPolicy ha come target un servizio multicluster, definisce le impostazioni a livello di backend (ad esempio, la capacità per pod) per i pod di backend selezionati dal servizio di targeting nel cluster locale. Per lo stesso servizio multi-cluster, è possibile definire impostazioni diverse a livello di backend in cluster diversi.

Nell'esempio seguente, in cluster A viene creato un GCPTrafficDistributionPolicy per definire l'algoritmo di bilanciamento del carico da utilizzare nel parco risorse, mentre GCPBackendPolicies si trova in ogni cluster. GCPBackendPolicy configura una capacità di 10 qps per pod per i pod di backend nel cluster locale, mentre GCPBackendPolicy nel cluster A configura i pod di backend nel cluster A come backend preferito.

Insieme, queste policy configurano i comportamenti di bilanciamento del carico per il traffico in-mesh inviato al servizio foo:

  • Il traffico proveniente da qualsiasi posizione preferisce i backend nel cluster A finché i pod di backend nel cluster A non devono gestire 10 query al secondo per pod.
    • Questo comportamento è definito principalmente da GCPBackendPolicy che imposta backendPreference su PREFERRED nel cluster A.
  • Il traffico che supera la capacità configurata dei backend nel cluster A viene instradato utilizzando l'algoritmo WATERFALL_BY_ZONE al cluster B. Per una spiegazione più dettagliata dei backend preferiti, consulta Panoramica del bilanciamento del carico avanzato.
    • Questo comportamento è definito principalmente da GCPTrafficDistributionPolicy, che definisce l'algoritmo nel cluster A e da GCPBackendPolicy, che definisce la capacità del backend nei cluster A e B.

Mesh di servizi multi-cluster con bilanciamento del carico avanzato

In Istio, i normali servizi Kubernetes diventano implicitamente "multi-cluster" quando nel mesh di servizi sono presenti più cluster e il servizio viene creato oltre i confini del cluster. Sebbene il seguente GCPTrafficDistributionPolicy abbia come target il normale servizio Kubernetes foo, si applica al servizio multi-cluster foo costituito da workload corrispondenti in due cluster.

  1. Crea GCPTrafficDistributionPolicy per il 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. Crea GCPBackendPolicy per il 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. Crea GCPBackendPolicy per il 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
    

Passaggi successivi