Configurare la gestione del traffico per i bilanciatori del carico delle applicazioni esterni regionali

Questo documento mostra esempi di utilizzo della gestione del traffico per alcuni usi specifici d'uso diversi. Sono possibili molti altri casi d'uso.

Il documento contiene esempi per i seguenti bilanciatori del carico:

• Bilanciatore del carico delle applicazioni esterno regionale
• Bilanciatore del carico delle applicazioni interno regionale
• Bilanciatore del carico delle applicazioni interno tra regioni

Bilanciatore del carico delle applicazioni esterno regionale e bilanciatore del carico delle applicazioni interno regionale. Per la configurazione della gestione del traffico dei bilanciatori di carico regionali, la documentazione dell'API mappa URL regionale e dell' API servizio di backend regionale fornisce un elenco completo dei campi, incluse le semantiche relative a relazioni, restrizioni e cardinalità.

L'unico la differenza tra questi due bilanciatori del carico è lo schema di bilanciamento del carico, che segue:

• I bilanciatori del carico delle applicazioni esterni regionali utilizzano EXTERNAL_MANAGED.
• I bilanciatori del carico delle applicazioni interni regionali utilizzano INTERNAL_MANAGED.

Bilanciatore del carico delle applicazioni interno regionale e bilanciatore del carico delle applicazioni interno tra regioni. Per la configurazione della gestione del traffico:

• I bilanciatori del carico delle applicazioni interni regionali utilizzano API di mappa degli URL regionali e la documentazione relativa all'API del servizio di backend regionale fornisce un elenco completo dei campi, inclusa la semantica su relazioni, restrizioni e cardinalità.

• I bilanciatori del carico delle applicazioni interni tra regioni utilizzano l'API Global URL Map e la documentazione relativa all'API globale del servizio di backend fornisce un elenco completo dei campi, inclusa la semantica su relazioni, restrizioni e cardinalità.

Nota: per i bilanciatori del carico delle applicazioni interni tra regioni, puoi utilizzare gli esempi forniti in questo documento sostituendo regions/REGION/backendServices con global/backendServices.

Oltre alle funzioni avanzate per la creazione di percorsi descritte in questa pagina, alcuni I bilanciatori del carico delle applicazioni si integrano con Service Extensions inserire una logica personalizzata nel percorso dei dati di bilanciamento del carico configurazione dei callout di Service Extensions.

Configura la gestione del traffico

Nell'ambiente di configurazione scelto, configura la gestione del traffico utilizzando le configurazioni YAML. Una mappa di URL e un servizio di backend hanno ciascuno il proprio file YAML. A seconda della funzionalità che ti interessa, devi scrivere un file YAML della mappa URL, un file YAML del servizio di backend o entrambi.

Per assistenza nella scrittura di questi file YAML, puoi utilizzare gli esempi in questa pagina e la documentazione dell'API Cloud Load Balancing.

Per i bilanciatori del carico delle applicazioni interni regionali e i bilanciatori del carico delle applicazioni esterni regionali, API di mappa degli URL regionali e la documentazione relativa all'API del servizio di backend regionale fornisce un elenco completo dei campi, inclusa la semantica su relazioni, restrizioni e cardinalità.

Mappa il traffico a un singolo servizio

Invia tutto il traffico a un singolo servizio. Assicurati di sostituire i segnaposto.

    defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
        - matchRules:
            - prefixMatch: /PREFIX
          priority: 1
          routeAction:
            weightedBackendServices:
              - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
                weight: 100

Suddividi il traffico tra due servizi

Suddividi il traffico tra due o più servizi. Assicurati di sostituire segnaposto.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: regions/REGION/backendServices/BACKEND_SERVICE_2
           weight: 5

Configurare un reindirizzamento URL

L'esempio seguente restituisce un codice di risposta 3xx configurabile. Anche l'esempio imposta l'intestazione della risposta Location con l'URI appropriato, sostituendo l'host e il percorso come specificato nell'azione di reindirizzamento.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         urlRedirect:
           hostRedirect: "new-host-name.com" # Omit to keep the requested host
           pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
           prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
           redirectResponseCode: FOUND
           stripQuery: True

Mirroring del traffico

