Traffic Director con gruppi di endpoint di rete internet

Puoi configurare Traffic Director in modo che utilizzi gruppi di endpoint di rete internet (NEG) 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 solo un NEG di questo tipo. Il nome di dominio completo viene risolto utilizzando l'ordine di risoluzione dei nomi della rete Virtual Private Cloud (VPC) sottostante.

Espandi il mesh di servizi Traffic Director utilizzando i backend di FQDN

Il mesh di servizi Traffic Director può instradare il traffico a servizi privati raggiungibili mediante connettività ibrida, inclusi servizi denominati on-premise, multi-cloud e internet. Il servizio remoto è indicato dal rispettivo nome di dominio completo.

Estensione del mesh di servizi Traffic Director a località on-premise o multi-cloud utilizzando i backend di FQDN tramite la connettività ibrida.
Estensione del mesh di servizi Traffic Director a località on-premise o multi-cloud utilizzando i backend di FQDN rispetto alla connettività ibrida (fai clic per ingrandire)

Puoi anche instradare il traffico a servizi raggiungibili tramite la rete internet pubblica.

Estensione del mesh di servizi Traffic Director a un servizio internet utilizzando i backend FQDN.
Estensione del mesh di servizi Traffic Director a un servizio internet utilizzando i backend FQDN (fai clic per ingrandire)

Risorse e architettura di Google Cloud

Questa sezione descrive le risorse e l'architettura per la configurazione di Traffic Director con un NEG internet.

INTERNET_FQDN_PORT gruppo di endpoint di rete

Per instradare il traffico a un servizio esterno a cui fa riferimento il rispettivo nome di dominio completo, utilizza il NEG internet globale di tipo INTERNET_FQDN_PORT. Il NEG contiene il nome di dominio completo del servizio e il relativo numero di porta. Traffic Director programma il nome di dominio completo nei proxy Envoy utilizzando la configurazione xDS.

Traffic Director non garantisce la risoluzione dei nomi e la raggiungibilità degli endpoint remoti. Il nome di dominio completo 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 del controllo di integrità per gli endpoint di rete del tipo INTERNET_FQDN_PORT è diverso da quello del controllo di integrità per altri tipi di endpoint di rete utilizzati con Cloud Load Balancing e Traffic Director. Mentre la maggior parte degli altri tipi di endpoint di rete utilizza il sistema centralizzato di controllo di integrità 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 il controllo di integrità:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

Puoi configurare i controlli di integrità utilizzando le API Compute Engine.

Considerazioni sul DNS

Esistono due considerazioni distinte riguardo 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 inoltre utilizzare altre funzionalità di Cloud DNS, ad esempio le zone di inoltro, per recuperare i record da un server DNS on-premise.

Modalità DNS Envoy

La modalità DNS di Envoy, chiamata anche rilevamento dei servizi, specifica in che modo il proxy Envoy utilizza i record DNS per gestire le connessioni in uscita. Traffic Director configura Envoy per l'utilizzo della modalità DNS rigida. La modalità DNS rigorosa consente il bilanciamento del carico a tutti gli endpoint risolti. Consente di rispettare lo stato del controllo di integrità ed svuotare le connessioni agli endpoint non integri o non più risolti tramite DNS. Non puoi modificare questa modalità.

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

Connettività e routing

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

  • 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 firewall VPC sono configurate correttamente per stabilire la connettività bidirezionale da Envoy ai tuoi endpoint di servizio privati e, se applicabile, al server DNS on-premise.
  • Per il failover di alta disponibilità a livello di regione, è necessario abilitare il routing dinamico globale. Per ulteriori dettagli, consulta Modalità di routing dinamico.

Se esegui il routing del traffico a un servizio esterno raggiungibile 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 verso internet.

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

Sicurezza

I backend FQDN sono compatibili con le funzionalità di sicurezza di Traffic Director e le API. Sulle connessioni in uscita verso il servizio esterno, puoi configurare il nome di dominio completo nell'intestazione SNI utilizzando i criteri TLS del client.

Limitazioni e considerazioni

  • I NEG internet del tipo INTERNET_IP_PORT non sono supportati con Traffic Director.
  • Con i backend FQDN è necessaria la versione 1.15.0 o successiva di Envoy.
  • Utilizza Google Cloud CLI o le API REST per configurare Traffic Director. La configurazione end-to-end mediante la console Google Cloud non è supportata.
  • I backend di nome di dominio completo sono supportati solo con Envoy. gRPC senza proxy non è supportato.

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

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

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

  • Il controllo di integrità che utilizza i protocolli UDP, SSL e gRPC non è supportato.

  • 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