Configurare backend esterni

Questo documento fornisce istruzioni per la configurazione dei backend esterni per Traffic Director utilizzando gruppi di endpoint di rete (FQDN) completi per il nome di dominio. Si presume che tu abbia una conoscenza del livello intermedio-avanzato con quanto segue:

• Bilanciamento del carico HTTP(S) esterno
• Cloud DNS
• Traffic Director
• Connettività ibrida

Questa guida alla configurazione fornisce istruzioni di base per:

• Configurazione di Traffic Director per l'utilizzo di un NEG Internet e TLS non autenticato per il traffico in uscita
• Routing del traffico a un servizio Cloud Run dal mesh di servizi

Prima di iniziare

Esamina la panoramica di Traffic Director con i gruppi di endpoint di rete Internet.

Ai fini di questa guida, le configurazioni di esempio presuppongono quanto segue:

• Tutte le risorse Compute Engine pertinenti, come proxy intermedi, risorse Traffic Director, zone Cloud DNS e connettività ibrida, sono collegate alla rete Virtual Private Cloud (VPC) predefinita.
• Il servizio example.com:443 è in esecuzione nell'infrastruttura on-premise. Il dominio example.com è gestito da tre endpoint, 10.0.0.100, 10.0.0.101 e 10.0.0.102. Esistono route che assicurano la connettività dai proxy Envoy a questi endpoint remoti.

Il deployment risultante è simile al seguente.

Esempio di configurazione con un NEG Internet (fai clic per ingrandire)

Routing del traffico con NEG e TLS via Internet con SNI

Dopo aver configurato Traffic Director con un NEG Internet utilizzando il nome di dominio completo e TLS per il traffico in uscita, l'implementazione di esempio si comporta come illustrato nel diagramma e nella descrizione seguenti del traffico.

Come viene indirizzato il traffico nell'esempio (fai clic per ingrandire)

I passaggi della seguente legenda corrispondono alla numerazione nel diagramma precedente.

Passaggio	Descrizione
0	Envoy riceve la configurazione di backend FQDN da Traffic Director tramite xDS.
0	Envoy, in esecuzione nella VM, esegue una query continua sul DNS per il nome di dominio completo configurato.
1	L'applicazione utente avvia una richiesta.
2	Parametri della richiesta.
3	Il proxy Envoy intercetta la richiesta. L'esempio presuppone che tu stia utilizzando 0.0.0.0 come indirizzo IP virtuale della regola di forwarding. Quando 0.0.0.0 è il VIP, l'intercettatore intercetta tutte le richieste. Il routing delle richieste si basa solo sui parametri del livello 7, a prescindere dall'indirizzo IP di destinazione nella richiesta originale generata dall'applicazione.
4	Envoy seleziona un endpoint remoto in stato integro ed esegue un handshake TLS con lo SNI ottenuto dal criterio TLS del client.
5	Envoy esegue il proxy della richiesta all'endpoint remoto.

Non viene mostrato nel diagramma, ma se i controlli di integrità sono configurati, Envoy verifica in modo continuo gli endpoint remoti e indirizza le richieste solo a endpoint in stato integro.

Configura connettività ibrida

Questo documento presuppone inoltre che la connettività ibrida sia già stabilita:

• La connettività ibrida tra la rete VPC e i servizi on-premise o un cloud pubblico di terze parti viene stabilita con Cloud VPN o Cloud Interconnect.
• Le regole e le route firewall VPC sono configurate correttamente per stabilire la connettività bidirezionale da Envoy agli endpoint di servizio privati e, facoltativamente, a un server DNS on-premise.
• Per uno scenario di failover ad alta disponibilità a livello di area geografica, è abilitato il routing dinamico globale. Per maggiori dettagli, consulta l'articolo Modalità di routing dinamico.

Imposta la configurazione di Cloud DNS

