Configura la gestione del traffico per gli Application Load Balancer interni

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

Il bilanciatore del carico delle applicazioni esterno regionale e il bilanciatore del carico delle applicazioni interno regionale. Per la configurazione di gestione del traffico dei bilanciatori del carico a livello di regione, l'API delle mappe URL a livello di regione e la documentazione dell' API del servizio di backend regionale forniscono un elenco completo dei campi, inclusa la semantica relativa a relazioni, restrizioni e cardinalità.

L'unica differenza tra questi due bilanciatori del carico è lo schema di bilanciamento del carico, come segue:

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

Application Load Balancer interno regionale e il bilanciatore del carico delle applicazioni interno tra regioni. Per la configurazione della gestione del traffico:

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

Prima di iniziare

Configura la gestione del traffico

All'interno dell'ambiente di configurazione che hai scelto, puoi impostare la gestione del traffico tramite le configurazioni YAML. Una mappa URL e un servizio di backend hanno ciascuno il proprio file YAML. A seconda delle funzionalità desiderate, 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 l'Application Load Balancer interno regionale, puoi utilizzare anche la console Google Cloud per configurare la gestione del traffico.

Per gli Application Load Balancer interni regionali e gli Application Load Balancer esterni regionali, la documentazione relativa all'API delle mappe URL a livello di regione e alla documentazione dell' API del servizio di backend regionale fornisce un elenco completo dei campi, inclusa la semantica relativa a relazioni, restrizioni e cardinalità.

Accedere agli esempi YAML nella console Google Cloud

Per accedere agli esempi YAML nella console Google Cloud:

  1. Nella console Google Cloud, vai alla pagina Bilanciamento del carico.

    Vai a Bilanciamento del carico

  2. Fai clic su Crea bilanciatore del carico.
  3. Completa i passaggi della procedura guidata per creare un bilanciatore del carico delle applicazioni interno regionale.
  4. Nella configurazione Regole di routing, seleziona Regola host, percorso e route avanzata.
  5. Fai clic su Aggiungi host e matcher percorso.
  6. Fai clic sul link Indicazioni sul codice.

Viene visualizzata la pagina Esempi YAML del matcher percorso.

Mappare il traffico a un singolo servizio

Inviare 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 servizi o tra più servizi. 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: 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. L'esempio imposta anche l'intestazione della risposta Location con l'URI appropriato, sostituendo l'host e il percorso come specificati 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 di mirroring configurato in base 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 tuo servizio di backend, anziché nella 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

Riscrivi l'URL richiesto

Riscrivi la parte del nome host dell'URL, la parte del percorso dell'URL o entrambi 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

Riprova a inviare 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: 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 della route

Specifica il timeout per la route selezionata. Il timeout viene calcolato dal momento in cui la richiesta viene completamente elaborata fino al completamento dell'elaborazione della risposta. Il 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

Configura fault injection

Introduci errori durante la gestione delle richieste per simulare errori, tra cui alta latenza, sovraccarico dei servizi, errori dei servizi e partizionamento della rete. Questa funzionalità è utile per testare la resilienza di un servizio a 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

Configura 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

Aggiungi e rimuovi intestazioni di richiesta e risposta

Aggiungi e rimuovi le intestazioni della richiesta 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.

Anche gli Application Load Balancer esterni regionali e gli Application Load Balancer interni supportano l'utilizzo di variabili nelle intestazioni personalizzate. Puoi specificare una o più variabili nei campi del valore dell'intestazione personalizzata (headerValue) che vengono poi tradotte nei relativi valori per richiesta corrispondenti. Per un elenco dei valori di intestazione supportati, consulta la pagina 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

Configura rilevamento outlier

Specifica i criteri per l'eliminazione delle VM o degli endpoint del backend in stato non integro dai NEG, insieme ai criteri che definiscono quando un backend o un endpoint viene considerato integro per 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 l'interruzione di circuito

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

Impostare i limiti superiori per le richieste per connessione, nonché il volume di connessioni a un servizio di backend. Limita anche il numero di richieste e nuovi tentativi in attesa.

    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: passaggi dettagliati

Questo esempio illustra i seguenti passaggi:

  1. Crea modelli distinti per servizi diversi.

  2. Creare gruppi di istanze per i modelli creati.

  3. Crea regole di routing che configurano una suddivisione del traffico al 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 denominata regional-lb-map.

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

  • Configuri un percorso alternativo che invia il 5% del traffico a blue-service e il 95% del traffico 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 (regional-lb-basic-check). Per le istruzioni, consulta Configurare un bilanciatore del carico delle applicazioni interno.
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

Richiama la funzione per creare tre servizi, red, green e blue. Il servizio red funge da servizio predefinito per le richieste inviate 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 mappa URL regional-lb-map-config.yaml aggiungendo questo 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 degli 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
    

Testare la configurazione

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

Poi controlla che le richieste inviate a FORWARDING_RULE_IP_ADDRESS/PREFIX vengano suddivise come previsto.

Crea una VM client

Per le istruzioni, consulta Creazione di un'istanza VM nella zona per verificare la connettività.

Invia richieste a FORWARDING_RULE_IP_ADDRESS

  1. Usa ssh per connetterti al client.

    gcloud compute ssh global-lb-client-us-west1-a \
       --zone=us-west1-a
    
  2. Esegui questo comando:

    for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
       RESULTS=
       for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}`"; done >/dev/null 2>&1
       IFS=':'
       echo "***"
       echo "*** Results of load balancing to $LB_IP: "
       echo "***"
       for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
       echo
    done
    
Controlla i risultati
***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

Invia richieste a FORWARDING_RULE_IP_ADDRESS/PREFIX

Invia richieste a FORWARDING_RULE_IP_ADDRESS/PREFIX e prendi nota della suddivisione del traffico.

for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
    RESULTS=
    for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}/PREFIX/index.html`"; done >/dev/null 2>&1
    IFS=':'
    echo "***"
    echo "*** Results of load balancing to $LB_IP/PREFIX: "
    echo "***"
    for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
    echo
done
Controlla i risultati
***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS/PREFIX:
***
21 blue-instance-group-8n49
27 blue-instance-group-vlqc
476 green-instance-group-c0wv
476 green-instance-group-rmf4

La configurazione canary invia correttamente il 95% delle richieste /PREFIX al servizio green e il 5% al servizio blue.

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 \
        --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 instradato in base alle regole di route e ai criteri di traffico che hai configurato.

Per informazioni su logging e monitoraggio, consulta Logging e monitoraggio di HTTP(S) interni.

Sintomi:

  • Aumento del traffico verso i servizi nelle regole sopra 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 specifiche. Questo è diverso dal modo in cui le regole percorso vengono interpretate per la corrispondenza del prefisso più lunga. Per una regola di percorso, gli Application Load Balancer interni selezioneranno una sola regola di percorso. Tuttavia, quando utilizzi le regole di route, potrebbe essere applicata più di una regola.

Quando definisci le regole di route, accertati che le regole in cima all'elenco non instradano inavvertitamente il traffico che altrimenti verrebbe instradato da una regola di route successiva. È probabile che il servizio che riceve traffico indirizzato erroneamente rifiuterà le richieste, mentre il servizio nelle tue regole di route riceverebbe una riduzione del traffico o nessun traffico.

Passaggi successivi