Questo documento introduce le best practice per la progettazione della gerarchia e della 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 le 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 dell'accesso granulare tra i carichi di lavoro all'interno di un'organizzazione può essere definito tramite i binding dei ruoli e le policy di rete. Per ulteriori informazioni, consulta
Identity and Access Management.
Ogni organizzazione all'interno di una zona GDC fornisce l'isolamento fisico per l'infrastruttura di calcolo e l'isolamento logico per la rete, 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 l'accesso. Per impostazione predefinita, la connettività di rete da un'organizzazione a un'altra non è consentita, a meno che non sia configurata esplicitamente per consentire il trasferimento dei dati da un'organizzazione e il trasferimento dei dati in un'altra.
Definire l'ambito dei carichi di lavoro che possono condividere un'organizzazione
L'ambito di un'organizzazione nel contesto aziendale può variare a seconda di come la tua azienda definisce i confini di attendibilità. Alcune aziende potrebbero preferire creare più risorse dell'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 i 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ò essere considerato attendibile con accesso privilegiato a tutti i carichi di lavoro dell'organizzazione.
- I carichi di lavoro possono condividere l'infrastruttura fisica sottostante con altri carichi di lavoro nella stessa organizzazione, a condizione che sia in vigore una separazione logica sufficiente.
- Lo stesso titolare del budget ha la responsabilità dei budget dei carichi di lavoro in aggregato. Per i dettagli sulla visualizzazione dei costi aggregati per l'organizzazione o sull'analisi granulare per carico di lavoro, consulta la pagina Fatturazione.
- I requisiti di disponibilità dei carichi di lavoro devono rispettare i requisiti di alta affidabilità per la distanza multizona.
Progettare i progetti per l'isolamento logico tra i carichi di lavoro
All'interno di un'organizzazione, ti 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 policy di Identity and Access Management (IAM) e policy di rete.
Quando progetti i limiti dei progetti, pensa al set più grande di funzionalità che possono essere condivise dalle risorse, come i binding dei ruoli, le policy di rete, o i 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 a tutti i cluster di un'organizzazione. Sebbene uno spazio dei nomi sia riservato a più cluster, ciò non significa che un pod venga pianificato automaticamente su tutti i cluster. Un pod pianificato per un cluster specifico rimane pianificato per quel cluster specifico.
Il seguente diagramma mostra come viene applicato un binding di ruolo 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 carichi di lavoro come le VM o i pod vengono sottoposti a deployment in un progetto e l'accesso a questi carichi di lavoro è regolato dal binding di ruolo. Il binding di ruolo si applica in modo coerente ai carichi di lavoro basati su VM e ai carichi di lavoro basati su container, indipendentemente dal cluster in cui vengono sottoposti a deployment.
Il seguente diagramma mostra come 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 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 siano sottoposte a deployment 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 consentire 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.
Creare progetti per ambiente di sviluppo software
Per ogni carico di lavoro, 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 i binding dei ruoli e le policy di rete in modo granulare, in modo che le modifiche apportate a un progetto utilizzato per un ambiente non di produzione non influiscano sull'ambiente di produzione.
Concedere associazioni di ruoli a livello di risorsa all'interno dei progetti
A seconda della struttura e dei requisiti del 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 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 software del team non devono avere l'autorizzazione per modificare il database.
Progettare i cluster per l'isolamento logico delle operazioni Kubernetes
Un cluster Kubernetes non è un limite rigido del tenant perché i binding dei ruoli e le policy di rete si applicano ai progetti, non ai cluster Kubernetes. I cluster e i progetti Kubernetes 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.