Cloud Service Mesh con gruppi di endpoint di rete con connettività ibrida

Cloud Service Mesh supporta ambienti che si estendono oltre Google Cloud, inclusi data center on-premise e altri cloud pubblici che puoi utilizzare connettività ibrida per raggiungere.

Configura Cloud Service Mesh in modo che il mesh di servizi possa inviare traffico agli endpoint esterni a Google Cloud. Questi endpoint includono i seguenti:

  • Bilanciatori del carico on-premise.
  • Applicazioni server su un'istanza di macchina virtuale (VM) in un altro cloud.
  • Qualsiasi altra destinazione raggiungibile con la connettività ibrida e raggiungibile con un indirizzo IP e una porta.

Aggiungi l'indirizzo IP e la porta di ogni endpoint a un gruppo di endpoint di rete con connettività ibrida (NEG). I NEG di connettività ibrida sono di tipo NON_GCP_PRIVATE_IP_PORT.

Il supporto di Cloud Service Mesh per i servizi on-premise e multi-cloud ti consente di:

  • Instrada il traffico a livello globale, inclusi gli endpoint dei servizi on-premise e multi-cloud.
  • Porta i vantaggi di Cloud Service Mesh e mesh di servizi, incluse funzionalità come l'Service Discovery e la gestione avanzata del traffico, ai servizi in esecuzione sulla tua infrastruttura esistente al di fuori di Google Cloud.
  • Combina le funzionalità di Cloud Service Mesh con Cloud Load Balancing per portare Google Cloud i servizi di rete in più ambienti.

I NEG di connettività ibrida (NEG NON_GCP_PRIVATE_IP_PORT) non sono supportati con i client gRPC senza proxy.

Casi d'uso

Cloud Service Mesh può configurare la rete tra servizi basati su VM e container in più ambienti, tra cui:

  • Google Cloud
  • Data center on-premise
  • Altri cloud pubblici

Instradare il traffico mesh a una posizione on-premise o a un altro cloud

Il caso d'uso più semplice per questa funzionalità è il routing del traffico. La tua applicazione esegue un proxy Envoy di Cloud Service Mesh . Cloud Service Mesh comunica al client i tuoi servizi e gli endpoint di ciascun servizio.

Instradamento del traffico mesh a una posizione on-premise o a un altro cloud.
Routing del traffico mesh a una posizione on-premise o a un altro cloud (fai clic per ingrandire)

Nel diagramma precedente, quando l'applicazione invia una richiesta al servizio on-prem, il client Cloud Service Mesh esamina la richiesta in uscita e ne aggiorna la destinazione. La destinazione viene impostata su un endpoint associato al servizio on-prem (in questo caso, 10.2.0.1). La richiesta viene quindi inviata tramite Cloud VPN o Cloud Interconnect alla destinazione prevista.

Se devi aggiungere altri endpoint, aggiorna Cloud Service Mesh per aggiungerli al tuo servizio. Non devi modificare il codice dell'applicazione.

Eseguire la migrazione di un servizio on-premise esistente a Google Cloud

L'invio di traffico a un endpoint nonGoogle Cloud consente di instradare il traffico verso altri ambienti. Puoi combinare questa funzionalità con la gestione avanzata del traffico per eseguire la migrazione dei servizi tra gli ambienti.

Eseguire la migrazione da una posizione on-premise a Google Cloud.
Migrazione da una posizione on-premise a Google Cloud (fai clic per ingrandire)

Il diagramma precedente estende il pattern precedente. Anziché configurare Cloud Service Mesh per inviare tutto il traffico al servizio on-prem, configuri Cloud Service Mesh per utilizzare la suddivisione del traffico basata sul peso per dividere il traffico tra due servizi.

La suddivisione del traffico ti consente di iniziare inviando lo 0% del traffico al servizio cloud e il 100% al servizio on-prem. Puoi quindi aumentare gradualmente la proporzione di traffico inviato al servizio cloud. Alla fine, invii il 100% del traffico al servizio cloud e puoi ritirare il servizio on-prem.

Google Cloud Servizi del perimetro della rete per deployment on-premise e multi-cloud

Infine, puoi combinare questa funzionalità con le soluzioni di rete esistenti di Google Cloud. Google Cloud offre un'ampia gamma di servizi di rete, come il bilanciamento del carico esterno globale con Google Cloud Armor per la protezione dagli attacchi DDoS (distributed denial-of-service), che puoi utilizzare con Cloud Service Mesh per aggiungere nuove funzionalità ai tuoi servizi on-premise o multicloud. La cosa migliore è che non devi esporre questi servizi on-premise o multicloud all'internet pubblico.

Deployment che interessano più ambienti.
Deployment che interessano più ambienti (fai clic per ingrandire)

