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

Bilanciatore del carico delle applicazioni esterno regionale rispetto al bilanciatore del carico delle applicazioni interno regionale. Per la configurazione della gestione del traffico dei bilanciatori del carico regionali, la documentazione dell'API della mappa URL regionale e dell'API del servizio di backend regionale fornisce 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.

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

Oltre alle funzionalità di routing avanzate descritte in questa pagina, i bilanciatori del carico delle applicazioni supportati si integrano con Service Extensions per consentirti di inserire logica personalizzata nel percorso dei dati di bilanciamento del carico.

Prima di iniziare

Assicurati di comprendere come funziona la gestione del traffico. Per saperne di più, consulta Panoramica della gestione del traffico per i bilanciatori del carico delle applicazioni esterni regionali.

Configurare la gestione del traffico

Nell'ambiente di configurazione scelto, puoi configurare 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 della mappa URL, un file YAML del servizio di backend o entrambi.

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

La Google Cloud console non è supportata.

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

Utilizzare gli esempi YAML nella Google Cloud console

Per utilizzare gli esempi YAML nella Google Cloud console:

  1. Nella Google Cloud console, 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 regional external Application Load Balancer.
  4. Nella configurazione Regole di routing, seleziona Regola avanzata per host e percorso.
  5. Fai clic su Aggiungi regola host e percorso.
  6. Esegui una delle seguenti operazioni:
    • Nella casella Matcher percorso, incolla gli esempi YAML di questo documento.
    • Fai clic sul link Guida al codice.
      • Viene visualizzata la pagina Esempi YAML matcher percorso. Puoi incollare gli esempi dalla pagina Esempi YAML matcher percorso nella casella Matcher percorso.
  7. Fai clic su Fine.

Mappare il traffico a un singolo servizio

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

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

Suddividere il traffico tra due servizi

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

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: projects/PROJECT_ID/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 specificato nell'azione di reindirizzamento.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: URL_MAP_NAME
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     defaultUrlRedirect:
       hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
       pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
       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 modalità fire and forget. Ciò significa che il bilanciatore del carico non attende una risposta dal backend a cui invia la richiesta di mirroring. Il mirroring delle richieste è utile per testare 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.

Per impostazione predefinita, il servizio di backend di mirroring riceve tutte le richieste, anche se il traffico originale viene suddiviso tra più servizi di backend ponderati. Puoi configurare il servizio di backend di mirroring in modo che riceva solo una percentuale delle richieste utilizzando il flag facoltativo mirrorPercent per specificare la percentuale di richieste di cui eseguire il mirroring espressa come valore compreso tra 0 e 100,0.

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

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

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

Riscrivere l'URL richiesto

Riscrivi la parte dell'hostname 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: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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 a inviare una richiesta

Configura le condizioni in cui il bilanciatore del carico riprova a inviare le richieste non riuscite, il tempo di attesa del bilanciatore del carico prima di riprovare e il numero massimo di tentativi consentiti.

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

Specificare il timeout della route

Specifica il timeout per la route selezionata. Il timeout viene calcolato dal momento in cui la richiesta viene elaborata completamente fino a quando la risposta non viene elaborata completamente. Il timeout include tutti i tentativi. Assicurati di sostituire i segnaposto.

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

Configurare la fault injection

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

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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 le policy di condivisione delle risorse tra origini (CORS) per gestire le impostazioni per l'applicazione delle richieste CORS.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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 delle richieste prima di inviare una richiesta al servizio di backend. Aggiungi e rimuovi anche le intestazioni delle risposte 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'utilizzo di variabili nelle intestazioni personalizzate. Puoi specificare una o più variabili nei campi dei valori delle intestazioni personalizzate (headerValue) che vengono poi tradotte nei valori corrispondenti per richiesta. Per un elenco dei valori delle intestazioni supportati, consulta Creare intestazioni personalizzate nelle mappe URL maps.

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

Specifica i criteri per l'espulsione di VM o endpoint di backend non integri nei 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: projects/PROJECT_ID/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

Configurare l'interruzione del circuito

L'interruzione del circuito consente di impostare soglie di errore per impedire che le richieste dei client sovraccarichino i backend. Una volta raggiunta una soglia di richieste impostata, il bilanciatore del carico smette di consentire nuove connessioni o di inviare richieste aggiuntive, dando ai backend il tempo di ripristinarsi. Pertanto, l'interruzione del circuito impedisce errori a cascata restituendo un errore al client anziché sovraccaricare un backend. In questo modo, è possibile gestire parte del traffico, fornendo al contempo il tempo necessario per gestire la situazione di sovraccarico, ad esempio gestendo un picco di traffico aumentando la capacità tramite la scalabilità automatica.

Imposta i limiti superiori per le richieste per connessione e per il volume di connessioni a un servizio di backend. Limita anche il numero di richieste e 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 configurano la 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, 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.

Definire i servizi

La seguente funzione Bash crea un servizio di backend, inclusi il template 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 esterno regionale. 
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-12 \
    --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")
}

Creare 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

Creare la mappa URL

Console

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

    Vai a Bilanciamento del carico

  2. Fai clic sul link regional-lb-map.

  3. Fai clic su Modifica .

Configurare le nuove regole di routing

  1. In Regole di routing, seleziona Regola avanzata per host e percorso.
  2. In Regola host e percorso, per creare l'azione predefinita, imposta Servizio su red-service.
  3. Fai clic su Fine.
  4. Fai clic su Aggiungi regola 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 percorso:

    defaultService: projects/PROJECT_ID/regions/us-west1/backendServices/red-service
name: matcher1
routeRules:
- priority: 2
  matchRules:
    - prefixMatch: /PREFIX
  routeAction:
    weightedBackendServices:
      - backendService: projects/PROJECT_ID/regions/us-west1/backendServices/green-service
        weight: 95
      - backendService: projects/PROJECT_ID/regions/us-west1/backendServices/blue-service
        weight: 5

  7. Fai clic su Fine.

  8. Fai clic su Aggiorna.

gcloud

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

    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: projects/PROJECT_ID/regions/us-west1/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /PREFIX
    routeAction:
      weightedBackendServices:
        - backendService: projects/PROJECT_ID/regions/us-west1/backendServices/green-service
          weight: 95
        - backendService: projects/PROJECT_ID/regions/us-west1/backendServices/blue-service
          weight: 5

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

    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 configurato in precedenza vengano gestite dalla configurazione red predefinita.

Quindi, verifica che le richieste inviate a FORWARDING_RULE_IP_ADDRESS/PREFIX vengano suddivise come previsto.

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

  1. Utilizza il gcloud compute backend-services export comando 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 alle policy di traffico configurate.

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

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 specificate. Questo è diverso dal modo in cui le regole di percorso vengono interpretate dalla corrispondenza del prefisso più lungo. Per una regola di percorso, i bilanciatori del carico delle applicazioni interni selezioneranno solo una singola regola di percorso; tuttavia, quando utilizzi le regole di route, potrebbe essere applicata più di una regola.

Quando definisci le regole di route, assicurati che le regole nella parte superiore dell'elenco non instradino inavvertitamente il traffico che altrimenti sarebbe stato instradato da una regola di route successiva. Il servizio che riceve il traffico instradato in modo errato probabilmente rifiuterà le richieste e il servizio nelle regole di route riceverà traffico ridotto o nullo.

Passaggi successivi