Informazioni sulle opzioni di configurazione del cluster

Questa pagina spiega le principali scelte di configurazione del cluster che puoi fare quando crei un cluster in Google Kubernetes Engine (GKE), sia che utilizzi la consoleGoogle Cloud , Google Cloud CLI o Terraform. Queste opzioni ti consentono di personalizzare un'ampia gamma di attributi e comportamenti del cluster in base alle tue esigenze, ad esempio se il cluster è accessibile dalle reti pubbliche e come vuoi che riceva gli upgrade di versione.

Molte delle opzioni descritte in questa guida non possono essere modificate dopo la creazione di un cluster. Queste includono scelte che influiscono sulla disponibilità e sulla rete di un cluster. Se devi modificare queste opzioni, devi creare un nuovo cluster e poi migrare il traffico al suo interno, il che potrebbe essere interruttivo.

Best practice:

Poiché molte opzioni di configurazione del cluster non possono essere modificate dopo la creazione del cluster, pianifica e progetta la configurazione del cluster con gli amministratori e gli architetti della tua organizzazione, gli architetti cloud, gli amministratori di rete o qualsiasi altro team responsabile della definizione, dell'implementazione e della manutenzione dell'architettura GKE eGoogle Cloud .

Questa pagina è destinata agli amministratori e agli architetti che definiscono le soluzioni IT e l'architettura di sistema in base alla strategia aziendale. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise. Google Cloud

Prima di leggere questa pagina, devi avere familiarità con quanto segue, nonché con i concetti di base di Kubernetes:

Livello di gestione del cluster

Prima di discutere delle opzioni del cluster, è importante comprendere il livello di flessibilità, responsabilità e controllo che richiedi per il tuo cluster. Il livello di controllo che ti serve determina la modalità di funzionamento da utilizzare in GKE e le scelte di configurazione del cluster che devi fare.

Quando crei un cluster in GKE, lo fai utilizzando una delle seguenti modalità di funzionamento:

  • Autopilot (consigliato): fornisce una configurazione del cluster completamente sottoposta a provisioning e gestita. I cluster Autopilot sono preconfigurati con una configurazione del cluster ottimizzata e pronta per i carichi di lavoro di produzione.

  • Standard: offre una flessibilità di configurazione avanzata rispetto all'infrastruttura sottostante del cluster. Per i cluster creati utilizzando la modalità Standard, determini la configurazione necessaria per i tuoi workload di produzione.

Per saperne di più su queste modalità e su Autopilot, consulta Modalità operative di GKE e la panoramica di Autopilot.

Puoi trovare un confronto dettagliato affiancato delle due modalità in Confronto tra GKE Standard e Autopilot.

Scelte di configurazione del cluster

Dopo aver scelto una modalità di funzionamento, seleziona la configurazione che ti serve per il cluster. Poiché i cluster Autopilot sono gestiti e configurati in modo più completo da Google Cloud rispetto ai cluster Standard, hanno meno scelte di configurazione disponibili.

Le opzioni di configurazione per tutti i cluster rientrano nelle seguenti categorie:

  • Nome e altri metadati: ogni cluster deve avere un nome identificativo univoco all'interno del progetto. Puoi anche aggiungere facoltativamente una descrizione e delle etichette del cluster.
  • Disponibilità e scalabilità: specifica dove vuoi che vengano eseguiti il piano di controllo e i nodi del cluster e se vuoi più repliche del control plane. Tutti i cluster Autopilot sono regionali, il che significa che hanno più control plane in più zone di calcolo in una Google Cloud regione.
  • Appartenenza al parco risorse: scegli se vuoi che il cluster sia membro di un parco risorse.
  • Networking: opzioni di networking, tra cui la rete Virtual Private Cloud (VPC) e la subnet in cui si trova il cluster, e se vuoi che il cluster sia accessibile dalle reti pubbliche.
  • Gestione delle versioni e degli upgrade: utilizza i canali di rilascio per scegliere l'equilibrio che preferisci tra nuove funzionalità e stabilità durante l'upgrade del software di questo cluster e imposta periodi di manutenzione ed esclusioni per scegliere quando gli upgrade possono e non possono essere eseguiti.
  • Sicurezza: indica se il cluster utilizza la federazione delle identità dei carichi di lavoro per GKE e il account di servizio utilizzato dai nodi del cluster per l'autenticazione aGoogle Cloud.
  • Funzionalità del cluster: attiva e configura funzionalità aggiuntive di GKE e Google Cloud per questo cluster, inclusi backup e osservabilità. La modalità Standard ti consente anche di creare cluster alpha di breve durata per provare le funzionalità alpha di Kubernetes.

