Pianificare le funzionalità del parco risorse

Un aspetto importante della pianificazione dei parchi risorse è decidere quali funzionalità abilitate per i parchi risorse vuoi utilizzare. In particolare, se utilizzi cluster esistenti e carichi di lavoro di produzione, ti consigliamo di identificare le funzionalità del parco risorse che possono essere adottate immediatamente con il minimo rischio o attrito 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à abilitate dall'utilizzo dei parchi e i relativi requisiti, nonché alcune indicazioni pratiche per l'adozione delle funzionalità.

Molte delle funzionalità descritte in questa guida sono disponibili solo in GKE Enterprise. Per maggiori dettagli, consulta le opzioni di deployment di GKE Enterprise.

Questa guida è rivolta ai Cloud Architect che vogliono iniziare a utilizzare i parchi nelle loro organizzazioni. Prima di leggere questa guida, assicurati di conoscere le nostre Panoramica della gestione del parco risorse e Pianificare le risorse del parco risorse, che illustrano come organizzare i cluster nuovi o esistenti in parchi risorse.

Best practice per l'adozione delle funzionalità

Tutte le funzionalità del parco (tranne l'osservabilità di base del parco) richiedono l'attivazione, in quanto devi specificare che vuoi utilizzarle. L'aggiunta di un cluster esistente a un parco risorse non ne modifica la configurazione. Se decidi di utilizzare le funzionalità del parco, alcune possono essere attivate immediatamente con rischi minimi, ma per altre potresti dover procedere con maggiore cautela. Questa sezione fornisce alcune indicazioni per l'adozione delle funzionalità.

In particolare, con i cluster e i carichi di lavoro esistenti, devi prestare particolare attenzione quando le funzionalità utilizzano la uguaglianza. Si tratta di un concetto del parco risorse in cui la funzionalità presume che gli spazi dei nomi, i servizi o le identità con lo stesso nome in cluster diversi siano la stessa cosa. Per scoprire di più sul principio di identità e sulle funzionalità che lo utilizzano, consulta Come funzionano i parchi pubblicitari.

Onboarding delle funzionalità a basso rischio

Le seguenti funzionalità "ambientali" non presuppongono alcun tipo di identità e non influiscono in alcun modo sui cluster. Possono essere utilizzati tutti in sicurezza anche con i workload e i cluster esistenti, consentendoti di usufruire immediatamente di una maggiore osservabilità e di approfondimenti sulla sicurezza nel tuo parco risorse, nonché 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 assumere la stessa identità, ma solo quando configuri o specifichi le 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 che utilizzano questi selettori facoltativi.

Onboarding delle funzionalità multi-cluster avanzate

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

Ad esempio, se hai già spazi dei nomi Kubernetes 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 le funzionalità che fanno questa supposizione. Analogamente, se vuoi utilizzare Cloud Service Mesh, devi capire quali endpoint di servizio verranno uniti nei tuoi cluster e confermare che questo è il comportamento desiderato.

Controlla l'uguaglianza dello spazio dei nomi

Se conosci bene le tue applicazioni, puoi eseguire la verifica dei tuoi spazi dei nomi semplicemente verificando che nessuna delle due applicazioni "diverse" utilizzi 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 denominato default in un cluster e uno spazio dei nomi denominato default in un altro cluster, ma vengono utilizzati per scopi diversi, devi rinominare uno dei due.

Per un approccio più rigoroso, prova quanto segue. Per ogni insieme di spazi dei nomi con lo stesso nome in diversi cluster di un parco risorse, verifica che:

  • in ogni cluster sono presenti le stesse regole RBAC e lo spazio dei nomi degli entità è autorizzato ad accedere allo spazio dei nomi.
  • l'insieme di immagini utilizzato dai pod (meno hash/tag) è lo stesso.
  • l'insieme di secret utilizzati dai pod sia 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 in nuovi spazi dei nomi. Una volta che hai verificato che gli spazi dei nomi sono uguali, puoi attivare le funzionalità che li utilizzano.

Verifica dell'identità del servizio

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à (specificamente per la sicurezza di Cloud Service Mesh): se namespace1/service1 è autorizzato a eseguire un'azione, i workload con quell'identità di qualsiasi cluster sono autorizzati.
  • Gestione del traffico: per impostazione predefinita, il traffico viene bilanciato su namespace1/service1 servizi in qualsiasi cluster.
  • Osservabilità: le metriche per namespace1/service1 in tutti i cluster vengono aggregate.

Se attivi Cloud Service Mesh con nuovi cluster e applicazioni, ti consigliamo di riservare combinazioni univoche di spazi dei nomi/nomi di servizi nell'intero mesh. Per le applicazioni esistenti, controlla i servizi per assicurarti che quelli 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 transazioni di pagamento) non utilizzino la stessa coppia [namespace, name] (ad esempio payments/api), perché verranno trattati come lo stesso servizio una volta che si trovano in un mesh di servizi. Questa unione concettuale avviene anche oltre i confini regionali. Inoltre, la funzionalità dei servizi potrebbe essere interessata.

L'identità del nome/del nome del servizio viene presupposta anche da Ingress multi-cluster e Gateway multi-cluster quando il traffico viene indirizzato ai servizi su più cluster, anche se solo per i servizi esposti all'esterno dei cluster.

Valutare l'identità del carico di lavoro

Una potente funzionalità del parco risorse è la federazione delle identità per i carichi di lavoro a livello di parco risorse. Ciò estende le funzionalità fornite in Workload Identity Federation per GKE, che consente ai carichi di lavoro del tuo cluster di autenticarsi su Google senza che tu debba scaricare, ruotare manualmente e gestire in generale le chiavi dell'account di servizio. Google Cloud I carichi di lavoro 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à di Identity and Access Management nei cluster.

Mentre la normale federazione delle identità per i carichi di lavoro per GKE 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 l'intero parco risorse, anche se i cluster si trovano in progetti diversi, con identità implicite per il parco risorse, nonché identità dello spazio dei nomi e del servizio. In questo modo, è più semplice configurare l'autenticazione per le applicazioni in più progetti, ma possono essere prese in considerazione considerazioni controllo dell'accesso oltre a quelle per la normale federazione delle identità di carico di lavoro per GKE se scegli di utilizzarla in parchi risorse multi-progetto, in particolare se il progetto host del parco risorse contiene una combinazione 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 Google Cloud servizi, consulta Utilizzare Workload Identity del parco risorse. Per indicazioni su come ridurre al minimo i rischi con la federazione di Workload Identity del parco risorse e alcuni esempi, consulta le Best practice per l'utilizzo di Workload Identity del parco risorse.

Impostazioni predefinite a livello di parco risorse

GKE Enterprise offre la possibilità di impostare i 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ò attivare Policy Controller per il proprio parco risorse e impostare i criteri predefiniti a livello di parco risorse. In questo modo, l'agente richiesto viene installato nei nuovi cluster di 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. 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 le impostazioni predefinite delle funzionalità. Ciò significa che puoi configurare in sicurezza le impostazioni predefinite a livello di parco risorse senza rischiare di attivare o configurare funzionalità sui cluster in cui non è ancora possibile 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 in base alle funzionalità che la tua organizzazione vuole utilizzare. Ad esempio, alcune funzionalità non supportano il lavoro con i cluster che non fanno parte del progetto host del parco risorse, mentre altre non sono supportate nei cluster esterni Google Cloud.

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

Mettere in evidenza
 Tipi di cluster
 Requisiti del progetto
 Requisiti VPC
Config Sync Tutti i cluster supportati da GKE Enterprise Nessuno Nessuno
Policy Controller Tutti i cluster supportati da GKE Enterprise 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 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à dei workload Ottimizzato per GKE su Google Cloud e Google Distributed Cloud su VMware. Sono supportati altri cluster Kubernetes, ma richiedono una configurazione aggiuntiva. Nessuno Nessuno
Autorizzazione binaria GKE su Google Cloud, Google Distributed Cloud su VMware, Google Distributed Cloud on 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 del 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

Valutare i requisiti di Virtual Private Cloud

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

Ad esempio, uno schema comune è che un'organizzazione abbia diversi progetti, ciascuno con il proprio VPC predefinito. Potrebbero esistere connessioni di peering tra di loro. Se non utilizzi una funzionalità con requisiti di un singolo VPC, puoi inserirle tutte 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, seguendo queste linee guida potresti avere parchi con un solo cluster. In questo caso, potresti dover rinunciare all'utilizzo di funzionalità con limitazioni VPC e creare parchi 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ò essere distribuito su 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 parchi risorse che includono cluster di più progetti, puoi utilizzare gateway a cluster singolo e indirizzare il traffico al gateway giusto in un altro modo (ad esempio utilizzando il DNS). Anche i cluster che utilizzano queste funzionalità devono trovarsi nella stessa rete VPC.

Passaggi successivi