Questa pagina fornisce un'analisi più approfondita di come i parchi risorse ti aiutano a gestire i deployment multi-cluster, inclusi alcuni termini e concetti chiave relativi ai parchi risorse. I parchi risorse sono un concetto di Google Cloud 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 una parte fondamentale del funzionamento della funzionalità multi-cluster in Google Cloud.
Questa guida è pensata per i 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 esegua più cluster, che si trovino inGoogle Cloud, su più cloud provider o on-premise.
Prima di leggere questa pagina, assicurati di conoscere i concetti di base di Kubernetes, come cluster e spazi dei nomi. In caso contrario, consulta Nozioni di base di Kubernetes, la documentazione di GKE e Preparare un'applicazione per Cloud Service Mesh.
Terminologia
Di seguito sono riportati alcuni termini importanti che utilizziamo quando parliamo di flotte.
Risorse compatibili con il parco risorse
Le risorse compatibili con il parco risorse sono Google Cloud risorse di progetto 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 risorse Google Cloud , si basa su un progetto Google Cloud , che chiamiamo progetto host del parco risorse. Un determinato Google Cloud progetto può avere associato solo un unico 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 vengono gestite o utilizzate insieme.
Infrastruttura di raggruppamento
Il primo concetto importante delle flotte è quello di raggruppamento, ovvero la scelta di quali risorse correlate compatibili con le flotte devono far parte di una flotta. La decisione su cosa raggruppare richiede di rispondere alle seguenti domande:
- Le risorse sono correlate tra loro?
- Le risorse che hanno grandi quantità di comunicazione tra servizi traggono il massimo vantaggio dalla gestione congiunta 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 il controllo unificato (o almeno reciprocamente attendibile) sulle risorse è fondamentale per garantire l'integrità della flotta.
Per illustrare questo punto, prendi in considerazione un'organizzazione con più linee di business (LOB). In questo caso, i servizi comunicano raramente tra i confini delle LOB, i servizi in LOB diverse vengono gestiti in modo diverso (ad esempio, i cicli di upgrade variano tra le LOB) e potrebbero persino avere un insieme diverso di amministratori per ogni LOB. In questo caso, potrebbe essere opportuno avere flotte per LOB. È probabile che ogni LOB adotti più parchi risorse per separare i servizi di produzione e non di produzione.
Man mano che esplorerai altri concetti di flotta nelle sezioni seguenti, potresti trovare altri motivi per creare più flotte in base alle esigenze specifiche della tua organizzazione.
Sameness
Un concetto importante nelle flotte è quello di uniformità. 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 l'amministrazione delle risorse del parco risorse. Se utilizzi funzionalità che sfruttano l'uguaglianza, questo presupposto fornisce 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 uguaglianza offrono vantaggi diversi, come mostrato nella tabella seguente:
| Proprietà di identità | Consente di… |
|---|---|
| Uno spazio dei nomi è considerato lo stesso in più cluster. |
|
| Una combinazione di spazio dei nomi e nome del servizio è considerata la stessa 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 la stessa in più cluster. |
|
Come suggerisce questo esempio, le diverse funzionalità della flotta si basano su diversi tipi di uguaglianza. Un numero inferiore di funzionalità non utilizza affatto la somiglianza. Puoi scoprire di più su questo argomento in Quali funzionalità utilizzano l'omogeneità?, incluse le funzionalità che puoi utilizzare senza dover considerare l'omogeneità a livello di flotta e quelle che potrebbero richiedere una pianificazione più attenta.
Uguaglianza 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 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 venga
istanziazione solo nei cluster A e B, è riservato implicitamente 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
cluster. Pertanto, l'identità dello spazio dei nomi richiede una proprietà coerente dello spazio dei nomi
in tutto il parco risorse.
Servizi identici
Cloud Service Mesh e Ingress multi-cluster utilizzano il concetto di identità 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 del servizio sono considerati lo stesso servizio.
Gli endpoint di servizio possono essere uniti nella mesh nel caso di Cloud Service 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 assicurarsi che i servizi con lo stesso nome all'interno dello stesso spazio dei nomi siano effettivamente la stessa cosa.
Nell'esempio seguente, il traffico internet viene bilanciato del carico su un servizio con lo stesso nome nello spazio dei nomi frontend presente nei cluster B e C. Analogamente,
utilizzando le proprietàmesh di servizih 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à identica durante l'accesso a risorse esterne
Con la federazione delle identità del workload del parco risorse, i servizi all'interno di un parco risorse possono sfruttare un'identità comune quando escono per accedere a risorse esterne come servizi, object store e così via. Google Cloud Questa identità comune consente di concedere ai servizi all'interno di un fleet l'accesso a una risorsa esterna una sola volta anziché cluster per cluster.
Per illustrare meglio 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 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. Il
service accountGoogle 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, nello spazio dei nomi backend, queste ereditano automaticamente le proprietà di identità del workload.
A causa dell'identità identica, è importante che tutte le risorse di una flotta
siano attendibili e ben gestite. Tornando all'esempio precedente, se il cluster C è
di proprietà di un team separato e 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à identiche all'interno di un parco risorse
All'interno del parco risorse, l'identità è utilizzata in modo simile all'identità esterna di cui abbiamo parlato 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 mesh di servizi multicluster in cui frontend ha accesso a backend.
Con Cloud Service Mesh e
fleet, non è necessario specificare che frontend nei cluster B e C può
accedere a backend nei cluster A e B. Specifichiamo invece che frontend
nella flotta può accedere a backend nella flotta. Questa proprietà non solo semplifica l'autorizzazione, ma rende anche i limiti delle risorse più flessibili. Ora i carichi di lavoro possono essere spostati facilmente da un cluster all'altro senza influire sul modo in cui vengono autorizzati. Come per l'identità dei workload, la governance delle risorse del parco dispositivi è fondamentale per garantire l'integrità della comunicazione da servizio a servizio.
Quali funzionalità utilizzano la somiglianza?
Alcune funzionalità del parco risorse non si basano affatto sull'identità e possono essere attivate e utilizzate senza dover considerare se vuoi presupporre una forma di identità nel parco risorse. Altre funzionalità (tra cui Config Sync e Policy Controller) possono utilizzare l'uguaglianza, ad esempio se vuoi selezionare uno spazio dei nomi in più cluster membri del parco per la configurazione da un'unica fonte di riferimento, ma non la richiedono per tutti i casi d'uso. Infine, esistono funzionalità come Ingress multi-cluster e la federazione delle identità per i carichi di lavoro a livello di parco risorse che presuppongono sempre una certa uniformità tra i cluster e potrebbero dover essere adottate con attenzione a seconda delle tue esigenze e dei carichi di lavoro esistenti.
Alcune funzionalità del parco risorse (come la federazione delle identità del workload del parco risorse) richiedono che l'intero parco risorse sia pronto per le ipotesi di uguaglianza che utilizzano. Altre funzionalità, come la gestione dei team, ti consentono di attivare gradualmente l'uguaglianza a livello di spazio dei nomi o di ambito del team.
La seguente tabella mostra quali funzionalità richiedono uno o più dei concetti di uguaglianza descritti in questa sezione.
| Funzionalità | Supporta l'adozione graduale della stessa identità | Dipende dall'identità 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 sul nome di dominio completo | N/D | No | No | No |
| Connettere il 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 compatibili con il parco risorse possono essere membri di un solo parco risorse alla volta, una limitazione applicata dagli strumenti e dai componenti Google Cloud . Questa limitazione garantisce che esista una sola fonte attendibile che governa un cluster. Senza esclusività, anche i componenti più semplici diventerebbero complessi da utilizzare, richiedendo alla tua organizzazione di ragionare e configurare il modo in cui interagirebbero più componenti di più flotte.
Alto livello di fiducia
L'uguaglianza dei servizi, l'uguaglianza delle identità dei carichi di lavoro e l'uguaglianza delle identità del mesh si basano su un principio di elevata fiducia tra i membri di un parco risorse. Questa fiducia consente di migliorare la gestione di queste risorse nella flotta, anziché gestirle risorsa per risorsa (ovvero cluster per cluster per le risorse Kubernetes), e in definitiva rende meno importante il limite del cluster.
In altre parole, all'interno di un parco veicoli, i cluster forniscono protezione da problemi di raggio di esplosione, disponibilità (sia del control plane che dell'infrastruttura sottostante), vicini rumorosi e così via. Tuttavia, non sono un limite di isolamento efficace per le norme e la governance, perché gli amministratori di qualsiasi membro di un parco risorse possono potenzialmente influire sul funzionamento 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 separati per mantenerli isolati. Poi, se necessario, i singoli servizi possono essere autorizzati oltre il confine del parco risorse.
Ambiti dei team
Un ambito del team è un meccanismo per suddividere ulteriormente il parco risorse in gruppi di cluster, consentendoti di definire le risorse compatibili con il 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 del team per sequenziare le implementazioni degli upgrade dei cluster nel parco risorse, anche se ciò richiede che ogni cluster sia associato a un solo team.
Un ambito del team può avere spazi dei nomi del parco risorse definiti in modo esplicito associati, in cui lo spazio dei nomi è considerato lo stesso nell'ambito. In questo modo hai un controllo più granulare sugli spazi dei nomi rispetto alla somiglianza degli spazi dei nomi predefinita fornita solo dai fleet.
Componenti abilitati per il parco risorse
I seguenti componenti 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 delle flotte 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 servizi esterni.Cloud Service Mesh
Cloud Service Mesh è una suite di strumenti che ti aiuta a monitorare e gestire un service mesh affidabile su Google Cloud, on-premise e altri ambienti supportati. Puoi formare 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 sistema archiviati in un'unica fonte attendibile, ad esempio un repository Git, sfruttando i concetti di base di Kubernetes come spazi dei nomi, etichette e annotazioni. Con Config Sync, le configurazioni vengono definite in tutto il parco risorse, ma applicate e applicate localmente in ciascuna delle risorse membro.Policy Controller
Policy Controller consente di applicare e applicare policy dichiarative per i tuoi cluster Kubernetes. Questi criteri fungono da sistemi 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, consentendo servizi a bassa latenza e ad 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 di applicare questi concetti ai tuoi sistemi? Vedi Pianificare le risorse del parco risorse.