Networking di servizi per applicazioni distribuite nella rete Cross-Cloud

Last reviewed 2024-05-31 UTC

Questo documento fa parte di una serie di guide alla progettazione per Cross-Cloud Network.

La serie è composta dai seguenti componenti:

Questo documento descrive come assemblare un'applicazione da un insieme di i servizi dei componenti creati. Ti consigliamo di leggere l'intero documento una volta prima di seguire la procedura.

Questo documento ti guida nelle seguenti decisioni:

  • Sia che crei personalmente il singolo servizio o utilizzi una servizio di terze parti
  • Indica se il servizio è disponibile a livello globale o regionale
  • Se il servizio viene utilizzato on-premise, da altri cloud o da nessuna delle due opzioni
  • Sia che si acceda all'endpoint di servizio tramite un VPC di servizi condivisi distribuire gli endpoint attraverso tutti i VPC dell'applicazione pertinenti

Questo documento ti guida nei seguenti passaggi:

  1. Decidere se l'applicazione è globale o regionale
  2. Scegliere servizi gestiti di terze parti o creare e pubblicare propri servizi
  3. Configurazione dell'accesso privato agli endpoint del servizio utilizzando una modalità condivisa o dedicata
  4. Assemblaggio dei servizi in applicazioni per farli corrispondere a un ambiente archetipo regionale

Gli sviluppatori definiscono il livello di networking dei servizi per la rete cross-cloud. A questo punto, gli amministratori hanno progettato una connettività per la rete cross-cloud che consente flessibilità delle opzioni di networking dei servizi descritte in questo documento. Nella in alcuni casi, i vincoli dovuti a una limitata transitività tra VPC esistono. Descriviamo questi vincoli quando possono influire sulle decisioni di progettazione.

Decidere se l'applicazione è regionale o globale

Determina se i clienti dell'applicazione che stai creando hanno bisogno di una regione o archetipo di deployment globale. Puoi ottenere la resilienza regionale diffondendo vengono caricati in più zone di una regione. Puoi ottenere la resilienza globale e distribuire i carichi tra le regioni.

Prendi in considerazione i seguenti fattori quando scegli un archetipo:

  • I requisiti di disponibilità dell'applicazione
  • La posizione in cui viene utilizzata l'applicazione
  • Costo

Per maggiori dettagli, consulta Deployment di Google Cloud archetipi.

Questa guida alla progettazione illustra come supportare i seguenti archetipi di deployment:

In un'applicazione distribuita cross-cloud, i diversi servizi dell'applicazione possono essere fornite da diversi provider di servizi cloud (CSP) o data center privati. Per contribuire a garantire una struttura di resilienza coerente, posiziona i servizi ospitati in diversi CSP in data center dei CSP vicini tra loro.

Il seguente diagramma mostra uno stack di applicazioni globale distribuito su cloud e diversi servizi di applicazioni vengono implementati in diversi fornitori di servizi cloud. Ciascuna il servizio globale delle applicazioni dispone di istanze dei carichi di lavoro in diverse regioni dello stesso CSP.

Stack di applicazioni globale distribuito su cloud.

Definizione e accesso ai servizi per le applicazioni

Per assemblare l'applicazione, puoi utilizzare i servizi gestiti di terze parti esistenti, creare e ospitare i tuoi servizi di applicazione o utilizzare una combinazione di entrambi.

Utilizzare i servizi gestiti da terze parti esistenti

Decidi quali servizi gestiti di terze parti puoi utilizzare per la tua applicazione. Determina quali ovvero quelli strutturati come servizi regionali o globali. Inoltre, per determinare le opzioni di accesso privato supportate da ciascun servizio.

Una volta che sai quali servizi gestiti puoi utilizzare, puoi determinare quali servizi devi creare.

Crea e accedi ai servizi per le applicazioni

Ogni servizio è ospitato da una o più istanze di carico di lavoro a cui è possibile accedere come singolo endpoint o come gruppo di endpoint.

Il pattern generale di un servizio di applicazioni è mostrato nel seguente diagramma. Il servizio dell'applicazione viene distribuito in una raccolta di carichi di lavoro di Compute Engine. In questo caso, un'istanza di carico di lavoro potrebbe essere una VM Compute Engine, un cluster Google Kubernetes Engine (GKE) o un altro backend che esegue codice. Le istanze del carico di lavoro sono organizzati come set di backend associati a un bilanciatore del carico.