Oltre a queste, i cluster standard hanno anche opzioni nella seguente categoria:

  • Pool di nodi: specifica i dettagli sui nodi del cluster, inclusi i pool di nodi, il sistema operativo dei nodi e il dimensionamento dei nodi.

Le sezioni seguenti esaminano alcune di queste categorie in modo più dettagliato, in particolare quelle con opzioni in cui non è possibile modificare l'impostazione dopo la creazione del cluster. Per un elenco completo delle opzioni di configurazione, consulta Riferimento alla configurazione.

La seguente tabella confronta le opzioni disponibili in alcune aree chiave per i cluster Autopilot e Standard:

Scelte del cluster Modalità
Autopilot Standard
Tipo di disponibilità A livello di regione Regionale o zonale
Canale di rilascio Rapid, Regolare o Stabile Qualsiasi canale
Versioni del cluster Predefinita o un'altra versione disponibile Predefinita o un'altra versione disponibile
Routing di rete VPC nativo Nativo di VPC o basato su route
Isolamento di rete Personalizzabile Personalizzabile
Funzionalità di Kubernetes Produzione Produzione o Alpha

Disponibilità del cluster

Con GKE, puoi creare un cluster personalizzato in base ai requisiti di disponibilità del tuo carico di lavoro e al tuo budget. Puoi scegliere tra cluster regionali con più repliche del control plane in più zone di calcolo in una regione Google Cloud o cluster zonali con un singolo control plane in una singola zona. I cluster Autopilot sono sempre regionali.

Per scegliere il tipo di cluster da creare in modalità Standard, consulta la sezione Scelta di un control plane regionale o di zona.

Queste impostazioni non possono essere aggiornate dopo la creazione del cluster: un cluster a livello di zona non può diventare un cluster a livello di regione e un cluster a livello di regione non può diventare un cluster a livello di zona.

Best practice:

Per i carichi di lavoro di produzione, utilizza i cluster regionali perché in genere offrono una disponibilità maggiore rispetto ai cluster zonali. Per gli ambienti di sviluppo, utilizza cluster regionali con pool di nodi a livello di zona. Un cluster con un piano di controllo regionale e pool di nodi zonali ha gli stessi costi di un cluster zonale. Per saperne di più sulle considerazioni specifiche per le regioni, consulta Area geografica e regioni.

Cluster a livello di regione

Un cluster regionale ha più repliche del control plane, in esecuzione in più zone all'interno della Google Cloud regione specificata. Devi sempre specificare una regione quando crei un cluster Autopilot o un altro cluster regionale.

Solo per i cluster Standard regionali, puoi anche scegliere in quali zone vengono eseguiti i nodi del cluster. I nodi di un cluster regionale possono essere eseguiti in più zone o in una singola zona a seconda delle località dei nodi configurate. Per impostazione predefinita, GKE replica ogni pool di nodi in tre zone della regione del piano di controllo. Quando crei un cluster Standard regionale o quando aggiungi un nuovo pool di nodi, puoi modificare la configurazione predefinita specificando le zone in cui vengono eseguiti i nodi del cluster. Tutte le zone devono trovarsi nella stessa regione del control plane.

Utilizza i cluster regionali per eseguire i carichi di lavoro di produzione, in quanto offrono una disponibilità superiore rispetto ai cluster di zona.

