Questo documento descrive la gerarchia delle risorse di Google Distributed Cloud (GDC) con air gap e come vengono gestite le risorse in un'istanza con air gap. Per i concetti sulla gestione delle risorse in più zone, consulta la panoramica multizona.
Lo scopo della gerarchia delle risorse GDC è duplice:
- Fornisce una gerarchia di proprietà, che associa il ciclo di vita di una risorsa al suo elemento padre immediato nella gerarchia.
- Fornire punti di collegamento e ereditarietà per i criteri dell'organizzazione e controllo dell'accesso dell'accesso.
La gerarchia delle risorse 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 criteri di controllo dell'accesso, come Identity and Access Management (IAM), che vengono ereditati dalle risorse secondarie.
Per saperne di più sulle best practice per organizzare i limiti di accesso, consulta Progettare 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
- 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 si trova in cima alla gerarchia delle risorse GDC e tutte le risorse appartenenti a un'organizzazione sono raggruppate nella risorsa organizzazione. In questo modo, puoi visualizzare e controllare centralmente ogni risorsa che appartiene a un'organizzazione.
Sia i progetti che i cluster sono limitati all'ambito dell'organizzazione. Possono essere collegati tra loro per organizzare le risorse del servizio. Tuttavia, i progetti e i cluster funzionano in modo indipendente l'uno dall'altro. Questa flessibilità offre molte opzioni diverse per organizzare servizi e carichi di lavoro. Ad esempio, puoi avere un cluster dedicato a un singolo progetto. Allo stesso modo, un cluster può estendersi su più progetti.
Le risorse di servizio sono entità che devono appartenere a un progetto o a un cluster e non possono essere condivise tra progetti o cluster. Esempi di risorse di servizio includono macchine virtuali (VM), database, bucket di archiviazione e backup. La maggior parte di queste risorse di livello inferiore ha come genitori le risorse del progetto.
Il seguente diagramma rappresenta un esempio di gerarchia delle risorse GDC:
Per ulteriori informazioni sulle best practice per l'organizzazione della gerarchia delle risorse per una gestione ottimale dei carichi di lavoro, consulta Progettare la separazione dei carichi di lavoro 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 carichi di lavoro 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 anziché ai loro autori. Ciò significa che qualsiasi tipo di risorsa per un'organizzazione non viene eliminato se l'utente che l'ha creato lascia l'organizzazione. Invece, tutti i tipi di risorse seguono il ciclo di vita dell'organizzazione in GDC.
I criteri di controllo dell'accesso IAM applicati alla risorsa organizzazione si applicano a tutta la gerarchia su tutte le risorse dell'organizzazione. Per saperne di più sulla concessione di autorizzazioni e policy 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 raggruppamento logico delle risorse di servizio. 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 ciclo di vita e un limite di 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 l'intera 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 in un'organizzazione. L'identicità dello spazio dei nomi considera tutti gli spazi dei nomi con un determinato nome come lo stesso spazio dei nomi per tutti i cluster all'interno della stessa organizzazione. Il singolo spazio dei nomi ha un proprietario coerente nell'insieme di cluster. I fornitori di servizi creano servizi con ambito di progetto creando componenti del control plane e del data plane nello spazio dei nomi.
Lo spazio dei nomi di un progetto ospita quanto segue:
- API di servizio con ambito a livello di progetto.
- Configurazioni dei criteri a livello di progetto, come ruoli e binding dei ruoli.
Puoi collegare un progetto solo a un sottoinsieme di cluster di un'organizzazione. Puoi eseguire il deployment dei carichi di lavoro containerizzati su questi cluster all'interno di uno spazio dei nomi del progetto. Il concetto di identità dello spazio dei nomi si applica allo spazio dei nomi del progetto su questi cluster. I criteri con ambito spazio dei nomi, come i criteri di controllo dell'accesso basato sui ruoli (RBAC), si applicano a tutti questi spazi dei nomi.
Per saperne di più sui progetti, consulta la Panoramica dei progetti.
Cluster Kubernetes
Un cluster Kubernetes è un insieme di nodi che eseguono carichi di lavoro containerizzati come parte di GKE su GDC. Puoi eseguire il provisioning dei cluster Kubernetes per supportare i requisiti di calcolo delle tue applicazioni. I cluster sono limitati all'organizzazione e devono essere collegati a uno o più progetti.
I cluster suddividono le risorse dell'infrastruttura in pool isolati da utilizzare dai progetti all'interno di un'organizzazione. I cluster sono inoltre separati logicamente l'uno dall'altro per fornire diversi domini di errore e garanzie di isolamento. L'applicazione dei criteri per organizzazione garantisce che i cluster possano essere condivisi tra team e utenti, mantenendo al contempo le prestazioni e le garanzie delle risorse. Inoltre, i criteri dell'organizzazione consentono ai workload delle VM di essere eseguiti insieme ai workload dei container senza introdurre complessità operative.
I cluster sono utili per le istanze in cui devi eseguire il deployment di carichi di lavoro containerizzati. Tuttavia, con l'opzione di deployment dei carichi di lavoro 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 ulteriori informazioni sui cluster Kubernetes, consulta la sezione Gestire i cluster Kubernetes.
Risorsa di servizio
Le risorse di servizio includono molte entità, ad esempio:
- VM
- Database
- Bucket di archiviazione
- Carichi di lavoro containerizzati
- Backup
Le risorse di servizio devono appartenere a un progetto o, facoltativamente, a un cluster per i workload containerizzati e non possono essere condivise tra i progetti. Ciò 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.
Le risorse di servizio possono essere implementate a livello globale o di zona a seconda del tipo. Per informazioni sulle opzioni di deployment multizona, consulta la documentazione del servizio specifico. Le risorse di servizio sono attive per impostazione predefinita e possono essere disattivate utilizzando un criterio dell'organizzazione.