Il seguente diagramma mostra un bilanciatore del carico generico con un insieme di backend.

Bilanciatore del carico con backend.

Per ottenere la distribuzione del carico scelta e automatizzare i failover, questi gruppi di endpoint utilizzano un bilanciatore del carico frontend. Utilizzando i gruppi di istanze gestite, puoi aumentare o diminuire in modo elastico la capacità del servizio mediante la scalabilità automatica degli endpoint che formano il backend del bilanciatore del carico. Inoltre, a seconda dei requisiti del servizio dell'applicazione, il bilanciatore del carico può anche fornire autenticazione, terminazione TLS e e servizi specifici per la connessione.

Determina l'ambito del servizio (regionale o globale)

Decidi se il tuo servizio ha bisogno e può supportare la resilienza regionale o globale. Un servizio software regionale può essere progettato per la sincronizzazione entro un budget di latenza regionale. Un servizio di applicazioni globali può supportare i failover sincronizzati tra i nodi distribuiti nelle regioni. Se la tua applicazione è globale, è possibile che anche i servizi che lo supportano siano globali. Ma se il servizio richiede la sincronizzazione tra le istanze per supportare il failover, devi considerare la latenza tra le regioni. Per la tua situazione, potresti dover fare affidamento su servizi regionali con ridondanza nelle stesse regioni o nelle vicinanze, supportando così la sincronizzazione a bassa latenza per il failover.

Cloud Load Balancing supporta endpoint ospitati all'interno di una singola regione o distribuiti in più regioni. In questo modo, puoi creare un livello rivolto ai clienti a livello globale che interagisce con livelli di servizio globali, regionali o ibride. Scegli i deployment dei servizi per garantire che il failover di rete dinamico (o il bilanciamento del carico tra regioni) sia in linea con lo stato di resilienza e le funzionalità della logica dell'applicazione.

Il seguente diagramma mostra come un servizio globale creato dal carico a livello di regione possono raggiungere backend in altre regioni, fornendo così il failover automatico tra regioni diverse. In questo esempio, la logica dell'applicazione è globale e il backend scelto supporta la sincronizzazione tra regioni. Ogni bilanciatore del carico invia principalmente le richieste alla regione locale, ma può eseguire il failover alle regioni remote.

Bilanciatori del carico con backend in regioni diverse.

  • Un backend globale è una raccolta di backend regionali a cui accedono uno o più bilanciatori del carico.
  • Sebbene i backend siano globali, il frontend di ogni bilanciatore del carico è a livello di regione.
  • In questo modello di architettura, i bilanciatori del carico distribuiscono principalmente il traffico solo all'interno regione, ma può anche bilanciare il traffico verso altre regioni quando le risorse nella regione locale non sono disponibili.
  • Un insieme di frontend di bilanciatori del carico regionali, ciascuno accessibile da altre regioni e ciascuno in grado di raggiungere i backend in altre regioni, forma un servizio globale aggregato.
  • Per assemblare uno stack di applicazioni globale, come discusso in Progettare stack di applicazioni globali, puoi utilizzare il routing DNS e i controlli di integrità per realizzare il failover tra regioni dei frontend.
  • I frontend dei bilanciatori del carico sono a loro volta accessibili da altre regioni utilizzando accesso globale (non mostrato nel diagramma).

Lo stesso pattern può essere usato per includere i servizi pubblicati con di failover. Il seguente diagramma illustra un servizio pubblicato che utilizza di backend globali.

Bilanciatori del carico accessibili da regioni diverse.

Nel diagramma, tieni presente che il servizio pubblicato ha il failover globale implementato nell'ambiente del producer. L'aggiunta del failover globale nell'ambiente consumer consente la resilienza ai guasti regionali nell'infrastruttura di bilanciamento del carico del consumer. Il failover del servizio tra regioni deve essere implementato sia nella logica dell'applicazione del servizio sia nella progettazione del bilanciamento del carico del producer di servizi. Altri meccanismi possono essere implementati dai produttori di servizi.

