Questa pagina fornisce un approfondimento su come i parchi risorse aiutano a gestire i deployment multi-cluster, inclusi alcuni concetti e terminologia principali del parco risorse. I parchi risorse sono un concetto di Google Cloud per l'organizzazione logica dei cluster e di altri per l'uso e la gestione di funzionalità multi-cluster e di applicare in modo coerente in tutti i sistemi. Le flotte hanno un ruolo cruciale nel modo la funzionalità multi-cluster aziendale funziona in Google Cloud.
Questa guida è rivolta ai lettori tecnici, tra cui system architect, di piattaforme e operatori di servizi, che vogliono sfruttare cluster e la relativa infrastruttura. Questi concetti sono utili ovunque in cui un'organizzazione esegue più cluster, su Google Cloud, su più cloud provider, oppure on-premise.
Avere familiarità con i concetti di base di Kubernetes, come i cluster namespaces; In caso contrario, vedi Kubernetes le basi, documentazione di GKE, e Preparazione di un'applicazione per Cloud Service Mesh.
Per saperne di più sulla piattaforma GKE Enterprise e sui componenti che utilizzano per i parchi risorse, consulta le nostre tecniche di GKE Enterprise panoramica ed 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 che riconoscono il 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 della flotta.
Progetto host del parco risorse
L'implementazione dei parchi risorse, come molte altre risorse Google Cloud, radicato in un progetto Google Cloud, che definiamo progetto host del parco risorse. R un determinato progetto Google Cloud può avere solo un singolo parco risorse (o nessun parco risorse) associate. 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 importante concetto di flotte è quello di raggruppamento, ovvero scegliendo quali risorse correlate in base al parco veicoli dovrebbero 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 vantaggi nella comunicazione tra servizi possono essere gestite insieme in un parco risorse.
- Risorse nello stesso ambiente di deployment (ad esempio, dell'ambiente) devono essere gestiti 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 raramente comunicano tramite la line-of-business confini, i servizi di line-of-business diverse vengono gestiti in modo diverso (ad esempio di upgrade variano a seconda della line-of-business) e potrebbero anche avere per ogni LOB. In questo caso, potrebbe essere opportuno disporre di parchi risorse per LOB. Inoltre, è probabile che ciascuna LOB adotti più flotte per separare di produzione e non di produzione.
Man mano che vengono esplorati altri concetti del parco risorse nelle sezioni seguenti, potresti trovare per creare più parchi risorse, se consideri il tuo delle esigenze organizzative.
Uniformità
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 caratteristiche che sfruttano l'uguaglianza, questo presupposto dell'uguaglianza fornisce alcune valide indicazioni 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 la stessa in più cluster. |
|
Come suggerisce questo, le diverse funzionalità del parco risorse si basano su tipi di uguaglianza diversi. Un numero minore di caratteristiche non utilizza affatto l'uguaglianza. Puoi scoprire di più al riguardo consultando la sezione Quali funzionalità utilizzano l'uguaglianza?, ad esempio quali funzionalità puoi utilizzare senza dover prendere in considerazione l'identicità a livello di parco risorse e quali funzionalità possono richiedere una pianificazione più attenta.
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 molte funzionalità del parco risorse. Un altro modo di pensare a questa proprietà è che uno spazio dei nomi viene definita logicamente in un'intera flotta, anche se la creazione di un'istanza uno 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, l'identicità 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 l'identicità dello spazio dei nomi, ciò implica che i servizi lo stesso spazio dei nomi e lo stesso nome di servizio sono considerati 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 garantire che i dati i servizi con nome all'interno dello stesso spazio dei nomi sono in realtà 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à mesh di servizi all'interno del parco risorse, il servizio nello spazio dei nomi frontend può
raggiunge 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
Con la federazione delle identità per i carichi di lavoro, i servizi all'interno di un parco risorse possono sfruttare un'identità comune durante il traffico in uscita verso accedere a risorse esterne come servizi Google Cloud, archivi di oggetti, e così via. Questa identità comune consente di fornire i servizi all'interno di un l'accesso al parco risorse a una risorsa esterna una sola volta invece che cluster per cluster.
Per illustrare ulteriormente questo punto, consideriamo l'esempio seguente. Cluster A, B
e C sono registrati con un'identità comune all'interno del loro parco risorse. Quando i servizi nel
backend accesso allo spazio dei nomi delle risorse Google Cloud, le relative identità sono
mappato a un account di servizio Google Cloud comune denominato back. La
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
sono 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. Proprio come i servizi del parco risorse 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 solo frontend
nel parco risorse può accedere a backend nel parco risorse. Questa proprietà non solo rende
l'autorizzazione più semplice, rende anche più flessibili i confini delle risorse; adesso
possono essere facilmente spostati da un cluster all'altro senza influire sul modo in cui
sono autorizzati. Come per l'identicità delle identità dei carichi di lavoro, la governance nel parco risorse
è fondamentale per garantire l'integrità
comunicazione.
Quali funzionalità utilizzano l'uguaglianza?
Alcune funzionalità del parco risorse non si basano affatto sull'uguaglianza e possono essere abilitate e utilizzate senza dover considerare se utilizzare una qualche forma di uguaglianza all'interno del parco risorse. Altre funzionalità (inclusi Config Sync e Policy Controller) possono utilizzare l'uguaglianza, ad esempio se vuoi selezionare uno spazio dei nomi in più cluster membro del parco risorse per la configurazione da un'unica fonte attendibile, ma non lo richiedono per tutti i casi d'uso. Infine, ci sono funzionalità come Ingress multi-cluster e la federazione delle identità per i carichi di lavoro a livello di parco risorse che presuppongono sempre una qualche forma di uguaglianza tra i cluster e potrebbero dover essere adottate con attenzione a seconda delle 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 dei team ti consentono di attivare gradualmente la stessa identità a livello dello spazio dei nomi o dell'ambito del team.
La seguente tabella mostra le funzionalità che richiedono uno o più concetti di uguaglianza descritti in questa sezione.
| Funzionalità | Supporta un'adozione graduale dell'uguaglianza | Dipende dall'identicità 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 sui nomi di dominio completi | N/D | No | No | No |
| Connetti 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 del parco risorse | No | Sì | Sì | Sì |
| Cloud Service Mesh | No | Sì | Sì | Sì |
Esclusività
Le risorse sensibili al parco risorse possono essere membri di un solo parco risorse in un determinato in tempo reale, una limitazione applicata dagli strumenti e componenti. Questa restrizione garantisce che sia presente una sola fonte attendibile per gestire un cluster. Senza l'esclusività, anche i componenti più semplici diventano complessi da usare e richiedono all'organizzazione di ragionare e configurare come 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 sono: basati su un principio di elevata fiducia tra i membri di una flotta. Questo fiducia consente di migliorare la gestione di queste risorse nel parco risorse, anziché gestire risorsa per risorsa (ovvero cluster per cluster risorse Kubernetes) e, infine, 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 fare in modo che i cluster non siano attendibili dal parco risorse possono disporre dei propri parchi risorse per mantenerli isolati. Poi, come 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, consentendoti di definire le risorse sensibili al parco risorse assegnati a uno specifico team di applicazione. 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, 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 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 il carico di lavoro
Un parco risorse offre un pool di identità per i carichi di lavoro comune che può essere utilizzato per: di autenticare e autorizzare i carichi di lavoro in modo uniforme all'interno di un mesh di servizi e servizi esterni.Cloud Service Mesh
Cloud Service Mesh è una suite di strumenti che consente di monitorare e gestire un ambiente mesh di servizi 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 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, la configurazione viene definita del parco risorse, ma applicate e applicate localmente in ciascuna delle risorse dei membri.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 essere utili per 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 servizio endpoint su cui è possibile bilanciare il carico, consentendo una bassa latenza e i servizi ad 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 ad applicare questi concetti ai tuoi sistemi? Consulta Pianifica le risorse del parco risorse.