Configura la gestione del traffico per Application Load Balancer esterni globali

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

Il documento contiene esempi di Application Load Balancer esterni globali. Gli Application Load Balancer esterni globali utilizzano lo schema di bilanciamento del carico EXTERNAL_MANAGED e i componenti di bilanciamento del carico globali, come la regola di forwarding, la mappa URL e il servizio di backend.

Per informazioni sulla gestione del traffico con un bilanciatore del carico delle applicazioni classico, consulta Panoramica della gestione del traffico per un bilanciatore del carico delle applicazioni classico.

Per informazioni sulla gestione del traffico con Application Load Balancer esterni regionali, consulta Panoramica della gestione del traffico per gli Application Load Balancer esterni regionali.

Oltre alle funzionalità di routing avanzate descritte in questa pagina, determinati bilanciatori del carico delle applicazioni si integrano con le estensioni di servizio per consentirti di inserire logica personalizzata nel percorso dati del bilanciamento del carico configurando i callout delle estensioni di servizio.

Prima di iniziare

Assicurati di comprendere come funziona la gestione del traffico. Per saperne di più, consulta la Panoramica della gestione del traffico per gli Application Load Balancer esterni globali.

Configurare e testare la gestione del traffico

All'interno dell'ambiente di configurazione che hai scelto, puoi impostare la gestione del traffico utilizzando le configurazioni YAML. Una mappa URL e un servizio di backend hanno ciascuno il proprio file YAML. A seconda della funzionalità desiderata, devi scrivere un file YAML con mappa URL, un file YAML del servizio di backend o entrambi.

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

La console Google Cloud non è supportata.

L'API globale della mappa URL e la documentazione dell' API del servizio di backend globale forniscono un elenco completo dei campi, inclusa la semantica relativa a relazioni, restrizioni e cardinalità.

Puoi aggiungere test di configurazione a una mappa URL per assicurarti che la mappa URL instrada le richieste come previsto. Puoi sperimentare diverse regole delle mappe URL ed eseguire tutti i test necessari per avere la certezza che la mappa instrada il traffico al servizio di backend o al bucket di backend appropriati. Per maggiori dettagli, consulta Aggiungere test a una mappa URL. Se vuoi testare le nuove modifiche a una mappa URL senza implementare la mappa, consulta Convalidare la configurazione della mappa URL.

Mappare il traffico a un singolo servizio

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

    defaultService: global/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: global/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: /PREFIX
        priority: PRIORITY  # 0 is highest
        routeAction:
          weightedBackendServices:
          - backendService: global/backendServices/BACKEND_SERVICE_1
            weight: 100

Suddividi il traffico tra due servizi

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

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

Configurare un reindirizzamento URL

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

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/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 di mirroring configurato in base al metodo fire and delete. Il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta sottoposta a mirroring. Il mirroring è utile per testare una nuova versione di un servizio di backend. Puoi utilizzarlo anche per eseguire il debug degli errori di produzione in una versione di debug del servizio di backend anziché nella versione di produzione.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: global/backendServices/BACKEND_SERVICE_2

Il mirroring del traffico è supportato solo nei seguenti casi:

  • Entrambi i servizi di backend hanno backend di gruppi di istanze. Non sono supportati altri tipi di backend.
  • Le richieste HTTP non hanno un corpo.

Il mirroring non può essere configurato solo per una parte specifica delle richieste. Anche se suddividi il traffico tra più servizi di backend ponderati, il servizio di backend di mirroring riceve tutte le richieste. Puoi tuttavia usare intestazioni personalizzate per registrare quale servizio di backend è stato utilizzato per gestire la richiesta originale. Nell'esempio seguente viene aggiunta un'intestazione personalizzata denominata x-weighted-picked-backend a tutte le richieste del client. Per il valore dell'intestazione, utilizza il nome del servizio di backend che ha pubblicato la richiesta originale.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
            - backendService: global/backendServices/BACKEND_SERVICE_1
              weight: 95
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_1
                  replace: True
            - backendService: global/backendServices/BACKEND_SERVICE_2
              weight: 5
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_2
                  replace: True
           requestMirrorPolicy:
             backendService: global/backendServices/BACKEND_SERVICE_3

Riscrivi l'URL richiesto

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

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/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

Riprova a effettuare una richiesta

Configura le condizioni in base alle quali il bilanciatore del carico tenta di ripetere le richieste non riuscite, il tempo di attesa prima di riprovare e il numero massimo di nuovi tentativi consentiti.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/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 è calcolato dal momento in cui la richiesta viene completamente elaborata fino all'elaborazione completa della risposta. Il timeout include tutti i nuovi tentativi. Assicurati di sostituire i segnaposto.

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

Configura fault injection

Introduci errori durante la gestione delle richieste per simulare gli errori, tra cui latenza elevata, sovraccarico dei servizi, errori dei servizi e partizionamento della rete. Questa funzionalità è utile per testare la resilienza di un servizio ai guasti simulati.

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

Configura CORS

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

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

Aggiungi e rimuovi intestazioni di richieste e risposte

