Percorso di apprendimento: scala le applicazioni - Considerazioni sulla produzione


In questo insieme di tutorial, alcune considerazioni sulla pianificazione sono semplificate in modo che tu possa concentrarti sull'apprendimento delle funzionalità e dei servizi chiave di Google Kubernetes Engine (GKE). Prima di iniziare a creare il tuo ambiente Google Kubernetes Engine simile a quello descritto in questo insieme di tutorial, tieni presente alcuni aspetti di pianificazione aggiuntivi. Queste considerazioni includono il livello di gestione del cluster, il networking e i tipi di disponibilità.

Networking

I cluster GKE richiedono un'attenta pianificazione degli indirizzi IP. Le opzioni di rete che scegli influiscono sull'architettura dei tuoi cluster GKE. Alcune di queste opzioni non possono essere modificate dopo la configurazione senza ricreare il cluster.

In questo insieme di tutorial, utilizzi cluster in modalità Autopilot che utilizzano sempre il networking in modalità nativa di VPC. I cluster nativi di VPC utilizzano intervalli di indirizzi IP alias sui nodi GKE e sono necessari per creare cluster su VPC condivisi. I cluster nativi di VPC vengono scalati più facilmente rispetto ai cluster basati su route senza consumare Google Cloud route e quindi sono meno soggetti a raggiungere i limiti di routing.

Prima di creare il tuo ambiente GKE ed eseguire il deployment dei carichi di lavoro, consulta le seguenti indicazioni sul networking:

Modalità cluster

In questo insieme di tutorial creerai un cluster GKE regionale che utilizza la modalità Autopilot. I cluster Autopilot sono preconfigurati con una configurazione del cluster ottimizzata e pronta per i carichi di lavoro di produzione. In alternativa, puoi utilizzare i cluster in modalità Standard per una flessibilità di configurazione più avanzata dell'infrastruttura sottostante.

Per una panoramica più completa, consulta i documenti di pianificazione che iniziano con le scelte di configurazione del cluster.

Spazi dei nomi

consentono di organizzare le applicazioni e isolare i componenti l'uno dall'altro. Ogni spazio dei nomi ha il proprio insieme di risorse, come pod, servizi e deployment. Ad esempio, puoi creare uno spazio dei nomi per tutti i tuoi servizi frontend e uno spazio dei nomi per i tuoi servizi backend. Questo raggruppamento semplifica la gestione dei servizi e il controllo dell'accesso.

In questo insieme di tutorial, esegui il deployment dei pod e dei servizi per l'applicazione di esempio Cymbal Bank in un unico spazio dei nomi. Questo approccio riduce la complessità del deployment, ma non consente di utilizzare gli spazi dei nomi per assegnare risorse a team e utenti diversi, come potresti fare in un ambiente di produzione. Per un esempio più sicuro e pronto per la produzione dell'applicazione di esempio Cymbal Bank che utilizza più spazi dei nomi, vedi Architettura dell'applicazione Cymbal Bank.

Budget di interruzione dei pod

I criteri del budget di interruzione dei pod (PDB) contribuiscono a garantire le prestazioni dell'app impedendo l'interruzione dei pod contemporaneamente quando apporti una modifica al sistema e limitano il numero di pod contemporaneamente non disponibili in un'applicazione replicata.

In questo insieme di tutorial, non configuri e non utilizzi i PDB. Quando completi il tutorial per simulare l'errore, tutti i servizi e i nodi devono rispondere come previsto. Quando esegui il deployment dei tuoi workload, i PDB sui nodi potrebbero bloccare lo svuotamento dei nodi.

Se utilizzi PDB, rivedi la configurazione prima di tentare di isolare e svuotare i nodi. Se i nodi non possono essere svuotati correttamente, potresti avere problemi con gli eventi di manutenzione pianificata.

Passaggi successivi

Per iniziare, completa il primo tutorial per eseguire il deployment di un singolo cluster GKE che esegue un'applicazione basata su microservizi.