Per determinare quale prodotto Cloud Load Balancing utilizzare, devi innanzitutto determinare il tipo di traffico che i bilanciatori del carico devono gestire. Considera le le seguenti regole generali:

  • Utilizza un bilanciatore del carico delle applicazioni per il traffico HTTP(S).
  • Utilizza un bilanciatore del carico di rete proxy per il traffico TCP non HTTP(S). Questo bilanciatore del carico proxy supporta anche l'offload TLS.
  • Utilizza un bilanciatore del carico di rete passthrough per conservare l'indirizzo IP di origine del client nell'intestazione o per supportare protocolli aggiuntivi come UDP, ESP e ICMP.

Per indicazioni dettagliate sulla scelta del bilanciatore del carico più adatto al tuo caso d'uso, consulta Scegliere un carico Google Cloud.

Servizi con backend serverless

Un servizio può essere definito utilizzando backend serverless. Il backend nel producer può essere organizzato in un ambiente serverless NEG come backend per un bilanciatore del carico. Questo servizio può essere pubblicato utilizzando Private Service Connect mediante la creazione di un collegamento a un servizio associati al frontend del bilanciatore del carico del producer, Il servizio pubblicato può essere utilizzato tramite endpoint Private Service Connect o backend Private Service Connect. Se il servizio richiede connessioni avviate dal producer, puoi utilizzare un Accesso VPC serverless per consentire a Cloud Run, App Engine standard e Gli ambienti delle funzioni Cloud Run inviano i pacchetti agli indirizzi IPv4 interni di in una rete VPC. L'accesso VPC serverless supporta anche l'invio di pacchetti ad altre reti connesse alla rete VPC selezionata.

Metodi per l'accesso privato ai servizi

L'applicazione può essere composta da servizi gestiti forniti da Google, servizi di terze parti forniti da fornitori esterni o gruppi di pari nella tua organizzazione e servizi sviluppati dal tuo team. Alcuni di questi servizi potrebbero essere accessibili utilizzando indirizzi IP pubblici. Questa sezione descrive i metodi che puoi utilizzare possono utilizzare per accedere a questi servizi tramite la rete privata. Esistono i seguenti tipi di servizio:

  • API pubbliche di Google
  • API serverless di Google
  • Servizi gestiti pubblicati da Google
  • Pubblicazione di servizi gestiti di fornitori e peer
  • I tuoi servizi pubblicati

Tieni presenti queste opzioni quando leggi le sezioni successive. A seconda di come allochi i servizi, puoi utilizzare una o più delle opzioni di accesso privato descritte.

L'organizzazione (o il gruppo all'interno di un'organizzazione) che assembla, pubblica e gestisce un servizio è indicata come produttore del servizio. Tu e la tua applicazione siete considerati utenti del servizio.

Alcuni servizi gestiti vengono pubblicati esclusivamente utilizzando servizi privati l'accesso alle app. Le progettazioni di rete consigliate in Connettività interna e VPC networking gestire i servizi pubblicati con accesso privato ai servizi Private Service Connect.

Per una panoramica delle opzioni per accedere ai servizi in privato, vedi Privato le opzioni di accesso per i servizi.

Ti consigliamo di utilizzare Private Service Connect per connetterti ai servizi gestiti, se possibile. Per ulteriori informazioni sui pattern di deployment per Private Service Connect, consulta Pattern di deployment di Private Service Connect.

Esistono due tipi di Private Service Connect e i diversi servizi possono essere pubblicati come uno dei due tipi:

I servizi pubblicati come endpoint Private Service Connect possono essere utilizzati direttamente da altri carichi di lavoro. I servizi si basano sull'autenticazione di resilienza di cui il producer del servizio ha eseguito il provisioning. Se vuoi aggiungere di controllo sull'autenticazione e sulla resilienza del servizio, puoi utilizzare Backend di Private Service Connect per aggiungere un livello di bilanciamento del carico per l'autenticazione e la resilienza nella rete del consumatore.

Il seguente diagramma mostra i servizi a cui viene eseguito l'accesso tramite gli endpoint Private Service Connect:

Accesso ai servizi tramite gli endpoint Private Service Connect.

Il diagramma mostra il seguente pattern:

  • Viene eseguito il deployment di un endpoint Private Service Connect nel consumer VPC, che rende disponibile il servizio producer per le VM nodi GKE.
  • Il deployment delle reti di consumatori e produttori deve avvenire nella stessa regione.

