Questo documento descrive la gerarchia delle risorse di Google Distributed Cloud (GDC) con air gap e il modo in cui le risorse vengono gestite in un'istanza con air gap. Per i concetti relativi alla gestione delle risorse in più zone, consulta la panoramica sulle multi-zone.
Lo scopo della gerarchia delle risorse GDC è duplice:
- Forniscono una gerarchia di proprietà, che associa il ciclo di vita di una risorsa all'elemento padre immediato nella gerarchia.
- Fornire i punti di collegamento e l'ereditarietà per i criteri dell'organizzazione e controllo dell'accesso dell'accesso.
La gerarchia delle risorse di GDC assomiglia al file system presente nei sistemi operativi come modo per organizzare e gestire le entità in modo gerarchico. In genere, ogni risorsa ha un solo elemento padre. Questa organizzazione gerarchica delle risorse consente di impostare policy di controllo dell'accesso, come Identity and Access Management (IAM), che vengono ereditate dalle risorse figlio.
Per saperne di più sulle best practice per l'organizzazione dei limiti di accesso, consulta Progetta i limiti di accesso tra le risorse.
Struttura delle risorse in dettaglio
Le seguenti entità sono tipi di risorse riconosciuti nella gerarchia delle risorse GDC:
- Organization (Organizzazione)
- Progetto
- Cluster Kubernetes condiviso
- Risorsa di servizio
Le risorse GDC sono organizzate in modo gerarchico. La maggior parte delle risorse nella gerarchia delle risorse ha un solo elemento padre. L'eccezione si applica solo alla risorsa di livello più alto. Al livello più basso, le risorse di servizio sono i componenti fondamentali di tutti i servizi GDC.
Un'organizzazione è il livello più alto della gerarchia delle risorse GDC e tutte le risorse che appartengono a un'organizzazione sono raggruppate nella risorsa Organizzazione. In questo modo, puoi avere visibilità e controllo centralizzati su ogni risorsa appartenente a un'organizzazione.
Sia i progetti che i cluster Kubernetes condivisi hanno come ambito l'organizzazione. Possono essere collegati tra loro per organizzare le risorse dei servizi. Tuttavia, i progetti e i cluster condivisi funzionano in modo indipendente l'uno dall'altro. Questa flessibilità offre molte opzioni diverse per l'organizzazione di servizi e workload. Ad esempio, puoi avere un cluster condiviso dedicato a un singolo progetto. Analogamente, un cluster condiviso può estendersi su più progetti.
Le risorse di servizio sono entità che devono appartenere a un progetto e non possono essere condivise tra progetti. Esempi di risorse di servizio includono macchine virtuali (VM), cluster Kubernetes standard, database, bucket di archiviazione e backup. La maggior parte di queste risorse di livello inferiore ha come risorse padre le risorse di progetto.
Il seguente diagramma rappresenta un esempio di gerarchia delle risorse GDC:
Per saperne di più sulle best practice per l'organizzazione della gerarchia delle risorse per una gestione ottimale dei workload, consulta Progetta la separazione dei workload degli utenti.
Organizzazione
La risorsa organizzazione rappresenta un'unità amministrativa o una funzione aziendale, ad esempio un'azienda, ed è la risorsa di primo livello nella gerarchia delle risorse GDC. Un'organizzazione definisce un confine di sicurezza che racchiude le risorse dell'infrastruttura da amministrare insieme in modo che gli utenti possano eseguire il deployment dei workload delle applicazioni. Le organizzazioni sono globali e coprono tutte le zone di un universo. All'interno di un'organizzazione, le risorse di servizio come le VM e i volumi di archiviazione sono raggruppate logicamente per progetti.
Tutti i progetti, i cluster e le risorse di servizio appartengono alla tua organizzazione, non ai relativi creatori. Ciò significa che nessun tipo di risorsa di un'organizzazione viene eliminato se l'utente che lo ha creato lascia l'organizzazione. Tutti i tipi di risorse seguono invece il ciclo di vita dell'organizzazione in GDC.
Le policy di controllo dell'accesso IAM applicate alla risorsa organizzazione si applicano a tutta la gerarchia su tutte le risorse dell'organizzazione. Per saperne di più sulla concessione di policy e autorizzazioni a livello di organizzazione, consulta le sezioni Policy dell'organizzazione e IAM.
Progetto
Un progetto è un'unità di tenancy che ogni servizio deve integrare. I progetti forniscono un gruppo logico delle risorse dei servizi. I progetti sono globali e coprono tutte le zone di un universo.
I progetti consentono la segmentazione delle risorse di servizio all'interno di un'organizzazione e forniscono un confine per il ciclo di vita e le policy per la gestione delle risorse. Le risorse di servizio all'interno di un progetto non possono mai sopravvivere al progetto stesso o spostarsi tra i progetti, garantendo che il controllo sia disponibile per tutta la durata di una risorsa. Pertanto, devi eseguire il deployment di risorse di qualsiasi tipo all'interno di uno spazio dei nomi del progetto.
Un progetto è considerato uno spazio dei nomi Kubernetes appropriato che si estende su più cluster condivisi in un'organizzazione. L'identicità degli spazi dei nomi considera tutti gli spazi dei nomi con un determinato nome come lo stesso spazio dei nomi per tutti i cluster condivisi all'interno della stessa organizzazione. Il singolo spazio dei nomi ha un proprietario coerente nell'insieme di cluster condivisi. I fornitori di servizi creano servizi con ambito di progetto creando componenti del control plane e del piano dati nello spazio dei nomi.
Lo spazio dei nomi di un progetto ospita quanto segue:
- API di servizio con ambito a livello di progetto.
- Configurazioni delle policy a livello di progetto, come ruoli e associazioni di ruoli.
Puoi collegare un progetto solo a un sottoinsieme di cluster condivisi in un'organizzazione. Puoi eseguire il deployment dei workload containerizzati su questi cluster condivisi all'interno di uno spazio dei nomi del progetto. Il concetto di identicità dello spazio dei nomi si applica allo spazio dei nomi del progetto su questi cluster condivisi. Le policy con ambito a livello di spazio dei nomi, come le policy di controllo degli accessi basato su ruoli (RBAC), si applicano a tutti questi spazi dei nomi.
Per saperne di più sui progetti, consulta la panoramica dei progetti.
Cluster Kubernetes condiviso
Un cluster Kubernetes è un insieme di nodi che eseguono workload containerizzati nell'ambito di GKE su GDC. Puoi eseguire il provisioning dei cluster Kubernetes per supportare i requisiti di computing delle tue applicazioni.
Un cluster condiviso è una configurazione del cluster con ambito a livello di organizzazione e deve essere collegato a uno o più progetti. Il cluster standard è un'altra configurazione del cluster che opera solo all'interno di un singolo progetto, ma è considerato una risorsa di servizio nella gerarchia delle risorse. Queste configurazioni dei cluster Kubernetes sono progettate per creare un'architettura Kubernetes che offre opzioni di gestione dei container in ambienti di sviluppo software, ad esempio per test, sviluppo e produzione. Per ulteriori informazioni sulle best practice per la separazione dei workload dei container, consulta Progetta la separazione dei workload.
Per ulteriori informazioni sui diversi tipi di cluster in GDC, consulta Configurazioni dei cluster Kubernetes.
I cluster condivisi suddividono le risorse dell'infrastruttura in pool isolati che possono essere utilizzati dai progetti all'interno di un'organizzazione. I cluster sono inoltre separati logicamente tra loro per fornire domini in errore e garanzie di isolamento diversi. L'applicazione delle policy per organizzazione garantisce che i cluster condivisi possano essere condivisi tra team e utenti, mantenendo al contempo le garanzie di prestazioni e risorse. Inoltre, le policy dell'organizzazione consentono l'esecuzione dei workload delle VM insieme ai workload dei container senza introdurre complessità operative.
I cluster sono utili nei casi in cui devi eseguire il deployment di workload containerizzati. Tuttavia, con l'opzione per il deployment di workload basati su VM, l'esistenza di un cluster Kubernetes non è richiesta in GDC.
I cluster sono una risorsa di zona e non possono estendersi su più zone. Per gestire i cluster in un deployment multizona, devi eseguire manualmente il deployment dei cluster in ogni zona.
Per saperne di più sui cluster Kubernetes, consulta la panoramica dei cluster Kubernetes.
Risorsa di servizio
Le risorse di servizio includono molte entità, ad esempio:
- VM
- Cluster Kubernetes standard
- Database
- Bucket di archiviazione
- Workload containerizzati
- Backup
Le risorse di servizio devono appartenere a un progetto e non possono essere condivise tra progetti. Questo ciclo di vita specifico del progetto significa che le risorse di servizio all'interno di un progetto non possono mai sopravvivere al progetto stesso, garantendo che il controllo sia disponibile per tutta la durata della risorsa.
Il deployment delle risorse di servizio può essere eseguito a livello globale o di zona, a seconda del tipo. Consulta la documentazione del servizio specifico per informazioni sulle opzioni di deployment multizona. Le risorse di servizio sono abilitate per impostazione predefinita e possono essere disabilitate utilizzando una policy dell'organizzazione.