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 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 spazi dei nomi; 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 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 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 alcuni oggetti Kubernetes, come gli spazi dei nomi con lo stesso nome vengono considerati come la stessa cosa. Questa normalizzazione viene eseguita per per rendere più gestibili le risorse del parco risorse. Offre una guida efficace su come configurare spazi dei nomi, servizi e identità. Tuttavia, segue 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 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
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.
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 dei 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 di base 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 le nostre requisiti e best practice del parco risorse.