Aggiungi e rimuovi le intestazioni delle richieste prima di inviare una richiesta al servizio di backend. Inoltre, aggiungi e rimuovi le intestazioni della risposta dopo aver ricevuto una risposta dal servizio di backend.

Esistono limitazioni relative ai valori validi per headerName e headerValue. Per maggiori dettagli, vedi Come funzionano le intestazioni personalizzate.

   defaultService: global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: global/backendServices/BACKEND_SERVICE_1
               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

Configura il rilevamento outlier

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

    loadBalancingScheme: EXTERNAL_MANAGED
    localityLbPolicy: RANDOM
    name: global/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

Configurare la suddivisione del traffico: passaggi dettagliati

Questo esempio illustra i seguenti passaggi:

  1. Crea modelli distinti per servizi diversi.

  2. Creare gruppi di istanze per questi modelli.

  3. Crea regole di routing che configurano una suddivisione del traffico tra il 95% e il 5%.

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

Queste istruzioni presuppongono quanto segue:

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

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

  • Configuri un percorso alternativo che invii il 5% del traffico a blue-service e il 95% a green-service.

  • Viene utilizzato un matcher percorso.

  • Stai utilizzando Cloud Shell o un altro ambiente in cui è installato bash.

Definisci i servizi

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

Queste istruzioni presuppongono che sia stato creato un controllo di integrità HTTP (global-lb-basic-check). Per istruzioni, consulta una delle seguenti pagine:

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=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=global-lb-basic-check \
    --global \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --global)
}

Crea i servizi

Richiama la funzione per creare tre servizi: red, green e blue. Il servizio red agisce come 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

Console

  1. Vai alla pagina Bilanciamento del carico nella console Google Cloud.
    Vai a Bilanciamento del carico
  2. Fai clic sul link global-lb-map.
  3. Fai clic su Modifica .

Configura le nuove regole di routing

  1. In Regole di routing, seleziona Regola avanzata per host, percorso e route.
  2. In Matcher nuovi host e percorso, crea l'azione predefinita impostando Servizio su red-service.
  3. Fai clic su Fine.
  4. Fai clic su Aggiungi matcher host e percorso.
  5. Nel campo Host, inserisci l'indirizzo IP della regola di forwarding del bilanciatore del carico.
  6. Incolla i seguenti contenuti YAML nella casella Matcher del percorso:

    defaultService: global/backendServices/red-service
    name: matcher1
    routeRules:
    - priority: 2
      matchRules:
        - prefixMatch: /PREFIX
      routeAction:
        weightedBackendServices:
          - backendService: global/backendServices/green-service
            weight: 95
          - backendService: global/backendServices/blue-service
            weight: 5
    
  7. Fai clic su Fine.

  8. Fai clic su Aggiorna.

gcloud

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

    gcloud compute url-maps export global-lb-map \
      --destination=global-lb-map-config.yaml \
      --global
    
  2. Aggiorna il file mappa URL global-lb-map-config.yaml aggiungendo quanto segue alla fine del file:

    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    pathMatchers:
    - defaultService: global/backendServices/red-service
      name: matcher1
      routeRules:
      - priority: 2
        matchRules:
          - prefixMatch: /PREFIX
        routeAction:
          weightedBackendServices:
            - backendService: global/backendServices/green-service
              weight: 95
            - backendService: global/backendServices/blue-service
              weight: 5
    
  3. Aggiorna la mappa URL utilizzando il comando gcloud compute url-maps import:

    gcloud compute url-maps import global-lb-map \
       --global \
       --source=global-lb-map-config.yaml
    

Testare la configurazione

Per testare la configurazione, assicurati innanzitutto che le richieste all'indirizzo IP del bilanciatore del carico configurato in precedenza siano gestite dalla configurazione red predefinita.

Verifica quindi che le richieste inviate a FORWARDING_RULE_IP_ADDRESS/prefix siano suddivise come previsto.

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

  1. Utilizza il comando gcloud compute backend_services export per ottenere la configurazione del servizio di backend.

    gcloud compute backend-services export red-service \
        --destination=red-service-config.yaml \
        --global
    
  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: 0
     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 \
        --global
    

Risoluzione dei problemi

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

Per informazioni su logging e monitoraggio, consulta Registrazione e monitoraggio HTTP(S) esterni.

Sintomi:

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

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

Le regole di route all'interno di una mappa URL vengono interpretate nell'ordine in cui sono specificate. Questo è diverso dal modo in cui le regole del percorso vengono interpretate dalla corrispondenza del prefisso più lunga. Per una regola percorso, l'Application Load Balancer esterno globale seleziona solo una regola per il percorso. Tuttavia, quando utilizzi le regole di route, potrebbe essere applicata più di una regola.

Quando definisci le regole di route, verifica che le regole all'inizio dell'elenco non instradano inavvertitamente il traffico che altrimenti verrebbe instradato da una regola di route successiva. È probabile che il servizio che riceva traffico indirizzato erroneamente rifiuterà le richieste, mentre il servizio nelle regole di route potrebbe ricevere meno traffico o addirittura nessun traffico.

Passaggi successivi