Questa pagina fornisce un approfondimento su 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 organizzare logicamente i cluster e altre risorse, consentendoti di utilizzare e gestire le funzionalità multi-cluster e di applicare criteri coerenti tra i tuoi sistemi. I parchi risorse sono una parte cruciale del funzionamento delle funzionalità multi-cluster aziendali in Google Cloud.
Questa guida è rivolta ai lettori tecnici, tra cui architetti di sistemi, operatori di piattaforma e operatori di servizi, che vogliono sfruttare più cluster e l'infrastruttura correlata. Questi concetti sono utili ovunque la tua organizzazione esegua più cluster, sia in Google Cloud, su più cloud provider oppure on-premise.
Avere familiarità con i concetti di base di Kubernetes, come i cluster e gli spazi dei nomi. In caso contrario, consulta le nozioni di base di Kubernetes, la documentazione di GKE e la pagina Preparazione di un'applicazione per Cloud Service Mesh.
Per 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 usiamo quando parliamo di flotte.
Risorse che riconoscono il 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, è radicata in un progetto Google Cloud, che definiamo progetto host del parco risorse. A un determinato progetto Google Cloud può essere associato un solo gruppo (o nessun parco risorse). Questa limitazione rafforza l'utilizzo dei progetti Google Cloud per garantire un maggiore isolamento tra le risorse non regolate o utilizzate insieme.
Infrastruttura di raggruppamento
Il primo importante concetto di parchi risorse è il concetto di raggruppamento, ovvero scegliere quali risorse correlate in base al parco risorse deve far parte di un parco risorse. Per decidere cosa raggruppare è necessario rispondere alle seguenti domande:
- Le risorse sono correlate tra loro?
- Le risorse che hanno grandi quantità di comunicazioni tra servizi traggono il massimo vantaggio dalla gestione collettiva in un parco risorse.
- Le risorse nello stesso ambiente di deployment (ad esempio, il tuo ambiente di produzione) devono essere gestite insieme in un parco risorse.
- Chi amministra le risorse?
- Avere un controllo unificato (o almeno reciprocamente attendibile) sulle risorse è fondamentale per garantire l'integrità del parco risorse.
Per spiegare questo punto, consideriamo un'organizzazione che ha più line-of-business (LOB). In questo caso, i servizi raramente comunicano tra le line-of-business, i servizi nelle varie LOB vengono gestiti in modo diverso (ad esempio, i cicli di upgrade variano a seconda delle LOB) e potrebbero anche avere un insieme diverso di amministratori per ogni LOB. In questo caso, avrebbe senso avere parchi per ogni LOB. Inoltre, è probabile che ciascuna LOB adotti più parchi risorse per separare i servizi di produzione da quelli non di produzione.
Man mano che altri concetti del parco risorse vengono esplorati nelle sezioni seguenti, potresti trovare altri motivi per creare più parchi risorse se consideri le tue esigenze organizzative specifiche.
Uniformità
Un concetto importante nelle flotte è quello di uguaglianza. Ciò significa che alcuni oggetti Kubernetes, come gli spazi dei nomi con lo stesso nome in cluster diversi, vengono trattati come la stessa cosa. Questa normalizzazione consente di gestire le risorse del parco risorse in modo più gestibile. Fornisce alcune solide indicazioni su come configurare spazi dei nomi, servizi e identità. Tuttavia, segue anche ciò che la maggior parte delle organizzazioni ha già implementato autonomamente.
Identicità dello spazio dei nomi
L'esempio fondamentale di uguaglianza 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 di 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 dello spazio dei nomi backend. Sebbene lo spazio dei nomi sia
basato solo nei cluster A e B, è implicitamente riservato nel cluster C
(consente di pianificare anche un servizio nello spazio dei nomi backend nel cluster C, se necessario).
Ciò significa che gli spazi dei nomi vengono allocati all'intero parco risorse e non per cluster. Di conseguenza, l'identicità dello spazio dei nomi
richiede una proprietà coerente in tutto il parco risorse.
Uguaglianza dei servizi
Il mesh di servizi cloud e Ingress multi-cluster utilizzano il concetto di uguaglianza dei servizi all'interno di uno spazio dei nomi. Come l'identicità dello spazio dei nomi, ciò implica che i servizi con lo stesso spazio dei nomi e lo stesso nome di servizio siano considerati lo stesso servizio.
Nel caso di Cloud Service Mesh, gli endpoint di servizio possono essere uniti nel mesh. Con Ingress multi-cluster, una risorsa MultiClusterService (MCS) rende l'unione degli endpoint più esplicita. Tuttavia, consigliamo pratiche simili per quanto riguarda la denominazione. Per questo motivo, è importante garantire che i servizi con nomi identici nello stesso spazio dei nomi siano in realtà la stessa cosa.
Nell'esempio seguente, il traffico internet viene bilanciato in un servizio con lo stesso nome nello spazio dei nomi frontend presente nei cluster B e C. Allo stesso modo,
utilizzando le proprietà 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.
Identicità dell'identità durante l'accesso 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, consideriamo l'esempio seguente. I cluster A, B e C sono registrati
con identità comune nel 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 denominato back. L'account di servizio Google Cloud back può essere autorizzato su un numero qualsiasi di servizi gestiti, da Cloud Storage a Cloud SQL. Quando vengono aggiunte nuove risorse del parco risorse, come i cluster, allo spazio dei nomi backend, queste ereditano automaticamente le proprietà di uguaglianza dell'identità dei carichi di lavoro.
A causa dell'identicità delle identità, è importante che tutte le risorse in un parco risorse siano attendibili e ben regolamentate. Riprendendo l'esempio precedente, se il Cluster C è
di proprietà di un team separato e non attendibile, anch'esso può creare uno spazio dei nomi backend
e accedere ai servizi gestiti come se fosse il backend nel cluster A
o B.
Identicità delle identità all'interno di un parco risorse
All'interno del parco risorse, l'identicità delle identità viene utilizzata in modo simile a quella esterna di cui abbiamo parlato in precedenza. Così come i servizi del parco risorse sono autorizzati una volta per un servizio esterno, possono essere autorizzati anche internamente.
Nell'esempio seguente, utilizziamo Cloud Service Mesh per creare un mesh di servizi multi-cluster in cui frontend ha accesso a backend.
Con il mesh di servizi Cloud e i parchi risorse, non è necessario specificare che frontend nei cluster B e C possa accedere a backend nei cluster A e B. Specifichiamo invece solo che frontend
nel parco risorse può accedere a backend nel parco risorse. 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 all'altro senza influire sul modo in cui vengono autorizzati. Come per l'identicità delle identità dei carichi di lavoro, la governance delle risorse del parco risorse è fondamentale per garantire l'integrità della comunicazione tra servizi.
Esclusività
Le risorse sensibili al parco risorse possono essere membri di un unico parco risorse in un determinato momento, una limitazione applicata dagli strumenti e dai componenti di Google Cloud. Questa limitazione garantisce che ci sia una sola fonte attendibile che gestisce un cluster. Senza l'esclusività, anche i componenti più semplici diventerebbero complessi da usare, il che costringe la tua organizzazione a ragionare e a configurare il modo in cui interagiscono più componenti di più parchi risorse.
Attendibilità elevata
L'uguaglianza dei servizi, l'identicità delle identità dei carichi di lavoro e delle identità mesh si basano su un principio di elevata affidabilità tra i membri di un parco risorse. Questo trust consente di migliorare la gestione di queste risorse nel parco risorse, anziché gestire risorsa per risorsa (ovvero cluster per cluster per le risorse Kubernetes), rendendo il confine del cluster meno importante.
In altre parole, all'interno di un parco risorse, i cluster offrono protezione da problemi di raggio d'attacco, disponibilità (sia del piano di controllo che dell'infrastruttura sottostante), dei vicini rumorosi e così via. Tuttavia, non rappresentano un forte limite di isolamento per i criteri e la governance, perché gli amministratori di qualsiasi membro di un parco risorse possono potenzialmente influire sulle operazioni dei servizi in altri membri del parco risorse.
Per questo motivo, consigliamo di collocare i cluster non attendibili dall'amministratore del parco risorse nei propri parchi risorse per mantenerli isolati. Quindi, se necessario, i singoli servizi possono essere autorizzati in tutto il parco risorse.
Ambiti dei team
L'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 delle applicazioni. A seconda del caso d'uso, un singolo cluster membro del parco risorse può essere associato senza team, un team o più team, consentendo a più team di condividere cluster. Puoi utilizzare gli ambiti dei team anche per sequenziare le implementazioni degli upgrade dei cluster nel parco risorse, anche se ciò richiede che ogni cluster sia associato a un solo team.
A un ambito del team possono essere associati spazi dei nomi del parco risorse definiti in modo esplicito, dove lo spazio dei nomi è considerato uguale in tutto l'ambito. In questo modo, avrai 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 GKE Enterprise e GKE sfruttano tutti 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 di 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 servizi esterni.Cloud Service Mesh
Cloud Service Mesh è una suite di strumenti che ti consente di monitorare e gestire un mesh di servizi affidabile su Google Cloud, on-premise e altri ambienti supportati. Puoi creare un mesh di servizi tra i cluster che fanno parte dello stesso parco risorse.Config Sync
Config Sync consente di eseguire il deployment e monitorare pacchetti di configurazione dichiarativi per il tuo sistema archiviati in una fonte attendibile centrale, come 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 applicata e applicata localmente in ciascuna delle risorse dei membri.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
Ingress multi-cluster utilizza il parco risorse per definire l'insieme di cluster e endpoint di servizio su cui è possibile bilanciare il carico del traffico, abilitando servizi a bassa latenza e ad alta disponibilità.Knative serving
Knative serving è una piattaforma di sviluppo Knative supportata e gestita da Google che elimina 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 in Casi d'uso multi-cluster.
- Vuoi iniziare ad applicare questi concetti ai tuoi sistemi? Consulta i nostri requisiti e best practice per il parco risorse.