Questa pagina fornisce un'analisi più approfondita di come i parchi risorse ti aiutano a gestire i deployment multi-cluster, incluse alcune terminologie e concetti chiave dei parchi risorse. I parchi risorse sono un Google Cloud concetto per l'organizzazione logica dei cluster e di altre risorse; ti consentono di utilizzare e gestire le funzionalità multi-cluster e di applicare criteri coerenti in tutti i tuoi sistemi. I parchi risorse costituiscono un elemento fondamentale del funzionamento della funzionalità multi-cluster aziendale in Google Cloud.
Questa guida è progettata per lettori tecnici, tra cui architetti di sistema, operatori di piattaforme e operatori di servizi, che vogliono sfruttare più cluster e l'infrastruttura correlata. Questi concetti sono utili ovunque la tua organizzazione esegue più cluster, inGoogle Cloud, su più cloud provider o on-premise.
Prima di leggere questa pagina, assicurati di conoscere i concetti di base di Kubernetes, come i cluster e i nomi di spazio, se non lo hai già fatto, consulta la sezione Concetti di base di Kubernetes, la documentazione di GKE e Preparazione di un'applicazione per Cloud Service Mesh.
Per scoprire di più sulla piattaforma GKE Enterprise e sui componenti che utilizzano i parchi risorse, consulta la nostra panoramica tecnica di GKE Enterprise e il tutorial Esplora GKE Enterprise. Tuttavia, non è necessario conoscere GKE Enterprise per seguire questa guida.
Terminologia
Di seguito sono riportati alcuni termini importanti che utilizziamo quando parliamo di parchi.
Risorse consapevoli del parco risorse
Le risorse a conoscenza del parco risorse sono risorse di progetti Google Cloud che possono essere raggruppate e gestite logicamente come parchi risorse. Al momento, solo i cluster Kubernetes possono essere membri del parco.
Progetto host del parco risorse
L'implementazione dei parchi risorse, come molte altre Google Cloud risorse, si basa su un progetto Google Cloud, che chiamiamo progetto host del parco risorse. Un determinato progetto Google Cloud può avere associato un solo parco risorse (o nessun parco risorse). Questa limitazione rafforza l'utilizzo dei progetti Google Cloud per fornire un isolamento più efficace tra le risorse che non sono gestite o utilizzate insieme.
Infrastruttura di raggruppamento
Il primo concetto importante dei parchi è il concetto di raggruppamento, ovvero scegliere quali parti di risorse aware del parco correlate devono essere incluse in un parco. La decisione su cosa raggruppare richiede di rispondere alle seguenti domande:
- Le risorse sono correlate tra loro?
- Le risorse con un volume elevato di comunicazioni tra servizi traggono il massimo vantaggio dalla gestione collettiva in un parco risorse.
- Le risorse nello stesso ambiente di implementazione (ad esempio l'ambiente di produzione) devono essere gestite insieme in un parco risorse.
- Chi amministra le risorse?
- Avere un controllo unificato (o almeno mutuamente attendibile) sulle risorse è fondamentale per garantire l'integrità del parco.
Per illustrare questo punto, prendiamo in considerazione un'organizzazione con più linee di business. In questo caso, i servizi comunicano raramente oltre i confini dei LOB, i servizi in LOB diversi vengono gestiti in modo diverso (ad esempio, i cicli di upgrade sono diversi tra i LOB) e potrebbero persino avere un insieme diverso di amministratori per ogni LOB. In questo caso, potrebbe essere opportuno avere parchi per LOB. È probabile che ogni LOB adotti anche più parchi risorse per separare i servizi di produzione e non di produzione.
Man mano che esplori altri concetti di parchi nelle sezioni seguenti, potresti trovare altri motivi per creare più parchi in base alle tue esigenze organizzative specifiche.
Ugualit'
Un concetto importante nei parchi è l'identità. Ciò significa che, quando utilizzi determinate funzionalità abilitate per il parco risorse, alcuni oggetti Kubernetes, come gli spazi dei nomi con lo stesso nome in cluster diversi, vengono trattati come se fossero la stessa cosa. Questa normalizzazione viene eseguita per semplificare la gestione delle risorse del parco risorse. Se utilizzi funzionalità che sfruttano l'identità, questa presunzione di identità fornisce alcune indicazioni precise su come configurare spazi dei nomi, servizi e identità. Tuttavia, segue anche ciò che la maggior parte delle organizzazioni sta già implementando.
I diversi tipi di identità offrono vantaggi diversi, come mostrato nella tabella seguente:
| Proprietà di identità | Ti consente di… |
|---|---|
| Uno spazio dei nomi è considerato uguale in più cluster. |
|
| Una combinazione di spazio dei nomi e nome del servizio è considerata uguale in più cluster. I servizi con lo stesso nome nello stesso spazio dei nomi utilizzano lo stesso selettore di etichette. |
|
| Una combinazione di spazio dei nomi e account di servizio (identità) è considerata uguale in più cluster. |
|
Come suggerisce, le diverse funzionalità del parco si basano su tipi diversi di identità. Un numero minore di funzionalità non utilizza affatto l'uguaglianza. Scopri di più in Quali funzionalità utilizzano l'uniformità?, incluse le funzionalità che puoi utilizzare senza dover considerare l'uniformità a livello di flotta e quelle che potrebbero richiedere una pianificazione più attenta.
Ugualitá dello spazio dei nomi
L'esempio fondamentale di identità in un parco risorse è l'identità dello spazio dei nomi. Gli spazi dei nomi con lo stesso nome in cluster diversi sono considerati uguali da molte funzionalità del parco risorse. Un altro modo per considerare questa proprietà è che uno spazio dei nomi è definito logicamente in un intero parco risorse, anche se l'istanziazione 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
instanziato solo nei cluster A e B, è implicitamente riservato nel cluster C
(consente di pianificare un servizio nello spazio dei nomi backend anche nel cluster C, se necessario).
Ciò significa che gli spazi dei nomi vengono allocati per l'intero parco risorse e non per singolo
cluster. Di conseguenza, l'uguaglianza dello spazio dei nomi richiede una proprietà dello spazio dei nomi coerente
in tutto il parco risorse.
Ugualit'à del servizio
Cloud Service Mesh e Ingress multi-cluster utilizzano il concetto di identità dei servizi all'interno di uno spazio dei nomi. Come per l'identità dello spazio dei nomi, questo implica che i servizi con lo stesso nome e lo stesso spazio dei nomi sono considerati come lo stesso servizio.
Gli endpoint di servizio possono essere uniti all'interno della mesh nel caso di Cloud Service Mesh. Con Ingress multi-cluster, una risorsa MultiClusterService (MCS) rende la unione degli endpoint più esplicita. Tuttavia, consigliamo pratiche simili per quanto riguarda la denominazione. Per questo motivo, è importante assicurarsi che i servizi con nomi identici all'interno dello stesso spazio dei nomi siano effettivamente la stessa cosa.
Nel seguente esempio, il traffico internet viene bilanciato su un servizio con lo stesso nome nello spazio dei nomi frontend presente in entrambi i cluster B e 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à uguale quando si accede a risorse esterne
Con la federazione di Workload Identity del parco risorse, i servizi all'interno di un parco risorse possono sfruttare un'identità comune in uscita per accedere a risorse esterne come Google Cloud servizi, 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 volta sola anziché cluster per cluster.
Per illustrare ulteriormente questo punto, considera l'esempio seguente. I cluster A, B e C sono registrati nell'identità comune all'interno del parco risorse. Quando i servizi nel
backend spazio dei nomi accedono Google Cloud alle risorse, le loro identità vengono mappate a un Google Cloud account di servizio comune chiamato back. L'Google Cloud account di servizio 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, nello spazio dei nomi backend, queste ereditano automaticamente le proprietà di identità del carico di lavoro.
A causa dell'identità uguale, è importante che tutte le risorse di un parco siano attendibili e ben gestite. Se torniamo all'esempio precedente, se il cluster C è di proprietà di un team separato non attendibile, anche questo può creare uno spazio dei nomi backend e accedere ai servizi gestiti come se fosse backend nel cluster A o B.
Identità uguali all'interno di un parco risorse
All'interno del parco risorse, l'identità uguale viene utilizzata in modo simile all'identità uguale esterna discussa in precedenza. Proprio come i servizi di flotta vengono autorizzati una volta per un servizio esterno, possono essere autorizzati anche internamente.
Nell'esempio seguente utilizziamo Cloud Service Mesh per creare un service mesh multi-cluster in cui frontend ha accesso a backend.
Con Cloud Service Mesh e i fleet, non è necessario specificare che frontend nei cluster B e C può accedere a backend nei cluster A e B. Specifichiamo invece che frontend
nel parco può accedere a backend nel parco. Questa proprietà non solo semplifica l'autorizzazione, ma rende anche più flessibili i confini delle risorse. Ora i carichi di lavoro possono essere spostati facilmente da un cluster all'altro senza influire sul modo in cui sono autorizzati. Come per l'identità del workload, la governance delle risorse del parco è fondamentale per garantire l'integrità della comunicazione tra servizi.
Quali funzionalità utilizzano l'uguaglianza?
Diverse funzionalità del parco risorse non si basano affatto sull'uniformità e possono essere attivate e utilizzate senza dover decidere se assumere una forma di uniformità nel parco risorse. Altre funzionalità (tra cui Config Sync e Policy Controller) possono utilizzare l'uguaglianza, ad esempio se vuoi selezionare un nome di spazio in più cluster di membri del parco per la configurazione da un'unica fonte attendibile, ma non lo richiedono per tutti i casi d'uso. Infine, esistono funzionalità come Ingress multi-cluster e la federazione delle identità di Workload a livello di parco risorse che presuppongono sempre una certa forma di identità tra i cluster e potrebbero dover essere adottate con cautela a seconda delle tue esigenze e dei carichi di lavoro esistenti.
Alcune funzionalità del parco risorse (ad esempio la federazione delle identità di Workload Identity del parco risorse) richiedono che l'intero parco risorse sia pronto per le ipotesi di identità che utilizzano. Altre funzionalità, come la gestione del team, ti consentono di attivare gradualmente l'uguaglianza a livello di spazio dei nomi o di ambito del team.
La tabella seguente mostra le funzionalità che richiedono uno o più dei concetti di identità descritti in questa sezione.
| Funzionalità | Supporta l'adozione graduale dell'identità | Dipende dalla somiglianza dello spazio dei nomi | Dipende dall'identità del servizio | Dipende dall'identità |
|---|---|---|---|---|
| Parchi risorse | N/D | No | No | No |
| Autorizzazione binaria | N/D | No | No | No |
| Crittografia trasparente tra nodi | N/D | No | No | No |
| Criterio di rete basato su nome di dominio completo | N/D | No | No | No |
| Connect Gateway | N/D | No | No | No |
| Config Sync | N/D | No | No | No |
| Policy Controller | N/D | No | No | No |
| Strategia di sicurezza di GKE | N/D | No | No | No |
| Advanced Vulnerability Insights | N/D | No | No | No |
| Postura di conformità | N/D | No | No | No |
| Sequenza di implementazione | N/D | No | No | No |
| Gestione dei team | Sì | Sì | Sì | No |
| Ingress multi-cluster | Sì | Sì | Sì | Sì |
| Servizi multi-cluster | Sì | Sì | Sì | Sì |
| Federazione delle identità per i workload di Fleet | No | Sì | Sì | Sì |
| Cloud Service Mesh | No | Sì | Sì | Sì |
Esclusività
Le risorse a conoscenza del parco risorse possono essere membri di un solo parco risorse alla volta, una limitazione applicata da Google Cloud strumenti e componenti. Questa limitazione garantisce che esista un'unica fonte attendibile per un cluster. Senza l'esclusività, anche i componenti più semplici diventerebbero difficili da utilizzare, richiedendo alla tua organizzazione di ragionare e configurare l'interazione di più componenti di più parchi.
Fiducia elevata
L'identità del servizio, l'identità del carico di lavoro e l'identità del 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é gestirle singolarmente (ovvero cluster per cluster per le risorse Kubernetes) e, in definitiva, rende meno importante il confine del cluster.
In altre parole, all'interno di un parco, i cluster offrono protezione da problemi di raggio d'azione, disponibilità (sia del piano di controllo sia dell'infrastruttura di base), vicini rumorosi e così via. Tuttavia, non rappresentano un confine di isolamento efficace 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 inserire i cluster non attendibili dall'amministratore del parco risorse in parchi risorse distinti per mantenerli isolati. Se necessario, i singoli servizi possono essere autorizzati oltre il confine del parco risorse.
Ambiti dei team
Un ambito di gruppo è un meccanismo per suddividere ulteriormente il parco risorse in gruppi di cluster, consentendoti di definire le risorse del parco risorse assegnate a un team di applicazioni specifico. A seconda del caso d'uso, un singolo cluster membro del parco risorse può essere associato a nessun team, a un team o a più team, consentendo a più team di condividere i cluster. Puoi anche utilizzare gli ambiti di gruppo per sequestrare gli upgrade dei cluster nel tuo parco risorse, anche se questo richiede che ogni cluster sia associato solo a un singolo gruppo.
A un ambito del team possono essere associati spazi dei nomi del parco risorse definiti in modo esplicito, in cui lo spazio dei nomi è considerato uguale in tutto l'ambito. In questo modo, hai un controllo più granulare sugli spazi dei nomi rispetto all'uguaglianza dello spazio dei nomi predefinita fornita solo dai parchi risorse.
Componenti abilitati per il parco risorse
I seguenti componenti di 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 dei parchi con ciascun componente, consulta i requisiti dei componenti.
Pool di identità del workload
Un parco risorse offre un pool di identità del workload comune che può essere utilizzato per autenticare e autorizzare i workload in modo uniforme all'interno di un mesh di servizi e per i servizi esterni.Cloud Service Mesh
Cloud Service Mesh è una suite di strumenti che ti aiuta a monitorare e gestire un affidabile service mesh 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 il monitoraggio di pacchetti di configurazione dichiarativa per il sistema archiviati in una fonte attendibile centrale, ad esempio un repository Git, sfruttando i concetti di base di Kubernetes come gli spazi dei nomi, le etichette e le annotazioni. Con Config Sync, le configurazioni vengono definite nel parco risorse, ma applicate e applicate localmente in ciascuna delle risorse membro.Policy Controller
Policy Controller consente di applicare e applicare criteri dichiarativi per i tuoi cluster Kubernetes. Questi criteri fungono da sistema di protezione e possono aiutarti con le best practice, la sicurezza e la gestione della 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 il traffico può essere bilanciato in base al carico, consentendo servizi a bassa latenza e alta disponibilità.
Passaggi successivi
- Scopri di più su quando utilizzare più cluster per soddisfare le tue esigenze tecniche e aziendali in Casi d'uso multi-cluster.
- Vuoi iniziare a pensare ad applicare questi concetti ai tuoi sistemi? Consulta Pianificare le risorse del parco veicoli.