Questa pagina illustra le due modalità operative e la configurazione principale del cluster scelte che puoi fare durante la creazione di un cluster in Google Kubernetes Engine (GKE). Come le scelte discusse qui non possono essere modificate dopo la creazione di un cluster. Queste scelte influiscono sulla disponibilità di un cluster, stabilità della versione e network.
Livello di gestione del cluster
Prima di parlare dei tipi di cluster, è importante comprendere il il livello di flessibilità, responsabilità e controllo di cui hai bisogno in un cluster Kubernetes. Il livello di controllo necessario determina la modalità di funzionamento da utilizzare in GKE e le configurazioni dei cluster che devi realizzare.
Modalità di funzionamento
Quando crei un cluster in GKE, puoi farlo utilizzando uno dei le seguenti modalità operative:
Autopilot: fornisce un cluster completamente gestito e di cui è stato eseguito il provisioning configurazione. Per i cluster creati utilizzando la modalità Autopilot, le opzioni di configurazione del cluster sono fatte per te. Autopilot cluster sono preconfigurati con una configurazione di cluster ottimizzata, pronto per i carichi di lavoro di produzione.
Standard: offre flessibilità di configurazione avanzata rispetto all'infrastruttura sottostante del cluster. Per i cluster creati utilizzando In modalità Standard, sei tu a stabilire le configurazioni necessarie per i carichi di lavoro di produzione.
Per saperne di più su queste modalità e su Autopilot, consulta la panoramica di Autopilot.
Scelte di configurazione del cluster
In base alla modalità operativa scelta, devi selezionare le configurazioni per il tuo cluster. In modalità Autopilot, la maggior parte delle scelte sono fatti apposta per te. In modalità Standard, devi selezionare 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 Zonal |
| 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 la disponibilità i requisiti del tuo carico di lavoro e del tuo 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 nel Per la modalità Standard, vedi Scelta di un piano di controllo a livello di regione o zona.
Dopo aver creato un cluster, non puoi modificarlo da di zona a regionale oppure da a livello di regione o di zona. Devi invece creare un nuovo cluster ed eseguire la migrazione del traffico che le sono assegnati.
Cluster di zona
I cluster di zona hanno un singolo piano di controllo in un zona. In base alla tua disponibilità requisiti, 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 uno zona. Questo piano di controllo gestisce i carichi di lavoro di nodi in esecuzione nella stessa zona. Se esegui un carico di lavoro in una singola zona, carico di lavoro non è 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 singola zona con nodi in esecuzione in più zone. Durante un upgrade un cluster o un'interruzione della zona in cui viene eseguito il piano di controllo, i carichi di lavoro vengono eseguiti tutti i test delle unità. 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 la disponibilità e costi per carichi di lavoro coerenti. Se vuoi mantenere la disponibilità e di nodi e pool di nodi cambiano di frequente, valuta la possibilità di utilizzare cluster regionale. Se esegui un carico di lavoro in più zone e si è verificata 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 ha più repliche del piano di controllo, in esecuzione in più zone all'interno di un 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 ciascun pool di nodi in tre zone della regione del piano di controllo. Quando crei un cluster o quando aggiungi un nuovo pool di nodi, puoi modificare l'impostazione configurazione specificando le zone in cui vengono eseguiti i nodi del cluster. Tutti 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 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 le risorse Kubernetes specifiche per il cluster oppure puoi fare delle scelte in merito al suo mix complessivo di stabilità e funzionalità.
Indipendentemente da come gestisci la versione del cluster, è consigliabile attivare l'upgrade automatico per cluster e i relativi nodi. GKE esegue automaticamente l'upgrade dei nodi Autopilot.
Canale di rilascio
Se conosci il livello di stabilità di cui hai bisogno per un determinato cluster, puoi registrarti il cluster 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 viene eseguito un aggiornamento disponibili in quel canale di rilascio. Il canale rapido riceve vari aggiornamenti: mese, mentre il canale stabile riceve soltanto pochi aggiornamenti all'anno.
Versione specifica
Se sai di dover utilizzare una versione specifica di Kubernetes supportata per un determinato carico di lavoro, puoi specificarlo durante la creazione del cluster.
Se non hai bisogno di controllare la versione specifica della patch che utilizzi, considera registrare il cluster in un canale di rilascio anziché per gestire direttamente la sua versione.
Versione predefinita
Se scegli di utilizzare una versione statica anziché registrare il cluster in un canale di rilascio (ossia nessun canale) e non imposti una versione specifica per il cluster viene usata la versione predefinita attuale. La versione predefinita è selezionati in base all'utilizzo e alle prestazioni reali, e vengono modificati regolarmente. La versione predefinita per il formato statico è in genere in linea con la release regolare canale. Sebbene la versione predefinita sia quella più matura, altre versioni disponibili sono le versioni GA che hanno superato i test interni e l'idoneità. Le modifiche alla versione predefinita vengono annunciate in una nota di rilascio.
Networking per il cluster
Quando crei un cluster GKE, puoi specificare la rete la modalità di routing 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 il routing del traffico da un pod a un altro. Un cluster che utilizza alias Gli IP sono chiamati cluster nativi 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. Questo è l'impostazione predefinita per i cluster creati in modalità Autopilot.
Per maggiori dettagli, consulta Modalità di rete del cluster predefinita grafico.
Scelte di isolamento della rete
Per impostazione predefinita, puoi configurare l'accesso dalle reti pubbliche carichi di lavoro con scale out impegnativi. Le route non vengono create automaticamente. Assegnazione cluster privati interni a pod e nodi, 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 elencate come Beta o Stabile sono inclusi nei cluster GKE. Le funzionalità alpha di Kubernetes sono disponibili nella versione speciale di GKE alpha cluster.
Ammasso Alfa
Un cluster alfa ha tutto API Kubernetes alpha (a volte chiamate gate di funzionalità) abilitate. Puoi utilizzare per i test preliminari e la convalida delle funzionalità di Kubernetes. Alfa I cluster 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.