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:
- Fornire una gerarchia di proprietà, che associa il ciclo di vita di una risorsa all'elemento padre immediato nella gerarchia.
- Fornire punti di collegamento ed ereditarietà per i criteri dell'organizzazione e del controllo dell'accesso.
La gerarchia delle risorse GDC assomiglia al file system dei 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 figlio.
Per saperne di più sulle best practice per l'organizzazione dei 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:
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 è la parte superiore della gerarchia delle risorse GDC e tutte le risorse appartenenti a un'organizzazione sono raggruppate nella risorsa organizzazione. In questo modo, è possibile visualizzare e controllare centralmente ogni risorsa appartenente a un'organizzazione.
Sia i progetti che i cluster Kubernetes condivisi sono di ambito organizzativo. Possono essere collegati tra loro per organizzare le risorse di servizio. Tuttavia, i progetti e i cluster condivisi funzionano indipendentemente l'uno dall'altro. Questa flessibilità offre molte opzioni diverse per l'organizzazione di servizi e carichi di lavoro. Ad esempio, puoi avere un cluster condiviso dedicato a un singolo progetto. Allo stesso modo, 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 i 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 elementi 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 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 limite 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 creatori. Ciò significa che nessun tipo di risorsa per un'organizzazione viene eliminato se l'utente che l'ha creata lascia l'organizzazione. Al contrario, 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 criteri e autorizzazioni a livello di organizzazione, consulta le sezioni Criteri 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 criteri 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 la durata di una risorsa. Pertanto, devi eseguire il deployment delle 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. La somiglianza dello spazio dei nomi considera tutti gli spazi dei nomi di 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 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 progetto.
- Configurazioni dei criteri 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 carichi di lavoro containerizzati su questi cluster condivisi all'interno di uno spazio dei nomi del progetto. Il concetto di somiglianza dello spazio dei nomi si applica allo spazio dei nomi del progetto su questi cluster condivisi. I criteri con ambito spazio dei nomi, come i criteri 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 carichi di lavoro containerizzati nell'ambito di GKE su GDC. Puoi eseguire il provisioning dei cluster Kubernetes per supportare i requisiti di calcolo delle tue applicazioni.
Un cluster condiviso è una configurazione di cluster con ambito organizzativo e deve essere collegata a uno o più progetti. Il cluster standard è un'altra configurazione di cluster che opera solo all'interno di un singolo progetto, ma è considerata una risorsa di servizio nella gerarchia delle risorse. Queste configurazioni di cluster Kubernetes sono progettate per creare un'architettura Kubernetes che offre opzioni di gestione dei container negli ambienti di sviluppo software, ad esempio per test, sviluppo e produzione. Per saperne di più sulle best practice per la separazione dei carichi di lavoro dei container, consulta Progettare la separazione dei carichi di lavoro.
Per saperne di più sui diversi tipi di cluster in GDC, consulta Configurazioni dei cluster Kubernetes.
I cluster condivisi suddividono le risorse dell'infrastruttura in pool isolati da utilizzare nei progetti all'interno di un'organizzazione. I cluster sono anche 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 condivisi possano essere condivisi tra team e utenti, mantenendo al contempo le garanzie di prestazioni e risorse. Inoltre, le policy dell'organizzazione consentono ai carichi di lavoro delle VM di essere eseguiti insieme ai carichi di lavoro dei container senza introdurre complessità operativa.
I cluster sono utili per le istanze in cui devi eseguire il deployment di carichi di lavoro containerizzati. Tuttavia, con l'opzione di eseguire il deployment di carichi di lavoro basati su VM, l'esistenza di un cluster Kubernetes non è obbligatoria in GDC.
I cluster sono solo una risorsa di zona e non possono estendersi su più zone. Per utilizzare 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
- Carichi di lavoro containerizzati
- Backup
Le risorse di servizio devono appartenere a un progetto e non possono essere condivise tra i 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 la durata della risorsa.
Le risorse di servizio possono essere sottoposte a deployment 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 un criterio dell'organizzazione.