Informazioni sulle opzioni di configurazione del cluster

Questa pagina illustra le principali opzioni di configurazione del cluster che puoi scegliere quando crei un cluster in Google Kubernetes Engine (GKE), indipendentemente dall'utilizzo della console Google Cloud, di Google Cloud CLI o di 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 discusse in questa guida non possono essere modificate dopo la creazione di un cluster. Sono incluse le scelte che influiscono sulla disponibilità e sulla rete di un cluster. Se devi modificare queste opzioni, devi creare un nuovo cluster e poi eseguire la migrazione del traffico al suo interno, il che potrebbe causare interruzioni.

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 e Google Cloud.

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

Prima di leggere questa pagina, devi conoscere quanto segue, oltre ai concetti di base di Kubernetes:

Livello di gestione del cluster

Prima di discutere le opzioni di cluster, è importante comprendere il livello di flessibilità, responsabilità e controllo di cui hai bisogno per il tuo cluster. Il livello di controllo richiesto determina la modalità di funzionamento da utilizzare in GKE e le scelte di configurazione del cluster da effettuare.

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

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

  • Standard: offre flessibilità di configurazione avanzata per l'infrastruttura sottostante del cluster. Per i cluster creati utilizzando la modalità standard, devi determinare la configurazione necessaria per i carichi di lavoro di produzione.

Per ulteriori informazioni su queste modalità e su Autopilot, consulta le modalità di funzionamento di GKE e la panoramica di Autopilot.

Puoi trovare un confronto dettagliato delle due modalità in Confronta GKE Standard e Autopilot.

Scelte di configurazione del cluster

Dopo aver scelto una modalità di funzionamento, seleziona la configurazione necessaria per il cluster. Poiché i cluster Autopilot sono gestiti e configurati in modo più completo da Google Cloud rispetto ai cluster standard, hanno meno opzioni 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 che lo identifichi e che sia univoco all'interno del progetto. Se vuoi, puoi anche aggiungere una descrizione e etichette ai cluster.
  • Disponibilità e scalabilità: specifica dove vuoi eseguire il piano di controllo e i nodi del cluster e se vuoi più repliche del piano di controllo. Tutti i cluster Autopilot sono regionali, il che significa che hanno più piani di controllo in più zone di calcolo in una regione Google Cloud.
  • Adesione al parco risorse: scegli se vuoi che il tuo cluster sia membro di un parco risorse.
  • Networking: opzioni di networking, tra cui la rete e la subnet Virtual Private Cloud (VPC) 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 il bilanciamento preferito tra nuove funzionalità e stabilità durante l'upgrade del software di questo cluster e imposta periodi di manutenzione ed esclusioni per scegliere quando possono e non possono essere eseguiti gli upgrade.
  • Sicurezza: include se il cluster utilizza la federazione delle identità per i carichi di lavoro per GKE e l'account di servizio utilizzato dai nodi del cluster per autenticarsi su Google Cloud.
  • Funzionalità del cluster: abilita e configura funzionalità aggiuntive di GKE e Google Cloud per questo cluster, inclusi i backup e l'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 opzioni anche nella seguente categoria:

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

Le sezioni seguenti esaminano alcune di queste categorie in modo più dettagliato, in particolare quelle con opzioni in cui non puoi modificare l'impostazione dopo aver creato il cluster. Per un elenco completo delle opzioni di configurazione, consulta Documentazione di riferimento sulla configurazione.

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

Scelte per i cluster Modalità
Autopilot Standard
Tipo di disponibilità A livello di regione Regionale o a livello di zona
Canale di rilascio Rapido, Regolare o Stabile Qualsiasi canale
Versioni cluster Predefinita o un'altra versione disponibile Predefinita o un'altra versione disponibile
Routing di rete Nativo VPC Nativo VPC o In base alle route
Isolamento della rete Personalizzabile Personalizzabile
Funzionalità di Kubernetes Produzione Produzione o alpha

Tipo di disponibilità del cluster

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

