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

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

Puoi configurare Cloud Service Mesh in modo che il tuo mesh di servizi possa inviare traffico a esterni a Google Cloud. Questi endpoint includono le seguenti:

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

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

Supporto di Cloud Service Mesh per servizi on-premise e multi-cloud ti consente di:

  • Instrada il traffico a livello globale, anche verso gli endpoint delle reti on-premise e multi-cloud.
  • Sfrutta i vantaggi di Cloud Service Mesh e del mesh di servizi, tra cui come il Service Discovery e la gestione avanzata del traffico, i servizi in esecuzione sull'infrastruttura esistente al di fuori di Google Cloud.
  • Combina le funzionalità di Cloud Service Mesh con Cloud Load Balancing per per trasferire i servizi di networking di Google Cloud in ambienti multiambiente.

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

Casi d'uso

Cloud Service Mesh può configurare il networking tra basate su VM e basate su container in più ambienti, tra cui:

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

Instrada il traffico mesh a una località on-premise o a un altro cloud

Il caso d'uso più semplice di questa funzionalità è il routing del traffico. Il tuo dell'applicazione esegue un proxy Envoy Cloud Service Mesh . Cloud Service Mesh il client sui tuoi servizi e sugli endpoint di ogni servizio.

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

Nel diagramma precedente, quando la tua applicazione invia una richiesta all'on-prem il client Cloud Service Mesh controlla la richiesta in uscita e gli aggiornamenti la sua destinazione. La destinazione viene impostata su un endpoint associato on-prem servizio (in questo caso, 10.2.0.1). La richiesta si sposterà poi Cloud VPN o Cloud Interconnect per raggiungere la destinazione prevista.

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

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

L'invio di traffico a un endpoint non Google Cloud ti consente di instradare il traffico a in altri ambienti. Puoi combinare questa funzionalità con il traffico avanzato per la migrazione dei servizi tra ambienti.

Migrazione da una località on-premise a Google Cloud.
Migrazione da una località on-premise a Google Cloud (fai clic per ingrandire)

Il diagramma precedente estende il pattern precedente. Invece di configurare Cloud Service Mesh per inviare tutto il traffico al servizio on-prem, configurare Cloud Service Mesh per l'utilizzo della suddivisione del traffico basata su pesi per la suddivisione il traffico tra due servizi.

La suddivisione del traffico ti consente di iniziare inviando lo 0% del traffico a cloud e il 100% al servizio on-prem. Puoi quindi aumentare gradualmente proporzione di traffico inviata al servizio cloud. Alla fine, invierai il 100% traffico al servizio cloud e potrai ritirare il servizio on-prem.

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

Infine, puoi combinare questa funzionalità con le applicazioni soluzioni di networking. Google Cloud offre una vasta gamma di come il bilanciamento del carico esterno globale con Google Cloud Armor per la protezione DDoS (Distributed Denial-of-Service), che puoi utilizzare Cloud Service Mesh per portare nuove funzionalità nei tuoi ambienti on-premise o multi-cloud i servizi di machine learning. L'aspetto migliore è che non è necessario esporre questi ambienti on-premise o multi-cloud servizi alla rete internet pubblica.

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

Nel diagramma precedente, il traffico dai client sulla rete internet pubblica entra dalla rete Google Cloud da un bilanciatore del carico di Google Cloud, come il nostro bilanciatore del carico delle applicazioni esterno globale. Quando il traffico raggiunge il bilanciatore del carico, puoi per applicare i servizi sul perimetro della rete, come la protezione DDoS di Google Cloud Armor Autenticazione utente Identity-Aware Proxy (IAP). Per ulteriori informazioni, vedi Servizi perimetrali della rete per deployment multiambiente.

Dopo aver applicato questi servizi, il traffico si ferma per breve tempo Google Cloud, in cui è presente un'applicazione o un proxy autonomo (configurato Cloud Service Mesh) inoltra il traffico attraverso Cloud VPN Cloud Interconnect al tuo servizio on-premise.

Risorse e architettura di Google Cloud

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

Il seguente diagramma illustra le risorse Google Cloud che consentono il supporto di servizi on-premise e multi-cloud per Cloud Service Mesh. La chiave è il NEG e i suoi endpoint di rete. Le altre risorse ovvero le risorse che configuri come parte di una configurazione standard di Cloud Service Mesh. Per semplicità, il diagramma non mostra opzioni come di backend.

Risorse Compute Engine per servizi on-premise e multi-cloud.
Risorse Compute Engine per servizi on-premise e multi-cloud (fai clic per ingrandire)

Quando configuri Cloud Service Mesh, utilizzi l'API globale dei servizi di backend risorsa per creare i servizi. Un servizio è un costrutto logico combina i seguenti elementi:

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

I servizi on-premise e multi-cloud sono come qualsiasi altro servizio che Cloud Service Mesh esegue la configurazione. La differenza principale è che utilizzi un modello ibrido NEG di connettività per configurare gli endpoint di questi servizi. Questi NEG e avere il tipo di endpoint di rete impostato su NON_GCP_PRIVATE_IP_PORT. La gli endpoint che aggiungi ai NEG di connettività ibrida devono essere IP:port validi combinazioni che i tuoi clienti possono raggiungere, tramite una connettività ibrida come Cloud VPN e Cloud Interconnect.

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

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

