Cloud Service Mesh con gruppi di endpoint di rete internet

Puoi configurare Cloud Service Mesh in modo da utilizzare gruppi di endpoint di rete (NEG) internet di tipo INTERNET_FQDN_PORT. Il servizio esterno è rappresentato dal suo nome di dominio completo (FQDN) e dal numero di porta nel NEG. Il NEG può contenere una sola coppia FQDN:Port e il servizio di backend può contenere un solo NEG di questo tipo. L'FQDN viene risolto utilizzando l'ordine di risoluzione dei nomi della rete Virtual Private Cloud (VPC) sottostante.

Espandere il mesh di servizi Cloud Service Mesh utilizzando backend FQDN

Il mesh di servizi Cloud Service Mesh può indirizzare il traffico verso servizi privati che sono raggiungibili utilizzando la connettività ibrida, inclusi servizi on-premise, multi-cloud e internet denominati. Il servizio remoto viene fatto riferimento dal relativo FQDN.

Estensione del mesh di servizi Cloud Service Mesh a località on-premise o multi-cloud utilizzando backend FQDN tramite connettività ibrida.
Espansione del mesh di servizi Cloud Service Mesh a località on-premise o multi-cloud utilizzando backend FQDN tramite connettività ibrida (fai clic per ingrandire)

Puoi anche indirizzare il traffico a servizi raggiungibili tramite internet pubblico.

Estensione del mesh di servizi Cloud Service Mesh a un servizio internet che utilizza backend FQDN.
Espansione del mesh di servizi Cloud Service Mesh a un servizio internet che utilizza backend FQDN (fai clic per ingrandire)

Risorse e architettura di Google Cloud

Questa sezione descrive le risorse e l'architettura per la configurazione di Cloud Service Mesh con un NEG su internet.

INTERNET_FQDN_PORT gruppo di endpoint di rete

Per instradare il traffico a un servizio esterno a cui viene fatto riferimento tramite il relativo FQDN, utilizza il NEG internet globale di tipo INTERNET_FQDN_PORT. Il file NEG contiene l'FQDN del servizio e il relativo numero di porta. Cloud Service Mesh programma il FQDN nei proxy Envoy utilizzando la configurazione xDS.

Cloud Service Mesh stesso non garantisce la risoluzione dei nomi e la raggiungibilità degli endpoint remoti. L'FQDN deve essere risolvibile dall'ordine di risoluzione dei nomi della rete VPC a cui sono collegati i proxy Envoy e gli endpoint risolti devono essere raggiungibili dai proxy Envoy.

Controlli di integrità

Il comportamento dei controlli di integrità per gli endpoint di rete di tipo INTERNET_FQDN_PORT è diverso da quello per altri tipi di endpoint di rete utilizzati con Cloud Load Balancing e Cloud Service Mesh. Sebbene la maggior parte degli altri tipi di endpoint di rete utilizzi il sistema di controllo dell'integrità centralizzato di Google Cloud, i NEG utilizzati per gli endpoint in ambienti multi-cloud (INTERNET_FQDN_PORT e NON_GCP_PRIVATE_IP_PORT) utilizzano il meccanismo di controllo dell'integrità distribuito di Envoy.

Envoy supporta i seguenti protocolli per i controlli di integrità:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

Configura i controlli di integrità utilizzando le API Compute Engine.

Considerazioni sul DNS

Esistono due aspetti distinti da considerare in merito al DNS:

  • Il server DNS che ospita i record di risorse del tuo servizio esterno.
  • La modalità con cui il proxy Envoy è configurato per utilizzare il DNS per la gestione delle connessioni.

Server Cloud DNS

Puoi creare una zona privata gestita Cloud DNS per ospitare i record DNS nel tuo progetto Google Cloud. Puoi anche utilizzare altre funzionalità di Cloud DNS, come le zone di inoltro, per recuperare i record da un server DNS on-premise.

Modalità DNS di Envoy

La modalità DNS di Envoy, chiamata anche service discovery, specifica in che modo il proxy Envoy utilizza i record DNS per gestire le connessioni in uscita. Cloud Service Mesh configura Envoy in modo che utilizzi la modalità DNS rigorosa. La modalità DNS rigorosa abilita il bilanciamento del carico su tutti gli endpoint risolti. Tiene conto dello stato controllo di integrità e svuota le connessioni agli endpoint non operativi o che non vengono più risolti utilizzando il DNS. Non puoi modificare questa modalità.

Per ulteriori informazioni sul Service Discovery, consulta la documentazione di Envoy.

Connettività e routing

Se indirizzi il traffico a un servizio privato, di seguito sono riportati i requisiti per la connettività di rete sottostante:

  • La connettività ibrida tra la rete VPC e il data center on-premise o il cloud pubblico di terze parti viene stabilita utilizzando 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, se applicabile, al server DNS on-premise.
  • Per un failover ad alta disponibilità a livello di regione, il routing dinamico globale deve essere abilitato. Per maggiori dettagli, consulta la modalità di routing dinamico.

Se indirizzi il traffico a un servizio esterno accessibile su internet, i requisiti sono i seguenti:

  • Le istanze di macchine virtuali (VM) client nella rete VPC devono avere un indirizzo IP esterno o Cloud NAT.
  • La route predefinita deve essere presente per il traffico in uscita su internet.

In entrambi i casi precedenti, il traffico utilizza il routing della rete VPC.

Sicurezza

I backend FQDN sono compatibili con le API e le funzionalità di sicurezza di Cloud Service Mesh. Nelle connessioni in uscita al servizio esterno, puoi configurare il FQDN nell'intestazione SNI utilizzando i criteri TLS client.

Limitazioni e considerazioni

  • I NEG di internet di tipo INTERNET_IP_PORT non sono supportati con Cloud Service Mesh.
  • Con i backend FQDN è necessaria la versione 1.15.0 o successive di Envoy.
  • Utilizza l'interfaccia a Google Cloud CLI o le API REST per configurare Cloud Service Mesh. La configurazione end-to-end tramite la console Google Cloud non è supportata.
  • I backend FQDN sono supportati solo con Envoy. gRPC senza proxy non è supportato.

  • Quando utilizzi il tipo NEG INTERNET_FQDN_PORT con Cloud Service Mesh, i controlli di stato degli endpoint remoti vengono eseguiti utilizzando il meccanismo di controllo di stato distribuito di Envoy. Ogni volta che viene aggiunto un nuovo endpoint remoto, tutti i proxy Envoy avviano il controllo di integrità in modo indipendente.

    Analogamente, quando un nuovo proxy Envoy viene aggiunto alla mesh, inizia a controllare tutti gli endpoint remoti. Pertanto, a seconda del numero di proxy Envoy e endpoint remoti nel tuo deployment, il mesh di controllo di integrità risultante potrebbe causare un traffico di rete significativo e un carico eccessivo sugli endpoint remoti. Puoi scegliere di non configurare i controlli di integrità.

  • Lo stato del controllo dell'integrità non è visibile nella console Google Cloud per i backend FQDN.

  • I controlli di integrità che utilizzano i protocolli UDP, SSL e gRPC non sono supportati.

  • Le seguenti opzioni di controllo di integrità non sono supportate:

    • Controllo di integrità HTTP/HTTP2/HTTPS
      • --proxy-header
      • --response
    • Controllo di integrità TCP
      • --proxy-header
      • --request
      • --response

Passaggi successivi