Nel diagramma precedente, il traffico proveniente dai client su internet pubblico entra nella rete diGoogle Cloudda un bilanciatore del carico Google Cloud , ad esempio il nostro bilanciatore del carico delle applicazioni esterno globale. Quando il traffico raggiunge il bilanciatore del carico, puoi applicare servizi edge di rete come la protezione DDoS di Cloud Armor o l'autenticazione utente di Identity-Aware Proxy (IAP). Per saperne di più, consulta Servizi del perimetro della rete per deployment multiambiente.

Dopo aver applicato questi servizi, il traffico si ferma brevemente in Google Cloud, dove un'applicazione o un proxy autonomo (configurato da Cloud Service Mesh) inoltra il traffico tramite Cloud VPN o Cloud Interconnect al tuo servizio on-premise.

Google Cloud risorse e architettura

Questa sezione fornisce informazioni di base sulle risorse Google Cloud che puoi utilizzare per fornire un mesh di servizi gestito da Cloud Service Mesh per ambienti on-premise e multi-cloud.

Il seguente diagramma mostra le risorse Google Cloud che consentono il supporto dei servizi on-premise e multi-cloud per Cloud Service Mesh. La risorsa chiave è il NEG e i relativi endpoint di rete. Le altre risorse sono quelle che configuri nell'ambito di una configurazione standard di Cloud Service Mesh. Per semplicità, il diagramma non mostra opzioni come più servizi di backend globali.

Risorse Compute Engine per servizi on-premise e multicloud.
Risorse di Compute Engine per servizi on-premise e multicloud (fai clic per ingrandire)

Quando configuri Cloud Service Mesh, utilizzi la risorsa API dei servizi di backend globali per creare servizi. Un servizio è un costrutto logico che combina quanto segue:

  1. Norme da applicare quando un client tenta di inviare traffico al servizio.
  2. Uno o più backend o endpoint che gestiscono il traffico destinato al servizio.

I servizi on-premise e multicloud sono come qualsiasi altro servizio che Cloud Service Mesh configura. La differenza principale è che utilizzi un NEG di connettività ibrida per configurare gli endpoint di questi servizi. Questi NEG hanno il tipo di endpoint di rete impostato su NON_GCP_PRIVATE_IP_PORT. Gli endpoint che aggiungi ai NEG di connettività ibrida devono essere combinazioni IP:port valide che i tuoi client possono raggiungere, ad esempio tramite connettività ibrida come Cloud VPN o Cloud Interconnect.

Ogni NEG ha un tipo di endpoint di rete e può contenere solo endpoint di rete dello stesso tipo. Questo tipo determina quanto segue:

  • La destinazione a cui i tuoi servizi possono inviare traffico.
  • Comportamento di controllo di integrità.

Quando crei il NEG, configuralo nel seguente modo per poter inviare il traffico a una destinazione on-premise o multi-cloud.

  • Imposta il tipo di endpoint di rete su NON_GCP_PRIVATE_IP_PORT. Questo rappresenta un indirizzo IP raggiungibile. Se questo indirizzo IP si trova on-premise o presso un altro cloud provider, deve essere raggiungibile da Google Cloud utilizzando la connettività ibrida, ad esempio quella fornita da Cloud VPN o Cloud Interconnect.
  • Specifica una Google Cloud zona che riduca al minimo la distanza geografica tra Google Cloud e il tuo ambiente on-premise o multicloud. Ad esempio, se ospiti un servizio in un ambiente on-premise a Francoforte, in Germania, puoi specificare la zona europe-west3-a Google Cloud quando crei il gruppo di elenchi di esclusione.

Il comportamento di controllo dell'integrità per gli endpoint di rete di questo tipo è diverso da quello per altri tipi di endpoint di rete. Mentre altri tipi di endpoint di rete utilizzano il sistema di controllo di integrità centralizzato di Google Cloud, gli endpoint di rete NON_GCP_PRIVATE_IP_PORT utilizzano il meccanismo di controllo di integrità distribuito di Envoy. Per ulteriori dettagli, consulta la sezione Limitazioni e altre considerazioni.

Considerazioni sulla connettività e sul networking

I client Cloud Service Mesh, come i proxy Envoy, devono essere in grado di connettersi a Cloud Service Mesh all'indirizzo trafficdirector.googleapis.com:443. Se perdi la connettività al control plane di Cloud Service Mesh, si verifica quanto segue:

  • I client Cloud Service Mesh esistenti non possono ricevere aggiornamenti della configurazione da Cloud Service Mesh. e continuano a funzionare in base alla configurazione attuale.
  • I nuovi client Cloud Service Mesh non possono connettersi a Cloud Service Mesh. Non possono utilizzare ilmesh di servizih finché non viene ristabilita la connettività.

Se vuoi inviare traffico tra Google Cloud e ambienti on-premise o multi-cloud, gli ambienti devono essere connessi tramite connettività ibrida. Ti consigliamo una connessione ad alta disponibilità abilitata da Cloud VPN o Cloud Interconnect.

Gli indirizzi IP e gli intervalli di indirizzi IP on-premise, di altri cloud e di subnet non devono sovrapporsi. Google Cloud

