Pianificare le funzionalità del parco risorse

Una parte importante della pianificazione dei parchi risorse è decidere quali funzionalità abilitate per i parchi risorse vuoi utilizzare. In particolare, se lavori con cluster esistenti e workload di produzione, potresti voler identificare le funzionalità del parco risorse che possono essere adottate immediatamente con un attrito o un rischio minimo per le applicazioni esistenti, pianificando al contempo altre funzionalità che potrebbero richiedere un'adozione più graduale o attenta. Questa guida descrive i diversi tipi di funzionalità abilitate dall'utilizzo dei parchi risorse e i relativi requisiti e fornisce alcune indicazioni pratiche sull'adozione delle funzionalità.

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

Best practice per l'adozione delle funzionalità

Tutte le funzionalità del parco risorse (ad eccezione dell'osservabilità di base del parco risorse) sono facoltative, in quanto 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à del parco risorse, alcune funzionalità possono essere abilitate immediatamente con un rischio minimo, ma potresti dover approcciare alcune funzionalità con maggiore attenzione. Questa sezione fornisce alcune indicazioni per l'adozione delle funzionalità.

Soprattutto con i cluster e i workload esistenti, devi prestare particolare attenzione quando le funzionalità utilizzano l'identicità. Si tratta di un concetto di parco risorse in cui le funzionalità presuppongono che gli spazi dei nomi, i servizi o le identità con lo stesso nome in cluster diversi siano la stessa cosa. Puoi scoprire di più sul principio di identicità e sulle funzionalità che lo utilizzano in Come funzionano i parchi risorse.

Onboarding delle funzionalità a basso rischio

Le seguenti funzionalità "ambientali" non presuppongono alcun tipo di identicità e non influiscono in alcun modo sui cluster. Possono essere utilizzate in sicurezza anche con workload e cluster esistenti, consentendoti di usufruire immediatamente di informazioni avanzate su osservabilità e 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à vengono installate sui singoli cluster. Le funzionalità possono presupporre l'identicità, ma solo quando si configurano o si specificano le risorse in più cluster. Ciò significa che puoi abilitare in sicurezza queste funzionalità sui cluster con workload esistenti e devi considerare l'identicità solo quando crei o utilizzi configurazioni per queste funzionalità che utilizzano questi selettori facoltativi.

Onboarding delle funzionalità multi-cluster avanzate

Le seguenti funzionalità avanzate riducono il sovraccarico 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 identicità per funzionare e l'abilitazione o la disabilitazione può influire su più cluster e sui relativi workload.

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 abilitare le funzionalità che fanno questa ipotesi. Allo stesso modo, se vuoi utilizzare Cloud Service Mesh, devi capire quali endpoint di servizio verranno uniti nei cluster e verificare che questo sia il comportamento desiderato.

Eseguire l'audit dell'identicità dello spazio dei nomi

Se conosci bene le tue applicazioni, puoi eseguire l'audit degli 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 procedere nel seguente modo. Per ogni insieme di spazi dei nomi con lo stesso nome in cluster diversi di un parco risorse, verifica che:

  • In ogni cluster, le stesse regole RBAC si trovano nel cluster e l'accesso allo spazio dei nomi delle entità è consentito.
  • 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 trattati come "gli stessi".

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

Eseguire l'audit dell'identicità del servizio

Se vuoi adottare Cloud Service Mesh per gestire le applicazioni basate su microservizi, un altro problema da considerare è l'identicità 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 eseguire un'operazione, i workload con quell'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 nome del servizio/spazio dei nomi nell'intero mesh. Per le applicazioni esistenti, esegui l'audit dei servizi per assicurarti che i servizi con lo stesso spazio dei nomi e lo stesso nome nei 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 per la contabilità dei pagamenti e un'API per le transazioni di pagamento) non utilizzino la stessa coppia [spazio dei nomi, nome] (ad esempio payments/api), perché verranno trattati come lo stesso servizio una volta che si trovano in un mesh di servizi. Questa unione concettuale si verifica anche oltre i confini regionali. Inoltre, la funzione dei servizi potrebbe essere compromessa.

L'identicità del nome/spazio dei nomi del servizio viene presupposta anche da Ingress multi-cluster e dal gateway multi-cluster quando il traffico viene indirizzato ai servizi in più cluster, anche se solo per i servizi esposti all'esterno dei cluster.

Considerare Workload Identity

Una potente funzionalità del parco risorse è la federazione delle identità per i workload a livello di parco risorse. Questa estende le funzionalità fornite in Workload Identity Federation for GKE, che consente ai workload nel cluster di autenticarsi su Google senza richiedere il download, la rotazione manuale e la gestione generale delle chiavi degli account di servizio. Google Cloud Al contrario, i workload si autenticano utilizzando token di breve durata generati dai cluster, con ogni cluster aggiunto come provider di identità a un pool di identità del workload speciale. I workload in esecuzione in uno spazio dei nomi specifico possono condividere la stessa identità di Identity and Access Management tra i cluster.

Mentre la federazione di Workload Identity standard per GKE utilizza un pool di identità a livello di progetto, la federazione delle identità per i workload a livello di parco risorse utilizza un pool di identità del workload per l'intero parco risorse, anche se i cluster si trovano in progetti diversi, con identicità implicita per le identità nel parco risorse, nonché identicità di spazio dei nomi e servizio. In questo modo è più semplice configurare l'autenticazione per le applicazioni tra i progetti, ma può avere considerazioni sul controllo dell'accesso oltre a quelle per Workload Identity Federation for GKE standard se scegli di utilizzarla nei 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 delle identità per i workload 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à per i workload 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à, 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 le policy predefinite a livello di parco risorse. In questo modo viene installato l'agente richiesto nei nuovi cluster membri del parco risorse e vengono applicate le policy predefinite.

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 aggiungi i cluster dopo aver configurato i valori predefiniti delle funzionalità. Ciò significa che puoi configurare in sicurezza i valori predefiniti a livello di parco risorse senza rischiare di abilitare o configurare le funzionalità sui 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 i parchi risorse in base alle funzionalità del parco risorse 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 Google Cloud.

La seguente tabella mostra i requisiti e le limitazioni attuali di ogni 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 Consulta le limitazioni Tutti i cluster utilizzati con Cloud Service Mesh che si trovano nello stesso progetto devono essere registrati nello stesso parco risorse. Per ulteriori informazioni, consulta Requisiti del parco risorse 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 rete VPC condivisa
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
Connect 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

Considerare 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 unico parco risorse.

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 un singolo VPC, puoi inserirli tutti in un unico parco risorse. Un altro pattern comune segue una topologia "hub e 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, seguendo queste linee guida, potresti avere parchi risorse con un solo cluster. In questo caso, potresti dover rinunciare all'utilizzo di funzionalità con restrizioni VPC e creare parchi risorse multi-progetto o riconsiderare l'architettura e spostare i workload, 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 ai 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 parchi risorse che includono cluster da più progetti, puoi utilizzare invece i gateway a cluster singolo e indirizzare il traffico al gateway corretto in un altro modo (ad esempio, utilizzando il DNS). I cluster che utilizzano queste funzionalità devono trovarsi anche nella stessa rete VPC.

Passaggi successivi