Il diagramma precedente mostra gli endpoint come risorse a livello di regione. Gli endpoint sono raggiungibili da altre regioni grazie all'accesso globale.

Per ulteriori informazioni sui pattern di deployment, consulta Pattern di deployment di Private Service Connect.

I backend Private Service Connect utilizzano un bilanciatore del carico configurato con il gruppo di endpoint di rete (NEG) Private Service Connect di backend. Per un elenco dei bilanciatori del carico supportati, consulta Informazioni sui backend di Private Service Connect.

I backend Private Service Connect consentono di creare quanto segue configurazioni backend:

  • Domini e certificati di proprietà del cliente davanti ai servizi gestiti
  • Failover controllato dal consumatore tra servizi gestiti in diverse regioni
  • Configurazione della sicurezza e controllo degli accessi centralizzati per i servizi gestiti

Nel diagramma seguente, il bilanciatore del carico globale utilizza un NEG Private Service Connect come backend per stabilire la comunicazione con il fornitore di servizi. Non sono disponibili altre configurazioni di rete e i dati vengono trasferiti all'infrastruttura SDN di Google.

Bilanciatore del carico globale che utilizza un gruppo di endpoint di rete.

La maggior parte dei servizi è progettata per le connessioni avviate dal consumer. Quando i servizi devono avviare connessioni dal producer, usa Private Service Connect di archiviazione.

Un aspetto chiave da considerare durante il deployment dell'accesso privato ai servizi o di Private Service Connect è la transitività. I servizi pubblicati generalmente non sono raggiungibili tramite una connessione di peering di rete VPC o tramite Network Connectivity Center. La la posizione della subnet o degli endpoint di accesso al servizio nella topologia VPC sia che si progetta la rete per il deployment di servizi condivisi o dedicati.

Opzioni come VPN ad alta disponibilità e proxy gestiti dal cliente forniscono metodi per consentire le comunicazioni transitive tra VPC.

Gli endpoint di Private Service Connect non sono raggiungibili su peering di rete VPC. Se hai bisogno di questo tipo di connettività, esegui il deployment di un bilanciatore del carico interno e di un NEG Private Service Connect come backend, come mostrato nel seguente diagramma:

Utilizzo di NEG per garantire la raggiungibilità.

È possibile accedere alle API di Google in privato utilizzando Endpoint e backend Private Service Connect. L'utilizzo degli endpoint è generalmente consigliato in quanto il produttore dell'API di Google offre resilienza e autenticazione basata su certificati.

crea un endpoint Private Service Connect in ogni VPC in cui è necessario accedere al servizio. Poiché l'indirizzo IP consumer è un indirizzo globale privato indirizzo IP, è necessaria una singola mappatura DNS per ogni servizio, anche se ci sono di istanze di endpoint in più VPC, come illustrato nelle diagramma:

Private Service Connect con le API di Google.

Definire i pattern di consumo dei servizi

I servizi possono essere eseguiti in diverse località: sulla rete VPC, su un altro VPC in un data center on-premise o nel cloud. Indipendentemente da dove dei carichi di lavoro di servizio, l'applicazione consuma quei servizi tramite di accesso rapido, ad esempio uno dei seguenti:

  • Un indirizzo IP in una subnet di accesso privato ai servizi
  • Un endpoint Private Service Connect
  • Un VIP per un bilanciatore del carico che utilizza i NEG Private Service Connect

I punti di accesso per i consumatori possono essere condivisi tra reti o dedicati a un un'unica rete. Decidi se creare punti di accesso ai servizi per i consumatori condivisi o dedicati in base al fatto che la tua organizzazione deleghi l'attività di creazione di punti di accesso ai servizi per i consumatori a ogni gruppo di applicazioni o gestisca l'accesso ai servizi in modo consolidato.

La gestione dell'accesso ai servizi riguarda le seguenti attività:

  • Creazione dei punti di accesso
  • Deployment dei punti di accesso in un VPC che ha il tipo appropriato di raggiungibilità
  • Registrazione dei punti di accesso consumer Indirizzi IP e URL in DNS
  • Gestione dei certificati di sicurezza e della resilienza per il servizio nello spazio consumer, quando viene aggiunto il bilanciamento del carico davanti ai punti di accesso consumer