Non puoi modificare la regione di un cluster regionale dopo averlo creato.

Cluster di zona

I cluster zonali hanno un unico control plane in una singola zona. I carichi di lavoro continuano a essere eseguiti durante un upgrade del cluster o un'interruzione della zona in cui è in esecuzione il control plane. Tuttavia, il cluster, i relativi nodi e i relativi carichi di lavoro non possono essere configurati finché non è disponibile il control plane. A seconda dei requisiti di disponibilità del carico di lavoro, puoi scegliere di distribuire i nodi per il cluster zonale in una singola zona o in più zone.

Per creare un cluster di zona, consulta la sezione Creazione di un cluster di zona.

Posizione e distribuzione dei nodi

Indipendentemente dal fatto che utilizzi cluster regionali o di zona, puoi determinare con precisione la posizione e la distribuzione dei nodi nelle zone. Puoi configurare le zone predefinite per tutti i pool di nodi futuri, nonché assegnare o modificare le zone specifiche per i nodi all'interno dei pool di nodi esistenti.

Cluster a zona singola

Un cluster a zona singola, che può essere un cluster regionale o di zona, esegue i carichi di lavoro sui nodi che si trovano in una sola zona. Se la zona subisce un'interruzione del servizio, tutti i carichi di lavoro diventano non disponibili.

I cluster zonali vengono creati per impostazione predefinita come cluster a zona singola, ma puoi aggiornare questa configurazione a cluster multizona.

Cluster multi-zonali

Un cluster multizona, che può essere un cluster regionale o zonale, migliora la disponibilità del carico di lavoro distribuendo i nodi in più zone all'interno di una singola regione. In questo modo puoi eseguire carichi di lavoro in più zone di una regione. Se esegui un workload in più zone e si verifica un'interruzione del servizio a livello di zona, il workload viene interrotto in quella zona, ma rimane disponibile nelle altre zone.

La distribuzione dei nodi GKE in più zone può comportare addebiti per il traffico in uscita di rete tra zone quando i nodi devono comunicare con i peer che si trovano in una zona diversa all'interno della regione.

I cluster regionali vengono creati per impostazione predefinita come cluster multizona, ma puoi aggiornare questa configurazione a cluster a zona singola.

Livello cluster

Come sai dalle versioni di GKE, GKE ha due livelli di funzionalità: un livello standard di funzionalità disponibili per tutti gli utenti GKE e un livello Enterprise che aggiunge potenti funzionalità per lavorare su scala aziendale, molte delle quali si basano sulla gestione del parco risorse GKE.

Per i cluster GKE su Google Cloud, scegli se aggiungere il livello aggiuntivo di funzionalità per ogni cluster. Una volta registrato un cluster nel livello GKE Enterprise, hai il diritto di utilizzare tutte le funzionalità enterprise disponibili. Se non specifichi un livello del cluster, il cluster utilizza il livello standard per impostazione predefinita, con alcune eccezioni.

Quando selezioni il livello del cluster, assicurati di comprendere quanto segue:

  • Molte funzionalità di GKE Enterprise richiedono l'appartenenza al parco risorse per funzionare. Puoi registrare un cluster in un parco risorse durante la creazione del cluster o dopo averlo creato. Se vuoi utilizzare le funzionalità di GKE Enterprise abilitate per il parco risorse con un cluster, ti consigliamo di registrare il cluster in un parco risorse al momento della creazione, in modo che il cluster erediti le impostazioni a livello di parco risorse per le funzionalità Enterprise. Puoi scoprire di più su questo argomento in Abbonamento alla flotta.
  • Puoi abilitare il livello Enterprise per un cluster solo se l'API GKE Enterprise (Anthos) è abilitata nel progetto del cluster.

Questa impostazione può essere modificata dopo la creazione del cluster.

