Questa pagina illustra le due modalità operative e le scelte principali di configurazione del cluster che puoi fare quando crei un cluster in Google Kubernetes Engine (GKE). Di regola, le scelte discusse qui non possono essere modificate dopo la creazione di un cluster. Queste scelte influiscono sulla disponibilità, sulla stabilità della versione e sulla rete di un cluster.
Livello di gestione del cluster
Prima di parlare dei tipi 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à operativa da utilizzare in GKE e le configurazioni del cluster da eseguire.
Modalità di funzionamento
Quando crei un cluster in GKE, puoi farlo utilizzando una delle seguenti modalità operative:
Autopilot: fornisce una configurazione del cluster completamente gestita e di cui è stato eseguito il provisioning. Per i cluster creati con la modalità Autopilot, le opzioni di configurazione dei cluster sono pensate per te. I cluster Autopilot sono preconfigurati con una configurazione del cluster ottimizzata, pronta per i carichi di lavoro di produzione.
Standard: offre flessibilità di configurazione avanzata sull'infrastruttura sottostante del cluster. Per i cluster creati utilizzando la modalità Standard, sei tu a determinare le configurazioni necessarie per i tuoi carichi di lavoro di produzione.
Per saperne di più su queste modalità e per saperne di più su Autopilot, consulta la panoramica di Autopilot.
Scelte di configurazione del cluster
In base alla modalità operativa scelta, seleziona le configurazioni richieste per il cluster. In modalità Autopilot, la maggior parte delle scelte viene fatta automaticamente. In modalità Standard, devi selezionare le configurazioni più adatte ai tuoi carichi di lavoro di produzione.
| Scelte del cluster | Modalità | |
|---|---|---|
| Autopilot | Standard | |
| Tipo di disponibilità | A livello di regione | A livello di regione o a livello di zona |
| Versione | Canale di rilascio | Canale di rilascio, Predefinito o Specifico |
| Routing di rete | Nativo VPC | VPC-native o basate su route |
| Isolamento della rete | Privato o Pubblico | Privato o Pubblico |
| Funzionalità di Kubernetes | Produzione | Produzione o Alpha |
Tipo di disponibilità del cluster
Con GKE puoi creare un cluster su misura per i requisiti di disponibilità del carico di lavoro e del budget. I tipi di cluster disponibili includono: a livello di zona (a zona singola o multi-zona) e a livello di regione.
Per aiutarti a scegliere quale cluster disponibile creare in modalità Standard, consulta Scelta di un piano di controllo regionale o di zona.
Dopo aver creato un cluster, non puoi modificarlo da a livello di zona a regionale o viceversa. Devi invece creare un nuovo cluster ed eseguire la migrazione del traffico al cluster.
Cluster di zona
I cluster di zona hanno un singolo piano di controllo in un'unica zona. A seconda dei requisiti di disponibilità, puoi scegliere di distribuire i nodi per il cluster di zona in una singola zona o in più zone.
Per creare un cluster di zona in modalità Standard, consulta Creazione di un cluster di zona.
Cluster a zona singola
Un cluster a zona singola ha un singolo 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 carico di lavoro non sarà disponibile in caso di interruzione del servizio a livello di zona.
Cluster multi-zona
Un cluster multi-zona ha un'unica replica del piano di controllo in esecuzione in una singola zona e nodi in esecuzione in più zone. Durante un upgrade del cluster o un'interruzione della zona in cui viene eseguito il piano di controllo, i carichi di lavoro vengono comunque eseguiti. Tuttavia, il cluster, i nodi e i carichi di lavoro non possono essere configurati fino a quando il piano di controllo non è disponibile. I cluster multi-zona 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 a livello di regione. 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 in altre 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 di una determinata regione. I nodi in un cluster a livello di regione 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 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 all'interno della stessa regione del piano di controllo.
Utilizza i cluster a livello di regione per eseguire i carichi di lavoro di produzione, poiché offrono una disponibilità maggiore rispetto ai cluster di zona.
Per creare un cluster a livello di regione in modalità Standard, consulta Creazione di un cluster a livello di regione.
Per creare un cluster a livello di regione in modalità Autopilot, consulta Creazione di un cluster Autopilot.
Versione cluster
Quando crei un cluster, puoi scegliere la versione Kubernetes specifica del cluster o fare delle scelte in merito al mix complessivo di stabilità e funzionalità.
Indipendentemente da come gestisci la versione del cluster, ti consigliamo di abilitare l'upgrade automatico per il cluster e i relativi nodi. GKE esegue automaticamente l'upgrade dei nodi per i cluster Autopilot.
Canale di rilascio
Se conosci il livello di stabilità di cui hai bisogno per un determinato cluster, puoi registrarlo in un canale di rilascio. Per impostazione predefinita, i nuovi cluster vengono registrati nel canale di rilascio regolare. Google esegue automaticamente l'upgrade del cluster e dei relativi nodi quando è disponibile un aggiornamento in quel canale di rilascio. Il canale rapido riceve diversi aggiornamenti al mese, mentre il canale stabile riceve solo pochi aggiornamenti all'anno.
Versione specifica
Se sai di dover utilizzare una versione specifica di Kubernetes supportata per un determinato carico di lavoro, puoi specificarla durante la creazione del cluster.
Se non hai bisogno di controllare la versione specifica della patch che utilizzi, valuta la possibilità di registrare il cluster in un canale di rilascio invece di gestirne direttamente la versione.
Versione predefinita
Se scegli di utilizzare una versione statica anziché registrare il cluster in un canale di rilascio (ovvero, nessun canale) e non imposti una versione specifica per il cluster, viene utilizzata la versione predefinita corrente. La versione predefinita viene selezionata in base all'utilizzo e alle prestazioni reali e viene modificata regolarmente. La versione predefinita per i contenuti statici è in genere allineata al canale di rilascio regolare. Sebbene la versione predefinita sia quella più matura, altre versioni rese disponibili sono quelle GA che hanno superato test e idoneità interni. Le modifiche alla versione predefinita vengono annunciate in una nota di rilascio.
Networking per il cluster
Quando crei un cluster GKE, puoi specificare la modalità di routing della rete e come isolare la rete del cluster.
Cluster nativi di VPC e basati su route
In Google Kubernetes Engine, i cluster possono essere distinti in base al modo in cui instradano il traffico da un pod a un altro pod. Un cluster che utilizza IP alias è chiamato cluster nativo di VPC. Un cluster che utilizza route di Google Cloud è chiamato cluster basato su route.
La modalità di rete VPC nativa è la modalità di rete consigliata per i nuovi cluster. Questa è l'impostazione predefinita per i cluster creati in modalità Autopilot.
Per maggiori dettagli, consulta il grafico Modalità di rete del cluster predefinita.
Scelte di isolamento della rete
Per impostazione predefinita, puoi configurare l'accesso dalle reti pubbliche ai carichi di lavoro del cluster. Le route non vengono create automaticamente. I cluster privati assegnano indirizzi interni a pod e nodi e i carichi di lavoro sono completamente isolati dalle reti pubbliche.
Per creare un cluster privato, consulta Creazione di un cluster privato.
Funzionalità di Kubernetes
Le nuove funzionalità in Kubernetes sono elencate come Alpha, Beta o Stabile, a seconda del loro stato in fase di sviluppo. Nella maggior parte dei casi, le funzionalità di Kubernetes indicate come beta o stabili sono incluse nei cluster GKE. Le funzionalità alpha di Kubernetes sono disponibili in cluster GKE alpha speciali.
Ammasso Alfa
In un cluster alpha sono abilitate tutte le API Kubernetes alpha (a volte chiamate "gate gate di funzionalità"). Puoi usare i cluster alpha per testare e convalidare le funzionalità di Kubernetes in fase iniziale. I cluster alpha non sono supportati per i carichi di lavoro di produzione, non possono essere aggiornati e scadono entro 30 giorni.
Per creare un cluster alpha in modalità Standard, consulta Creazione di un cluster alpha.