Configurare i backend esterni con i gruppi di endpoint di rete internet

Questo documento fornisce istruzioni per la configurazione di backend esterni per Cloud Service Mesh utilizzando gruppi di endpoint di rete (NEG) di internet, che richiedono un nome di dominio completo. Questo documento è rivolto agli utenti che hanno un livello di familiarità intermedio o avanzato con quanto segue:

Questa guida alla configurazione fornisce istruzioni di base per quanto segue:

  • Configurazione di Cloud Service Mesh per l'utilizzo di un NEG di internet e TLS non autenticato per il traffico in uscita
  • Instradare il traffico a un servizio Cloud Run dal tuo mesh di servizi

Prima di iniziare

Consulta la panoramica di Cloud Service Mesh con 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 i proxy intermedi, le risorse Cloud Service Mesh, le zone Cloud DNS e la connettività ibrida, sono collegate alla rete Virtual Private Cloud (VPC) predefinita.
  • Il servizio example.com:443 è in esecuzione nella tua infrastruttura on-premise. Il dominio example.com è servito 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.

Configurazione di esempio con un NEG internet.
Configurazione di esempio con un NEG internet (fai clic per ingrandire)

Routing del traffico con un NEG internet e TLS con SNI

Dopo aver configurato Cloud Service Mesh con un NEG internet utilizzando il FQDN e TLS per il traffico in uscita, il deployment di esempio si comporta come illustrato nel seguente diagramma e nella descrizione del traffico.

La modalità di routing del traffico nell'esempio.
Come viene indirizzato il traffico nell'esempio (fai clic per ingrandire)

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

Passaggio Descrizione
0 Envoy riceve la configurazione del backend FQDN da Cloud Service Mesh tramite xDS.
0 Envoy, in esecuzione nella VM, esegue continuamente query sul DNS per l'FQDN configurato.
1 L'applicazione dell'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 funzionante ed esegue un handshake TLS con l'SNI ottenuto dal criterio TLS del client.
5 Envoy esegue il proxy della richiesta all'endpoint remoto.

Non è mostrato nel diagramma, ma se i controlli di integrità sono configurati, Envoy esamina continuamente gli endpoint remoti e instrada le richieste solo agli endpoint integri.

Configura la 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 del firewall VPC sono configurate correttamente per stabilire la raggiungibilità bidirezionale da Envoy agli endpoint dei servizi privati e, facoltativamente, a un server DNS on-premise.
  • Per uno scenario di failover HA regionale riuscito, il routing dinamico globale è attivo. Per maggiori dettagli, vedi Modalità di routing dinamico.

Configurazione di Cloud DNS

Utilizza i seguenti comandi per configurare una zona privata Cloud DNS per il dominio (FQDN) example.com con record A che rimandano 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
  1. 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 Cloud Service Mesh con un NEG FQDN internet

In questa sezione, configuri Cloud Service Mesh con un FQDN internet NEG.

Crea il NEG, il controllo di integrità e il servizio di 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
  1. 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
  1. Crea un controllo di integrità globale:
    gcloud compute health-checks create http service-a-http-health-check \
        --global
  1. 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
  1. 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 regola di forwarding costituiscono una mappa di regole di routing che fornisce informazioni di routing per il traffico nella tua mesh.

Questa mappa 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
  1. 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
  1. 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 piano dati ignori l'indirizzo IP di destinazione e indirizzi le richieste in base solo 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

Configurare TLS e HTTPS non autenticati

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

Un criterio TLS 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 client viene associato a una risorsa di servizio di backend utilizzando il campo securitySettings.

gcloud

  1. Crea e importa la policy TLS del client; imposta l'SNI sul FQDN 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
  1. Se nella sezione precedente hai configurato un controllo di integrità HTTP con il servizio di backend, scollega il controllo di integrità dal servizio di backend:
    gcloud compute backend-services update on-prem-service-a \
        --global \
        --no-health-checks
  1. Crea un controllo di integrità HTTPS:
    gcloud compute health-checks create https service-a-https-health-check \
        --global
  1. Collega il criterio TLS del client al servizio di backend creato precedentemente. In questo modo, viene applicato 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 di internet per instradare il traffico verso qualsiasi servizio raggiungibile tramite FQDN, ad esempio servizi interni ed esterni risolvibili tramite DNS o servizi Cloud Run.

