Bilanciamento del carico avanzato sui cluster GKE

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

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

Puoi utilizzare il bilanciamento del carico avanzato per:

• Mantieni il traffico in una zona di servizio fino a quando la capacità locale non è esaurita.
• Invia il traffico al servizio in una posizione "principale" con failover a una posizione secondaria quando un numero sufficiente di endpoint nella posizione principale diventa non operativo.
• Controlla quando si verifica il failover (in base alla percentuale di host integri).

Limitazioni

• Si applicano limitazioni generali all'utilizzo del bilanciamento del carico avanzato su Google Cloud .
• Questa funzionalità è disponibile solo per gli utenti di Cloud Service Mesh gestito che utilizzano Traffic Director come piano di controllo e richiede la versione del piano di dati 1.19.10-asm.22 o successiva.
• Non tutti i campi in GCPTrafficDistributionPolicy e GCPBackendPolicy sono supportati per managedCloud Service Mesh (TD). I campi supportati sono:
  • GCPTrafficDistributionPolicy
    • ServiceLbAlgorithm
    • AutoCapacityDrain
    • FailoverConfig
  • GCPBackendPolicy
    • MaxRatePerEndpoint
    • BackendPreference
• Il bilanciamento del carico avanzato può essere applicato solo ai servizi Kubernetes supportati da carichi di lavoro in esecuzione su Google Cloud. I servizi o i carichi di lavoro esterni (come ServiceEntry) non sono supportati.
• I criteri di bilanciamento del carico possono essere applicati solo ai singoli servizi Kubernetes. I criteri di bilanciamento del carico a livello di spazio dei nomi/a livello di mesh non sono supportati.
• È supportata solo la capacità QPS.
• Sono supportate solo le versioni GKE >= 1.31.1.
• Le policy di bilanciamento del carico avanzate del mesh di servizi devono essere applicate solo ai servizi che servono solo il traffico del 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 repo gke-gateway-api.

GCPTrafficDistributionPolicy

GCPTrafficDistributionPolicy configura il criterio di bilanciamento del carico a livello di servizio per i servizi Kubernetes. Consente di:

• Scegli un algoritmo di bilanciamento del carico personalizzato. Gli algoritmi supportati sono descritti nella tabella del bilanciamento del carico avanzato.
• Attiva lo scaricamento automatico della capacità.
• Modifica la soglia di integrità failover.

Se più criteri GCPTrafficDistributionPolicy hanno come target lo stesso servizio, verrà applicato il criterio più antico.

GCPBackendPolicy

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

• Capacità del backend del servizio.
• Designare i backend preferiti.

Se più criteri GCPBackendPolicy hanno come target lo stesso servizio in un cluster, verrà applicato il criterio più antico.

Stato del criterio

Sia GCPTrafficDistributionPolicy che GCPBackendPolicy hanno un campo stato che indica lo stato di attacco del criterio.

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

...
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 eseguire il provisioning di Cloud Service Mesh su un cluster GKE.

1. Verifica 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 risorsa personalizzata 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 la risorsa personalizzata GCPTrafficDistributionPolicy se non è già installata:

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

I criteri di esempio in questa guida dell'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 singolo backend del servizio in un'architettura a mesh di servizi Cloud Service Mesh. Puoi creare il seguente criterio GCPTrafficDistributionPolicy in modo che il traffico venga distribuito nella 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

Nota: le impostazioni in GCPTrafficDistributionPolicy hanno la precedenza su quelle nell'API di servizio Kubernetes di base.

Per impostazione predefinita, i backend dei servizi vengono trattati come se avessero una capacità infinita. Se esistono host funzionanti sufficienti nella zona locale/più vicina, il traffico non verrà mai distribuito al di fuori di questa zona per una determinata località del client. Se vuoi, puoi configurare 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 se una percentuale sufficiente di host è integra nei backend principali. Per ulteriori informazioni sui backend principali e su altra terminologia, consulta la panoramica del bilanciamento del carico avanzato. GCPTrafficDistributionPolicy ti consente di configurare la percentuale di host integri soglia fino a quando il traffico non viene spostato dai backend principali ai backend di failover. Il failover viene attivato prima con una soglia più alta. Ad esempio, se vuoi che il failover venga attivato non appena la percentuale di host integri scende al di sotto del 90% nei backend principali, puoi configurare il seguente criterio di distribuzione del traffico Google Cloud:

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

GCPTrafficDistributionPolicy e GCPBackendPolicy vengono applicati a diversi ambiti in un mesh di servizi multi-cluster.

Quando un criterio di distribuzione del traffico Google Cloud ha come target un servizio multi-cluster, definisce il comportamento del bilanciamento del carico a livello di servizio in tutti i cluster. Per un determinato servizio multi-cluster è necessario creare un solo criterio di distribuzione del traffico Google Cloud. Se utilizzi l'API Istio per configurare il tuo mesh di servizi, puoi creare GCPTrafficDistributionPolicy in qualsiasi cluster del parco risorse. Puoi controllare se una norma è in conflitto con un'altra esaminando il relativo stato.

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

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

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

• Il traffico da qualsiasi luogo preferisce i backend nel cluster A finché i pod di backend nel cluster A non devono gestire 10 qps 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 indirizzato al cluster B utilizzando l'algoritmo WATERFALL_BY_ZONE. Per una spiegazione più dettagliata dei backend preferiti, consulta la 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, sia nel cluster A che nel cluster B.

Nota: questa sezione mostra la capacità di Cloud Service Mesh di bilanciare il carico del traffico su più cluster. A scopo dimostrativo, esegui il deployment del servizio di esempio foo e dei relativi pod di backend in entrambi i cluster.

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

1. Crea il criterio 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 il criterio 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 il criterio 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

• Scopri di più sul bilanciamento del carico avanzato