Questa pagina fornisce un'analisi più approfondita del modo in cui i gruppi di distribuzione aiutano a gestire i deployment multi-cluster, inclusi alcuni concetti e terminologia chiave. Le flotte sono un concetto Google Cloud per l'organizzazione logica dei cluster e di altre risorse, che consente di utilizzare e gestire funzionalità multi-cluster e di applicare criteri coerenti nei sistemi. Le flotte costituiscono una parte fondamentale del funzionamento della funzionalità multi-cluster aziendale in Google Cloud.
Questa guida è rivolta ai lettori tecnici, tra cui system engineer, operatori di piattaforme e operatori di servizio che vogliono utilizzare più cluster e l'infrastruttura correlata. Questi concetti sono utili ovunque nella tua organizzazione esegua più cluster, in Google Cloud, su più cloud provider o on-premise.
Dovresti acquisire familiarità con i concetti di base di Kubernetes, come i cluster e gli spazi dei nomi; se non lo sei, vedi Kubernetes di base, la documentazione di GKE e Preparare un'applicazione per Anthos Service Mesh.
Per scoprire di più sulla piattaforma Anthos e sui componenti che utilizzano le flotte, consulta il nostro tutorial di panoramica tecnico e Esplora Anthos. Tuttavia, non è necessario conoscere Anthos per seguire questa guida.
Terminologia
Di seguito sono riportati alcuni termini importanti che utilizziamo quando parliamo di flotte.
Risorse sensibili alla flotta
Le risorse consapevoli del parco risorse sono risorse di progetto Google Cloud che possono essere logicamente raggruppate e gestite come gruppi. Solo i cluster Kubernetes possono essere membri della flotta.
Progetto host della flotta
L'implementazione di gruppi di dispositivi, come molte altre risorse di Google Cloud, è rooted in un progetto Google Cloud, che noi chiamiamo "progetto dell'host del parco risorse". A un determinato progetto Cloud può essere associato solo un singolo parco risorse (o nessun parco risorse). Questa restrizione si rafforza usando i progetti Cloud per offrire un isolamento più efficace tra le risorse non regolate o utilizzate insieme.
Infrastruttura di raggruppamento
Il primo importante concetto di flotte è il concetto di raggruppamento, ovvero la scelta di relativi risorse flotte di risorse La decisione su quali elementi raggruppare richiede la risposta alle seguenti domande:
- Le risorse sono correlate tra loro?
- Le risorse con una grande quantità di comunicazione cross-service traggono il massimo vantaggio dalla gestione collettiva 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?
- Disporre di un controllo unificato (o almeno reciprocamente attendibile) sulle risorse è fondamentale per garantire l'integrità del parco risorse.
Per illustrare questo punto, prendiamo in considerazione un'organizzazione con più settori di attività. In questo caso, i servizi comunicano raramente nei confini dell'azienda. In questo caso, avrebbe senso avere flotte per ogni LOB. Ogni LOB adotta probabilmente anche più flotte per separare i propri servizi di produzione e non di produzione.
Nelle sezioni seguenti puoi scoprire altri concetti del parco risorse. Potresti trovare altri motivi per creare più gruppi contemporaneamente tenendo conto delle tue specifiche esigenze organizzative.
Stessa coerenza
Un concetto importante nelle flotte è il concetto di ugualità. Ciò significa che alcuni oggetti Kubernetes, come gli spazi dei nomi con lo stesso nome in cluster diversi, vengono considerati come la stessa cosa. Questa normalizzazione viene eseguita per rendere più gestibile le risorse di amministrazione del parco risorse. Offre indicazioni solide su come configurare spazi dei nomi, servizi e identità. Tuttavia, segue quanto riportato nella maggior parte delle organizzazioni che implementano già.
Spazio dei nomi uguale
L'esempio fondamentale di coerenza in un parco risorse è lo stesso spazio dei nomi. Gli spazi dei nomi con lo stesso nome in cluster diversi vengono considerati allo stesso modo da più componenti. 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.
Esamina il seguente esempio di spazio dei nomi backend. Anche se lo spazio dei nomi è indicato solo nei cluster A e B, è implicitamente riservato nel cluster C (consente a un servizio nello spazio dei nomi backend di essere pianificato anche nel cluster C, se necessario).
Ciò significa che gli spazi dei nomi vengono allocati per l'intero parco risorse e non per cluster. Di conseguenza, la coerenza dello spazio dei nomi richiede una proprietà coerente dello spazio dei nomi in tutto il parco risorse.
Ugualità dei servizi
Anthos Service Mesh e Multi Cluster Ingress utilizzano il concetto di ugualità dei servizi in uno spazio dei nomi. Come per lo stesso spazio dei nomi, ciò significa che i servizi con lo stesso spazio dei nomi e lo stesso nome di servizio sono considerati lo stesso servizio.
Nel caso di Anthos Service Mesh, è possibile unire gli endpoint di servizio nel mesh. Con Ingress multi-cluster, una risorsa MultiClusterService (MCS) rende l'endpoint unisce più esplicito; tuttavia, consigliamo pratiche simili con rispetto alla denominazione. Per questo motivo, è importante assicurarsi che i servizi con nome identico all'interno dello stesso spazio dei nomi siano effettivamente la stessa cosa.
Nell'esempio seguente, il traffico Internet è bilanciato del carico all'interno di un servizio con lo stesso nome nello spazio dei nomi frontend presente sia nei cluster B che in C. Allo stesso modo,
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.
Stessa identità quando accedi a risorse esterne
I servizi all'interno di un parco risorse possono sfruttare un'identità comune mentre sono in uscita per accedere a risorse esterne come servizi Google Cloud, archivi di oggetti e così via. Questa identità comune consente di concedere ai servizi all'interno di un parco risorse una sola volta la risorsa anziché il cluster per cluster.
Per illustrare meglio questo punto, considera il seguente esempio. I cluster A, B, e C sono registrati nell'identità comune all'interno del loro parco risorse. Quando i servizi nello spazio dei nomi backend accedono alle risorse Google Cloud, le loro identità sono mappate a un account di servizio Google Cloud comune chiamato back. L'account di servizio Google Cloud back può essere autorizzato in un numero qualsiasi di servizi gestiti, da Cloud Storage a Cloud SQL. Quando si aggiungono nuove risorse del parco risorse, ad esempio i cluster nello spazio dei nomi backend, queste ereditano automaticamente le proprietà dell'identità del carico di lavoro.
A causa della stessa identità, è importante che tutte le risorse di un parco risorse siano attendibili e gestite in modo accurato. Riesaminando l'esempio precedente, se il Cluster C è di proprietà di un team separato e non attendibile, anche questi possono creare uno spazio dei nomi backend e accedere ai servizi gestiti come se fossero backend nel Cluster A
o B.
Stessa identità all'interno di un parco risorse
All'interno del parco risorse, la stessa identità è utilizzata in modo analogo all'identità esterna di cui abbiamo parlato in precedenza. Analogamente a quanto accade per i servizi esterni, i servizi del parco risorse possono essere autorizzati anche internamente.
Nel seguente esempio, utilizziamo Anthos Service Mesh per creare un mesh di servizi multi-cluster in cui frontend ha accesso a backend.
Con Anthos Service Mesh e i parco dispositivi, non è necessario specificare che frontend nei cluster B e C può accedere a backend nei cluster A e B. Noi specifichiamo che frontend
nel parco risorse può accedere a backend nel parco risorse. Questa proprietà non solo semplifica l'autorizzazione, ma rende anche i limiti delle risorse più flessibili; ora è possibile spostare facilmente i carichi di lavoro da cluster a cluster senza influire sulla relativa autorizzazione. Come per la stessa identità dei carichi di lavoro, la governance sulle risorse del parco risorse è fondamentale per garantire l'integrità della comunicazione da servizio a servizio.
Esclusività
Le risorse incentrate sul parco risorse possono essere membri di un singolo parco risorse in qualsiasi momento, una restrizione applicata dagli strumenti e dai componenti Google Cloud. Questa restrizione assicura che venga pubblicata una sola fonte attendibile in un cluster. Senza esclusività, anche i componenti più semplici sarebbero completi da utilizzare e l'organizzazione dovrebbe pensare e configurare come interagiscono più componenti di più gruppi.
Fiducia
L'uniformità dei servizi, l'uniformità delle identità dei carichi di lavoro e la stessa identità delle reti si basano su un principio di affidabilità elevata tra i membri di un parco risorse. Questa attendibilità rende possibile l'aumento del livello di gestione di queste risorse nel parco risorse, invece della gestione delle singole risorse (ovvero cluster per cluster per le risorse Kubernetes), e alla fine rende il confine del cluster meno importante.
In altre parole, all'interno di un parco risorse, i cluster proteggono da problemi di esplosione, disponibilità (sia del piano di controllo sia dell'infrastruttura sottostante), vicini rumorosi e così via. Tuttavia, non rappresentano un forte limite di isolamento 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 posizionare i cluster che non sono considerati attendibili dall'amministratore del parco risorse in modo da tenerli isolati. Successivamente, come necessario, è possibile autorizzare i singoli servizi a livello internazionale.
Componenti abilitati per flotta
I seguenti componenti Anthos e GKE sfruttano tutti i concetti della flotta, come lo spazio dei nomi e l'uniformità dell'identità, per fornire un modo semplificato di lavorare con i tuoi cluster e servizi. Per i requisiti o le limitazioni attuali per l'utilizzo di gruppi di dispositivi con ogni componente, consulta i requisiti dei componenti.
Pool di identità del carico di lavoro
Un parco risorse offre un pool di identità del carico di lavoro comune, che può essere utilizzato per autenticare e autorizzare in modo uniforme i carichi di lavoro all'interno di un mesh di servizi e nei servizi esterni.Anthos Service Mesh
Anthos Service Mesh è una suite di strumenti che consente di monitorare e gestire un service mesh affidabile su Google Cloud, on-premise e in altri ambienti supportati. Puoi formare un mesh di servizi in cluster che fanno parte dello stesso parco risorse.Anthos Config Management
Anthos Config Management ti consente di eseguire il deployment e monitorare i criteri dichiarativi e le modifiche alla configurazione per il tuo sistema, archiviate in un repository Git centrale, sfruttando i concetti principali di Kubernetes come spazi dei nomi, etichette e annotazioni. Con Anthos Config Management, i criteri e la configurazione sono definiti in tutto il parco risorse, ma applicati e applicati in locale in ciascuna risorsa dei membri.Ingress multi-cluster
La risorsa Ingress multi-cluster utilizza il parco risorse per definire il set di cluster ed endpoint di servizio su cui è possibile bilanciare il traffico, consentendo servizi a bassa latenza e ad alta disponibilità.Cloud Run for Anthos
Cloud Run for Anthos è una piattaforma per sviluppatori Knative supportata e gestita da Google che astrae la complessità dell'infrastruttura sottostante, semplificando la creazione, il deployment e la gestione di app e servizi nei cluster nel tuo parco risorse Anthos.
Passaggi successivi
- Scopri di più su quando utilizzare più cluster per soddisfare le tue esigenze tecniche e aziendali in Casi d'uso multi-cluster.
- Pensi di applicare questi concetti ai tuoi sistemi? Consulta i nostri requisiti e le nostre best practice per la flotta.