Utilizza i comandi seguenti per configurare una zona privata di Cloud DNS per il dominio (FQDN) example.com, con record A che puntano agli endpoint 10.0.0.100, 10.0.0.101, 10.0.0.102 e 10.0.0.103.

gcloud

1. Crea una zona privata gestita da DNS e collegala alla rete predefinita:

   gcloud dns managed-zones create example-zone \
       --description=test \
       --dns-name=example.com \
       --networks=default \
       --visibility=private
   

2. Aggiungi i record DNS alla zona privata:

   gcloud dns record-sets transaction start \
       --zone=example-zone
   
   gcloud dns record-sets transaction add 10.0.0.100 10.0.0.101 10.0.0.102 10.0.0.103 \
       --name=example.com \
       --ttl=300 \
       --type=A \
       --zone=example-zone
   
   gcloud dns record-sets transaction execute \
       --zone=example-zone
   

Configurare Traffic Director con un NEG FQDN Internet

In questa sezione configurerai Traffic Director con un NEG FQDN Internet.

Crea il servizio di NEG, controllo di integrità e backend

gcloud

1. Crea il NEG Internet:

   gcloud compute network-endpoint-groups create on-prem-service-a-neg \
       --global \
       --network-endpoint-type INTERNET_FQDN_PORT
   

2. Aggiungi l'endpoint FQDN:Port al NEG Internet:

   gcloud compute network-endpoint-groups update on-prem-service-a-neg \
       --global \
       --add-endpoint=fqdn=example.com,port=443
   

3. Creare un controllo di integrità globale:

   gcloud compute health-checks create http service-a-http-health-check \
       --global
   

4. Crea un servizio di backend globale denominato on-prem-service-a e associalo al controllo di integrità:

   gcloud compute backend-services create on-prem-service-a \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --health-checks service-a-http-health-check
   

5. Aggiungi il NEG denominato on-prem-service-a-neg come backend del servizio di backend:

   gcloud compute backend-services add-backend on-prem-service-a \
       --global \
       --global-network-endpoint-group \
       --network-endpoint-group on-prem-service-a-neg
   

Crea una mappa di regole di routing

La mappa URL, il proxy HTTP di destinazione e la regola di forwarding costituiscono una mappa di regole di routing che fornisce informazioni sul routing per il traffico nel tuo mesh.

Questa mappa degli URL contiene una regola che instrada tutto il traffico HTTP a on-prem-service-a.

gcloud

1. Crea la mappa URL:

   gcloud compute url-maps create td-url-map \
       --default-service on-prem-service-a
   

2. Crea il proxy HTTP di destinazione e associa la mappa URL al proxy di destinazione:

   gcloud compute target-http-proxies create td-proxy \
       --url-map td-url-map
   

3. Crea la regola di forwarding globale utilizzando l'indirizzo IP 0.0.0.0. Si tratta di un indirizzo IP speciale che fa sì che il tuo piano dati ignori l'indirizzo IP di destinazione e le richieste di route solo in base ai parametri HTTP della richiesta.

   gcloud compute forwarding-rules create td-forwarding-rule \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --address=0.0.0.0 \
       --target-http-proxy=td-proxy \
       --ports=443 \
       --network=default
   

Configura TLS non autenticato e HTTPS

Facoltativamente, se vuoi configurare HTTPS non autenticato tra i tuoi proxy Envoy e i tuoi servizi on-premise, segui queste istruzioni. Queste istruzioni mostrano anche come configurare lo SNI nell'handshake TLS.

Un criterio TLS del client specifica l'identità e il meccanismo di autenticazione del client quando un client invia richieste in uscita a un determinato servizio. Un criterio TLS del client viene associato a una risorsa di servizio di backend utilizzando il campo securitySettings.

gcloud

1. Crea e importa il criterio TLS del client; imposta lo SNI sul nome di dominio completo configurato nel NEG:

   cat << EOF > client_unauthenticated_tls_policy.yaml
   name: "client_unauthenticated_tls_policy"
   sni: "example.com"
   EOF
   
   gcloud beta network-security client-tls-policies import client_unauthenticated_tls_policy \
       --source=client_unauthenticated_tls_policy.yaml \
       --location=global
   

