Pianificare le funzionalità del parco risorse

Una parte importante della pianificazione delle flotte è decidere quali funzionalità abilitate per le flotte vuoi utilizzare. In particolare, se lavori con cluster e carichi di lavoro di produzione esistenti, potresti voler identificare le funzionalità del parco risorse che possono essere adottate immediatamente con attrito o rischio minimi per le tue applicazioni esistenti, pianificando al contempo altre funzionalità che potrebbero richiedere un'adozione più graduale o attenta. Questa guida descrive i diversi tipi di funzionalità attivate utilizzando le flotte e i relativi requisiti e fornisce alcuni consigli pratici sull'adozione delle funzionalità.

Questa guida è rivolta agli architetti cloud che vogliono iniziare a utilizzare i fleet nella loro organizzazione. Prima di leggere questa guida, assicurati di conoscere la nostra panoramica della gestione dei parchi risorse e la pianificazione delle risorse del parco risorse, che descrive l'organizzazione di cluster nuovi o esistenti in parchi risorse.

Best practice per l'adozione delle funzionalità

Tutte le funzionalità del parco auto (ad eccezione dell'osservabilità di base del parco auto) sono attivate, nel senso che devi specificare che vuoi utilizzarle. La semplice aggiunta di un cluster esistente a un parco risorse non ne modifica la configurazione. Quando decidi di utilizzare le funzionalità della flotta, alcune possono essere attivate immediatamente con un rischio minimo, ma per altre potrebbe essere necessario prestare maggiore attenzione. Questa sezione fornisce alcune indicazioni per l'adozione delle funzionalità.

Soprattutto con i cluster e i carichi di lavoro esistenti, devi prestare particolare attenzione a dove le funzionalità utilizzano la somiglianza. Si tratta di un concetto di parco risorse in cui gli spazi dei nomi, i servizi o le identità con lo stesso nome in cluster diversi sono considerati dalla funzionalità come la stessa cosa. Per saperne di più sul principio di identità e sulle funzionalità che lo utilizzano, consulta la sezione Come funzionano le flotte.

Onboarding delle funzionalità a basso rischio

Le seguenti funzionalità "ambientali" non presuppongono alcun tipo di somiglianza e non influiscono in alcun modo sui cluster. Possono essere utilizzati in modo sicuro anche con workload e cluster esistenti, consentendoti di usufruire immediatamente di una migliore osservabilità e di approfondimenti sulla sicurezza nel tuo parco risorse, nonché della possibilità di gestire l'ordine degli upgrade dei cluster in base all'appartenenza al parco risorse.

Le seguenti funzionalità sono installate su singoli cluster. Le funzionalità possono presupporre l'identità, ma solo quando si configurano o specificano risorse in più cluster. Ciò significa che puoi attivare in sicurezza queste funzionalità sui tuoi cluster con i workload esistenti e devi considerare l'uguaglianza solo quando crei o utilizzi configurazioni per questi cluster che utilizzano questi selettori facoltativi.

Onboarding delle funzionalità multi-cluster avanzate

Le seguenti potenti funzionalità riducono l'overhead operativo della gestione di più cluster. Tuttavia, è necessario prestare maggiore attenzione a queste funzionalità, in quanto tutte richiedono un'ipotesi di uno o più tipi di uguaglianza per funzionare e l'attivazione o la disattivazione può influire su più cluster e sui relativi carichi di lavoro.

Ad esempio, se hai spazi dei nomi Kubernetes esistenti con lo stesso nome in cluster e applicazioni diversi (incluso lo spazio dei nomi predefinito), devi verificare di volerli trattare come lo stesso spazio dei nomi prima di attivare qualsiasi funzionalità che si basa su questo presupposto. Allo stesso modo, se vuoi utilizzare Cloud Service Mesh, devi capire quali endpoint di servizio verranno uniti nei tuoi cluster e confermare che questo è il comportamento desiderato.

Verifica dell'identità dello spazio dei nomi di controllo

Se conosci bene le tue applicazioni, puoi controllare i tuoi spazi dei nomi semplicemente verificando che due applicazioni "diverse" non utilizzino lo stesso spazio dei nomi. In particolare, fai attenzione all'utilizzo ad hoc dello spazio dei nomi predefinito. Ad esempio, se hai uno spazio dei nomi chiamato default in un cluster e uno spazio dei nomi chiamato default in un altro cluster, ma vengono utilizzati per scopi diversi, devi rinominarne uno.

Per un approccio più rigoroso, prova a svolgere i seguenti passaggi. Per ogni insieme di spazi dei nomi con lo stesso nome in diversi cluster di un parco risorse, verifica che:

  • In ogni cluster, le stesse regole RBAC si trovano nel cluster e il principale dello spazio dei nomi ha accesso allo spazio dei nomi.
  • l'insieme di immagini utilizzate dai pod (meno hash/tag) è lo stesso.
  • l'insieme di secret utilizzati dai pod è identico.

Se tutte queste condizioni sono vere, gli spazi dei nomi sono sufficientemente simili da essere considerati "uguali".

Se gli spazi dei nomi non sono sufficientemente simili, puoi eseguire la migrazione delle app a nuovi spazi dei nomi. Una volta che hai deciso di assumere l'identità dello spazio dei nomi, puoi attivare le funzionalità che lo utilizzano.

Audit service sameness

Se vuoi adottare Cloud Service Mesh per gestire le tue applicazioni basate su microservizi, un altro problema da considerare è l'identità del servizio. Ciò significa che per qualsiasi combinazione di spazio dei nomi e nome del servizio, Cloud Service Mesh li tratterà come lo stesso servizio logico in termini di:

  • Identità (in particolare per la sicurezza di Cloud Service Mesh): se namespace1/service1 è autorizzato a fare qualcosa, i workload con questa identità di qualsiasi cluster sono autorizzati.
  • Gestione del traffico: per impostazione predefinita, il traffico viene bilanciato del carico tra i servizi namespace1/service1 in qualsiasi cluster.
  • Osservabilità: le metriche per namespace1/service1 in tutti i cluster vengono aggregate.

Se abiliti Cloud Service Mesh con nuovi cluster e applicazioni, ti consigliamo di riservare combinazioni univoche di spazio dei nomi/nome del servizio nell'intero mesh. Per le applicazioni esistenti, esegui un audit dei tuoi servizi per assicurarti che i servizi con lo stesso spazio dei nomi e lo stesso nome nei tuoi cluster siano quelli che vuoi trattare come lo stesso servizio in termini di identità, gestione del traffico e osservabilità.

In particolare, assicurati che servizi logicamente diversi (ad esempio un'API di contabilità dei pagamenti e un'API di transazione di pagamento) non utilizzino la stessa coppia [spazio dei nomi, nome] (ad esempio payments/api) perché verranno trattati come lo stesso servizio una volta inseriti in un mesh di servizi. Questo unione concettuale si verifica anche oltre i confini regionali. Inoltre, la funzione dei servizi potrebbe essere compromessa.

L'uguaglianza dello spazio dei nomi/del nome del servizio è presupposta anche da Ingress multi-cluster e dal gateway multi-cluster quando indirizzano il traffico ai servizi su più cluster, anche se solo per i servizi esposti all'esterno dei cluster.

Prendi in considerazione Workload Identity

Una funzionalità potente del parco risorse è la federazione delle identità per i workload a livello di parco risorse. Ciò estende le funzionalità fornite in Workload Identity Federation for GKE, che consente ai carichi di lavoro nel cluster di autenticarsi su Google senza richiedere di scaricare, ruotare manualmente e gestire in generale le chiavi del service account. Google Cloud I carichi di lavoro, invece, si autenticano utilizzando token di breve durata generati dai cluster, con ogni cluster aggiunto come provider di identità a un pool di identità dei carichi di lavoro speciale. I carichi di lavoro in esecuzione in uno spazio dei nomi specifico possono condividere la stessa identità Identity and Access Management tra i cluster.

Mentre la federazione delle identità per i carichi di lavoro per GKE standard utilizza un pool di identità a livello di progetto, la federazione delle identità per i carichi di lavoro a livello di parco risorse utilizza un pool di identità per i carichi di lavoro per l'intero parco risorse, anche se i cluster si trovano in progetti diversi, con l'uguaglianza implicita per le identità in tutto il parco risorse, nonché per lo spazio dei nomi e il servizio. In questo modo è più semplice configurare l'autenticazione per le applicazioni nei vari progetti, ma possono essere prese in considerazione controlli dell'accesso aggiuntivi rispetto a quelli per la federazione delle identità dei carichi di lavoro per GKE se scegli di utilizzarla in parchi risorse multi-progetto, in particolare se il progetto host del parco risorse ha un mix di cluster del parco risorse e non del parco risorse.

Per scoprire di più sulla federazione di Workload Identity del parco risorse e su come utilizzarla per accedere ai servizi Google Cloud , consulta Utilizzare Workload Identity del parco risorse. Per indicazioni su come ridurre al minimo il rischio con la federazione delle identità del parco risorse con alcuni esempi, consulta Best practice per l'utilizzo di Workload Identity del parco risorse.

Valori predefiniti a livello di parco risorse

GKE offre la possibilità di impostare valori predefiniti a livello di parco risorse per determinate funzionalità aziendali, tra cui Cloud Service Mesh, Config Sync e Policy Controller. In questo modo puoi configurare i cluster per utilizzare queste funzionalità senza dover configurare ogni cluster singolarmente. Ad esempio, un amministratore può abilitare Policy Controller per il proprio parco risorse e impostare criteri predefiniti a livello di parco risorse. In questo modo viene installato l'agente richiesto nei nuovi cluster membri del parco risorse e vengono applicati i criteri predefiniti.

Tuttavia, questi valori predefiniti vengono applicati automaticamente solo ai nuovi cluster che aggiungi al parco risorse al momento della creazione del cluster. I cluster esistenti e i relativi workload non sono interessati, anche se li hai già aggiunti al parco risorse o se li aggiungi dopo aver configurato i valori predefiniti delle funzionalità. Ciò significa che puoi configurare in modo sicuro i valori predefiniti a livello di parco risorse senza rischiare di attivare o configurare funzionalità su cluster in cui non sei pronto a farlo. Puoi sempre scegliere di applicare le impostazioni predefinite ai cluster esistenti in un secondo momento.

Requisiti delle funzionalità

Esistono alcune limitazioni da considerare quando implementi le flotte in base alle funzionalità della flotta che la tua organizzazione vuole utilizzare. Ad esempio, alcune funzionalità non supportano l'utilizzo di cluster che non si trovano nel progetto host del parco risorse, mentre altre non sono supportate sui cluster esterni a Google Cloud.

La seguente tabella mostra i requisiti e le limitazioni attuali di ciascun componente, con alcune linee guida specifiche nelle sezioni seguenti.

Funzionalità
 Tipi di cluster
 Requisiti del progetto
 Requisiti VPC
Config Sync Tutti i cluster supportati da GKE Nessuno Nessuno
Policy Controller Tutti i cluster supportati da GKE Nessuno Nessuno
Cloud Service Mesh Vedi le limitazioni. Tutti i cluster utilizzati con Cloud Service Mesh che si trovano nello stesso progetto devono essere registrati nello stesso parco risorse. Per saperne di più, consulta i requisiti del parco di Cloud Service Mesh. I cluster GKE devono trovarsi nella stessa rete VPC.
Servizi multi-cluster (MCS) GKE su Google Cloud Nessuno Consulta MCS su VPC condiviso
Ingress multi-cluster e gateway multi-cluster GKE su Google Cloud Le risorse Ingress/Gateway, i cluster GKE e il parco risorse devono trovarsi nello stesso progetto. Le risorse Ingress/Gateway e i cluster GKE devono trovarsi nella stessa rete VPC.
Pool di identità del workload Ottimizzato per GKE su Google Cloud e Google Distributed Cloud su VMware. Sono supportati altri cluster Kubernetes, ma richiedono un lavoro di configurazione aggiuntivo. Nessuno Nessuno
Autorizzazione binaria GKE su Google Cloud, Google Distributed Cloud su VMware, Google Distributed Cloud su bare metal Nessuno Nessuno
Advanced Vulnerability Insights GKE su Google Cloud Nessuno Nessuno
Security posture GKE su Google Cloud Nessuno Nessuno
Postura di conformità GKE su Google Cloud Nessuno Nessuno
Metriche di utilizzo delle risorse del parco risorse GKE su Google Cloud Nessuno Nessuno
Logging del parco risorse Tutti Nessuno Nessuno
Connettere il gateway Tutti Nessuno Nessuno
Gestione dei team del parco risorse Tutti Nessuno Nessuno
Policy di rete FQDN dei pod GKE su Google Cloud Nessuno Nessuno
Crittografia trasparente tra nodi GKE su Google Cloud Nessuno Nessuno
Config Controller Non applicabile Nessuno Nessuno
Sequenza di implementazione GKE su Google Cloud Nessuno Nessuno

Considera i requisiti di Virtual Private Cloud

Se prevedi di utilizzare una funzionalità come Cloud Service Mesh che richiede che i cluster si trovino in una singola rete Virtual Private Cloud (VPC), come mostrato nella tabella precedente, devi creare un parco risorse per ogni VPC. Se non prevedi di utilizzare queste funzionalità, puoi inserire più VPC in un'unica flotta.

Ad esempio, un pattern comune è che un'organizzazione abbia diversi progetti, ognuno con il proprio VPC predefinito. Questi potrebbero avere connessioni di peering esistenti tra loro. Se non utilizzi una funzionalità con requisiti di una sola rete VPC, puoi inserirli tutti in un'unica flotta. Un altro pattern comune segue una topologia "hub and spoke", che utilizza più VPC. Se non utilizzi una funzionalità con requisiti di un singolo VPC, puoi inserire i cluster di tutti questi VPC in un unico parco risorse. Tieni presente che in alcuni casi il rispetto di queste linee guida potrebbe comportare la creazione di flotte con un solo cluster. In questo caso, potresti dover rinunciare all'utilizzo di funzionalità con limitazioni VPC e creare flotte multi-progetto oppure riconsiderare l'architettura e spostare i carichi di lavoro, a seconda dei casi.

Requisiti per il networking multi-cluster

Se vuoi utilizzare Ingress multi-cluster o gateway multi-cluster per la gestione del traffico, tieni presente che in entrambi i casi il controller del gateway non può estendersi a più progetti. Ciò significa che tutti i cluster che vuoi utilizzare con queste funzionalità devono trovarsi nello stesso progetto e nello stesso parco risorse. Se devi creare flotte che includono cluster di più progetti, puoi utilizzare invece i gateway a cluster singolo e indirizzare il traffico al gateway corretto in un altro modo (ad esempio utilizzando DNS). I cluster che utilizzano queste funzionalità devono trovarsi anche nella stessa rete VPC.

Passaggi successivi