Pianifica le funzionalità del parco risorse

Una parte importante della pianificazione dei parchi risorse è decidere quali funzionalità abilitate per il parco 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 come parte di 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 risorse 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. Quando decidi di utilizzare le funzionalità del parco, alcune possono essere attivate immediatamente con rischi minimi, ma potresti dover affrontare altre con maggiore attenzione. 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 ai punti in cui le caratteristiche usano identicità. Questo è un concetto di parco risorse in cui la caratteristica presuppone che spazi dei nomi, servizi o identità con lo stesso nome in cluster diversi siano la stessa cosa. Per scoprire di più sul principio di identità e su quali funzionalità lo utilizzano, consulta Come funzionano i parchi pubblicitari.

Onboarding delle funzionalità a basso rischio

I seguenti elementi "ambient" le caratteristiche non presuppongono alcun tipo di uguaglianza e non influiscono in nessun modo sui cluster. Possono essere utilizzati tutti in sicurezza anche con i carichi di lavoro 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à sono 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 abilitare queste funzionalità in modo sicuro sui tuoi cluster con carichi di lavoro esistenti e devi considerare l'uguaglianza solo quando crei o utilizzi le configurazioni che usano questi selettori facoltativi.

Onboarding delle funzionalità multi-cluster avanzate

Le seguenti potenti funzionalità riducono l'overhead operativo associato alla gestione di più cluster. Tuttavia, occorre prestare maggiore attenzione a queste funzionalità, poiché tutte richiedono il presupposto di uno o più tipi di uguaglianza per funzionare e l'abilitazione o la disabilitazione di queste funzionalità 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. Allo stesso modo, se vuoi utilizzare Cloud Service Mesh, devi sapere quali endpoint di servizio verranno uniti tra i tuoi cluster e confermare che si tratta di un comportamento desiderato.

Controlla l'identicità dello spazio dei nomi

Se conosci bene le tue applicazioni, puoi eseguire la revisione 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, che però sono utilizzati per scopi diversi, devi rinominarne uno.

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

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

Controlla l'uguaglianza dei servizi

Se vuoi adottare Cloud Service Mesh per gestire le applicazioni basate su microservizi, un altro problema da considerare è l'uguaglianza dei servizi. 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 carichi di lavoro 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 abiliti Cloud Service Mesh con nuovi cluster e applicazioni, ti consigliamo di prenotare combinazioni univoche di spazio dei nomi/nome di servizio in tutto il mesh. Per le applicazioni esistenti, controlla i tuoi servizi per assicurarti che quelli con lo stesso spazio dei nomi e nome in tutti i cluster siano quelli che vorresti fossero trattati 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 accounting 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 avviene anche oltre i confini regionali. Inoltre, la funzionalità dei servizi potrebbe essere compromessa.

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 nella federazione delle identità per i carichi di lavoro per GKE, che consente ai carichi di lavoro nel 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 vengono invece autenticati mediante token di breve durata generati dai cluster, con ogni cluster aggiunto come provider di identità a uno speciale pool di identità per i carichi di lavoro. 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 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 nei vari progetti, ma se scegli di utilizzarla in parchi risorse multiprogetto, puoi avere considerazioni sul controllo dell'accesso superiori a quelle per la normale federazione delle identità per i carichi di lavoro per GKE, in particolare se il progetto host del parco risorse ha 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 servizi Google Cloud, consulta Utilizzare Workload Identity del parco risorse. Per indicazioni su come ridurre al minimo i rischi con la federazione delle identità per i carichi di lavoro del parco risorse con alcuni esempi, consulta le best practice per l'utilizzo di Workload Identity del parco risorse.

Valori predefiniti a livello di parco risorse

GKE Enterprise consente di configurare valori predefiniti a livello di parco risorse per alcune 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. Viene installato l'agente richiesto nei nuovi cluster di membri del parco risorse e vengono applicati i criteri predefiniti.

Tuttavia, queste impostazioni predefinite si applicano automaticamente solo ai nuovi cluster che aggiungi al parco risorse al momento della creazione del cluster. I cluster esistenti e i relativi carichi di lavoro 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 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 lavorare con cluster che non fanno parte del progetto host del parco risorse, mentre altri non sono supportati su cluster esterni a Google Cloud.

La tabella seguente mostra i requisiti e le limitazioni attuali di ciascun componente. Nelle sezioni seguenti sono riportate alcune linee guida specifiche.

Mettere in primo piano
 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 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 ulteriori informazioni, vedi 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 in lo stesso progetto. Le risorse Ingress/Gateway e i cluster GKE devono trovarsi nella stessa rete VPC.
Pool di identità per i carichi di lavoro Ottimizzato per GKE su Google Cloud Google Distributed Cloud on 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 dei team del parco risorse Tutti Nessuno Nessuno
Criteri di rete FQDN 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 unico parco risorse.

Ad esempio, un modello comune è che un'organizzazione abbia più progetti, ciascuno con il proprio VPC predefinito. Potrebbero esserci connessioni in peering esistenti tra loro. Se non utilizzi una funzionalità con requisiti di un VPC singolo, questi possono essere inseriti in un unico parco risorse. Un altro modello comune segue un "hub e spoke" che utilizza diversi VPC. Se non utilizzi una funzionalità con requisiti di un singolo VPC, puoi posizionare 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 restrizioni VPC e creare parchi risorse multiprogetto o riconsiderare la tua 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 gateway non può coprire i progetti. Ciò significa che tutti i cluster che vuoi utilizzare con queste funzionalità devono trovarsi nello stesso progetto e nella stessa flotta. 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