configura backend esterni con gruppi di endpoint di rete internet
Questo documento fornisce le 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 è rivolto agli utenti che avere un livello di conoscenza da intermedio a avanzato di quanto segue:
Questa guida alla configurazione fornisce istruzioni di base per:
- Configurazione di Cloud Service Mesh per l'utilizzo di un NEG internet TLS non autenticato per il traffico in uscita
- Routing del traffico a un servizio Cloud Run dal mesh di servizi
Prima di iniziare
Esamina Cloud Service Mesh con endpoint di rete internet Panoramica dei gruppi.
Ai fini di questa guida, le configurazioni di esempio presuppongono quanto segue:
- Tutte le risorse Compute Engine pertinenti, come i proxy intermedi, Risorse Cloud Service Mesh, zone Cloud DNS e modello ibrido connettività, sono collegate al Virtual Private Cloud (VPC) predefinito in ogni rete.
- 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 garantiscono la connettività da che Envoy esegue il proxy verso questi endpoint remoti.
Il deployment risultante è simile al seguente.
Routing del traffico con NEG internet e TLS con SNI
Dopo aver configurato Cloud Service Mesh con un NEG internet utilizzando il nome di dominio completo e il protocollo TLS per il traffico in uscita, il deployment di esempio si comporta come a quelli illustrati nel seguente diagramma e nella descrizione del traffico.
I passaggi nella seguente legenda corrispondono alla numerazione nella precedente in questo diagramma.
Passaggio | Descrizione |
---|---|
0 | Envoy riceve la configurazione del backend FQDN da Cloud Service Mesh tramite xDS. |
0 | Envoy, in esecuzione sulla VM, esegue continuamente query sul DNS per il valore Nome di dominio completo. |
1 | L'applicazione utente avvia una richiesta. |
2 | Parametri della richiesta. |
3 | Il proxy Envoy intercetta la richiesta. L'esempio presuppone che
stai utilizzando 0.0.0.0 come IP virtuale della regola di forwarding
(VIP). Quando 0.0.0.0 è il VIP, Envoy intercetta tutti
richieste. Il routing delle richieste si basa solo sui parametri di livello 7
a prescindere dall'indirizzo IP di destinazione nella richiesta originale.
generati 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 è mostrato nel diagramma, ma se sono configurati i controlli di integrità, Envoy esegue controlli di integrità continui e instrada gli endpoint remoti e instrada le richieste solo endpoint integri.
Configura la connettività ibrida
Questo documento presuppone inoltre che la connettività ibrida sia già stata stabilita:
- Connettività ibrida tra la rete VPC e on-premise servizi o un cloud pubblico di terze parti con Cloud VPN e Cloud Interconnect.
- Le regole e le route del firewall VPC sono configurate correttamente su stabilire una connettività bidirezionale da Envoy al servizio privato e, facoltativamente, a un server DNS on-premise.
- Per uno scenario di failover ad alta disponibilità a livello di regione, il routing dinamico globale in un bucket in cui è abilitato il controllo delle versioni. Per maggiori dettagli, vedi Routing dinamico .
Imposta la configurazione di Cloud DNS
Utilizza i comandi seguenti per configurare una zona privata di Cloud DNS per
dominio (FQDN) example.com
con A
record che puntano a endpoint
10.0.0.100
, 10.0.0.101
, 10.0.0.102
e 10.0.0.103
.
gcloud
- 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
- 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
Configura Cloud Service Mesh con un NEG FQDN internet
In questa sezione configurerai Cloud Service Mesh con un FQDN internet NEG.
Crea il servizio NEG, controllo di integrità e 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 eseguire il 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 denominato
on-prem-service-a-neg
come backend del backend servizio:
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 regola di routing che fornisce informazioni sui percorsi per il traffico nella tua rete 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 alla destinazione. proxy:
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 instradare le richieste in base solo Parametri HTTP.
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 desideri configurare HTTPS non autenticato tra il tuo Envoy proxy e dei servizi on-premise, usa queste istruzioni. Questi le istruzioni spiegano anche come configurare SNI nel TLS handshake.
Un criterio TLS del client specifica l'identità del client e il meccanismo di autenticazione
quando un client invia richieste in uscita a un determinato servizio. Il protocollo TLS di un client
è collegato a una risorsa del servizio di backend utilizzando l'istruzione securitySettings
.
gcloud
- Creare e importare il criterio TLS del client. imposta l'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
- Se hai configurato un controllo di integrità
HTTP
con il servizio di backend nella 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; Questa operazione applica 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 oppure dai servizi Cloud Run.
Esegui la migrazione da un NEG IP:Port
a un NEG FQDN:Port
NON_GCP_PRIVATE_IP_PORT
NEG richiede la programmazione degli endpoint di servizio nel
NEG come coppie statiche IP:PORT
, mentre INTERNET_FQDN_NEG
consente agli endpoint
e risolti in modo dinamico
tramite il DNS. Puoi eseguire la migrazione al NEG internet
impostare i record DNS per gli endpoint dei servizi on-premise e configurare
Cloud Service Mesh, come descritto nei passaggi seguenti:
- 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 che hai creato nel passaggio 2 come backend. Associa lo stesso controllo di integrità utilizzato alla servizio di backend NEG di connettività ibrida con il nuovo servizio di backend. Verifica che i nuovi endpoint remoti siano integri.
- Aggiorna la mappa di regole di routing per fare riferimento al nuovo servizio di backend in base a sostituendo il backend precedente che include il NEG di connettività ibrida.
- Per evitare tempi di inattività durante la migrazione live in un deployment di produzione,
puoi usare il traffico basato sulla ponderazione. Innanzitutto, configura il nuovo backend
di Google Cloud in modo da ricevere solo una piccola percentuale di traffico, ad esempio il 5%. Utilizza le funzionalità di
le istruzioni per la configurazione del traffico
dei dati.
- Verifica che i nuovi endpoint remoti gestiscano correttamente il traffico.
- Se utilizzi la suddivisione del traffico basata sulla ponderazione, configura il nuovo backend per ricevere il 100% del traffico. Questo passaggio svuota il backend precedente completamente gestito di Google Cloud.
- Dopo aver verificato che i nuovi backend gestiscono il traffico senza per risolvere i problemi, elimina il vecchio servizio di backend.
Risoluzione dei problemi
Per risolvere i problemi di deployment, utilizza le istruzioni riportate in questa sezione. Se le tue non vengono risolti con queste informazioni; consulta Risoluzione dei problemi relativi alle implementazioni che utilizzano Envoy.
Un endpoint on-premise non riceve traffico
Se un endpoint non riceve traffico, assicurati che superi l'integrità controlli e che le query DNS dal client Envoy restituiscano il suo indirizzo IP costantemente.
Envoy utilizza la modalità strict_dns
per gestire le connessioni. Bilancia il carico del traffico
in tutti gli endpoint risolti che sono integri. L'ordine in cui gli endpoint vengono
risolto non importa in modalità strict_dns
, ma Envoy svuota il traffico verso qualsiasi
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
,
che corrisponde all'indirizzo IP della regola di forwarding e il dominio altostrat.com
si risolve in 10.0.0.100
, che è il tuo endpoint di servizio on-premise. Vuoi
per inviare traffico al dominio altostrat.com
, che è configurato nel NEG.
È possibile che l'applicazione in Compute Engine
GKE imposta l'intestazione Host
HTTP su example.com
(Host:
example.com
), che viene trasferita all'endpoint on-premise. Se
utilizzano HTTPS, Envoy imposta lo SNI su altostrat.com
durante l'handshake TLS.
Envoy ottiene lo SNI dalla risorsa del criterio 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 il Host
a altostrat.com
(Host: altostrat.com
). Questa operazione può essere eseguita in
Cloud Service Mesh utilizzando la riscrittura dell'URL o 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 utilizza l'indirizzo speciale 0.0.0.0
come inoltro
l'indirizzo IP della regola.
Envoy restituisce molti errori 5xx
Se Envy restituisce un numero eccessivo di errori 5xx, procedi come segue:
- Controlla i log di Envoy per capire se la risposta proviene dal (backend on-premise) e la causa dell'errore 5xx.
- Assicurati che le query DNS abbiano esito positivo e che non siano presenti
SERVFAIL
oNXDOMAIN
errori. - 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 raggiungibile da Envoy. Controlla le regole e le route del firewall sul lato 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 il nome di dominio completo
in Cloud Service Mesh. Devi prima stabilire una connessione
e la connettività tra i client Envoy e il servizio esterno. Se ricevi
un errore 502
durante le connessioni al servizio esterno, segui questi passaggi:
- Assicurati di avere le route corrette, in particolare quella predefinita
0.0.0.0/0
e regole firewall configurate. - Assicurati che le query DNS abbiano esito positivo e che non siano presenti
SERVFAIL
oNXDOMAIN
errori. - Se il proxy Envoy è in esecuzione su una VM di Compute Engine che non un indirizzo IP esterno o un cluster GKE privato, configurare Cloud NAT o un altro metodo per stabilire le connessioni in uscita la connessione a internet.
Se gli errori persistono o se ricevi altri errori 5xx, controlla Envoy per restringere l'origine degli errori.
Impossibile raggiungere i servizi serverless dal mesh di servizi
Puoi inviare il traffico al serverless (Cloud Run, Cloud Functions e App Engine) mediante backend FQDN in Cloud Service Mesh. Se il proxy Envoy è in esecuzione su un a una VM di Compute Engine che non ha un indirizzo IP esterno o cluster GKE privato, devi configurare Accesso privato Google sulla subnet per poter accedere alle API di Google e i servizi di machine learning.
Passaggi successivi
- Per saperne di più sui criteri TLS del client, consulta Cloud Service Mesh la sicurezza dei servizi e nella sezione Sicurezza di rete all'API.