Configurazione della gestione del traffico per bilanciatori del carico HTTP(S) esterni a livello di area geografica

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo documento mostra alcuni 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 HTTP(S) esterno a livello di area geografica
  • Bilanciatore del carico HTTP(S) interno a livello di area geografica

Per la configurazione dei bilanciatori del carico a livello di area geografica, l'unica differenza tra questi due bilanciatori del carico è lo schema del bilanciamento del carico, come segue:

  • I bilanciatori del carico HTTP(S) esterni a livello di area geografica utilizzano EXTERNAL_MANAGED.
  • I bilanciatori del carico HTTP(S) interni a livello di area geografica usano INTERNAL_MANAGED.

I bilanciatori del carico HTTP(S) esterni globali utilizzano lo schema di bilanciamento del carico EXTERNAL_MANAGED e i componenti di bilanciamento del carico globale, ad esempio la regola di forwarding, la mappa URL e il servizio di backend. Per informazioni sulla gestione del traffico con bilanciatori del carico HTTP(S) esterni globali, consulta la panoramica sulla gestione del traffico per i bilanciatori del carico HTTP(S) esterni globali.

Per informazioni sulla gestione del traffico con bilanciatore del carico HTTP(S) esterno globale (versione classica), consulta la panoramica sulla gestione del traffico per il bilanciatore del carico HTTP(S) globale esterno (classico).

Configura gestione del traffico

All'interno dell'ambiente di configurazione scelto, imposta la gestione del traffico utilizzando 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 mappa URL, un file YAML servizio di backend o entrambi.

Se hai bisogno di aiuto per scrivere questi file YAML, puoi utilizzare gli esempi in questa pagina e la documentazione dell'API Cloud Load Balancing.

La documentazione relativa all'API Maps URL regionale e all' API di servizio di backend a livello di area geografica fornisce un elenco completo dei campi, tra cui la semantica relativa a relazioni, limitazioni e cardinalità.

Mappa il traffico a un singolo servizio

Invia tutto il traffico a un solo 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 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 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 mirror configurato, in base all'attivazione e all'eliminazione. Il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta con mirroring. Il mirroring è utile per testare una nuova versione di un servizio di backend. Puoi anche utilizzarla 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

Riscrivere l'URL richiesto

Riscrivi 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

Riprova a inviare una richiesta

Configura le condizioni in cui il bilanciatore del carico tenta di nuovo le richieste non riuscite, quanto tempo deve attendere il bilanciatore del carico prima di riprovare e il numero massimo di 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 il percorso selezionato. Il timeout viene calcolato dal momento in cui la richiesta viene elaborata completamente 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 latenza elevata, sovraccarico del servizio, errori di servizio e partizionamento di rete. Questa funzionalità è utile per testare la resilienza di un servizio agli 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 CORS (condivisione delle risorse multiorigine) 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 richieste e risposte

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

   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 il rilevamento di 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 abbastanza integro per ricevere nuovamente 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'interruzione dell'interruttore consente di impostare soglie di errore per impedire alle richieste del client di sovraccaricare 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, lasciando ai backend il tempo di recupero. Pertanto, l'interruzione del circuito previene gli errori a cascata restituendo un errore al client anziché sovraccaricare un backend. Ciò consente di pubblicare parte del traffico e, al tempo stesso, di avere tempo per gestire la situazione di sovraccarico, ad esempio gestire un picco di traffico aumentando la capacità tramite la scalabilità automatica.

Imposta i limiti superiori per le richieste per connessione e 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. Crea gruppi di istanze per questi modelli.

  3. Crea regole di routing che configuri una 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 che:

  • L'area geografica è 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, chiamato red-service, che è il servizio di backend predefinito.

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

  • Viene usato un matcher di 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.

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-9 \
    --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 effettuare 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 mappa URL regional-lb-map-config.yaml aggiungendolo 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

Testare la configurazione

Per verificare la configurazione, verifica innanzitutto che le richieste all'indirizzo IP del bilanciatore del carico impostate in precedenza siano gestite dalla configurazione predefinita di red.

Quindi verifica che le richieste inviate a FORWARDING_RULE_IP_ADDRESS/PREFIX siano divise 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 \
    --region=us-west1

  2. Aggiorna il file red-service-config.yaml come indicato di seguito:

    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

Risolvere i problemi

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

Sintomi:

  • Aumento del traffico verso i servizi nelle regole sopra la regola in questione.
  • 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 sono specificate.

Le regole di route in 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 di percorso, il bilanciamento del carico HTTP(S) interno seleziona solo una singola regola di percorso; tuttavia, quando utilizzi regole di route, potrebbero applicarsi più di una regola.

Quando definisci le regole di route, assicurati che le regole in cima all'elenco non indirizzino inavvertitamente il traffico che sarebbe stato altrimenti instradato da una regola di route successiva. È probabile che il servizio che riceve traffico indirizzato in modo errato rifiuterebbe le richieste e che il servizio nelle regole di route riceverebbe traffico ridotto o nessun traffico.

Passaggi successivi