Questo documento presenta le best practice per la progettazione della gerarchia e della separazione dei workload in Google Distributed Cloud (GDC) con air gap utilizzando organizzazioni, progetti e cluster Kubernetes. Queste indicazioni bilanciano l'utilizzo efficiente delle risorse, l'isolamento dei workload e la facilità delle operazioni.
Progetta 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. Il controllo granulare degli accessi tra i workload all'interno di un'organizzazione può essere definito tramite associazioni di ruoli e policy di rete. Per saperne di più, consulta Identity and Access Management.
Ogni organizzazione all'interno di una zona GDC fornisce l'isolamento fisico per l'infrastruttura di computing e l'isolamento logico per il networking, lo spazio di 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 in modo esplicito 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 workload che possono condividere un'organizzazione
L'ambito di un'organizzazione nel contesto della tua azienda potrebbe 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 workload.
In generale, ti consigliamo di raggruppare più workload in un'unica organizzazione in base ai seguenti indicatori:
- I workload possono condividere le dipendenze. Ad esempio, potrebbe trattarsi di un'origine dati condivisa, della connettività tra i workload o di uno strumento di monitoraggio condiviso.
- I workload possono condividere una radice di attendibilità amministrativa. Lo stesso amministratore può avere accesso con privilegi a tutti i workload dell'organizzazione.
- I workload possono condividere l'infrastruttura fisica sottostante con altri workload della stessa organizzazione, purché sia presente una separazione logica sufficiente.
- Lo stesso responsabile 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 workload, consulta la pagina Fatturazione.
- I requisiti di disponibilità del workload devono seguire i requisiti di alta affidabilità per la distanza tra più zone.
Progetta i progetti per l'isolamento logico tra i workload
All'interno di un'organizzazione, consigliamo di eseguire il provisioning di più progetti per creare una separazione logica tra le risorse. I progetti della stessa organizzazione potrebbero condividere l'infrastruttura fisica sottostante, ma vengono utilizzati per separare i workload con un confine logico basato sulle policy di Identity and Access Management (IAM) e sulle policy di rete.
Quando progetti i confini dei progetti, pensa al più grande insieme di funzionalità che può essere condiviso dalle risorse, come associazioni di ruoli, policy di rete o requisiti di osservabilità. Raggruppa le risorse che possono condividere questa funzionalità in un progetto e sposta le risorse che non possono condividere questa funzionalità 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 specifico.
Il seguente diagramma mostra come viene applicata un'associazione di ruoli a un progetto che si estende su più cluster.
Le associazioni dei ruoli vengono impostate a livello di progetto per definire chi può fare cosa su quale tipo di risorsa. Il deployment dei workload, come VM o pod, viene eseguito in un progetto e l'accesso a questi workload è regolato dall'associazione dei ruoli. L'associazione dei ruoli si applica in modo coerente ai workload basati su VM e su container, indipendentemente dal cluster in cui viene eseguito il deployment.
Il seguente diagramma mostra in che modo le policy di rete gestiscono l'accesso tra i progetti.
La comunicazione tra progetti tra Backend Project, Frontend Project e Database Project è disabilitata. Tuttavia, le risorse all'interno di ogni progetto possono comunicare tra loro.
Le policy di rete vengono impostate a livello di progetto per consentire in modo selettivo 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, mentre 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 il deployment delle risorse venga eseguito nello stesso cluster o meno.
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 di dati in ingresso 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 sviluppo software
Per ogni workload, ti consigliamo di creare progetti separati per ogni ambiente di sviluppo software. Un ambiente di sviluppo software è un'area all'interno del tuo universo GDC destinata a tutte le operazioni che corrispondono a una fase del ciclo di vita designata. Ad esempio, potresti avere ambienti di sviluppo software per test, sviluppo e produzione. La separazione degli ambienti di sviluppo software consente di definire in modo granulare le associazioni dei ruoli e le policy di rete, in modo che le modifiche apportate in un progetto utilizzato per un ambiente non di produzione 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, concedi associazioni di ruoli granulari per consentire ai singoli sviluppatori di accedere ad alcune, ma non a tutte, le risorse del progetto. Ad esempio, un team potrebbe avere un amministratore di database che deve gestire il database, ma non modificare altre risorse, mentre gli sviluppatori software del team non devono avere l'autorizzazione per modificare il database.
Progetta i cluster per l'isolamento logico delle operazioni di Kubernetes
Un cluster Kubernetes non è un confine rigido per i tenant perché le associazioni dei ruoli e le policy di rete si applicano ai progetti, non ai cluster Kubernetes. I cluster e i progetti Kubernetes hanno una relazione many-to-many. Potresti avere più cluster Kubernetes in un singolo progetto o un singolo cluster Kubernetes che si estende su più progetti.