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 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 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 esegua più cluster, che si tratti di Google Cloud, di più provider cloud o di un ambiente on-premise.
Devi conoscere i concetti di base di Kubernetes, come i cluster e gli spazi dei nomi. Se non li conosci, consulta la sezione Nozioni di base su 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 avere familiarità con GKE Enterprise per seguire questa guida.
Terminologia
Di seguito sono riportati alcuni termini importanti che usiamo per parlare di flotte.
Risorse consapevoli del parco risorse
Le risorse sensibili al parco risorse sono risorse di progetto Google Cloud che possono essere logicamente raggruppate e gestite 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 progetto Google Cloud può avere associato un solo parco risorse (o nessun parco risorse). Questa limitazione rafforza l'utilizzo dei progetti Google Cloud per Offrire un maggiore isolamento tra le risorse non regolate o utilizzate in sinergia.
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 che hanno grandi quantità di vantaggi nella comunicazione tra servizi possono essere gestite insieme 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 reciprocamente attendibile) sulle risorse fondamentale per garantire l'integrità della flotta.
Per spiegare questo punto, consideriamo un'organizzazione che ha più righe di aziendali (LOB). 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. Inoltre, è probabile che ciascuna LOB adotti più flotte per separare 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.
Uguale
Un concetto importante nelle flotte è quello di uguaglianza. Ciò significa che, quando utilizzi determinate funzionalità abilitate per il parco risorse, alcuni oggetti Kubernetes, ad esempio gli spazi dei nomi che hanno lo stesso nome in cluster diversi, vengono trattati come se fossero la stessa cosa. Questa normalizzazione viene eseguita per semplificare l'amministrazione 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, ciò segue anche quanto, secondo noi, la maggior parte delle organizzazioni che già implementano autonomamente.
Tipi di uguaglianza diversi offrono vantaggi diversi, come illustrato nella seguente tabella:
| Proprietà Sameness | Ti consente di… |
|---|---|
| Uno spazio dei nomi è considerato uguale in più cluster. |
|
| Una combinazione di spazio dei nomi e nome di 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 uguale in più cluster. |
|
Come suggerisce questo, 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'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
creata solo nei cluster A e B, è implicitamente riservata 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
in un cluster Kubernetes. Di conseguenza, la somiglianza dello spazio dei nomi richiede una proprietà coerente dello spazio dei nomi
all'interno del 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 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.
Nel caso di Cloud Service Mesh, gli endpoint di servizio possono essere uniti nel mesh. Con Ingress multi-cluster, La risorsa MultiClusterService (MCS) rende la l'unione degli endpoint più esplicita; Tuttavia, consigliamo prassi simili riguardo alla denominazione. Per questo motivo, è importante assicurarsi che i servizi con nomi identici all'interno dello stesso spazio dei nomi siano effettivamente la stessa cosa.
Nell'esempio seguente, il traffico Internet viene bilanciato su un'istanza
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 delle identità dei carichi di lavoro del parco risorse, i servizi all'interno di un parco risorse possono sfruttare un'identità comune in uscita per accedere a risorse esterne come servizi Google Cloud, oggetti store 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 il seguente esempio. I cluster A, B e C sono registrati nell'identità comune all'interno del parco risorse. Quando i servizi nel
nome spazio 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. Come nuove risorse del parco risorse
ad esempio, i cluster vengono aggiunti allo spazio dei nomi backend,
ereditare le proprietà di uguaglianza
delle identità per i carichi di lavoro.
A causa dell'identicità delle identità, è importante che tutte le risorse di un parco risorse
siano affidabili e ben regolati. Ritornando all'esempio precedente, se il Cluster C è
di proprietà di un team separato e non attendibile, anch'essi possono creare uno spazio dei nomi backend
e accedono ai servizi gestiti come se fossero il backend nel Cluster A
o B.
Identicità delle identità all'interno di un parco risorse
All'interno del parco risorse, l'identità dell'identità è utilizzata in modo simile all'identità esterna l'identicità di cui abbiamo parlato in precedenza. Così come i servizi di flotta vengono autorizzati una volta per un servizio esterno, possono essere autorizzati anche internamente.
Nell'esempio seguente viene utilizzato Cloud Service Mesh
per creare un mesh di servizi multi-cluster in cui frontend ha accesso a backend.
Con Cloud Service Mesh e
parchi risorse, non è necessario specificare che frontend nei cluster B e C possa
accesso 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 carico di lavoro, 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 di Workload Identity 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 (come la federazione delle identità per i carichi di lavoro) richiedono che l'intero parco risorse sia pronto per il presupposto di uguaglianza che utilizza. 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 seguente tabella mostra le funzionalità che richiedono uno o più concetti di uguaglianza descritti in questa sezione.
| Funzionalità | Supporta l'adozione graduale dell'identità | Dipende dalla somiglianza dello spazio dei nomi | Dipende dall'uguaglianza del servizio | Dipende dall'identicità dell'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 carichi di lavoro di Fleet | No | Sì | Sì | Sì |
| Cloud Service Mesh | No | Sì | Sì | Sì |
Esclusività
Le risorse a conoscenza del parco possono essere membri di un solo parco alla volta, una limitazione applicata dagli strumenti e dai componenti di Google Cloud. Questa restrizione garantisce che sia presente una sola fonte attendibile per gestire 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.
Attendibilità 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 elevare il livello di gestione di queste risorse al 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 risorse, i cluster forniscono protezione dalle esplosioni e la disponibilità (sia del piano di controllo che di sottostante infrastrutturale), vicini rumorosi e così via. Tuttavia, non sono un'ottima limite di isolamento per criteri e governance perché gli amministratori membro di un parco risorse può potenzialmente influire sulle operazioni dei servizi in membri della flotta.
Per questo motivo, consigliamo di inserire i cluster non attendibili dall'amministratore del parco in parchi 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, è possibile associare un singolo cluster membro del parco risorse senza team. uno o più team, consentendo a più team di condividere i cluster. Puoi anche utilizzare gli ambiti dei team per seguire implementazioni degli upgrade dei cluster nel parco risorse, anche se ciò richiede che ogni cluster sia associato a un solo dell'IA.
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, 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 concetti del parco risorse, come l'identicità dello spazio dei nomi e delle identità, per offrire con i tuoi cluster e servizi. Per eventuali requisiti attuali o limitazioni per l'utilizzo di parchi risorse con ogni componente, consulta il componente requisiti.
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 service mesh 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 in altri ambienti supportati. Puoi creare un mesh di servizi tra i cluster che fanno parte dello stesso parco risorse.Config Sync
Config Sync ti consente di eseguire il deployment e il monitoraggio di pacchetti di configurazione per il 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, 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 nei tuoi cluster Kubernetes. Queste norme fungono da sistema di protezione e possono aiutare 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 il traffico può essere bilanciato in base al carico, consentendo servizi a bassa latenza e alta disponibilità.Knative serving
Knative serving è uno sviluppatore Knative supportato e gestito da Google completamente gestita che astrae la complessità dell'infrastruttura sottostante, rendendo semplifica la creazione, il deployment e la gestione di app e servizi nei cluster della tua flotta.
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.