Per aiutarti a scegliere il tipo di cluster da creare in modalità Standard, consulta Scegliere un piano di controllo regionale o zonale.

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 a livello di regione perché in genere offrono una disponibilità superiore rispetto ai cluster di zona. Per gli ambienti di sviluppo, utilizza i cluster regionali con pool di nodi di zona. Un cluster con un piano di controllo a livello di regione e pool di nodi zonali ha gli stessi costi di un cluster zonale. Per saperne di più sulle regioni, consulta Regioni e zone.

Cluster a livello di regione

Un cluster a livello di regione include più repliche del piano di controllo, in esecuzione in più zone all'interno della regione Google Cloud specificata. Devi sempre specificare una regione quando crei un cluster Autopilot o un altro cluster a livello di area geografica.

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 o 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 a livello di regione per eseguire i carichi di lavoro di produzione, in quanto offrono una maggiore disponibilità rispetto ai cluster di zona.

Non puoi modificare la regione di un cluster regionale dopo la creazione del cluster.

Cluster a livello di zona (solo cluster standard)

I cluster zonali hanno un unico piano di controllo in un'unica zona. A seconda dei requisiti di disponibilità del tuo workload, puoi scegliere di distribuire i nodi per il cluster a livello di zona in una singola zona o in più zone.

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

Cluster a zona singola

Un cluster a zona singola ha un unico piano di controllo in esecuzione in una zona. Questo piano di controllo gestisce i carichi di lavoro sui nodi in esecuzione nella stessa zona. Se esegui un carico di lavoro in una singola zona, questo non è disponibile in caso di interruzione della zona.

Cluster multi-zonali

Un cluster multi-zona ha una singola replica del piano di controllo in esecuzione in un'unica zona e nodi in esecuzione in più zone. Durante un upgrade del cluster o un'interruzione della zona in cui è in esecuzione il piano di controllo, i carichi di lavoro continuano a essere eseguiti. Tuttavia, il cluster, i suoi nodi e i suoi carichi di lavoro non possono essere configurati finché non è disponibile il piano di controllo. I cluster multizonali bilanciano disponibilità e costi per carichi di lavoro coerenti. Se vuoi mantenere la disponibilità e il numero di nodi e pool di nodi cambia di frequente, valuta la possibilità di utilizzare un cluster regionale. Se esegui un carico di lavoro in più zone e si verifica un'interruzione a livello di zona, il carico di lavoro viene interrotto in quella zona, ma rimane disponibile nelle altre zone.

Livello cluster

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

Per i cluster GKE su Google Cloud, puoi selezionare se aggiungere il livello aggiuntivo di funzionalità in base al 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 utilizzerà per impostazione predefinita il livello standard, con alcune eccezioni.

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

  • Molte funzionalità di GKE Enterprise richiedono l'appartenenza a un parco risorse per funzionare. Puoi registrare un cluster in un parco risorse durante la creazione del cluster o dopo aver creato il cluster. Se vuoi utilizzare le funzionalità di GKE Enterprise abilitate per il parco risorse con un cluster, ti consigliamo di registrarlo a un parco risorse al momento della creazione, in quanto il cluster erediterà le impostazioni a livello di parco risorse per le funzionalità di Enterprise. Puoi approfondire questo argomento nella sezione Abbonamento a un parco auto.
  • 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 a un parco risorse, consulta le opzioni di deployment di GKE Enterprise.

Abbonamento a un parco risorse

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

Sebbene tu possa aggiungere cluster a un parco risorse in qualsiasi momento, se hai abilitato GKE Enterprise, ti consigliamo vivamente di registrare nuovi cluster di livello Enterprise a 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 che hai scelto per una serie di funzionalità aziendali e con i log e le metriche consigliate già abilitati. Per saperne di più, consulta le 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 workload attivi da un parco risorse all'altro.

Scopri di più sull'aggiunta di cluster ai parchi risorse in Creare 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 della rete e se vuoi che i nodi del cluster siano accessibili dalle reti pubbliche.

Se non sei un amministratore di rete, ti consigliamo di consultare gli esperti 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 di più sul networking di GKE in Informazioni sul networking di GKE e sulle best practice per le opzioni di networking in Best practice per il networking di GKE. Questa sezione descrive solo un sottoinsieme delle nostre possibili opzioni di networking.

Rete e subnet

