Nota di traduzione.: questo materiale proviene da un progetto educativo — risposta a una domanda comune nella progettazione di infrastrutture basate su Kubernetes. Speriamo che le descrizioni dettagliate dei pro e dei contro di ciascuna opzione aiutino a fare la scelta ottimale anche per il vostro progetto.
TL;DR: lo stesso insieme di carichi di lavoro può essere eseguito su più grandi cluster (ogni cluster avrà un grande numero di workload) o su un gran numero di piccoli (con un numero ridotto di carichi in ciascun cluster).
Di seguito è riportata una tabella che valuta i pro e i contro di ciascun approccio:
Quando si utilizza Kubernetes come piattaforma per l’esecuzione di applicazioni, sorgono spesso alcune domande fondamentali sulle sfumature della configurazione dei cluster:
- Quanti cluster utilizzare?
- Di quanto grande farli?
- Cosa deve includere ogni cluster?
In questo articolo cercherò di rispondere a tutte queste domande analizzando i pro e i contro di ciascun approccio.
Formulazione della domanda
Come creatore di software, è probabile che stiate sviluppando ed eseguendo in parallelo molteplici applicazioni.
Inoltre, è probabile che molteplici istanze di queste applicazioni vengano eseguite in vari ambienti: per esempio, potrebbero essere dev, test e prod.
Il risultato è una vera e propria matrice di applicazioni e ambienti:
Applicazioni e ambienti
Nell'esempio sopra sono rappresentate 3 applicazioni e 3 ambienti, che in totale forniscono 9 possibili varianti.
Ogni istanza dell'applicazione rappresenta un'unità di distribuzione autosufficiente, con la quale è possibile lavorare indipendentemente dalle altre.
Si prega di notare che istanza dell'applicazione può consistere in molteplici componenti, come frontend, backend, database, ecc. Nel caso di un'applicazione a microservizi, l'istanza includerà tutti i microservizi.
Di conseguenza, gli utenti di Kubernetes si pongono alcune domande:
- Vale la pena collocare tutte le istanze dell'applicazione in un unico cluster?
- Vale la pena creare un cluster separato per ogni istanza dell'applicazione?
- O, forse, dovremmo considerare una combinazione delle opzioni sopra menzionate?
Tutte queste opzioni sono del tutto praticabili, poiché Kubernetes è un sistema flessibile che non limita le possibilità dell'utente.
Ecco alcune delle possibili soluzioni:
- un grande cluster condiviso;
- un gran numero di piccoli cluster specializzati;
- un cluster per ogni applicazione;
- un cluster per ogni ambiente.
Come mostrato di seguito, i primi due approcci sono agli estremi opposti della gamma di opzioni:
Da alcuni grandi cluster (a sinistra) a molti piccoli (a destra)
In generale, si considera che un cluster sia "maggiore" di un altro se ha una maggiore somma di nodi e pod. Ad esempio, un cluster con 10 nodi e 100 pod è maggiore di un cluster con 1 nodo e 10 pod.
Bene, iniziamo!
1. Un grande cluster comune
La prima opzione è quella di ospitare tutti i carichi di lavoro in un unico cluster:
Un grande cluster
In questo approccio, il cluster è utilizzato come piattaforma infrastrutturale universale — tutto ciò di cui hai bisogno è semplicemente distribuito nel cluster Kubernetes esistente. I namespace
Esaminiamo i pro e i contro di questo approccio.
+ Utilizzo efficace delle risorse
Nel caso di un cluster unico, richiederà solo una copia di tutte le risorse necessarie per avviare e gestire il cluster Kubernetes.
Ad esempio, questo è valido per i nodi master. Di solito, ci sono 3 nodi master per ogni cluster Kubernetes, quindi per un unico cluster il numero rimarrà lo stesso (in confronto, 10 cluster richiederanno 30 nodi master).
La sottigliezza sopra menzionata si applica anche ad altri servizi che operano a livello di cluster, come bilanciatori di carico, controller Ingress, sistemi di autenticazione, logging e monitoraggio.
In un cluster unico, tutti questi servizi possono essere utilizzati immediatamente per tutti i carichi di lavoro (non è necessario crearne copie, come nel caso di più cluster).
+ Economicità
Di conseguenza, un minor numero di cluster di solito è più economico, poiché non ci sono costi per risorse ridondanti.
Questo è particolarmente vero per i nodi master, che possono costare significativamente, indipendentemente dalla modalità di distribuzione (on-premises o nel cloud).
Alcuni servizi Kubernetes gestiti, come
Google Kubernetes Engine (GKE) o , forniscono uno strato di gestione gratuitamente. In questo caso, la questione dei costi è meno urgente.
Esistono anche servizi gestiti che addebitano una tariffa fissa per il funzionamento di ciascun cluster Kubernetes (ad esempio, ).
+ Amministrazione efficace
Gestire un singolo cluster è più semplice che gestirne diversi.
L'amministrazione può includere le seguenti attività:
- aggiornamento della versione di Kubernetes;
- configurazione della pipeline CI/CD;
- installazione del plugin CNI;
- configurazione del sistema di autenticazione degli utenti;
- installazione del controller di accesso;
e molte altre…
Nel caso di un singolo cluster, dovrai occuparti di tutto questo solo una volta.
Per più cluster, dovrai ripetere le operazioni più volte, il che probabilmente richiederà qualche automazione dei processi e strumenti per garantire sistematicità e uniformità.
E ora alcune parole sui contro.
− Punto unico di guasto
In caso di guasto dell'unico cluster, tutte le tutti carichi di lavoro smetteranno di funzionare!
Ci sono molteplici scenari in cui qualcosa può andare storto:
- un aggiornamento di Kubernetes potrebbe portare effetti collaterali inaspettati;
- un componente del cluster (ad esempio, il plugin CNI) inizia a funzionare in modo diverso da quanto previsto;
- uno dei componenti del cluster è configurato in modo errato;
- un guasto nell'infrastruttura sottostante.
Un tale incidente può causare danni significativi a tutti i carichi di lavoro ospitati nel cluster condiviso.
− Mancanza di isolamento rigoroso
Lavorare in un cluster condiviso significa che le applicazioni condividono l'hardware, le capacità di rete e il sistema operativo sui nodi del cluster.
In un certo senso, due container con due applicazioni diverse in esecuzione sullo stesso nodo sono simili a due processi in esecuzione sulla stessa macchina sotto lo stesso kernel del sistema operativo.
I container Linux offrono una certa forma di isolamento, ma non è così forte come quella fornita, ad esempio, dalle macchine virtuali. In sostanza, il processo in un container è lo stesso processo eseguito nel sistema operativo dell'host.
Questo può diventare un problema dal punto di vista della sicurezza: tale organizzazione consente teoricamente a applicazioni non correlate di interagire tra di loro (intenzionalmente o accidentalmente).
Inoltre, tutti i carichi di lavoro nel cluster Kubernetes condividono alcuni servizi comuni al cluster, come — questo consente alle applicazioni di trovare i Service di altre applicazioni nel cluster.
Tutti i punti sopra menzionati possono avere un significato diverso a seconda dei requisiti di sicurezza delle applicazioni.
Kubernetes offre vari strumenti per prevenire problemi nel sistema di sicurezza, come e . Tuttavia, per configurarli correttamente è necessaria una certa esperienza, inoltre non sono in grado di chiudere completamente tutte le falle nella sicurezza.
È importante ricordare sempre che Kubernetes è stato originariamente progettato per la condivisione, e non per l'isolamento e la sicurezza.
− Mancanza di multi-tenancy rigida
Considerando l'abbondanza di risorse comuni nel cluster Kubernetes, ci sono molti modi in cui le diverse applicazioni possono "calpestarsi" a vicenda.
Ad esempio, un'applicazione potrebbe monopolizzare una risorsa comune (come la CPU o la memoria) e privare altre applicazioni che operano sullo stesso nodo dell'accesso ad essa.
Kubernetes fornisce vari meccanismi di controllo per tale comportamento, come (vedi anche l'articolo “» — nota del traduttore.), e . Tuttavia, come nel caso della sicurezza, la loro configurazione è piuttosto complessa e non possono prevenire completamente tutti gli effetti collaterali imprevisti.
− Un gran numero di utenti
Nel caso di un singolo cluster, è necessario concedere l'accesso a molte persone. E più alto è il loro numero, maggiore è il rischio che possano "rompere" qualcosa.
All'interno del cluster è possibile controllare chi e cosa può fare tramite (vedi l'articolo “» — nota del traduttore.). Tuttavia, ciò non impedirà agli utenti di "rompere" qualcosa all'interno della propria area di responsabilità.
− I cluster non possono crescere all'infinito
Un cluster utilizzato per tutti i carichi di lavoro sarà probabilmente piuttosto grande (in termini di nodi e pod).
Ma qui emerge un altro problema: i cluster in Kubernetes non possono crescere all'infinito.
Esiste un limite teorico alla dimensione del cluster. In Kubernetes, questo è di circa .
Tuttavia, nella vita reale, i problemi possono iniziare molto prima, ad esempio, con soli .
Il fatto è che i grandi cluster esercitano un alto carico sul layer di controllo di Kubernetes. In altre parole, per mantenere il cluster operativo ed utilizzare efficacemente le risorse, è necessaria un'attenta configurazione.
Questo problema è esaminato nell'articolo corrispondente sul blog originale intitolato "».
Ma consideriamo l'approccio opposto: molti piccoli cluster.
2. Molti piccoli cluster specializzati
In questo approccio, utilizzi un cluster separato per ogni elemento distribuito:
Molti piccoli cluster
Ai fini di questo articolo, l' elemento distribuito si riferisce a un'istanza dell'applicazione, ad esempio, la versione dev di un'applicazione separata.
In questa strategia, Kubernetes è utilizzato come un ambiente di esecuzione specializzato per istanze separate dell'applicazione.
+ Utilizzo efficace delle risorse
+ Raggio d'azione limitato
Quando un cluster "si rompe", le conseguenze negative sono limitate solo ai carichi di lavoro distribuiti in quel cluster. Tutti gli altri workload rimangono intatti.
+ Isolamento
I carichi di lavoro collocati in cluster individuali non condividono risorse comuni, come CPU, memoria, sistema operativo, rete o altri servizi.
Di conseguenza, otteniamo un'rigida isolamento tra applicazioni non correlate, il che può giovare alla loro sicurezza.
+ Numero limitato di utenti
Considerando che ogni cluster contiene solo un set limitato di carichi di lavoro, si riduce il numero di utenti che vi accedono.
Meno persone hanno accesso al cluster, minore è il rischio che qualcosa "si rompa".
Esaminiamo i contro.
- Utilizzo inefficiente delle risorse
Come accennato in precedenza, ogni cluster Kubernetes richiede un certo set di risorse di gestione: nodi master, componenti del layer di controllo, soluzioni per il monitoraggio e la registrazione.
In caso di un alto numero di piccoli cluster, è necessario allocare una quota maggiore di risorse per la gestione.
- Costi elevati
L'utilizzo inefficiente delle risorse comporta automaticamente costi elevati.
Ad esempio, avere 30 master-node invece di tre alla stessa potenza computazionale avrà sicuramente un impatto sui costi.
− Complessità di amministrazione
Amministrare molti cluster Kubernetes è molto più difficile che lavorare con uno solo.
Ad esempio, sarà necessario configurare l'autenticazione e l'autorizzazione per ogni cluster. Anche l'aggiornamento della versione di Kubernetes dovrà essere effettuato più volte.
Probabilmente sarà necessario applicare l'automazione per aumentare l'efficienza di tutte queste attività.
Ora consideriamo scenari meno estremi.
3. Un cluster per ogni applicazione
In questo approccio, si crea un cluster separato per tutte le istanze di una specifica applicazione:
Cluster per applicazione
Questo approccio può essere considerato come una generalizzazione del principio "un cluster separato per team", poiché solitamente un team di ingegneri si occupa dello sviluppo di una o più applicazioni.
+ Utilizzo efficace delle risorse
+ Il cluster può essere adattato all'applicazione
Se un'applicazione ha esigenze particolari, possono essere implementate nel cluster senza influenzare gli altri cluster.
Tali esigenze possono includere worker con GPU, specifici plugin CNI, service mesh o qualche altro servizio.
Ogni cluster può essere adattato all'applicazione in esso operante, in modo da contenere solo ciò che è necessario.
− Ambienti diversi in un cluster
Un limite di questo approccio è che le istanze delle applicazioni di ambienti diversi coesistono in un unico cluster.
Ad esempio, la versione prod dell'applicazione funziona nello stesso cluster della versione dev. Ciò significa anche che gli sviluppatori operano nello stesso cluster in cui è in esecuzione la versione di produzione dell'applicazione.
Se a causa delle azioni degli sviluppatori o di bug della versione dev si verifica un guasto nel cluster, ciò potrebbe potenzialmente danneggiare anche la versione prod — un enorme svantaggio di questo approccio.
E infine, l'ultimo scenario della nostra lista.
4. Un cluster per ogni ambiente
Questo scenario prevede la dedicazione di un cluster separato per ogni ambiente:
Un cluster per ambiente
Ad esempio, potresti avere cluster dev, test e prod, in cui eseguire tutte le istanze dell'applicazione destinate a un certo ambiente.
Ecco i pro e contro di questo approccio.
+ Isolamento dell'ambiente prod
Nell'ambito di questo approccio, tutti gli ambienti risultano isolati gli uni dagli altri. Tuttavia, nella pratica, questo è particolarmente importante per l'ambiente di produzione.
Le versioni di produzione dell'applicazione ora non dipendono da ciò che accade in altri cluster e ambienti.
In questo modo, se nel cluster di sviluppo si verifica all'improvviso un problema, le versioni di produzione delle applicazioni continueranno a funzionare come se nulla fosse successo.
+ Il cluster può essere adattato all'ambiente
Ogni cluster può essere adattato al suo ambiente. Ad esempio, si può:
- installare nel cluster di sviluppo strumenti per lo sviluppo e il debug;
- installare framework e strumenti di test nel cluster test;
- utilizzare hardware più potente e canali di rete nel cluster prod.
Questo consente di aumentare l'efficienza sia dello sviluppo che dell'operatività delle applicazioni.
+ Limitazione dell'accesso al cluster di produzione
La necessità di lavorare direttamente con il cluster di produzione si presenta raramente, quindi è possibile limitare notevolmente il numero di persone che vi hanno accesso.
Si può andare oltre e privare completamente le persone dell'accesso a questo cluster, eseguendo tutte le implementazioni tramite uno strumento automatizzato CI/CD. Questo approccio ridurrà al minimo il rischio di errori umani proprio dove è più critico.
E ora alcune parole sui contro.
− Assenza di isolamento tra le applicazioni
Il principale svantaggio dell'approccio è l'assenza di isolamento hardware e delle risorse tra le applicazioni.
Le applicazioni non correlate condividono le risorse del cluster: il kernel di sistema, la CPU, la memoria e alcuni altri servizi.
Come già accennato, ciò può essere potenzialmente pericoloso.
− Impossibilità di localizzare le dipendenze delle applicazioni
Se un'applicazione ha requisiti specifici, è necessario soddisfarli in tutti i cluster.
Ad esempio, se un'applicazione richiede una GPU, allora ogni cluster deve contenere almeno un worker con GPU (anche se utilizzato solo da quell'applicazione).
Di conseguenza, rischiamo di avere costi più elevati e un uso inefficiente delle risorse.
Conclusione
Con un certo insieme di applicazioni, è possibile collocarle in diversi grandi cluster o in molti più piccoli.
L'articolo esamina i pro e i contro di diversi approcci, da un unico cluster globale a diversi piccoli e specializzati:
- un grande cluster comune;
- un gran numero di piccoli cluster specializzati;
- un cluster per ogni applicazione;
- un cluster per ogni ambiente.
Quindi, quale approccio scegliere?
Come al solito, la risposta dipende dallo scenario d'uso: è necessario valutare i pro e i contro dei vari approcci e scegliere l'opzione più ottimale.
Tuttavia, la scelta non è limitata agli esempi sopra riportati: è possibile utilizzare qualsiasi loro combinazione!
Ad esempio, è possibile organizzare un paio di cluster per ciascun team: un cluster per lo sviluppo (che avrà ambienti dev e test) e un cluster per production (dove si troverà l'ambiente di produzione).
Facendo riferimento alle informazioni di questo articolo, sarete in grado di ottimizzare adeguatamente i pro e i contro per uno scenario specifico. Buona fortuna!
P.S.
Leggi anche nel nostro blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