Per alcune organizzazioni, potrebbe essere opportuno assegnare la gestione dell'accesso ai servizi a un di marketing, mentre altri potrebbero essere strutturati per dare una maggiore indipendenza a ciascun consumatore o dal team addetto all'applicazione. Un sottoprodotto del funzionamento in modalità dedicata è che degli elementi vengono replicati. Ad esempio, un servizio viene registrato con più nomi DNS da ciascun gruppo di applicazioni e gestisce più insiemi di certificati TLS.

La struttura del VPC descritta in Segmentazione della rete e per le applicazioni distribuite Rete cross-cloud consente la connettività per il deployment di punti di accesso ai servizi in un ambiente modalità dedicata. Il deployment dei punti di accesso consumer condivisi viene eseguito nel servizio VPC a cui è possibile accedere da qualsiasi altro VPC rete esterna. Nell'applicazione viene eseguito il deployment di punti di accesso consumer dedicati VPC, a cui è possibile accedere solo dalle risorse al suo interno VPC dell'applicazione.

La differenza principale tra un VPC di servizio e un VPC di applicazione è la connettività transitiva dei punti di accesso ai servizi abilitata da un VPC di servizio. Servizio I VPC non sono limitati all'hosting di punti di accesso consumer. Un VPC può ospitare risorse di applicazioni, nonché punti di accesso condivisi per i consumatori. In questo caso, il VPC deve essere configurato gestito come servizio in un VPC.

Accesso ai servizi gestiti condivisi

Per tutti i metodi di consumo dei servizi, incluso Private Service Connect, assicurati di svolgere le seguenti attività:

  • Esegui il deployment dei punti di accesso consumer dei servizi in un VPC dei servizi. VPC di servizio hanno la connettività transitiva ad altri VPC.
  • Annunci la subnet per il punto di accesso del consumatore come annuncio route personalizzato dal router Cloud che esegue il peering con altre reti tramite VPN ad alta disponibilità. Per le API Google, pubblicizza l'indirizzo IP host dell'API.
  • Aggiorna le regole del firewall multicloud per consentire alla subnet di accesso ai servizi privati.

In particolare per l'accesso privato ai servizi, assicurati di poter soddisfare le i seguenti requisiti aggiuntivi:

Per l'accesso ai servizi serverless, assicurati di poter soddisfare quanto segue requisiti:

  • Il connettore di accesso richiede una subnet normale /28 dedicata
  • Per impostazione predefinita, Cloud Router annuncia le subnet regolari
  • Crea regole firewall in entrata per consentire a tutte le subnet di accesso VPC all'interno dei VPC
  • Aggiorna le regole del firewall multicloud per consentire la subnet del connettore di accesso VPC
  • Crea una o più regole firewall in entrata per consentire alla subnet di accesso ai servizi privati di accedere alle VPC dell'applicazione

Accesso ai servizi gestiti dedicati

Assicurati di svolgere le seguenti attività:

  • In ogni VPC dell'applicazione in cui è necessario l'accesso, esegui il deployment di una regola di inoltro per il servizio per creare un punto di accesso.
  • Per l'accesso privato ai servizi, crea regole firewall in entrata per consentire una subnet di accesso privato ai servizi nei VPC delle applicazioni.

Per l'accesso ai servizi serverless, assicurati di poter soddisfare quanto segue requisiti:

  • Il connettore di accesso richiede una subnet regolare /28 dedicata
  • Crea regole firewall in entrata per consentire la subnet del connettore di accesso VPC all'interno delle VPC dell'applicazione

Assembla lo stack di applicazioni

Questa sezione descrive l'assemblaggio di uno stack di applicazioni regionale o globale.

Progetta stack di applicazioni a livello di regione

Quando un'applicazione segue gli archetipi di deployment regionale o multiregionale, utilizza gli stack di applicazioni regionali. Gli stack di applicazioni a livello di regione è pensato come una concatenazione di livelli di servizio delle applicazioni regionali. Per ad esempio un livello del servizio web a livello di regione che comunica con un livello dell'applicazione nella stessa regione, che a sua volta comunica con un livello di database nella stessa regione, e lo stack di applicazioni regionali.

Ogni livello di servizio di applicazioni regionale utilizza bilanciatori del carico per distribuire il traffico tra gli endpoint del livello nella regione. L'affidabilità viene ottenuta distribuendo le risorse di backend su tre o più zone della regione.

