Configura backend esterni con gruppi di endpoint di rete internet
Questo documento fornisce istruzioni per configurare backend esterni per Cloud Service Mesh utilizzando i gruppi di endpoint di rete (NEG) che richiedono un nome di dominio completo. Questo documento è destinato agli utenti che hanno un livello di conoscenza intermedio e avanzato di quanto segue:
- Bilanciatore del carico delle applicazioni esterno
- Cloud DNS
- Mesh di servizi Cloud
- Connettività ibrida
Questa guida alla configurazione fornisce istruzioni di base per i seguenti argomenti:
- Configurazione di Cloud Service Mesh per l'utilizzo di un NEG internet e di TLS non autenticato per il traffico in uscita
- Routing del traffico a un servizio Cloud Run dal tuo mesh di servizi
Prima di iniziare
Esamina la panoramica di Cloud Service Mesh 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 intermedio, risorse Cloud Service Mesh, zone Cloud DNS e connettività ibrida, sono collegate alla rete Virtual Private Cloud (VPC) predefinita.
- Il servizio
example.com:443
è in esecuzione nella tua infrastruttura on-premise. Il dominioexample.com
è gestito da tre endpoint:10.0.0.100
,10.0.0.101
e10.0.0.102
. Esistono route che assicurano la connettività dai proxy Envoy a questi endpoint remoti.
Il deployment risultante è simile al seguente.
Routing del traffico con un NEG internet e TLS con SNI
Dopo aver configurato Cloud Service Mesh con un NEG internet utilizzando il nome di dominio completo e TLS per il traffico in uscita, il deployment di esempio si comporta come illustrato nel diagramma e nella descrizione seguenti del traffico.
I passaggi nella seguente legenda corrispondono alla numerazione nel diagramma precedente.
Passaggio | Descrizione |
---|---|
0 | Envoy riceve la configurazione backend del nome di dominio completo da Cloud Service Mesh tramite xDS. |
0 | Envoy, in esecuzione nella VM, interroga continuamente il DNS per trovare 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 (VIP) della regola di forwarding. Quando 0.0.0.0 è il VIP, Envoy intercetta tutte le richieste. Il routing delle richieste si basa solo sui parametri di livello 7, indipendentemente dall'indirizzo IP di destinazione nella richiesta originale generata dall'applicazione. |
4 | Envoy seleziona un endpoint remoto 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 è indicato nel diagramma, ma se vengono configurati controlli di integrità, Envoy controlla in modo continuo gli endpoint remoti e instrada le richieste solo verso endpoint integri.
Configura la connettività ibrida
Questo documento presuppone inoltre che la connettività ibrida sia già stata 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 regione riuscito, è abilitato il routing dinamico globale. Per ulteriori dettagli, consulta 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
in cui sono presenti record A
che puntano agli endpoint 10.0.0.100
, 10.0.0.101
, 10.0.0.102
e 10.0.0.103
.
gcloud
- Crea una zona privata gestita DNS e collegala alla rete predefinita:
gcloud dns managed-zones create example-zone \ --description=test \ --dns-name=example.com \ --networks=default \ --visibility=private
- Aggiungi 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
Configura Cloud Service Mesh con un NEG FQDN internet
In questa sezione configurerai Cloud Service Mesh con un NEG FQDN internet.
Crea il NEG, il controllo di integrità e il servizio di backend
gcloud
- Crea il NEG internet:
gcloud compute network-endpoint-groups create on-prem-service-a-neg \ --global \ --network-endpoint-type INTERNET_FQDN_PORT
- 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
- Crea un controllo di integrità globale:
gcloud compute health-checks create http service-a-http-health-check \ --global
- 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
- Aggiungi il NEG chiamato
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 delle regole di routing, che fornisce informazioni di routing per il traffico nel mesh.
Questa mappa URL contiene una regola che instrada tutto il traffico HTTP a
on-prem-service-a
.
gcloud
- Crea la mappa URL:
gcloud compute url-maps create td-url-map \ --default-service on-prem-service-a
- 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
- Crea la regola di forwarding globale utilizzando l'indirizzo IP
0.0.0.0
. Si tratta di un indirizzo IP speciale per cui il tuo piano dati ignora l'indirizzo IP di destinazione e instrada le richieste 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 e HTTPS non autenticati
Facoltativamente, se vuoi configurare HTTPS non autenticato tra i proxy Envoy e i servizi on-premise, utilizza queste istruzioni. Queste istruzioni mostrano inoltre come configurare SNI nell'handshake TLS.
Un criterio TLS client specifica il meccanismo di identità e autenticazione client quando un client invia richieste in uscita a un determinato servizio. Un criterio TLS del client è collegato a una risorsa del servizio di backend usando il campo securitySettings
.
gcloud
- Crea e importa il criterio TLS del client; imposta lo SNI sul nome di dominio completo che hai 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
- Se hai configurato un controllo di integrità
HTTP
con il servizio di backend nella sezione precedente, scollega il controllo di integrità dal servizio di backend:
gcloud compute backend-services update on-prem-service-a \ --global \ --no-health-checks
- Crea un controllo di integrità
HTTPS
:
gcloud compute health-checks create https service-a-https-health-check \ --global
- Collega il criterio TLS del client al servizio di backend che hai creato in precedenza. In questo modo viene applicato il protocollo HTTPS non autenticato su 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 esterni e interni risolvibili DNS o servizi Cloud Run.
Migrazione da un NEG IP:Port
a un NEG FQDN:Port
Il NEG NON_GCP_PRIVATE_IP_PORT
richiede la programmazione degli endpoint di servizio nel
NEG come coppie IP:PORT
statiche, mentre INTERNET_FQDN_NEG
consente la risoluzione
dinamica degli endpoint utilizzando il DNS. Puoi eseguire la migrazione al NEG internet configurando i record DNS per gli endpoint di servizio on-premise e configurando Cloud Service Mesh come descritto nei seguenti passaggi:
- Configura i record DNS per il tuo nome di dominio completo.
- Crea un nuovo NEG internet con il nome di dominio completo.
- Crea un nuovo servizio di backend con il NEG internet creato nel passaggio 2 come backend. Associare lo stesso controllo di integrità che hai utilizzato con il servizio di backend NEG di connettività ibrida al nuovo servizio di backend. Verifica che i nuovi endpoint remoti siano integri.
- Aggiorna la mappa delle regole di routing per fare riferimento al nuovo servizio di backend sostituendo il backend precedente che include il NEG di connettività ibrida.
- Se non vuoi tempi di inattività durante la migrazione live in un deployment di produzione, puoi utilizzare il traffico basato sulla ponderazione. Inizialmente, configura il nuovo servizio di backend in modo che riceva solo una piccola percentuale di traffico, ad esempio il 5%. Consulta le istruzioni per configurare la suddivisione del traffico.
- Verifica che i nuovi endpoint remoti stiano gestendo il traffico in modo corretto.
- Se utilizzi la suddivisione del traffico in base alla ponderazione, configura il nuovo servizio di backend in modo che riceva il 100% del traffico. Questo passaggio svuota il servizio di backend precedente.
- Dopo aver verificato che i nuovi backend stiano gestendo il traffico senza problemi, elimina il servizio di backend precedente.
Risoluzione dei problemi
Per risolvere i problemi di deployment, utilizza le istruzioni riportate in questa sezione. Se i problemi non vengono risolti con queste informazioni, consulta Risoluzione dei problemi dei deployment che utilizzano Envoy.
Un endpoint on-premise non riceve traffico
Se un endpoint non riceve traffico, assicurati che stia superando 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 carico del traffico
tra tutti gli endpoint risolti in stato integro. L'ordine in cui vengono risolti gli endpoint non ha importanza in modalità strict_dns
, ma Envoy svuota il traffico verso qualsiasi endpoint che non è più presente nell'elenco degli indirizzi IP restituiti.
L'intestazione dell'host HTTP non corrisponde al nome di dominio completo quando la richiesta raggiunge il server on-premise
Considera un esempio in cui il dominio example.com
viene risolto in 10.0.0.1
, ovvero l'indirizzo IP della regola di forwarding, e il dominio altostrat.com
viene risolto in 10.0.0.100
, che è l'endpoint di servizio on-premise. Vuoi inviare il traffico al dominio altostrat.com
, che è configurato nel tuo NEG.
È possibile che l'applicazione in Compute Engine o GKE imposti l'intestazione HTTP Host
su example.com
(Host:
example.com
), che viene riportata all'endpoint on-premise. Se utilizzi HTTPS, Envoy imposta il valore SNI su altostrat.com
durante l'handshake TLS.
Envoy recupera l'SNI dalla risorsa del criterio TLS del client.
Se questo conflitto causa problemi durante l'elaborazione o il routing della richiesta quando raggiunge l'endpoint on-premise, come soluzione alternativa puoi riscrivere l'intestazione Host
in altostrat.com
(Host: altostrat.com
). Questa operazione può essere eseguita in Cloud Service Mesh utilizzando la riscrittura degli URL oppure sull'endpoint remoto se dispone della funzionalità di riscrittura delle intestazioni.
Un'altra soluzione alternativa meno complessa è impostare l'intestazione Host
su altostrat.com
(Host: altostrat.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:
- Controlla i log di Envoy per capire se la risposta proviene dal backend (backend on-premise) e qual è la causa dell'errore 5xx.
- Assicurati che le query DNS abbiano esito positivo e che non siano presenti errori
SERVFAIL
oNXDOMAIN
. - 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 firewall sul lato di Google Cloud e 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 utilizzando i backend di FQDN in Cloud Service Mesh. 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:
- Assicurati di aver configurato le route corrette, in particolare la route predefinita
0.0.0.0/0
e le regole del firewall. - Assicurati che le query DNS abbiano esito positivo e che non siano presenti errori
SERVFAIL
oNXDOMAIN
. - 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 Cloud NAT o un altro mezzo per stabilire la connettività a internet in uscita.
Se gli errori persistono o se ricevi altri errori 5xx, controlla i log di Envoy per circoscrivere l'origine degli errori.
Impossibile raggiungere i servizi serverless dal mesh di servizi
Puoi inviare traffico ai servizi serverless (Cloud Run, Cloud Functions e App Engine) utilizzando i backend di dominio completo in Cloud Service Mesh. 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 scoprire di più sui criteri TLS del client, consulta Sicurezza del servizio Cloud Service Mesh e l'API Network Security.