Per ulteriori dettagli sulle funzionalità incluse in GKE Enterprise, incluso il sottoinsieme di funzionalità che non richiedono l'appartenenza al parco risorse, consulta Opzioni di deployment di GKE Enterprise.

Abbonamento al parco risorse

Se la tua organizzazione utilizza più cluster, puoi semplificare la gestione multi-cluster aggiungendo i cluster a un parco risorse: un raggruppamento logico di cluster Kubernetes. La creazione di un parco risorse aiuta la tua organizzazione a migliorare il livello di gestione dai singoli cluster a interi gruppi di cluster e ti consente di utilizzare funzionalità abilitate per il parco risorse come Multi Cluster Ingress, Config Sync e Policy Controller.

Anche se puoi aggiungere cluster a un parco risorse in qualsiasi momento, se hai abilitato GKE Enterprise, ti consigliamo vivamente di registrare i nuovi cluster di livello Enterprise in un parco risorse durante la creazione dei cluster. Questo perché questi cluster "nati nel parco risorse" vengono creati con le impostazioni predefinite a livello di parco risorse scelte per una serie di funzionalità enterprise e con log e metriche consigliati già abilitati. Puoi scoprire di più su questi argomenti nelle seguenti guide:

Questa impostazione può essere aggiornata dopo la creazione del cluster per registrarlo o annullarne la registrazione, anche se sconsigliamo di spostare i cluster con carichi di lavoro attivi da un parco risorse all'altro.

Puoi scoprire molto di più sull'aggiunta di cluster ai parchi risorse in Crea parchi risorse per semplificare la gestione multi-cluster.

Impostazioni di networking

Quando crei un cluster GKE, puoi specificare una serie di impostazioni di rete, tra cui la rete in cui si trova il cluster, la modalità di routing di rete e se vuoi che i nodi del cluster siano accessibili da reti pubbliche.

Se non sei un amministratore di rete, devi consultare gli specialisti di Networking della tua organizzazione prima di creare un cluster pronto per la produzione, poiché molte di queste opzioni non possono essere modificate dopo la creazione del cluster. Se sei un amministratore di rete, puoi scoprire molto di più sul networking GKE in Informazioni sul networking GKE, con le best practice per le opzioni di networking in Best practice per il networking GKE. Questa sezione descrive solo un sottoinsieme delle nostre possibili opzioni di networking.

Rete e subnet

La rete Virtual Private Cloud (VPC) in cui si trova un cluster determina le altre risorse di Compute Engine con le quali può comunicare. Per impostazione predefinita, i cluster GKE vengono creati nella rete predefinita del tuo progetto, anche se puoi scegliere un'altra rete se tu o il tuo amministratore ne avete creata una. Se disponibile, puoi specificare che vuoi che il tuo cluster appartenga a una subnet VPC specifica; in caso contrario, viene utilizzata la subnet predefinita. Puoi anche specificare facoltativamente di utilizzare un intervallo di indirizzi IP specifico all'interno di quella subnet per i tuoi pod e servizi.

Queste impostazioni non possono essere aggiornate dopo la creazione del cluster.

Scelte relative all'isolamento di rete

Puoi personalizzare l'isolamento di rete nel cluster prendendo in considerazione i seguenti due aspetti:

  • Accesso al control plane: per impostazione predefinita, sono abilitati sia l'endpoint interno sia quello esterno del control plane, mentre l'endpoint basato su DNS è disabilitato. Puoi scegliere di:

    • Disattiva sia l'endpoint esterno che quello interno e utilizza solo l'endpoint DNS.
    • Disattiva l'endpoint esterno solo per impedire l'accesso ai client esterni.
    • Abilita le reti autorizzate per controllare quali indirizzi IP raggiungono gli endpoint del control plane.

  • Configurazione di rete del cluster: puoi scegliere di attivare i nodi privati nel cluster per isolare completamente i carichi di lavoro dalle reti pubbliche. Puoi abilitare i nodi privati per interi cluster o a livello di pool di nodi (per Standard) o di workload (per Autopilot). L'attivazione dei nodi privati a livello di pool di nodi o workload sostituisce qualsiasi configurazione dei nodi a livello di cluster.