Quando crei il NEG, configuralo come segue in modo da poter inviare traffico in 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 l'indirizzo IP è on-premise o deve essere raggiungibile da Google Cloud utilizzando alla connettività ibrida, ad esempio quella fornita da Cloud VPN o Cloud Interconnect.
  • Specifica una zona Google Cloud che riduce al minimo la distanza geografica tra Google Cloud e in un ambiente on-premise o multi-cloud. Ad esempio, se ospiti un in un ambiente on-premise a Francoforte, in Germania, e specificare la zona Google Cloud europe-west3-a quando crei il NEG.

Il comportamento del controllo di integrità per gli endpoint di rete di questo tipo è diverso da un comportamento del controllo di integrità per altri tipi di endpoint di rete. Mentre le altre i tipi di endpoint di rete utilizzano il controllo di integrità centralizzato di Google Cloud di rete, NON_GCP_PRIVATE_IP_PORT di endpoint di rete utilizzano la tecnologia meccanismo di controllo di integrità. Per ulteriori dettagli, consulta Sezione Limitazioni e altre considerazioni.

Considerazioni su connettività e networking

I client Cloud Service Mesh, ad esempio i proxy Envoy, devono poter connettersi in Cloud Service Mesh all'indirizzo trafficdirector.googleapis.com:443. Se perdi al piano di controllo Cloud Service Mesh, si verifica quanto segue:

  • I client Cloud Service Mesh esistenti non possono ricevere la configurazione e gli aggiornamenti da Cloud Service Mesh. L'azienda continua a operare in base ai propri configurazione attuale.
  • I nuovi client Cloud Service Mesh non possono connettersi a Cloud Service Mesh. Loro non possono utilizzare il mesh di servizi finché la connettività non viene ristabilita.

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

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

Limitazioni e altre considerazioni

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

Impostazione di proxyBind

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

Connettività e interruzione della connettività

Per maggiori dettagli su requisiti e limitazioni di connettività, consulta 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 un 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 si risolvono in backend diversi i servizi di machine learning. 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 gli endpoint GKE). La mappa URL può contenere regole, ad esempio della suddivisione del traffico basata sulla ponderazione, che suddividono il traffico in ciascuno di questi backend i servizi di machine learning.

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 punta ai backend in Google Cloud. Tuttavia, ti sconsigliamo di farlo perché i NEG di connettività ibrida non traggono vantaggio dall'integrità centralizzata controllare. Per una spiegazione del controllo di integrità centralizzato controllo di integrità, consulta la sezione Controllo di integrità.

Registrazione degli endpoint

Se vuoi aggiungere un endpoint a un NEG, devi aggiornare il NEG. Questo può manualmente o mediante l'automazione utilizzando la piattaforma Google Cloud le API REST NEG o Google Cloud CLI.

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 utilizzando gruppi di istanze gestite di Compute Engine (MIG) o GKE (in Google Cloud), il controller MIG o NEG gestisce automaticamente la registrazione degli endpoint.

Controllo di integrità

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

  • Per gli endpoint di rete di tipo NON_GCP_PRIVATE_IP_PORT, Cloud Service Mesh configura i propri client in modo che utilizzino il piano dati per gestire il controllo di integrità. Per evitare l'invio di richieste a backend in stato non integro, le istanze Envoy eseguire i propri controlli di integrità e utilizzare i propri meccanismi.
  • Poiché il tuo piano dati gestisce i controlli di integrità, non puoi utilizzare Console Google Cloud, l'API o Google Cloud CLI per recuperare l'integrità verifica lo stato.

In pratica, per NON_GCP_PRIVATE_IP_PORT si intende quanto segue:

  • Poiché i client Cloud Service Mesh gestiscono ciascuno il controllo di integrità in una in modo distribuito, potresti notare un aumento del traffico di rete a causa controllo di integrità. L'aumento dipende dal numero di Cloud Service Mesh e il numero di endpoint necessari per l'integrità di ciascun client controllo. Ad esempio:
    • Quando aggiungi un altro endpoint a un NEG di connettività ibrida, I client Cloud Service Mesh potrebbero iniziare a eseguire il controllo di integrità degli endpoint nei NEG di connettività ibrida.
    • Quando aggiungi un'altra istanza al tuo mesh di servizi, ad esempio una VM che esegue il codice dell'applicazione, nonché un dal client Cloud Service Mesh), la nuova istanza potrebbe iniziare a essere integro e controllare gli endpoint nei NEG di connettività ibrida.
    • Il traffico di rete dovuto ai controlli di integrità aumenta in modo quadratico Percentuale (O(n^2)).

Rete VPC

Un mesh di servizi è identificato in modo univoco dalla sua rete Virtual Private Cloud (VPC) . I client Cloud Service Mesh ricevono la configurazione da Cloud Service Mesh in base alla rete VPC specificata nel bootstrap configurazione. Pertanto, anche se il tuo mesh si trova completamente all'esterno di data center Google Cloud, devi fornire un VPC valido del nome della rete nella configurazione del bootstrap.

Account di servizio

All'interno di Google Cloud, il bootstrap Envoy predefinito è configurato le informazioni sull'account di servizio di una o entrambe di deployment GKE. Quando corri al di fuori di in Google Cloud, devi specificare esplicitamente un account di servizio, un nome di rete e il numero di progetto nel bootstrap Envoy. Questo account di servizio deve avere autorizzazioni sufficienti per la connessione con l'API Cloud Service Mesh.

Passaggi successivi