Eseguire la migrazione da un NEG IP:Port a un NEG FQDN:Port

Il NEG NON_GCP_PRIVATE_IP_PORT richiede di programmare gli endpoint di servizio nel NEG come coppie IP:PORT statiche, mentre INTERNET_FQDN_NEG consente di risolvere gli endpoint in modo dinamico utilizzando il DNS. Puoi eseguire la migrazione al NEG su internet impostando i record DNS per gli endpoint di servizio on-premise e configurando Cloud Service Mesh come descritto nei passaggi che seguono:

  1. Configura i record DNS per il tuo FQDN.
  2. Crea un nuovo NEG internet con l'FQDN.
  3. Crea un nuovo servizio di backend con il NEG internet che hai creato nel passaggio 2 come backend. Associa lo stesso controllo di integrità che hai utilizzato con il servizio di backend NEG per la connettività ibrida al nuovo servizio di backend. Verifica che i nuovi endpoint remoti siano operativi.
  4. Aggiorna la mappa delle regole di routing in modo da fare riferimento al nuovo servizio di backend, sostituendo il vecchio backend che include il NEG di connettività ibrida.
  5. Se vuoi evitare tempi di riposo durante la migrazione in produzione, puoi utilizzare il traffico basato sul peso. 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.
    1. Verifica che i nuovi endpoint remoti gestiscano correttamente il traffico.
  6. Se utilizzi la suddivisione del traffico in base al peso, configura il nuovo servizio di backend in modo che riceva il 100% del traffico. Questo passaggio svuota il vecchio servizio di backend.
  7. Dopo aver verificato che i nuovi backend gestiscono il traffico senza problemi, elimina il vecchio servizio di backend.

Risoluzione dei problemi

Per risolvere i problemi di implementazione, segui le istruzioni riportate in questa sezione. Se i problemi non vengono risolti con queste informazioni, consulta la sezione Risoluzione dei problemi di implementazione 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 carico del traffico su tutti gli endpoint risolti che sono integri. L'ordine in cui gli endpoint vengono risolti non è importante in modalità strict_dns, ma Envoy scarica il traffico su qualsiasi endpoint non più presente nell'elenco degli indirizzi IP restituiti.

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

Prendiamo l'esempio in cui il dominio example.com si risolve in 10.0.0.1, che è l'indirizzo IP della regola di forwarding, e il dominio altostrat.com si risolve in 10.0.0.100, che è l'endpoint del servizio on-premise. Vuoi inviare traffico al dominio altostrat.com, 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 l'SNI su altostrat.com durante l'handshake TLS. Envoy ottiene l'SNI dalla risorsa della policy TLS del client.

Se questo conflitto causa problemi di elaborazione o instradamento 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 dell'URL o nell'endpoint remoto se dispone della funzionalità di riscrittura dell'intestazione.

Un'altra soluzione alternativa meno complessa consiste nell'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 inoltro.

Envoy restituisce molti errori 5xx

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

  • Controlla i log di Envoy per distinguere se la risposta proviene dal backend (backend on-premise) e qual è il motivo dell'errore 5xx.
  • Assicurati che le query DNS siano andate a buon fine e che non siano presenti 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 accessibili da Envoy. Controlla le regole e le route del firewall sia sul lato Google Cloud sia su quello on-premise.

Impossibile raggiungere i servizi esterni tramite internet pubblico dal mesh di servizi

Puoi inviare traffico ai servizi situati sulla rete internet pubblica utilizzando i backend FQDN in Cloud Service Mesh. Devi prima stabilire la connettività internet tra i client Envoy e il servizio esterno. Se ricevi un messaggio di errore 502 durante le connessioni al servizio esterno:

  • Assicurati di avere configurato le route corrette, in particolare la route predefinita0.0.0.0/0, e le regole firewall.
  • Assicurati che le query DNS siano andate a buon fine e che non siano presenti errori SERVFAIL o NXDOMAIN.
  • Se il proxy Envoy è in esecuzione su una VM 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à internet in uscita.

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

Impossibile raggiungere i servizi serverless dal mesh di servizi

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

Passaggi successivi