Livelli di servizio delle applicazioni in altri CSP o dati on-premise center deve essere implementato in regioni equivalenti nelle reti esterne. Inoltre, rende disponibili i servizi pubblicati nella regione dello stack. Per allineare lo stack delle applicazioni all'interno di una regione, gli URL del livello di servizio dell'applicazione devono risolvere l'indirizzo IP regionale frontend del bilanciatore del carico specifico. Questi DNS vengono registrate nella zona DNS pertinente per ogni servizio dell'applicazione.

Il seguente diagramma mostra uno stack regionale con resilienza in standby attivo:

Impianto regionale con resilienza attiva/in standby.

Viene eseguito il deployment di un'istanza completa dello stack di applicazioni in ogni regione tra i diversi data center del cloud. Quando si verifica un errore regionale in uno dei livelli di servizio dell'applicazione, lo stack nell'altra regione assume il controllo dell'intera applicazione. Questo failover viene eseguito in risposta al monitoraggio out-of-band dei diversi livelli di servizio delle applicazioni.

Quando un errore viene per uno dei livelli di servizio, il frontend dell'applicazione nuovamente ancorate allo stack di backup. L'applicazione è scritta per fare riferimento a un insieme di record dei nomi regionali che riflettono lo stack di indirizzi IP a livello di regione nel DNS, in modo che dell'applicazione mantiene le proprie connessioni all'interno della stessa regione.

Progettare stack di applicazioni globali

Quando un'applicazione segue l'archetipo di deployment globale delle applicazioni, ogni include backend in più regioni. L'inclusione dei backend in più regioni espande il pool di resilienza per il livello di servizio dell'applicazione oltre una singola regione consente il rilevamento e la riconvergenza automatici del failover.

Il seguente diagramma mostra uno stack di applicazioni globale:

Stack globale utilizzando un progetto hub e un progetto applicazione.

Il diagramma precedente mostra un'applicazione globale assemblata dai seguenti componenti:

  • Servizi in esecuzione in data center on-premise con frontend di bilanciatori del carico. La i punti di accesso del bilanciatore del carico sono raggiungibili tramite Cloud Interconnect VPC di transito.
  • Un VPC di transito ospita connessioni ibride un data center esterno e il VPC dell'applicazione.
  • Un VPC dell'applicazione che ospita l'applicazione di base in esecuzione sulle istanze di carico di lavoro. Queste istanze del carico di lavoro sono dietro ai bilanciatori del carico. I bilanciatori del carico sono raggiungibili da qualsiasi regione della rete e possono raggiungere i backend in qualsiasi regione della rete.
  • Un VPC di servizi che ospita punti di accesso per i servizi in esecuzione in altre località, ad esempio in VPC di terze parti. Questi punti di accesso ai servizi raggiungibile tramite la connessione VPN ad alta disponibilità tra il VPC dei servizi e VPC di transito.
  • VPC dei producer di servizi ospitati da altre organizzazioni o sia l'organizzazione principale sia le applicazioni eseguite in altre località. I servizi pertinenti vengono resi accessibili dai backend Private Service Connect implementati come backend globali per i bilanciatori del carico regionali ospitati nel VPC dei servizi. I bilanciatori del carico a livello di regione sono raggiungibili da qualsiasi altra regione.

Se vuoi che l'applicazione creata sia raggiungibile da internet, puoi aggiungere un bilanciatore del carico delle applicazioni esterno globale che indichi i carichi di lavoro dell'applicazione nel VPC dell'applicazione (non mostrato nel diagramma).

Per supportare uno stack di applicazioni globale, abbiamo utilizzato backend globali per ogni livello di applicazione. In questo modo è possibile recuperare da un errore di tutti gli endpoint di backend in una regione. Ogni regione ha un frontend del bilanciatore del carico a livello di regione il livello di servizio dell'applicazione. Quando si verifica un failover regionale, i frontend dei bilanciatori del carico regionali interni possono essere raggiunti in più regioni, perché utilizzano l'accesso globale. Poiché lo stack delle applicazioni è globale, vengono utilizzati i criteri di routing della geolocalizzazione DNS per selezionare il frontend regionale più appropriato per una determinata richiesta o un determinato flusso. In caso di errore del frontend, integrità DNS controlli può essere usato per automatizzare il failover da un frontend all'altro.