Queste impostazioni possono essere modificate dopo la creazione del cluster.

Per ulteriori informazioni sull'isolamento di rete, consulta Informazioni sulla personalizzazione dell'isolamento di rete e Personalizzare l'isolamento di rete.

Best practice:

Utilizza Cloud NAT per fornire ai pod di GKE l'accesso alle risorse con indirizzi IP pubblici. Cloud NAT migliora la postura di sicurezza complessiva del cluster perché i pod non sono esposti direttamente a internet, ma possono comunque accedere alle risorse con accesso a internet.

Cluster nativi di VPC e basati su route

In GKE, i cluster possono essere distinti in base al modo in cui instradano il traffico da un pod a un altro. Un cluster che utilizza indirizzi IP alias è chiamato cluster nativo di VPC. Un cluster che utilizza Google Cloud route è chiamato cluster basato su route.

Per impostazione predefinita, tutti i nuovi cluster GKE utilizzano il routing nativo di VPC, che è l'opzione consigliata. Puoi modificare questa impostazione durante la creazione del cluster per creare un cluster basato su route solo in modalità Standard. Questa impostazione non può essere aggiornata dopo la creazione del cluster.

Puoi scoprire di più sui cluster nativi di VPC e sui relativi vantaggi, inclusi eventuali requisiti speciali, in Cluster nativi di VPC.

Best practice:

Utilizza la modalità di rete nativa VPC per i tuoi cluster. Questo è il valore predefinito per i cluster Autopilot.

Versioni e upgrade

Con i canali di rilascio, GKE sceglie le versioni del software per un cluster con il bilanciamento che preferisci tra disponibilità e stabilità delle funzionalità. Quando crei un cluster, puoi scegliere il canale di rilascio che preferisci. I nuovi cluster (sia Autopilot che Standard) sono registrati per impostazione predefinita al canale di rilascio regolare, anche se puoi scegliere una versione specifica durante la creazione del cluster, se necessario.

I cluster Autopilot utilizzano sempre i canali di rilascio. I cluster standard utilizzano i canali di rilascio per impostazione predefinita, ma puoi scegliere di non registrare il cluster in un canale di rilascio (anche se non lo consigliamo perché questa impostazione ti offre un accesso più limitato alle funzionalità del cluster).

GKE esegue automaticamente l'upgrade di tutti i cluster nel tempo, indipendentemente dalla registrazione al canale di rilascio. GKE esegue automaticamente l'upgrade del control plane del cluster e dei relativi nodi man mano che nuove versioni diventano disponibili in quel canale di rilascio. Puoi controllare la tempistica e l'ambito degli upgrade con periodi di manutenzione ed esclusioni.

Puoi modificare il canale di rilascio di un cluster in qualsiasi momento.

Per informazioni sugli upgrade automatici imminenti, consulta le note di rilascio di GKE.

Best practice:

Scegli un canale di rilascio per GKE per selezionare le versioni del tuo cluster per bilanciare la disponibilità e la stabilità delle funzionalità. Utilizza periodi di manutenzione ed esclusioni per controllare la tempistica e l'ambito degli upgrade automatici.

Funzionalità alpha (solo cluster standard)

Le nuove funzionalità di Kubernetes sono elencate come alpha, beta o stabile, a seconda del loro stato di sviluppo. Nella maggior parte dei casi, le funzionalità di Kubernetes elencate come beta o stabili sono incluse nei cluster GKE.

Se vuoi sperimentare funzionalità molto nuove che non sono pronte per la produzione, le funzionalità alpha sono disponibili in cluster alpha GKE speciali. Un cluster alpha ha tutte le API alpha di Kubernetes (a volte chiamate funzionalità gate) abilitate. Puoi utilizzare i cluster alpha per test e convalida anticipati delle funzionalità di Kubernetes. I cluster Alpha non sono supportati per i carichi di lavoro di produzione, non possono essere aggiornati o aggiunti ai canali di rilascio e scadono entro 30 giorni.