2. Se hai configurato un controllo di integrità HTTP con il servizio di backend nella sezione precedente, scollegalo dal servizio di backend:

   gcloud compute backend-services update on-prem-service-a \
       --global \
       --no-health-checks
   

3. Crea un controllo di integrità HTTPS:

   gcloud compute health-checks create https service-a-https-health-check \
       --global
   

4. Collega il criterio TLS del client al servizio di backend che hai creato in precedenza. Applica il protocollo HTTPS non autenticato a tutte le richieste in uscita dal client a questo servizio di backend:

   gcloud compute backend-services export on-prem-service-a \
       --global \
       --destination=on-prem-service-a.yaml
   
   cat << EOF >> on-prem-service-a.yaml
   securitySettings:
     clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client_unauthenticated_tls_policy
   healthChecks:
     - projects/${PROJECT_ID}/global/healthChecks/service-a-https-health-check
   EOF
   
   gcloud compute backend-services import on-prem-service-a \
       --global \
       --source=on-prem-service-a.yaml
   

Puoi utilizzare i NEG FQDN Internet per instradare il traffico a qualsiasi servizio raggiungibile tramite FQDN, ad esempio servizi DNS esterni e interni risolvibili dal DNS o servizi Cloud Run.

Esegui la migrazione da un NEG di IP:Port a un NEG di FQDN:Port

Il NEG NON_GCP_PRIVATE_IP_PORT richiede la programmazione degli endpoint del servizio nel NEG come coppie statiche di IP:PORT, mentre INTERNET_FQDN_NEG consente la risoluzione dinamica degli endpoint tramite DNS. Per eseguire la migrazione al NEG Internet, puoi configurare i record DNS per gli endpoint dei servizi on-premise e configurare Traffic Director come descritto nei seguenti passaggi:

1. Configura i record DNS per il tuo nome di dominio completo.
2. Crea un nuovo NEG Internet con il nome di dominio completo.
3. Crea un nuovo servizio di backend con il NEG Internet creato al passaggio 2 come backend. Associa lo stesso controllo di integrità che hai utilizzato al servizio di backend NEG di connettività ibrida con il nuovo servizio di backend. Verifica che i nuovi endpoint remoti siano in stato integro.
4. Aggiorna la mappa delle regole di routing in modo che faccia riferimento al nuovo servizio di backend sostituendo il vecchio backend che include il NEG di connettività ibrida.
5. Se vuoi tempi di inattività pari a zero durante la migrazione live in un deployment di produzione, puoi utilizzare il traffico ponderato. Inizialmente, configura il nuovo servizio di backend in modo da ricevere solo una piccola percentuale di traffico, ad esempio il 5%. Segui le istruzioni per configurare la suddivisione del traffico.
6. Verifica che i nuovi endpoint remoti stiano gestendo correttamente il traffico.
7. Se utilizzi la suddivisione del traffico basata sul peso, configura il nuovo servizio di backend in modo da ricevere il 100% del traffico. Questo passaggio svuota il vecchio servizio di backend.
8. Dopo aver verificato che i nuovi backend stiano gestendo il traffico senza problemi, elimina il vecchio servizio di backend.

Risolvere i problemi

Per risolvere i problemi di deployment, segui le istruzioni riportate in questa sezione. Se i problemi che riscontri non sono risolti con queste informazioni, consulta la sezione Risoluzione dei problemi relativi ai deployment che utilizzano Envoy.

Un endpoint on-premise non riceve traffico

Se un endpoint non riceve traffico, assicurati che superi i controlli di integrità e che le query DNS del client Envoy restituiscano il suo indirizzo IP in modo coerente.