Servizi pubblicati utilizzando i backend Private Service Connect sfrutta i vantaggi di Private Service Connect Global l'accesso alle app. Questa funzionalità consente di raggiungere un backend Private Service Connect da qualsiasi regione e riduce le interruzioni dovute a errori del livello di servizio dell'applicazione. Ciò significa che i backend di Private Service Connect possono essere utilizzati come backend globali, come descritto in Determinare l'ambito del servizio: regionale o globale.

Fornisci accesso privato ai servizi ospitati in reti esterne

Potresti voler pubblicare un punto di accesso locale per un servizio ospitato su un altro in ogni rete. In questi casi, puoi utilizzare un carico proxy TCP regionale interno bilanciatore del carico utilizzando NEG ibridi. Puoi creare un servizio ospitato on-premise o in disponibili per i client nella tua rete VPC, come come mostrato nel seguente diagramma:

Punto di accesso locale che utilizza NEG ibridi.

Se vuoi rendere disponibile il servizio ibrido in una rete VPC diversa da quella che ospita il bilanciatore del carico, puoi utilizzare Private Service Connect per pubblicare il servizio. Posizionando un collegamento di servizio davanti al bilanciatore del carico proxy TCP regionale interno, puoi consentire ai client di altre reti VPC di raggiungere i servizi ibridi in esecuzione on-premise o in altri ambienti cloud.

In un ambiente cross-cloud, l'utilizzo di un NEG ibrido consente una comunicazione sicura tra applicazioni.

Quando un'altra organizzazione pubblica un servizio di applicazione, utilizza un NEG ibrido per estendere le astrazioni di accesso privato per quel servizio. Il seguente diagramma illustra questo scenario:

NEG ibridi davanti ai servizi in altre reti.

Nel diagramma precedente, il livello di servizio dell'applicazione è completamente composto nel CSP adiacente, che è evidenziato nelle parti del diagramma non disattivate. I bilanciatori del carico ibride vengono utilizzati in combinazione con i collegamenti a servizi Private Service Connect come meccanismo per pubblicare il servizio di applicazione esterno per il consumo privato all'interno di Google Cloud. I bilanciatori del carico ibridi con NEG ibridi I collegamenti di servizio Private Service Connect si trovano in un VPC che fanno parte di un progetto di producer di servizi. Questo progetto di producer di servizi di solito potrebbe essere un VPC diverso VPC di transito, perché rientra nell'ambito amministrativo del producer organizzazione o progetto, quindi separati dai sistemi di trasporto i servizi di machine learning. Il VPC del producer non deve essere connesso tramite VPC o HA-VPN con il VPC consumer (ovvero la rete VPC VPC condiviso nel diagramma).

Centralizza l'accesso ai servizi

L'accesso ai servizi può essere centralizzato in una rete VPC e accedervi da altre reti di applicazioni. Il seguente diagramma mostra il pattern comune che consente la centralizzazione dei punti di accesso:

VPC di servizi dedicati.

Il seguente diagramma mostra tutti i servizi a cui si accede da un VPC di servizi dedicati:

VPC di servizi dedicati con bilanciatori del carico centralizzati.

Quando i servizi sono in primo piano con bilanciatori del carico delle applicazioni, puoi consolidare su un numero inferiore di bilanciatori del carico utilizzando le mappe URL per indirizzare il traffico per i backend dei servizi diversi anziché utilizzare bilanciatori del carico diversi per ogni servizio. In linea di principio, uno stack di applicazioni potrebbe essere completamente composto utilizzando un singolo bilanciatore del carico delle applicazioni, oltre a backend di servizi e mappature URL appropriate.

In questa implementazione, devi utilizzare NEG ibride nelle VPC per la maggior parte dei tipi di backend. L'eccezione è un NEG o un backend di Private Service Connect, come descritto in Eseguire il chaining esplicito dei bilanciatori del carico L7 di Google Cloud con Private Service Connect.

L'utilizzo di NEG ibridi nelle VPC comporta la rinuncia alla riparazione automatica e alla scalabilità automatica per i backend. I servizi pubblicati dispongono già di un bilanciatore del carico nel tenant del produttore che fornisce la scalabilità automatica. Pertanto, si verificano le limitazioni dei NEG ibridi solo se si centralizza la funzione di bilanciamento del carico per i livelli di servizio composti in modo nativo anziché essere consumati dalla pubblicazione.

