La risorsa organizzazione rappresenta un'unità amministrativa o una funzione aziendale che condivide lo stesso pool di risorse e le stesse norme comuni. Google Distributed Cloud (GDC) con air gap fornisce l'isolamento fisico tra le organizzazioni utilizzando funzionalità multi-tenant a livello hardware. Ogni organizzazione ha anche i propri componenti del control plane per i suoi servizi, che non sono condivisi con altre organizzazioni. Tutte le risorse, come progetti, cluster e servizi, appartengono a un'organizzazione anziché ai loro autori. Pertanto, le risorse non vengono eliminate se l'utente che le ha create lascia l'organizzazione. Invece, tutti i tipi di risorse seguono il ciclo di vita dell'organizzazione. Per ulteriori informazioni, consulta la gerarchia delle risorse GDC.
Connettività di rete esterna
Per essere utile, un'organizzazione richiede la connettività a reti esterne. In questo modo, gli amministratori della piattaforma e gli operatori delle applicazioni possono gestire l'organizzazione e le relative risorse, mentre gli utenti finali possono utilizzare i servizi di cui è stato eseguito il deployment al suo interno. In GDC, tutta la connettività esterna è fornita dalle interconnessioni.
Quando viene creata un'organizzazione, non viene automaticamente collegata a nessuna rete. In qualità di operatore, devi eseguire passaggi di configurazione aggiuntivi per collegare un'organizzazione a un interconnessione esistente o eseguirne il provisioning di una nuova e dedicata. In genere, ciò comporta:
- Aggiunta dell'organizzazione a un
AttachmentGroup. - Creazione di risorse
Interconnectper nuove connessioni fisiche o logiche. - Definizione delle risorse
RoutePolicyper annunciare le route di rete dell'organizzazione alla rete esterna.
Le organizzazioni offrono funzionalità di networking avanzate, inclusa la possibilità per le organizzazioni con interconnessioni dedicate di utilizzare indirizzi IP esterni sovrapposti, il che semplifica la gestione degli IP.
Per concetti e procedure di configurazione dettagliati, consulta la panoramica dell'interconnessione.
Modelli di connettività Interconnect
Gli interconnessioni GDC supportano due configurazioni principali che si allineano a diversi requisiti di sicurezza e gestione IP.
Connettività di rete esterna condivisa
Questo modello consente a più organizzazioni di connettersi a una zona GDC tramite una rete esterna comune. In questa configurazione, l'operatore dell'infrastruttura (IO) in genere gestisce la connessione fisica e il peering BGP. Un requisito fondamentale è che gli indirizzi IP esterni utilizzati da ogni organizzazione devono essere univoci nella rete condivisa. Questo modello è più semplice da gestire per gli ambienti con un dominio di trust comune.
Connettività di rete esterna dedicata
Questo modello è destinato alle organizzazioni che richiedono un maggiore grado di isolamento, connettendosi a una rete esterna distinta. Con la connettività dedicata, l'interconnessione BGP può essere gestita dal PA, che ha un maggiore controllo.
Un vantaggio significativo di questo modello è la possibilità per le organizzazioni di utilizzare indirizzi IP esterni sovrapposti. Questa funzionalità semplifica la gestione degli indirizzi IP eliminando la necessità di risolvere i conflitti tra gli intervalli IP in tutti i tenant dell'universo GDC.
Per concetti e procedure di configurazione dettagliati, consulta la panoramica di Interconnect.
Architetture dell'organizzazione
GDC offre due architetture per le organizzazioni:
- Architettura dell'organizzazione GDC con air gap v1 (organizzazione v1)
- Architettura dell'organizzazione GDC con air gap v2 (organizzazione v2)
In superficie, le organizzazioni con entrambe le architetture vengono sottoposte al provisioning, utilizzate e gestite in modo simile. Tuttavia, le architetture di cluster, networking e storage sottostanti sono diverse in ogni tipo di organizzazione.
Architettura dell'organizzazione GDC con air gap v1
Un'organizzazione v1 è costituita da due cluster:
- Cluster di amministrazione dell'organizzazione: esegue i componenti del control plane dei servizi gestiti e del Marketplace per l'organizzazione. Ospita anche alcuni servizi di infrastruttura di base.
- Cluster di sistema: esegue i workload delle macchine virtuali (VM) e alcuni workload del data plane dei servizi gestiti per l'organizzazione. Il numero di nodi worker dipende dall'utilizzo del cluster.
A volte, il PA e l'AO sono necessari per accedere a questi tipi di cluster per eseguire il deployment dei carichi di lavoro e gestire il sistema.
Lo spazio di archiviazione per i cluster virtuali viene gestito da un driver CSI specifico del fornitore all'interno del cluster.
Architettura GDC con air gap Org v2
Un'organizzazione v2 è costituita da un cluster chiamato cluster di infrastruttura dell'organizzazione, che esegue i componenti del piano di controllo e del piano dati dell'organizzazione. Questo cluster ospita anche il server API di gestione in cui vengono implementati tutti i servizi e i carichi di lavoro non containerizzati. Il server API di gestione fornisce un livello in cui i PA e gli AO possono eseguire il deployment dei carichi di lavoro, ma non interagire direttamente con il cluster dell'infrastruttura dell'organizzazione.
L'archiviazione per i cluster virtuali viene gestita da un driver CSI proxy che consente al driver CSI del cluster di infrastruttura dell'organizzazione di gestire le operazioni.
I componenti di Networking, tra cui la gestione degli indirizzi IP, il reindirizzamento in entrata e in uscita e la struttura VRF, offrono miglioramenti rispetto all'architettura dell'organizzazione v1 per la sicurezza e l'usabilità del sistema.
Novità per le organizzazioni v2
L'architettura dell'organizzazione v2 introduce modifiche in diversi componenti rispetto all'architettura dell'organizzazione v1.
Architettura delle API e del cluster
L'architettura dell'organizzazione v2 fornisce un solo cluster per l'organizzazione, anziché due cluster forniti nell'architettura precedente. La riduzione dei cluster consente un utilizzo più elastico delle risorse hardware.
Esiste anche la separazione di rete del control plane e del data plane che non era disponibile per le organizzazioni v1. Il server API di gestione o il control plane può ora essere esposto su una rete del cliente diversa da quella a cui è esposto il data plane. Questa separazione offre un livello di isolamento aggiuntivo facoltativo tra il provisioning delle risorse cloud e il consumo delle risorse. I tuoi amministratori e sviluppatori devono avere connessioni a entrambe le reti esterne.
Archiviazione
La nuova architettura dell'organizzazione v2 rimuove le credenziali di archiviazione NetApp dal cluster utente eseguendo il deployment del driver CSI KubeVirt anziché del driver CSI NetApp Trident presente nell'architettura precedente. Questo aggiornamento del driver CSI riduce ulteriormente i privilegi diretti dell'array di archiviazione.
Networking
Per le organizzazioni v2 sono disponibili i seguenti miglioramenti del networking:
- Crittografia end-to-end
- Cluster dedicato per la gestione del traffico di rete
- Networking VM semplificato
- Utilizzo e gestione più efficienti degli indirizzi IP
Crittografia da nodo a nodo
L'architettura dell'organizzazione v2 fornisce la crittografia tra i nodi bare metal dell'organizzazione in modo che tutto il traffico di rete dei clienti venga criptato quando lascia il nodo fisico per impedire agli switch di rete di avere visibilità sul traffico non criptato.
Cluster dedicato per la gestione del traffico di rete
Il cluster perimetrale è un cluster virtuale scalabile che gestisce tutto il traffico in entrata e in uscita (nord/sud) per l'organizzazione. Questo cluster consente inoltre al tuo universo GDC di passare in futuro a opzioni di sistema di rilevamento e prevenzione delle intrusioni (IDPS) virtuali più scalabili.
Networking di VM semplificato
L'architettura dell'organizzazione v2 unisce due interfacce per VM dell'architettura precedente in un'unica interfaccia. Le VM vengono spostate in un modello di rete VPC (Virtual cloud privato) virtuale predefinito, il che significa che sono connesse alla rete a livello 3 (L3).
I clienti possono anche definire le proprie subnet, il che non è supportato per le organizzazioni v1.
Utilizzo e gestione efficienti degli indirizzi IP
L'architettura dell'organizzazione v2 consente indirizzi IP esterni sovrapposti per le organizzazioni. Gli indirizzi IP esterni sovrapposti consentono alle organizzazioni di connettersi direttamente alle reti dei clienti, eliminando la necessità di un unico spazio di indirizzi IP esterni di grandi dimensioni allineato a tutte le organizzazioni dell'universo GDC.
Gli indirizzi IP vengono forniti anche per organizzazione anziché essere ancorati a una singola subnet principale con ambito a livello di zona. Questa funzionalità consente agli amministratori di specificare i propri indirizzi IP, anziché richiedere a te in qualità di operatore di specificarne uno. Questa funzionalità offre una migliore elasticità e isolamento per le organizzazioni che desiderano un forte isolamento di rete non condividendo una supernet principale.
Per le organizzazioni v1, gli indirizzi IP NAT in uscita erano necessari uno per progetto, per cluster utente e per organizzazione. Per le organizzazioni v2, questo requisito è migliorato notevolmente a uno per progetto, per organizzazione. Questa modifica offre una maggiore efficienza nell'utilizzo degli indirizzi IP forniti dai clienti.
Differenze funzionali tra le organizzazioni v1 e v2
Un'organizzazione v2 fornisce le stesse funzionalità di un'organizzazione v1. Le uniche funzionalità non disponibili in un'organizzazione v2 sono le seguenti:
- Vertex AI
- Interfaccia a riga di comando del servizio di database
Quale architettura utilizzeranno le organizzazioni multizona?
In un universo GDC multizona, se estendi un'organizzazione esistente in una nuova zona, l'organizzazione nella nuova zona deve utilizzare la stessa architettura della zona esistente. Pertanto, l'utilizzo di architetture dell'organizzazione diverse per zona non è supportato.
Come eseguire il provisioning di un'organizzazione v2
Quando viene eseguito il provisioning di un'organizzazione, le organizzazioni v2 vengono create per impostazione predefinita per i clienti non soggetti a procedure di accreditamento.
Tuttavia, le organizzazioni v2 forniscono un cambiamento architettonico significativo. Per le implementazioni dei clienti soggette ad accreditamento, l'architettura dell'organizzazione v1 rimane quella predefinita finché l'architettura dell'organizzazione v2 non completa l'accreditamento.
L'impostazione predefinita dell'architettura dell'organizzazione è controllata da un flag funzionalità configurato quando implementi una zona.
Come forzare l'architettura dell'organizzazione
In rari casi, potresti voler ignorare il comportamento di provisioning predefinito e scegliere di forzare un'architettura organizzativa specifica aggiungendo il campo spec.compatibilityOptions.architectureOverridePolicy alla risorsa Organization durante la procedura di provisioning. Per saperne di più,
vedi la pagina Creare un'organizzazione
cliente.
È sconsigliato ignorare l'architettura organizzativa predefinita, a meno che tu non abbia un valido motivo per forzare un comportamento specifico.
Ad esempio, potresti forzare un'organizzazione v1 se riscontri un problema significativo con un'organizzazione v2 che blocca un'attività. Allo stesso modo, potresti forzare un'organizzazione v2 se richiedi l'accreditamento e hai bisogno di una singola organizzazione v2 per avviare la procedura di accreditamento. Questi flag di override devono essere rimossi quando non sono più strettamente necessari per evitare il provisioning futuro dell'organizzazione con l'architettura errata.
Cosa succede alle organizzazioni v1 esistenti?
Le organizzazioni esistenti create prima di GDC air-gapped 1.14.2 rimangono sulla stessa architettura anche se la zona GDC viene aggiornata alla versione 1.14.2 o successive. Sebbene non sia disponibile alcun upgrade in loco per la conversione delle organizzazioni v1 in organizzazioni v2, le funzionalità esistenti nelle organizzazioni v1 continueranno a essere supportate fino al futuro ritiro dell'architettura dell'organizzazione v1.
Eventuali nuove funzionalità in futuro potrebbero essere aggiunte solo alle organizzazioni v2. Pertanto, ti consigliamo di spostare i carichi di lavoro dalle organizzazioni v1 alla nuova architettura dell'organizzazione v2 il prima possibile. Un singolo universo GDC air-gap può contenere contemporaneamente entrambe le architetture dell'organizzazione, il che semplifica la transizione.