Oltre a inoltrare la richiesta al servizio di backend selezionato, puoi inviare una richiesta identica al servizio di backend mirror configurato in modalità fire and forget. Il bilanciatore del carico non attende una risposta dal a cui invia la richiesta sottoposta a mirroring. Il mirroring è utile per il test una nuova versione di un servizio di backend. Puoi anche utilizzarlo per eseguire il debug degli errori di produzione su una versione di debug del servizio di backend anziché sulla versione di produzione.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: 1
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: regions/REGION/backendServices/BACKEND_SERVICE_2

Tieni presenti le seguenti limitazioni quando utilizzi il mirroring del traffico:

• Il mirroring del traffico è supportato quando entrambi i servizi di backend sono stati gestiti gruppi di istanze, NEG a livello di zona o backend NEG ibridi. Non è supportato per NEG internet, NEG serverless e Private Service Connect di backend.
• Le richieste al servizio di backend con mirroring non generano log per Cloud Logging e Cloud Monitoring.

Riscrivere l'URL richiesto

Riscrivere la parte del nome host dell'URL, la parte del percorso dell'URL o entrambe prima di inviare una richiesta al servizio di backend selezionato. Assicurati di sostituire i segnaposto.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           urlRewrite:
             hostRewrite: "new-host-name.com" # Omit to keep the requested host
             pathPrefixRewrite: "/new-path/" # Omit to keep the requested path

Riprovare una richiesta

Configura le condizioni in cui i nuovi tentativi del bilanciatore del carico non sono riusciti richieste, quanto tempo attende il bilanciatore del carico prima di riprovare il numero massimo di nuovi tentativi consentiti.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

Specifica il timeout del percorso

Specifica il timeout per la route selezionata. Il timeout viene calcolato dal momento in cui la richiesta viene elaborata completamente fino al momento in cui la risposta viene elaborata completamente. Timeout (Timeout) include tutti i nuovi tentativi. Assicurati di sostituire i segnaposto.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 500000000

Configurare l'iniezione di errori

Inserisci errori durante l'elaborazione delle richieste per simulare errori, tra cui alta latenza, sovraccarico del servizio, errori di servizio e partizione della rete. Questa funzionalità è utile per testare la resilienza di un per risolvere gli errori simulati.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 500000000
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

Configurare CORS

Configura i criteri di condivisione delle risorse tra origini (CORS) per gestire le impostazioni per l'applicazione delle richieste CORS.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: my-domain.com
               allowMethods: GET, POST
               allowHeaders: Authorization, Content-Type
               maxAge: 1200
               allowCredentials: True

Aggiungere e rimuovere intestazioni di richiesta e risposta

Aggiungi e rimuovi le intestazioni della richiesta prima di inviare una richiesta al backend completamente gestito di Google Cloud. Inoltre, aggiungi e rimuovi le intestazioni di risposta dopo aver ricevuto una risposta dal servizio di backend.

I bilanciatori del carico delle applicazioni esterni regionali e i bilanciatori del carico delle applicazioni interni supportano anche l'uso di variabili nelle intestazioni personalizzate. Puoi specificare una o più variabili nel del valore dell'intestazione (headerValue) che vengono poi tradotti nei relativi campi i valori per richiesta corrispondenti. Per un elenco dei valori delle intestazioni supportati, consulta Creare intestazioni personalizzate nelle mappe URL.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
               headerAction:
                 requestHeadersToAdd:
                 - headerName: header-1-name
                   headerValue: header-1-value
                   replace: True
                 requestHeadersToRemove:
                 - header-2-name
                 - header-3-name
                 responseHeadersToAdd:
                 - headerName: header-4-name
                   headerValue: header-4-value
                   replace: True
                responseHeadersToRemove:
                - header-5-name
                - header-6-name

Configurare il rilevamento degli outlier