La rete VPC (Virtual Private Cloud) 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 progetto, anche se puoi scegliere un'altra rete se tu o il tuo amministratore ne avete creata una. Se disponibile, puoi specificare che il tuo cluster debba appartenere a una subnet VPC specifica; in caso contrario, verrà utilizzata la subnet predefinita. Se vuoi, puoi anche specificare che vuoi utilizzare un determinato intervallo di indirizzi IP all'interno della subnet per i pod e i servizi.

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

Scelte di isolamento della rete

Puoi personalizzare l'isolamento della rete nel tuo cluster tenendo conto dei seguenti due aspetti:

  • Accesso al control plane: per impostazione predefinita, sono attivati sia l'endpoint interno sia l'endpoint esterno del control plane e 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 clienti esterni.
    • Consenti alle reti autorizzate di controllare quali indirizzi IP raggiungono gli endpoint del piano di controllo.

  • 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 carico di lavoro (per Autopilot). L'attivazione dei nodi privati a livello di pool di nodi o di carico di lavoro 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 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 sono comunque in grado di accedere alle risorse rivolte a internet.

Cluster nativi di VPC e basati su route

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

Per impostazione predefinita, tutti i nuovi cluster GKE utilizzano il routing nativo VPC, che è l'opzione consigliata. Puoi modificare questa impostazione al momento della 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, nella pagina Cluster nativi di VPC.

Best practice:

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

Versioni e upgrade

Con i canali di rilascio, GKE sceglie le versioni software per un cluster in base al bilanciamento scelto tra disponibilità e stabilità delle funzionalità. Quando crei un cluster, puoi scegliere il canale di release che preferisci. I nuovi cluster (sia Autopilot che Standard) sono registrati nel canale di rilascio regolare per impostazione predefinita, 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 tuo 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 piano di controllo e dei nodi del cluster man mano che le nuove versioni diventano disponibili nel 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 i 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 Stable, a seconda del loro stato di sviluppo. Nella maggior parte dei casi, le funzionalità Kubernetes elencate come beta o stabili sono incluse nei cluster GKE.

Se vuoi fare esperimenti con funzionalità molto nuove che non sono pronte per la produzione, le funzionalità alpha sono disponibili in cluster alpha GKE speciali. In un cluster alpha sono attivate tutte le API Kubernetes alpha (a volte chiamate feature gate). Puoi utilizzare i cluster alpha per i test e la convalida iniziali delle funzionalità di Kubernetes. I cluster alpha non sono supportati per i carichi di lavoro di produzione, non è possibile eseguirne l'upgrade o aggiungerli 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 la sezione Creare un cluster alpha.

Impostazioni di sicurezza

GKE dispone di una serie di impostazioni di sicurezza che puoi specificare al momento della creazione del cluster. Sono incluse le impostazioni di crittografia, le funzionalità di sicurezza come la Autorizzazione binaria, il account di servizio che vuoi utilizzare per i nodi del cluster (discututo più dettagliatamente nella sezione successiva) e se il tuo cluster utilizza la federazione delle identità per i carichi di lavoro per GKE.

Come per altre impostazioni, prima di creare un cluster pronto per la produzione, ti consigliamo di consultare colleghi esperti, in questo caso gli esperti di sicurezza della tua organizzazione. Puoi scoprire di più sulla sicurezza di GKE nella nostra Panoramica della sicurezza e nell'articolo Migliora la sicurezza del tuo cluster.

Account di servizio per i nodi

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

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

Se utilizzi l'account di servizio predefinito di Compute Engine per altre funzioni nel progetto o nell'organizzazione, l'account di servizio potrebbe avere più autorizzazioni di quelle necessarie per GKE, il che potrebbe esporre a rischi per la sicurezza.

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

Impostazioni del node pool (solo cluster standard)

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

Se scegli di creare un cluster standard, puoi specificare una serie di opzioni per i nodi, 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 VM spot temporanee per i nodi.
  • Il tipo di macchina di Compute Engine da utilizzare per i nodi.
  • L'account di servizio che vuoi utilizzare per i nodi, come descritto in Impostazioni 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 durante la creazione di un cluster standard, il pool di nodi predefinito è costituito da tre nodi in ciascuna delle zone del cluster, con l'immagine del nodo cos_containerd predefinita e un tipo di macchina generico.

Scopri 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