Questo documento introduce le best practice per la progettazione della gerarchia e la separazione dei carichi di lavoro in Google Distributed Cloud (GDC) air-gapped utilizzando organizzazioni, progetti e cluster Kubernetes. Queste indicazioni bilanciano l'utilizzo efficiente delle risorse, l'isolamento dei carichi di lavoro e la facilità delle operazioni.
Progettare organizzazioni per l'isolamento fisico e logico tra i clienti
La risorsa Organization è la radice di tutte le risorse di proprietà di un singolo cliente. Controllo dell'accesso granulare tra i carichi di lavoro all'interno di un'organizzazione può
essere definito tramite i binding dei ruoli e i criteri di rete. Per ulteriori informazioni, consulta la sezione
Gestione dell'identità e dell'accesso.
Ogni organizzazione all'interno di una zona GDC fornisce l'isolamento fisico per l'infrastruttura di calcolo e l'isolamento logico per il networking, l'archiviazione e altri servizi. Gli utenti di un'organizzazione non hanno accesso alle risorse di un'altra organizzazione, a meno che non venga concesso esplicitamente. La connettività di rete da un'organizzazione all'altra non è consentita per impostazione predefinita, a meno che non sia configurata esplicitamente per consentire il trasferimento di dati in uscita da un'organizzazione e il trasferimento di dati in entrata in un'altra.
Definisci l'ambito dei carichi di lavoro che possono condividere un'organizzazione
L'ambito di un'organizzazione nel contesto della tua azienda può variare in base a come la tua azienda definisce i confini di attendibilità. Alcune aziende potrebbero preferire creare più risorse organizzazione per entità diverse dell'azienda. Ad esempio, ogni reparto aziendale potrebbe essere un cliente indipendente di GDC con un'organizzazione indipendente se i reparti richiedono una separazione fisica e amministrativa completa dei propri carichi di lavoro.
In generale, ti consigliamo di raggruppare più carichi di lavoro in una singola organizzazione in base ai seguenti indicatori:
- I carichi di lavoro possono condividere le dipendenze. Ad esempio, potrebbe trattarsi di un'origine dati condivisa, della connettività tra carichi di lavoro o di uno strumento di monitoraggio condiviso.
- I carichi di lavoro possono condividere una radice di attendibilità amministrativa. Lo stesso amministratore può avere accesso privilegiato a tutti i workload dell'organizzazione.
- I carichi di lavoro possono condividere l'infrastruttura fisica sottostante con altri carichi di lavoro nella stessa organizzazione, a condizione che sia presente una separazione logica sufficiente.
- Lo stesso titolare del budget è responsabile dei budget dei workload nel loro complesso. Per informazioni dettagliate sulla visualizzazione dei costi aggregati per l'organizzazione o sull'analisi granulare per carico di lavoro, consulta la pagina Fatturazione.
- I requisiti di disponibilità del carico di lavoro devono rispettare i requisiti di alta disponibilità per la distanza multizona.
Progetta progetti per l'isolamento logico tra i carichi di lavoro
All'interno di un'organizzazione, consigliamo di eseguire il provisioning di più progetti per creare una separazione logica tra le risorse. I progetti nella stessa organizzazione potrebbero condividere l'infrastruttura fisica sottostante, ma vengono utilizzati per separare i carichi di lavoro con un limite logico basato su criteri Identity and Access Management (IAM) e criteri di rete.
Quando progetti i confini del progetto, pensa al più grande insieme di funzionalità che possono essere condivise dalle risorse, come associazioni di ruoli, norme di rete o requisiti di osservabilità. Raggruppa le risorse che possono condividere questa funzionalità in un progetto e sposta le risorse che non possono condividerla in un altro progetto.
In termini di Kubernetes, un progetto è uno spazio dei nomi Kubernetes riservato in tutti i cluster di un'organizzazione. Anche se uno spazio dei nomi è riservato in più cluster, ciò non significa che un pod venga pianificato automaticamente in tutti i cluster. Un pod pianificato per un determinato cluster rimane pianificato per quel cluster.
Il seguente diagramma mostra come viene applicata un'associazione di ruoli a un progetto che si estende su più cluster.
I binding dei ruoli vengono impostati a livello di progetto per definire chi può fare cosa su quale tipo di risorsa. I workload come VM o pod vengono distribuiti in un progetto e l'accesso a questi workload è regolato dal binding dei ruoli. Il binding del ruolo si applica in modo coerente ai carichi di lavoro basati su VM e a quelli basati su container, indipendentemente dal cluster in cui vengono implementati.
Il seguente diagramma mostra come i criteri di rete gestiscono l'accesso tra i progetti.
La comunicazione tra progetti tra Backend Project, Frontend Project e Database Project è disattivata. Tuttavia, le risorse all'interno di ogni progetto possono
comunicare tra loro.
I criteri di rete vengono impostati a livello di progetto per consentire selettivamente l'accesso alla rete tra le risorse. Per impostazione predefinita, tutte le risorse all'interno di un singolo progetto possono comunicare tra loro sulla rete interna e una risorsa in un progetto non può comunicare con una risorsa in un altro progetto. Questo comportamento per le policy di rete si applica indipendentemente dal fatto che le risorse vengano o meno implementate nello stesso cluster.
Puoi anche definire una risorsa personalizzata ProjectNetworkPolicy per abilitare
la comunicazione tra progetti. Questa policy è definita per ogni progetto per consentire
il traffico in entrata da altri progetti. Il seguente diagramma illustra una
risorsa personalizzata ProjectNetworkPolicy definita per Backend Project per
abilitare il trasferimento dei dati da Frontend Project e Database Project.
Inoltre, lo stack di monitoraggio raccoglie le metriche in tutta l'organizzazione, ma puoi filtrare ed eseguire query a vari livelli della gerarchia delle risorse. Puoi eseguire query sulle metriche con entità come un cluster o uno spazio dei nomi.
Crea progetti per ambiente di deployment
Per ogni carico di lavoro, ti consigliamo di creare progetti separati per la produzione, lo sviluppo e qualsiasi altro ambiente di deployment di cui hai bisogno. La separazione degli ambienti di deployment di produzione e sviluppo ti consente di definire in modo granulare i binding dei ruoli e le norme di rete, in modo che le modifiche apportate a un progetto utilizzato per lo sviluppo non influiscano sull'ambiente di produzione.
Concedi associazioni di ruoli a livello di risorsa all'interno dei progetti
A seconda della struttura e dei requisiti del tuo team, potresti consentire agli sviluppatori di modificare qualsiasi risorsa all'interno del progetto che gestiscono oppure potresti richiedere un controllo dell'accesso più granulare. All'interno di un progetto, puoi concedere associazioni di ruoli granulari per consentire ai singoli sviluppatori di accedere ad alcune risorse del progetto, ma non a tutte. Ad esempio, un team potrebbe avere un amministratore di database che deve gestire il database ma non modificare altre risorse, mentre gli sviluppatori di software del team non devono avere l'autorizzazione per modificare il database.
Progetta cluster per l'isolamento logico delle operazioni Kubernetes
Un cluster Kubernetes non è un limite rigido del tenant perché le associazioni di ruoli e i criteri di rete si applicano ai progetti, non ai cluster Kubernetes. I cluster Kubernetes e i progetti hanno una relazione di tipo many-to-many. Potresti avere più cluster Kubernetes in un singolo progetto o un singolo cluster Kubernetes che si estende su più progetti.