Specifica i criteri per l'eliminazione di endpoint o VM di backend in stato non integro in NEG, insieme ai criteri che definiscono quando un backend o un endpoint considerato sufficientemente integro da ricevere di nuovo il traffico. Assicurati di sostituire i segnaposto.

    loadBalancingScheme: LOAD_BALANCING_SCHEME
    localityLbPolicy: RANDOM
    name: regions/REGION/backendServices/BACKEND_SERVICE_1
    outlierDetection:
      baseEjectionTime:
        nanos: 0
        seconds: '30'
      consecutiveErrors: 5
      consecutiveGatewayFailure: 3
      enforcingConsecutiveErrors: 2
      enforcingConsecutiveGatewayFailure: 100
      enforcingSuccessRate: 100
      interval:
        nanos: 0
        seconds: '1'
      maxEjectionPercent: 50
      successRateMinimumHosts: 5
      successRateRequestVolume: 100
      successRateStdevFactor: 1900
    region: region/REGION

Configura interruzione di circuito

L'interruttore di sicurezza ti consente di impostare soglie di errore per impedire alle richieste dei client di sovraccaricare i tuoi backend. Quando le richieste raggiungono un limite impostato, il bilanciatore del carico smette di consentire nuove connessioni o di inviare richieste aggiuntive, dando ai backend il tempo di recuperare. Pertanto, l'interruzione di circuito impedisce gli errori a cascata restituendo un errore al client anziché sovraccaricando un backend. Ciò consente la pubblicazione di una parte del traffico fornendo al contempo Tempo necessario per gestire la situazione di sovraccarico, ad esempio un picco di traffico aumentando la capacità tramite la scalabilità automatica.

Imposta i limiti massimi per le richieste per connessione e per il volume di a un servizio di backend. Limita anche il numero di richieste in attesa e di nuovi tentativi.

    loadBalancingScheme: LOAD_BALANCING_SCHEME # EXTERNAL_MANAGED or INTERNAL_MANAGED
    localityLbPolicy: RANDOM
    affinityCookieTtlSec: 0
    backends:
    - balancingMode: UTILIZATION
      capacityScaler: 1.0
      group: region/REGION/instanceGroups/INSTANCE_GROUP
      maxUtilization: 0.8
    circuitBreakers:
      maxConnections: 1000
      maxPendingRequests: 200
      maxRequests: 1000
      maxRequestsPerConnection: 100
      maxRetries: 3
    connectionDraining:
      drainingTimeoutSec: 0
    healthChecks:
    - region/REGION/healthChecks/HEALTH_CHECK

Configurare la suddivisione del traffico: procedura dettagliata

Questo esempio illustra i seguenti passaggi:

1. Crea modelli distinti per servizi diversi.

2. Crea gruppi di istanze per questi modelli.

3. Crea regole di routing che impostino la suddivisione del traffico del 95% / 5%.

4. Invia comandi curl che mostrano che le percentuali di suddivisione del traffico corrispondono approssimativamente alla configurazione.

Queste istruzioni presuppongono quanto segue:

• La regione è us-west1.

• Sono stati creati un proxy di destinazione e una regola di forwarding, insieme a una mappa URL denominato regional-lb-map.

• La mappa URL invia tutto il traffico a un servizio di backend, chiamato red-service, che è il servizio di backend predefinito.

• Hai configurato un percorso alternativo che invia il 5% del traffico a blue-service e il 95% del traffico a green-service.

• Viene utilizzato un matcher di percorso.

• Stai utilizzando Cloud Shell o un altro ambiente con bash installato.

Definisci i servizi

La seguente funzione bash crea un servizio di backend, che include modello di istanza e gruppo di istanze gestite.

function make_service() {
  local name="$1"
  local region="$2"
  local zone="$3"
  local network="$4"
  local subnet="$5"
  local subdir="$6"

  www_dir="/var/www/html/$subdir"

  (set -x; \
  gcloud compute instance-templates create "${name}-template" \
    --region="$region" \
    --network="$network" \
    --subnet="$subnet" \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee ${www_dir}index.html
  systemctl restart apache2"; \
  gcloud compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud compute backend-services create "${name}-service" \
    --load-balancing-scheme=LOAD_BALANCING_SCHEME\
    --protocol=HTTP \
    --health-checks=regional-lb-basic-check \
    --health-checks-region="$region" \
    --region="$region"; \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --region="$region")
}

crea i servizi

Chiama la funzione per creare tre servizi, red, green e blue. Il servizio red funge da servizio predefinito per le richieste a /. I servizi green e blue sono entrambi configurati su /PREFIX per gestire rispettivamente il 95% e il 5% del traffico.

make_service red us-west1 us-west1-a lb-network backend-subnet ""
make_service green us-west1 us-west1-a lb-network backend-subnet /PREFIX
make_service blue us-west1 us-west1-a lb-network backend-subnet /PREFIX

Crea la mappa URL

gcloud

1. Esporta la mappa URL esistente utilizzando il comando gcloud compute url-maps export:

   gcloud compute url-maps export regional-lb-map \
     --destination=regional-lb-map-config.yaml \
     --region=us-west1
   

2. Aggiorna il file della mappa URL regional-lb-map-config.yaml aggiungendo quanto segue alla fine del file:

   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/us-west1/backendServices/red-service
     name: matcher1
     routeRules:
     - priority: 2
       matchRules:
         - prefixMatch: /PREFIX
       routeAction:
         weightedBackendServices:
           - backendService: regions/us-west1/backendServices/green-service
             weight: 95
           - backendService: regions/us-west1/backendServices/blue-service
             weight: 5
   

3. Aggiorna la mappa URL utilizzando il comando gcloud compute url-maps import:

   gcloud compute url-maps import regional-lb-map \
      --region=us-west1 \
      --source=regional-lb-map-config.yaml
   

Testa la configurazione

Per testare la configurazione, assicurati innanzitutto che le richieste gli indirizzi IP del bilanciatore del carico configurati in precedenza sono gestiti dall'impostazione predefinita red configurazione.

Poi, assicurati che le richieste inviate a FORWARDING_RULE_IP_ADDRESS/PREFIX siano suddivise come previsto.

Configurare l'affinità sessione in base a HTTP_COOKIE

Il controllo del traffico ti consente di configurare l'affinità sessione in base a un cookie fornito. Per configurare l'affinità di sessione basata su HTTP_COOKIE per un servizio di backend chiamato red-service, segui queste istruzioni.

1. Utilizza il comando gcloud compute backend-services export per recuperare la configurazione del servizio di backend.

   gcloud compute backend-services export red-service \
       --destination=red-service-config.yaml \
       --region=us-west1
   

2. Aggiorna il file red-service-config.yaml come segue:

   sessionAffinity: 'HTTP_COOKIE'
   localityLbPolicy: 'RING_HASH'
   consistentHash:
    httpCookie:
     name: 'http_cookie'
     path: '/cookie_path'
     ttl:
       seconds: 100
       nanos: 500000000
    minimumRingSize: 10000
   

3. Nel file red-service-config.yaml, elimina la seguente riga:

   sessionAffinity: NONE
   

4. Aggiorna il file di configurazione del servizio di backend:

   gcloud compute backend-services import red-service \
       --source=red-service-config.yaml \
       --region=us-west1
   

Risoluzione dei problemi

Utilizza queste informazioni per la risoluzione dei problemi quando il traffico non viene indirizzato in base alle regole di routing e ai criteri di traffico che hai configurato.

Sintomi:

• Aumento del traffico verso i servizi nelle regole precedenti a quella in questione.
• Un aumento imprevisto delle risposte HTTP 4xx e 5xx per una determinata regola di route.

Soluzione: controlla l'ordine delle regole di routing. Le regole di route vengono interpretate nell'ordine in cui vengono specificati.

Le regole di route all'interno di una mappa URL vengono interpretate nell'ordine in cui vengono specificato. Questo è diverso dal modo in cui le regole dei percorsi vengono interpretate dalla corrispondenza del prefisso più lungo. Per una regola di percorso, i bilanciatori del carico delle applicazioni interni selezionare una singola regola percorso; Tuttavia, quando utilizzi le regole di route, possono essere potrebbe essere applicabile.

Quando definisci le regole di routing, assicurati che le regole nella parte superiore dell'elenco non indirizzino inavvertitamente il traffico che altrimenti sarebbe stato indirizzato da una regola di routing successiva. Il servizio che riceve traffico indirizzato erroneamente rifiuterà probabilmente le richieste e il servizio nelle tue regole di route riceverebbe meno traffico o non ne riceverebbe affatto.

Passaggi successivi

• Esegui la pulizia della configurazione del bilanciatore del carico.