Envoy utilizza la modalità strict_dns per gestire le connessioni. Bilancia il traffico tra tutti gli endpoint risolti che sono in stato integro. L'ordine in cui gli endpoint vengono risolti non è importante nella modalità strict_dns, ma Envoy svuota il traffico verso qualsiasi endpoint che non è più presente nell'elenco degli indirizzi IP restituiti.

L'intestazione host HTTP non corrisponde a FQDN quando la richiesta raggiunge il mio server on-premise

Considera un esempio in cui il dominio abc.com viene risolto in 10.0.0.1, che è l'indirizzo IP della regola di forwarding, e il dominio xyz.com viene risolto in 10.0.0.100, che è il tuo endpoint di servizio on-premise. Vuoi inviare traffico al dominio xyz.com, che è configurato nel tuo NEG.

È possibile che l'applicazione in Compute Engine o GKE imposti l'intestazione HTTP Host su abc.com (Host: abc.com), che viene trasferita all'endpoint on-premise. Se utilizzi HTTPS, Envoy imposta lo SNI su xyz.com durante l'handshake TLS. Envoy ottiene lo SNI dalla risorsa di criteri TLS del client.

Se questo conflitto causa problemi di elaborazione o routing della richiesta quando raggiunge l'endpoint on-premise, come soluzione alternativa puoi riscrivere l'intestazione Host in xyz.com (Host: xyz.com). Puoi eseguire questa operazione in Traffic Director utilizzando la riscrittura dell'URL o sull'endpoint remoto se è presente la funzionalità di riscrittura dell'intestazione.

Un'altra soluzione meno complessa è impostare l'intestazione Host su xyz.com (Host: xyz.com) e utilizzare l'indirizzo speciale 0.0.0.0 come indirizzo IP della regola di forwarding.

Envoy restituisce molti errori 5xx

Se Envy restituisce un numero eccessivo di errori 5xx, procedi nel seguente modo:

• Controlla i log Envoy per distinguere se la risposta proviene dal backend (backend on-premise) e dal motivo dell'errore 5xx.
• Accertati che le query DNS abbiano esito positivo e che non contengano errori SERVFAIL o NXDOMAIN.
• Assicurati che tutti gli endpoint remoti superino i controlli di integrità.
• Se i controlli di integrità non sono configurati, assicurati che tutti gli endpoint siano raggiungibili da Envoy. Controlla le regole e le route del tuo firewall sia sul lato Google Cloud sia sul lato on-premise.

Impossibile raggiungere servizi esterni sulla rete Internet pubblica dal mesh di servizi

Puoi inviare il traffico ai servizi che si trovano sulla rete Internet pubblica mediante backend FQDN in Traffic Director. Devi prima stabilire la connettività Internet tra i client Envoy e il servizio esterno. Se ricevi un errore 502 durante le connessioni al servizio esterno, procedi come segue:

• Assicurati di aver configurato le route corrette, in particolare quelle predefinite 0.0.0.0/0 e quelle firewall.
• Accertati che le query DNS abbiano esito positivo e che non contengano errori SERVFAIL o NXDOMAIN.
• Se il proxy Envoy è in esecuzione su una VM di Compute Engine che non dispone di un indirizzo IP esterno o in un cluster GKE privato, devi configurare Cloud NAT o un altro mezzo per stabilire la connettività Internet in uscita.

Se gli errori persistono o se ricevi altri errori 5xx, controlla i log Envoy per limitare l'origine degli errori.

Impossibile raggiungere i servizi serverless dal mesh di servizi

Puoi inviare il traffico ai servizi serverless (Cloud Run, Cloud Functions e App Engine) utilizzando i backend FQDN in Traffic Director. Se il proxy Envoy è in esecuzione su una VM di Compute Engine che non ha un indirizzo IP esterno o in un cluster GKE privato, devi configurare l'accesso privato Google sulla subnet per poter accedere alle API e ai servizi Google.

Passaggi successivi

• Per ulteriori informazioni sui criteri TLS del client, consulta le sezioni relative alla sicurezza del servizio Traffic Director e all'API Network Security.