Quando utilizzi questo pattern di rete di servizi, ricorda che i servizi consumate tramite un ulteriore livello di bilanciamento del carico.

Utilizza il bilanciamento del carico proxy per usufruire dei vantaggi della scalabilità della connettività VPC spoke di Network Connectivity Center tra le VPC, fornendo al contempo connettività transitiva ai servizi pubblicati tramite i bilanciatori del carico proxy.

Endpoint di servizio Private Service Connect e regole di forwarding per il servizio privato non sono raggiungibili nei VPC dello spoke di Network Connectivity Center. Analogamente, le reti dietro le connessioni ibride (Cloud Interconnect o HA-VPN) non sono raggiungibili tramite le VPC spoke di Network Connectivity Center perché le route dinamiche non vengono propagate tramite Network Connectivity Center.

Questa mancanza di transitività può essere aggirata eseguendo il deployment di bilanciatori del carico proxy con le risorse non transitive gestite come NEG ibridi. In questo modo, possiamo implementare bilanciatori del carico proxy davanti ai frontend dei servizi e ai carichi di lavoro raggiungibili tramite le connessioni ibride.

I frontend proxy del bilanciatore del carico vengono implementati in subnet VPC che vengono propagate nelle VPC spoke di Network Connectivity Center. Questa propagazione consente la raggiungibilità tramite Network Connectivity Center delle risorse non transitive tramite i bilanciatori di carico proxy.

La modalità centralizzata aggiunge un livello di bilanciamento del carico lato consumer del servizio. Quando utilizzi questa modalità, devi gestire anche i certificati, resilienza e ulteriori mappature DNS nel progetto consumer.

Altre considerazioni

Questa sezione contiene considerazioni relative a prodotti e servizi comuni non esplicitamente trattati in questo documento.

Considerazioni sul control plane GKE

Il deployment del piano di controllo GKE viene eseguito in una progetto tenant collegato al VPC del cliente tramite peering di rete VPC. Poiché il peering di rete VPC non è transitivo, non è possibile la comunicazione diretta con il control plane tramite una topologia di rete in peering VPC con hub e spoke.

Quando valuti le opzioni di progettazione di GKE, come l'accesso diretto e decentralizzato al piano di controllo da origini multi-cloud è una considerazione chiave. Se il deployment di GKE viene eseguito in un VPC centralizzato, l'accesso al piano di controllo è disponibile tra i cloud e all'interno in Google Cloud. Tuttavia, se il deployment di GKE viene eseguito in VPC decentralizzati, la comunicazione diretta con il piano di controllo non è possibile. Se i requisiti di un'organizzazione richiedono l'accesso ai il piano di controllo GKE oltre ad adottare la strategia di progettazione, gli amministratori di rete possono implementare un che agisce da proxy, superando così la limitazione del peering non transitivo il piano di controllo GKE.

Sicurezza - Controlli di servizio VPC

Per i carichi di lavoro che coinvolgono dati sensibili, utilizza Controlli di servizio VPC per configurare i perimetri di servizio attorno alle tue risorse VPC e servizi e controllare il movimento dei dati attraverso il confine del perimetro. Utilizzo Controlli di servizio VPC, puoi raggruppare i progetti e la rete on-premise in un unico perimetro che impedisce l'accesso ai dati attraverso i servizi di machine learning. Le regole di ingresso e uscita di VPC Service Controls possono essere utilizzate per consentire la comunicazione tra progetti e servizi in perimetri di servizio diversi, incluse le reti VPC esterne al perimetro.

Per le architetture di deployment consigliate, un processo di onboarding completo, e operative, consulta le best practice per Controlli di servizio VPC per imprese e Nozioni di base sulla sicurezza Schema.

DNS per API/servizi

I producer di servizi possono pubblicare servizi utilizzando Private Service Connect. Facoltativamente, il producer di servizi può configurare un nome di dominio DNS da associare. con il servizio. Se è configurato un nome di dominio e un consumer di servizi crea un endpoint che ha come target il servizio, Private Service Connect e Service Directory creano automaticamente le voci DNS per il servizio in una zona DNS privata nella rete VPC del consumer di servizi.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: