Nota. transl.: stu materiale hè da un prughjettu educativu hè a risposta à una quistione populari quandu cuncepisce l'infrastruttura basata in Kubernetes. Speremu chì e descrizioni abbastanza dettagliate di i pros è i contra di ogni opzione vi aiuterà à fà a megliu scelta per u vostru prughjettu.
TL; DR: u listessu settore di carichi di travagliu pò esse eseguitu nantu à parechji grandi clusters (ogni cluster averà un gran numaru di carichi di travagliu) o nantu à parechji chjuchi (cù un picculu numeru di carichi di travagliu in ogni cluster).
Quì sottu hè una tavula chì evalueghja i pro è i contra di ogni approcciu:
Quandu si usa Kubernetes cum'è una piattaforma per eseguisce l'applicazioni, parechje dumande fundamentale sò spessu nascenu nantu à l'intricatezza di a creazione di clusters:
- Quanti clusters deve aduprà?
- Quantu grande li devu fà ?
- Chì duverebbe include ogni cluster?
In questu articulu, pruvaraghju à risponde à tutte queste dumande analizendu i vantaghji è i contra di ogni approcciu.
A dichjarazione di una dumanda
Cum'è sviluppatore di software, probabilmente sviluppate è operate parechje applicazioni à u stessu tempu.
Inoltre, assai casi di queste applicazioni sò prubabilmente eseguite in diverse ambienti - per esempiu, questi ponu esse dev, francese test и prod.
U risultatu hè una matrice sana di applicazioni è ambienti:
Applicazioni è Ambienti
L'esempiu sopra rapprisenta 3 applicazioni è 3 ambienti, chì risultanu in un totale di 9 opzioni pussibuli.
Ogni istanza di l'applicazione hè una unità di implementazione autonoma chì pò esse travagliatu indipindentamente di l'altri.
nutate chì istanza di l'applicazione pò esse cumpostu di parechji cumpunenti, cum'è frontend, backend, database, etc. In u casu di una applicazione di microservizi, l'istanza includerà tutti i microservizi.
In u risultatu, l'utilizatori di Kubernetes anu parechje dumande:
- Tutti l'istanze di l'applicazione devenu esse piazzate in un cluster?
- Vale a pena avè un cluster separatu per ogni istanza di l'applicazione?
- O forse una cumminazione di l'avvicinamenti sopra deve esse usata?
Tutte queste opzioni sò abbastanza viabili, postu chì Kubernetes hè un sistema flexible chì ùn limita micca e capacità di l'utilizatori.
Eccu alcuni di i modi pussibuli:
- un grande cluster cumunu;
- assai picculi clusters altamente specializati;
- un cluster per applicazione;
- un cluster per ambiente.
Comu mostra quì sottu, i primi dui approcci sò à l'estremità opposte di a scala di l'opzioni:
Da uni pochi grossi gruppi (a manca) à parechji picculi (a diritta)
In generale, un cluster hè cunsideratu "più grande" di l'altru s'ellu hà una summa più grande di nodi è pods. Per esempiu, un cluster cù 10 node è 100 pods hè più grande di un cluster cù 1 node è 10 pods.
Ebbè, cuminciamu !
1. Un grande cluster cumunu
A prima opzione hè di mette tutti i carichi di travagliu in un cluster:
Un grande cluster
In questu approcciu, u cluster hè utilizatu cum'è universale piattaforma infrastrutturali - basta implementà tuttu ciò chì avete bisognu in un cluster Kubernetes esistente.
Kubernetes permette parti di u cluster per esse logicamente separati l'una di l'altru, in modu chì ogni istanza di l'applicazione pò avè u so propiu namespace.
Fighjemu i vantaghji è i contra di stu approcciu.
+ Utilizazione efficace di e risorse
Cù un solu cluster, avete bisognu di una sola copia di tutte e risorse necessarie per eseguisce è gestisce u cluster Kubernetes.
Per esempiu, questu hè veru per i nodi maestri. Di genere, ogni cluster Kubernetes hà 3 nodi maestri, cusì per un cluster unicu u so numeru resterà cusì (per paragunà, 10 clusters necessitanu 30 nodi maestri).
A suttilità sopra s'applica ancu à altri servizii chì operanu in tuttu u cluster, cum'è equilibratori di carica, cuntrolli Ingress, autentificazione, logging è sistemi di monitoraghju.
In un cluster unicu, tutti sti servizii ponu esse aduprati in una volta per tutti i carichi di travagliu (ùn ci hè bisognu di creà copie di elli, cum'è u casu cù parechje clusters).
+ Cheap
In cunseguenza di ciò chì sopra, menu clusters sò generalmente più prezzu perchè ùn ci sò micca spese generali.
Questu hè soprattuttu veru per i nodi maestri, chì ponu custà una quantità significativa di soldi, indipendentemente da cumu sò ospitu (in u locu o in u nuvulu).
Certi servizii gestiti Kubernetes, cum'è o , furnisce a strata di cuntrollu gratuitamente. In questu casu, u prublema di u costu hè menu agutu.
Ci sò ancu servizii amministrati chì paganu una tarifa fissa per l'operazione di ogni cluster Kubernetes (per esempiu, ).
+ Amministrazione efficiente
A gestione di un cluster hè più faciule ch'è di gestisce parechji.
L'amministrazione pò include i seguenti compiti:
- aghjurnamentu di a versione di Kubernetes;
- crià un pipeline CI/CD;
- installà u plugin CNI;
- crià un sistema di autentificazione di l'utilizatori;
- stallazione di un cuntrollu di accessu;
è tanti altri…
In u casu di un cluster, avete da fà tuttu questu solu una volta.
Per parechji clusters, l'operazioni duveranu esse ripetute parechje volte, chì prubabilmente necessitanu una certa automatizazione di prucessi è arnesi per assicurà a coherenza è a cunsistenza in u prucessu.
È avà uni pochi di parolle nantu à i contra.
− Unicu puntu di fallimentu
In casu di rifiutu u solu u cluster cesserà di travaglià immediatamente tutte e carichi di travagliu!
Ci hè parechje manere chì e cose ponu sbaglià:
- l'aghjurnamentu di Kubernetes porta à effetti latu inespettati;
- Un cumpunente di cluster-wide (per esempiu, un plugin CNI) cumencia à ùn travaglià cum'è previstu;
- unu di i cumpunenti di u cluster ùn hè micca cunfiguratu bè;
- fallimentu in l'infrastruttura sottostante.
Un tali incidente pò causà gravi danni à tutti i carichi di travagliu ospitati in un cluster spartutu.
− Nisun isolamentu rigidu
Eseguisce in un cluster spartutu significa chì l'applicazioni sparte l'hardware, e capacità di rete è u sistema operatore in i nodi di cluster.
In un certu sensu, dui cuntenituri cù duie applicazioni diverse chì currenu nantu à u stessu node sò cum'è dui prucessi chì funzionanu nantu à a listessa macchina cù u stessu kernel OS.
I cuntenituri Linux furniscenu una certa forma di isolamentu, ma ùn hè micca cusì forte cum'è quellu furnitu da, per esempiu, e macchine virtuali. In essenza, un prucessu in un cuntainer hè u stessu prucessu in esecuzione nantu à u sistema operatore host.
Chistu pò esse un prublema di sicurità: stu arrangementu teoricamente permette à l'applicazioni senza relazione di cumunicà cù l'altri (intenzionalmente o accidentalmente).
Inoltre, tutti i carichi di travagliu in un cluster Kubernetes sparte parechji servizii di u cluster cum'è - questu permette à l'applicazioni di truvà i servizii di altre applicazioni in u cluster.
Tutti i punti sopra ponu avè significati diffirenti sicondu i requisiti di sicurezza di l'applicazione.
Kubernetes furnisce diverse arnesi per prevene prublemi di sicurezza cum'è и . Tuttavia, a stallazione curretta richiede una certa sperienza; in più, ùn sò micca capaci di chjude assolutamente tutti i buchi di sicurezza.
Hè impurtante di ricurdà sempre chì Kubernetes hè statu inizialmente pensatu per spartera, micca per isolamentu è sicurità.
− Mancanza di multi-tenancy strettu
Data l'abbundanza di risorse spartute in un cluster Kubernetes, ci sò parechje manere chì e diverse applicazioni ponu passà nantu à i pedi di l'altri.
Per esempiu, una applicazione puderia monopolizà una risorsa cumuna (cum'è CPU o memoria) è ricusà l'altri applicazioni chì currenu nantu à u stessu nodu accessu à questu.
Kubernetes furnisce diversi miccanismi per cuntrullà stu cumpurtamentu, cum'è (vede ancu l'articulu ""- ca. trad.), и . Tuttavia, cum'è in u casu di sicurità, a so cunfigurazione hè abbastanza micca triviale è ùn sò micca capaci di prevene assolutamente tutti l'effetti secundari imprevisti.
− Un gran numaru di utilizatori
In u casu di un cluster unicu, avete da apre l'accessu à ellu à parechje persone. È u più grande u so numeru, u più altu u risicu chì "rompe" qualcosa.
Dentru u cluster pudete cuntrollà quale pò fà ciò chì usendu (vede l'articulu ""- ca. trad.). Tuttavia, ùn impedisce micca à l'utilizatori di "rompere" qualcosa in a so zona di rispunsabilità.
− I clusters ùn ponu micca cresce indefinitu
U cluster chì hè utilizatu per tutti i carichi di travagliu serà prubabilmente abbastanza grande (in quantu à u numeru di nodi è pods).
Ma quì nasce un altru prublema: i clusters in Kubernetes ùn ponu micca cresce indefinitu.
Ci hè un limitu teoricu nantu à a dimensione di u cluster. In Kubernetes hè circa .
Tuttavia, in a vita vera, i prublemi ponu principià assai prima - per esempiu, solu cù .
U fattu hè chì i grandi clusters ponenu una carica alta nantu à a capa di cuntrollu di Kubernetes. In altri palori, mantene u cluster in funziunamentu efficiente richiede una sintonizazione curretta.
Stu prublema hè esploratu in un articulu relatatu in u blog originale chjamatu "».
Ma cunsideremu l'approcciu oppostu: parechji picculi clusters.
2. Parechji picculi clusters specializati
Cù questu approcciu, utilizate un cluster separatu per ogni elementu chì implementate:
Parechji picculi clusters
Per i scopi di stu articulu, sottu elementu dispiegabile si riferisce à una istanza di una applicazione - per esempiu, una versione dev di una applicazione separata.
Questa strategia usa Kubernetes cum'è un specializatu runtime per i casi individuali di l'applicazione.
Fighjemu i vantaghji è i contra di stu approcciu.
+ "Radiu di esplosione" limitatu
Quandu un cluster falla, e cunsequenze negative sò limitate solu à quelli carichi di travagliu chì sò stati implementati in quellu cluster. Tutti l'altri carichi di travagliu restanu intatti.
+ Isolamentu
I carichi di travagliu ospitati in clusters individuali ùn sparte micca risorse cum'è processore, memoria, sistema operatore, rete o altri servizii.
U risultatu hè un isolamentu strettu trà l'applicazioni senza relazione, chì pò esse benefiziu per a so sicurità.
+ Picculu numeru di utilizatori
Dapoi chì ogni cluster cuntene solu un settore limitatu di carichi di travagliu, u numeru di utilizatori cù accessu à questu hè ridutta.
Quantu menu persone anu accessu à u cluster, u più bassu u risicu chì qualcosa "romperà".
Fighjemu i contra.
− Utilizazione inefficace di e risorse
Cumu l'ammentatu prima, ogni cluster Kubernetes richiede un settore specificu di risorse di gestione: nodi maestri, cumpunenti di strati di cuntrollu, suluzioni di monitoraghju è logu.
In u casu di un gran numaru di picculi clusters, una parte più grande di risorse deve esse attribuita à a gestione.
− Caru
L'usu inefficace di risorse implica automaticamente alti costi.
Per esempiu, u mantenimentu di 30 nodi maestri invece di trè cù a listessa putenza di computing averà necessariamente affettatu i costi.
− Difficultà in l'amministrazione
A gestione di più cluster Kubernetes hè assai più difficiule di gestisce solu unu.
Per esempiu, avete da cunfigurà l'autentificazione è l'autorizazione per ogni cluster. A versione Kubernetes duverà ancu esse aghjurnata parechje volte.
Puderete bisognu di utilizà l'automatizazione per fà tutte queste attività più efficaci.
Avà guardemu à scenarii menu estremi.
3. Un cluster per applicazione
In questu approcciu, create un cluster separatu per tutti i casi di una applicazione particulare:
Cluster per applicazione
Stu percorsu pò esse cunsideratu cum'è una generalizazione di u principiu "cluster separatu per squadra", postu chì di solitu una squadra di ingegneri sviluppa una o più applicazioni.
Fighjemu i vantaghji è i contra di stu approcciu.
+ U cluster pò esse adattatu à l'applicazione
Se una applicazione hà bisogni speciali, ponu esse implementati in un cluster senza affettà altri clusters.
Tali bisogni ponu include i travagliadori GPU, certi plugins CNI, una rete di serviziu, o qualchì altru serviziu.
Ogni cluster pò esse adattatu à l'applicazione chì curre in ellu in modu chì cuntene solu ciò chì hè necessariu.
− Ambienti differenti in un cluster
U svantaghju di stu approcciu hè chì l'istanze di l'applicazioni da diverse ambienti coexistenu in u stessu cluster.
Per esempiu, a versione prod di l'applicazione corre in u stessu cluster cum'è a versione dev. Questu significa ancu chì i sviluppatori operanu in u stessu cluster in quale a versione di produzzione di l'applicazione hè operata.
Se, per via di l'azzioni di sviluppatori o glitches in a versione dev, un fallimentu si trova in u cluster, allora a versione prod puderia ancu soffre - un grande inconveniente di questu approcciu.
È infine, l'ultimu scenariu nantu à a nostra lista.
4. Un cluster per ambiente
Stu scenariu implica l'assignazione di un cluster separatu per ogni ambiente:
Un cluster per ambiente
Per esempiu, pudete avè clusters dev, francese test и prod, in quale eseguite tutte e istanze di l'applicazione dedicata à un ambiente specificu.
Eccu i vantaghji è i contra di stu approcciu.
+ Isolamentu di l'ambiente prod
In questu approcciu, tutti l'ambienti sò isolati da l'altri. Tuttavia, in a pratica, questu hè particularmente impurtante in un ambiente prod.
E versioni di pruduzzione di l'applicazione sò avà indipendenti da ciò chì succede in altri clusters è ambienti.
In questu modu, se un prublema si presenta di colpu in u cluster dev, e versioni prod di l'applicazioni continuanu à travaglià cum'è s'ellu ùn era nunda.
+ U cluster pò esse adattatu à l'ambiente
Ogni cluster pò esse adattatu à u so ambiente. Per esempiu, pudete:
- installà strumenti per u sviluppu è u debugging in u cluster dev;
- installà frameworks di prova è arnesi in u cluster francese test;
- aduprà hardware più putente è canali di rete in u cluster prod.
Questu permette di aumentà l'efficienza di u sviluppu di l'applicazione è di u funziunamentu.
+ Restrizzione di l'accessu à u cluster di produzzione
U bisognu di travaglià direttamente cù un cluster di prod raramente nasce, perchè pudete limità significativamente u circhiu di e persone chì anu accessu à questu.
Pudete andà ancu più luntanu è nigà l'accessu à e persone à stu cluster in tuttu, è eseguisce tutte e implementazioni utilizendu un strumentu CI / CD automatizatu. Un tali approcciu minimizeghja u risicu di l'errori umani esattamente induve hè più pertinente.
È avà uni pochi di parolle nantu à i contra.
− Nisun isolamentu trà l'applicazioni
U principale svantaghju di l'approcciu hè a mancanza di l'isolamentu di hardware è risorse trà l'applicazioni.
L'applicazioni senza relazione sparte e risorse di cluster: u core di u sistema, u processore, a memoria è altri servizii.
Comu diciatu, questu pò esse potenzialmente periculoso.
− Incapacità di localizà e dipendenze di l'applicazione
Se una applicazione hà esigenze speciali, allora deve esse soddisfatte in tutti i clusters.
Per esempiu, se una applicazione richiede una GPU, allora ogni cluster deve cuntene almenu un travagliadore cù una GPU (ancu s'ellu hè utilizatu solu da quella applicazione).
In u risultatu, risichemu i costi più elevati è l'usu inefficace di risorse.
cunchiusioni
Se tenete un settore specificu d'applicazioni, ponu esse posti in parechji grandi clusters o parechji chjuchi.
L'articulu discute i pro è i contra di diversi approcci, chì varieghja da un cluster globale à parechji picculi è altamente specializati:
- un grande cluster generale;
- assai picculi clusters altamente specializati;
- un cluster per applicazione;
- un cluster per ambiente.
Allora chì approcciu duvete piglià?
Cum'è sempre, a risposta dipende di u casu d'usu: avete bisognu di pisà i pros and cons di diversi approcci è sceglie l'opzione più ottima.
Tuttavia, a scelta ùn hè micca limitata à l'esempii sopra - pudete aduprà qualsiasi cumminazzioni di elli!
Per esempiu, pudete urganizà un paru di clusters per ogni squadra: un cluster di sviluppu (in quale ci saranu ambienti dev и francese test) è cluster per Pruduzzioni (induve l'ambiente di produzzione serà situatu).
Basatu nantu à l'infurmazioni in questu articulu, pudete ottimisà i pro è i contra in cunseguenza per un scenariu specificu. Bona Furtuna !
PS
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «";
- «».
Source: www.habr.com