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.
- Sequenza di implementazione basata sul parco risorse
- Osservabilità del parco risorse
- Postura di sicurezza
- Postura di conformità
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.
- Config Sync. Potresti dover prendere in considerazione l'uguaglianza se vuoi utilizzare i selettori facoltativi spazio dei nomi e ambito del team.
- Autorizzazione binaria. Potresti dover prendere in considerazione l'identità, lo spazio dei nomi o l'uguaglianza del servizio se vuoi utilizzare le regole basate sugli ambiti facoltative.
- Policy Controller. Potresti dover prendere in considerazione l'uguaglianza dello spazio dei nomi se vuoi escludere gli spazi dei nomi dall'applicazione.
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.
- Federazione delle identità per i carichi di lavoro di Fleet
- Cloud Service Mesh
- Gateway multi-cluster
- Ingress multi-cluster
- Gestione del team del parco risorse
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
- Scopri di più sulla gestione delle funzionalità del parco risorse in Gestire le funzionalità a livello di parco risorse.
- Scopri di più su come funzionano i parchi risorse in Come funzionano i parchi risorse.