Le funzionalità alpha non sono disponibili per i cluster Autopilot.

Per creare un cluster alpha, consulta Creazione di un cluster alpha.

Impostazioni di sicurezza

GKE dispone di una serie di impostazioni di sicurezza che puoi specificare al momento della creazione del cluster. Questi includono le impostazioni di crittografia, le funzionalità di sicurezza come Autorizzazione binaria, il account di servizio che vuoi utilizzare per i nodi del cluster (descritto in dettaglio nella sezione successiva) e se il cluster utilizza Workload Identity Federation for GKE.

Come per altre impostazioni, prima di creare un cluster pronto per la produzione, devi consultarti con colleghi esperti, in questo caso gli specialisti della sicurezza della tua organizzazione. Puoi scoprire di più sulla sicurezza di GKE nella nostra panoramica sulla sicurezza e in Rafforzare la sicurezza del cluster.

Service account per i nodi

GKE utilizza i service account IAM collegati ai nodi per eseguire attività di sistema come il logging e il monitoraggio. Come minimo, questi service account nodo devono avere il ruolo Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) sul tuo progetto. Per impostazione predefinita, GKE utilizza l'account di servizio predefinito di Compute Engine, che viene creato automaticamente nel tuo progetto, come service account del nodo.

Se la tua organizzazione applica il vincolo del criterio dell'organizzazione iam.automaticIamGrantsForDefaultServiceAccounts, il account di servizio Compute Engine predefinito nel tuo progetto potrebbe non ottenere automaticamente le autorizzazioni richieste per GKE.

Se utilizzi il account di servizio predefinito di Compute Engine per altre funzioni nel tuo progetto o nella tua organizzazione, il account di servizio potrebbe disporre di più autorizzazioni di quelle necessarie a GKE, il che potrebbe esporti a rischi per la sicurezza.

Non puoi modificare l'account di servizio per i cluster in modalità Autopilot o per i pool di nodi in modalità standard dopo la creazione.

Impostazioni del node pool (solo cluster Standard)

Come sai dalla panoramica dell'amministrazione dei cluster e dalle modalità di funzionamento di GKE, se utilizzi Autopilot per i tuoi cluster non devi preoccuparti della configurazione dei nodi perché GKE li configura per te. I nodi del cluster Autopilot sono tutti completamente gestiti da GKE e utilizzano tutti lo stesso sistema operativo del nodo.

Se scegli di creare un cluster standard, puoi specificare una serie di opzioni per i nodi durante la creazione di un cluster, tra cui:

  • Il nome, il numero, le dimensioni e la posizione dei pool di nodi che vuoi utilizzare. I pool di nodi sono gruppi di nodi all'interno del cluster che condividono una configurazione comune.
  • Il sistema operativo del nodo che vuoi utilizzare per i nuovi nodi.
  • Se vuoi utilizzare le VM spot temporanee per i nodi.
  • Il tipo di macchina di Compute Engine che vuoi utilizzare per i nodi.
  • L'account di servizio che vuoi utilizzare per i nodi, come descritto in Impostazioni di sicurezza.

Alcune impostazioni del pool di nodi di un cluster possono essere modificate dopo la creazione del cluster, anche se tutti i cluster Standard richiedono almeno un pool di nodi. Se non specifichi un numero di nodi e un tipo di macchina quando crei un cluster Standard, il suo pool di nodi predefinito è costituito da tre nodi in ciascuna zona del cluster, con l'immagine del nodo cos_containerd predefinita e un tipo di macchina per uso generico.

Puoi scoprire di più sulla configurazione pool di nodi in Informazioni sui node pool e Aggiungere e gestire i node pool.

Riferimento alla configurazione

Trova un elenco completo delle possibili opzioni di configurazione nelle seguenti guide di riferimento:

Passaggi successivi