Limitazioni e altre considerazioni

Di seguito sono riportate le limitazioni dell'utilizzo dei NEG di connettività ibrida.

Impostazione di proxyBind

Puoi impostare il valore di proxyBind solo quando crei un targetHttpProxy. Non puoi aggiornare un targetHttpProxy esistente.

Connettività e interruzione della connettività

Per maggiori dettagli sui requisiti e sulle limitazioni di connettività, consulta la sezione Considerazioni su connettività e networking.

Tipi di backend misti

Un servizio di backend può avere backend VM o NEG. Se un servizio di backend ha backend NEG, tutti i NEG devono contenere lo stesso tipo di endpoint di rete. Non puoi avere un servizio di backend con più NEG, ognuno con tipi di endpoint diversi.

Una mappa URL può avere regole host che vengono risolte in servizi di backend diversi. Potresti avere un servizio di backend con solo NEG di connettività ibrida (con endpoint on-premise) e un servizio di backend con NEG autonomi (con endpoint GKE). La mappa URL può contenere regole, ad esempio la suddivisione del traffico in base al peso, che suddividono il traffico tra ciascuno di questi servizi di backend.

Utilizzo di un NEG con endpoint di tipo NON_GCP_PRIVATE_IP_PORT con backend Google Cloud

È possibile creare un servizio di backend con un NEG di connettività ibrida che rimanda ai backend in Google Cloud. Tuttavia, non consigliamo questo pattern perché i NEG di connettività ibrida non traggono vantaggio dal controllo centralizzato dello stato. Per una spiegazione del controllo di integrità centralizzato e distribuito, consulta la sezione Controllo di integrità.

Registrazione dell'endpoint

Se vuoi aggiungere un endpoint a un NEG, devi aggiornarlo. Puoi farlo manualmente o automatizzarlo utilizzando le API REST NEG o Google Cloud CLI. Google Cloud

Quando viene avviata una nuova istanza di un servizio, puoi utilizzare le API Google Cloud per registrare l'istanza con il NEG che hai configurato. Quando utilizzi i gruppi di istanze gestite (MIG) di Compute Engine o GKE (in Google Cloud), il controller MIG o NEG gestisce automaticamente la registrazione degli endpoint, rispettivamente.

Controllo di integrità

Quando utilizzi i NEG di connettività ibrida, il comportamento del controllo di integrità differisce dal comportamento standard centralizzato del controllo di integrità nei seguenti modi:

  • Per gli endpoint di rete di tipo NON_GCP_PRIVATE_IP_PORT, Cloud Service Mesh configura i suoi client in modo che utilizzino il piano dati per gestire il controllo dell'integrità. Per evitare di inviare richieste ai backend in stato non integro, le istanze Envoy eseguono i propri controlli di integrità e utilizzano i propri meccanismi.
  • Poiché il piano dati gestisce i controlli di integrità, non puoi utilizzare la consoleGoogle Cloud , l'API o Google Cloud CLI per recuperare lo stato del controllo di integrità.

In pratica, l'utilizzo di NON_GCP_PRIVATE_IP_PORT significa quanto segue:

  • Poiché ogni client Cloud Service Mesh gestisce il controllo di integrità in modo distribuito, potresti notare un aumento del traffico di rete a causa del controllo di integrità. L'aumento dipende dal numero di client Cloud Service Mesh e dal numero di endpoint che ogni client deve controllare. Ad esempio:
    • Quando aggiungi un altro endpoint a un NEG di connettività ibrida, i client Cloud Service Mesh esistenti potrebbero iniziare a eseguire il controllo di integrità degli endpoint nei NEG di connettività ibrida.
    • Quando aggiungi un'altra istanza al mesh di servizi (ad esempio, un'istanza VM che esegue il codice dell'applicazione e un client Cloud Service Mesh), la nuova istanza potrebbe iniziare a eseguire il controllo di integrità degli endpoint nei NEG di connettività ibrida.
    • Il traffico di rete dovuto ai controlli di integrità aumenta a una velocità quadratica (O(n^2)).

Rete VPC

Una mesh di servizi è identificata in modo univoco dal nome della rete Virtual Private Cloud (VPC). I client Cloud Service Mesh ricevono la configurazione da Cloud Service Mesh in base alla rete VPC specificata nella configurazione di bootstrap. Pertanto, anche se la mesh si trova completamente al di fuori di un data centerGoogle Cloud , devi fornire un nome di rete VPC valido nella configurazione di bootstrap.

Service account

All'interno di Google Cloud, il bootstrap di Envoy predefinito è configurato per leggere le informazioni account di servizio da uno o entrambi gli ambienti di deployment di Compute Engine e GKE. Quando viene eseguito al di fuori di Google Cloud, devi specificare esplicitamente un account di servizio, un nome di rete e un numero di progetto nel bootstrap di Envoy. Questo account di servizio deve disporre di autorizzazioni sufficienti per connettersi all'API Cloud Service Mesh.

Passaggi successivi