Questa pagina fornisce un'analisi più approfondita di come i parchi risorse aiutano a gestire i deployment multi-cluster, inclusi alcuni concetti e terminologia chiave del parco risorse. I parchi risorse sono un concetto di Google Cloud per l'organizzazione logica dei cluster e di altre risorse. Consente di utilizzare e gestire le funzionalità multi-cluster e di applicare criteri coerenti in tutti i sistemi. I parchi risorse sono una parte fondamentale del funzionamento delle funzionalità multi-cluster aziendali in Google Cloud.
Questa guida è pensata per i lettori tecnici, tra cui architetti di sistema, operatori di piattaforma e operatori di servizi, che vogliono sfruttare più cluster e la relativa infrastruttura. Questi concetti sono utili ovunque la tua organizzazione esegua più cluster, in Google Cloud, su più cloud provider o on-premise.
Avere familiarità con i concetti di base di Kubernetes, come cluster e spazi dei nomi. In caso contrario, consulta le Nozioni di base su Kubernetes, la documentazione di GKE e Preparazione di un'applicazione per Anthos Service Mesh.
Se vuoi saperne di più sulla piattaforma GKE Enterprise e sui componenti che utilizzano i parchi risorse, consulta la panoramica tecnica di GKE Enterprise e il tutorial Esplora GKE Enterprise. Tuttavia, non è necessario avere familiarità con GKE Enterprise per seguire questa guida.
Terminologia
Di seguito sono riportati alcuni termini importanti che utilizziamo quando parliamo di parchi risorse.
Risorse sensibili al parco risorse
Le risorse sensibili al parco risorse sono risorse di progetto Google Cloud che possono essere raggruppate logicamente e gestite come parchi risorse. Al momento solo i cluster Kubernetes possono essere membri del parco risorse.
Progetto host del parco risorse
L'implementazione dei parchi risorse, come molte altre risorse Google Cloud, è basata su un progetto Google Cloud, che definiamo progetto host del parco risorse. Un determinato progetto Google Cloud può essere associato a un singolo parco risorse (o nessun parco risorse). Questa limitazione rafforza l'uso dei progetti Google Cloud per fornire un isolamento più forte tra le risorse che non sono regolate o utilizzate insieme.
Infrastruttura di raggruppamento
Il primo importante concetto di parchi risorse è il concetto di raggruppamento, ovvero la scelta delle parti correlate delle risorse sensibili al parco risorse da far parte di un parco risorse. Per decidere cosa raggruppare devi rispondere alle seguenti domande:
- Le risorse sono correlate tra loro?
- Le risorse che hanno grandi quantità di comunicazioni tra servizi sono i maggiori vantaggi di essere gestite insieme in un parco risorse.
- Le risorse nello stesso ambiente di deployment (ad esempio, l'ambiente di produzione) devono essere gestite insieme in un parco risorse.
- Chi amministra le risorse?
- Avere un controllo unificato (o almeno affidabile) sulle risorse è fondamentale per garantire l'integrità del parco risorse.
Per illustrare questo punto, prendiamo in considerazione un'organizzazione con più linee di business (LOB). In questo caso, i servizi comunicano raramente oltre i confini LOB, i servizi in LOB diverse sono gestiti in modo diverso (ad esempio, i cicli di upgrade variano tra le LOB) e potrebbero anche avere un insieme di amministratori diverso per ogni LOB. In questo caso, potrebbe essere opportuno avere parchi risorse per ogni LOB. Ogni LOB adotta probabilmente più parchi risorse per separare i servizi di produzione da quelli non di produzione.
Poiché nelle sezioni seguenti vengono illustrati altri concetti del parco risorse, potresti trovare altri motivi per creare più parchi risorse, in base alle tue esigenze organizzative specifiche.
Identicità
Un concetto importante nei parchi risorse è il concetto di uguaglianza. Ciò significa che alcuni oggetti Kubernetes come spazi dei nomi con lo stesso nome in cluster diversi vengono trattati come la stessa cosa. Questa normalizzazione rende più trattabile l'amministrazione delle risorse del parco risorse. Offre indicazioni efficaci su come configurare spazi dei nomi, servizi e identità. Tuttavia, segue anche quello che la maggior parte delle organizzazioni sta già implementando.
Uniformità dello spazio dei nomi
L'esempio fondamentale di univocità in un parco risorse è l'identicità dello spazio dei nomi. Gli spazi dei nomi con lo stesso nome in cluster diversi sono considerati uguali da molti componenti. Un altro modo per pensare a questa proprietà è che uno spazio dei nomi è definito logicamente in un intero parco risorse, anche se l'istanza dello spazio dei nomi esiste solo in un sottoinsieme delle risorse del parco risorse.
Considera il seguente esempio di spazio dei nomi backend. Sebbene lo spazio dei nomi sia
instabile solo nei Cluster A e B, è implicitamente riservato nel Cluster C
(consente a un servizio nello spazio dei nomi backend di essere pianificato anche nel Cluster C, se necessario).
Ciò significa che gli spazi dei nomi sono allocati per l'intero parco risorse e non per cluster. Di conseguenza, l'identicità dello spazio dei nomi richiede una proprietà
coerente in tutto il parco risorse.
Identicità del servizio
Anthos Service Mesh e Ingress multi-cluster utilizzano il concetto di uniformità dei servizi all'interno di uno spazio dei nomi. Come per l'identicità dello spazio dei nomi, ciò implica che i servizi con lo stesso spazio dei nomi e lo stesso nome di servizio sono considerati dello stesso servizio.
Nel caso di Anthos Service Mesh, gli endpoint di servizio possono essere uniti nel mesh. Con Ingress multi-cluster, una risorsa MultiClusterService (MCS) rende più esplicita l'unione dell'endpoint; tuttavia, consigliamo pratiche simili in merito alla denominazione. Per questo motivo, è importante assicurarsi che i servizi con nomi identici all'interno dello stesso spazio dei nomi siano in realtà la stessa cosa.
Nell'esempio seguente, il carico del traffico internet viene bilanciato su un servizio con lo stesso nome nello spazio dei nomi frontend presente sia nei Cluster B che nei Cluster C. Analogamente, utilizzando le proprietà del mesh di servizi all'interno del parco risorse, il servizio nello spazio dei nomi frontend può raggiungere un servizio con lo stesso nome nello spazio dei nomi auth presente nei Cluster A e C.
Identità dell'identità uguale quando si accede alle risorse esterne
I servizi all'interno di un parco risorse possono sfruttare un'identità comune durante il traffico in uscita per accedere a risorse esterne come servizi Google Cloud, archivi di oggetti e così via. Questa identità comune consente di concedere ai servizi all'interno di un parco risorse l'accesso a una risorsa esterna una sola volta anziché cluster per cluster.
Per illustrare ulteriormente questo punto, considera l'esempio riportato di seguito. I cluster A, B e C sono registrati con un'identità comune all'interno del parco risorse. Quando i servizi nello spazio dei nomi backend accedono alle risorse Google Cloud, le loro identità vengono mappate a un account di servizio Google Cloud comune chiamato back. L'account di servizio Google Cloud back può essere autorizzato su un numero qualsiasi di servizi gestiti, da Cloud Storage a Cloud SQL. Man mano che nuove risorse del parco risorse, come i cluster, vengono aggiunte nello spazio dei nomi backend, ereditano automaticamente le proprietà di identità dell'identità dei carichi di lavoro.
A causa dell'identicità dell'identità, è importante che tutte le risorse
di un parco risorse siano affidabili e ben regolamentate. Ripensando all'esempio precedente, se il Cluster C è di proprietà di un team separato e non attendibile, anche questi utenti possono creare uno spazio dei nomi backend e accedere ai servizi gestiti come se fossero backend nel Cluster A o B.
Identità dell'identità all'interno di un parco risorse
Nel parco risorse, l'identicità dell'identità viene utilizzata in modo simile a quella esterna di cui abbiamo parlato in precedenza. I servizi del parco risorse possono essere autorizzati una sola volta per un servizio esterno, ma anche internamente.
Nell'esempio seguente, stiamo utilizzando Anthos Service Mesh per creare un mesh di servizi multi-cluster in cui frontend ha accesso a backend.
Con Anthos Service Mesh e i parchi risorse, non è necessario specificare che frontend nei cluster B e C può accedere a backend nei cluster A e B. ma specifichiamo che frontend
nel parco risorse può accedere a backend. Questa proprietà non solo semplifica l'autorizzazione, ma rende anche più flessibili i confini delle risorse. Ora i carichi di lavoro possono essere facilmente spostati da un cluster a un altro senza influire sulla relativa autorizzazione. Come per l'identicità dei carichi di lavoro, la governance sulle risorse del parco risorse è fondamentale per garantire l'integrità della comunicazione tra servizi.
Esclusività
Le risorse sensibili al parco risorse possono appartenere a un solo parco risorse in un determinato momento, una limitazione applicata dagli strumenti e dai componenti di Google Cloud. Questa limitazione garantisce che un cluster sia gestito da una sola fonte attendibile. Senza l'esclusività, anche i componenti più semplici diventarebbero complessi da usare, e la tua organizzazione diventerebbe quindi costretti a definire le modalità di interazione di più componenti di più parchi risorse.
Fiducia elevata
Le stesse caratteristiche dei servizi, delle identità per i carichi di lavoro e dell'identità mesh si basano su un principio di elevata fiducia tra i membri di un parco risorse. Questa attendibilità consente di migliorare il livello di gestione di queste risorse nel parco risorse, anziché gestire risorsa per risorsa (ovvero cluster per cluster per le risorse Kubernetes) e, infine, rende meno importante il confine del cluster.
In altri termini, all'interno di un parco risorse, i cluster forniscono protezione da problemi a livello di raggio di attacco, disponibilità (del piano di controllo e dell'infrastruttura sottostante), vicini rumorosi e così via. Tuttavia, non costituiscono un confine di isolamento netto per criteri e governance perché gli amministratori di qualsiasi membro di un parco risorse possono potenzialmente influire sulle operazioni dei servizi di altri membri del parco risorse.
Per questo motivo, consigliamo di inserire i cluster non considerati attendibili dall'amministratore del parco risorse nei propri parchi risorse per mantenerli isolati. Quindi, se necessario, i singoli servizi possono essere autorizzati attraverso il confine del parco risorse.
Ambiti dei team
Un ambito del team è un meccanismo per suddividere ulteriormente il parco risorse in gruppi di cluster, in modo da definire le risorse sensibili del parco risorse assegnate a uno specifico team dell'applicazione. A seconda del caso d'uso, un singolo cluster membro del parco risorse può essere associato senza team, senza uno o più team, in modo che più team possano condividere i cluster. Puoi utilizzare gli ambiti dei team anche per sequenziare le implementazioni di upgrade dei cluster nel parco risorse, anche se questo richiede che ogni cluster sia associato a un solo team.
A un ambito del team possono essere associati spazi dei nomi del parco risorse esplicitamente definiti, dove lo spazio dei nomi è considerato lo stesso in tutto l'ambito. Questo ti offre un controllo più granulare sugli spazi dei nomi rispetto all'identicità dello spazio dei nomi predefinita fornita dai soli parchi risorse.
Componenti abilitati per il parco risorse
I seguenti componenti di GKE Enterprise e GKE sfruttano i concetti del parco risorse, come l'identicità dello spazio dei nomi e delle identità, per offrire un modo semplificato per lavorare con i tuoi cluster e servizi. Per eventuali requisiti o limitazioni attuali per l'utilizzo dei parchi risorse con ogni componente, consulta i requisiti dei componenti.
Pool di identità per i carichi di lavoro
Un parco risorse offre un pool di identità per i carichi di lavoro comune che può essere utilizzato per autenticare e autorizzare i carichi di lavoro in modo uniforme all'interno di un mesh di servizi e verso i servizi esterni.Anthos Service Mesh
Anthos Service Mesh è una suite di strumenti che consente di monitorare e gestire un mesh di servizi affidabile su Google Cloud, on-premise e in altri ambienti supportati. Puoi creare un mesh di servizi tra cluster che fanno parte dello stesso parco risorse.Config Sync
Config Sync consente di eseguire il deployment e il monitoraggio di pacchetti di configurazione dichiarativi per il sistema archiviati in una fonte attendibile centrale, ad esempio un repository Git, sfruttando i concetti fondamentali di Kubernetes come spazi dei nomi, etichette e annotazioni. Con Config Sync, la configurazione viene definita in tutto il parco risorse, ma applicate e applicate localmente in ciascuna risorsa membro.Policy Controller
Policy Controller consente di applicare e applicare criteri dichiarativi per i cluster Kubernetes. Questi criteri fungono da sistema di protezione e possono aiutarti con la gestione di best practice, sicurezza e conformità dei tuoi cluster e del tuo parco risorse.Ingress multi-cluster
Il parco risorse Ingress multi-cluster utilizza il parco risorse per definire l'insieme di cluster ed endpoint di servizio su cui è possibile bilanciare il carico del traffico, abilitando servizi a bassa latenza e ad alta disponibilità.Cloud Run for Anthos
Cloud Run for Anthos è una piattaforma di sviluppo Knative gestita e supportata da Google che astrae la complessità dell'infrastruttura sottostante, semplificando la creazione, il deployment e la gestione di app e servizi nei cluster del tuo parco risorse.
Che cosa succede dopo?
- Scopri di più su quando utilizzare più cluster per soddisfare le tue esigenze tecniche e aziendali nei Casi d'uso multi-cluster.
- Sei pronto a pensare di applicare questi concetti ai tuoi sistemi? Consulta i nostri requisiti e best practice del parco risorse.