Nota del traduttore.: questo materiale proviene da un progetto educativo — una risposta a una domanda comune nella progettazione di infrastrutture basate su Kubernetes. Speriamo che le descrizioni dettagliate dei vantaggi e degli svantaggi di ciascuna opzione aiutino a fare la scelta ottimale anche per il tuo progetto.
TL;DR: lo stesso set di carichi di lavoro può essere eseguito su più grandi cluster (ogni cluster avrà un numero elevato di workload) o su diversi piccoli (con pochi carichi in ciascun cluster).
Di seguito è riportata una tabella che valuta i vantaggi e gli svantaggi di ciascun approccio:
Quando si utilizza Kubernetes come piattaforma per l'esecuzione di applicazioni, sorgono spesso alcune domande fondamentali sulle sottigliezze della configurazione dei cluster:
- Quanti cluster utilizzare?
- Quanto grandi dovrebbero essere?
- Cosa dovrebbe includere ciascun cluster?
In questo articolo cercherò di rispondere a tutte queste domande, analizzando i vantaggi e gli svantaggi di ciascun approccio.
Formulazione della questione
In qualità di sviluppatore software, è probabile che tu stia sviluppando e gestendo contemporaneamente numerose applicazioni.
Inoltre, molti esemplari di queste applicazioni vengono probabilmente eseguiti in diversi ambienti, ad esempio possono essere dev, test e prod.
Il risultato è una vera e propria matrice di applicazioni e ambienti:
Applicazioni e ambienti
Nell'esempio sopra sono presentate 3 applicazioni e 3 ambienti, il che porta a 9 possibilità diverse.
Ogni esemplare dell'applicazione rappresenta un'unità di deployment autonoma, con cui è possibile lavorare indipendentemente dalle altre.
Nota che esemplare dell'applicazione può consistere in molteplici componenti, come frontend, backend, database, ecc. Nel caso di un'applicazione a microservizi, un esemplare includerà tutti i microservizi.
Di conseguenza, gli utenti di Kubernetes si pongono alcune domande:
- È utile posizionare tutti gli esemplari dell'applicazione in un unico cluster?
- È opportuno creare un cluster separato per ogni esemplare dell'applicazione?
- Oppure, forse, è meglio utilizzare una combinazione dei metodi sopra citati?
Tutte queste opzioni sono del tutto valide, poiché Kubernetes è un sistema flessibile che non limita le possibilità degli utenti.
Ecco alcuni dei percorsi possibili:
- un grande cluster centrale;
- numerosi piccoli cluster specializzati;
- un cluster per ogni applicazione;
- un cluster per ogni ambiente.
Come mostrato di seguito, le prime due opzioni si trovano agli estremi opposti della scala delle possibilità:
Da pochi grandi cluster (a sinistra) a molti piccoli (a destra)
In generale, si considera che un cluster sia "maggiore" di un altro se ha un numero maggiore di nodi e pod. Ad esempio, un cluster con 10 nodi e 100 pod è più grande di un cluster con 1 nodo e 10 pod.
Bene, cominciamo!
1. Un grande cluster centrale
La prima opzione è ospitare tutti i carichi di lavoro in un unico cluster:
Un grande cluster
Nell'ambito di questo approccio, il cluster viene utilizzato come piattaforma infrastrutturale universale — tutto ciò di cui hai bisogno viene semplicemente distribuito nel cluster Kubernetes esistente. Namespace
Kubernetes consente di separare logicamente le parti del cluster, in modo che per ogni istanza dell'applicazione si possa usare il proprio spazio dei nomi.
Esaminiamo i pro e i contro di questo approccio.
+ Utilizzo efficace delle risorse
In caso di un singolo cluster, è necessaria solo una copia di tutte le risorse necessarie per avviare e gestire il cluster Kubernetes.
Ad esempio, questo vale per i nodi master. Di solito, ogni cluster Kubernetes ha 3 nodi master, quindi per un singolo cluster il numero rimarrà tale (per confronto, 10 cluster avranno bisogno di 30 nodi master).
Questa sottigliezza si applica anche ad altri servizi che operano a livello di cluster, come i bilanciatori di carico, i controller Ingress, i sistemi di autenticazione, logging e monitoraggio.
In un unico cluster, tutti questi servizi possono essere utilizzati immediatamente per tutti i carichi di lavoro (non è necessario creare copie, come nel caso di più cluster).
+ Economicità
Di conseguenza, un numero minore di cluster di solito costa meno, poiché non ci sono spese per risorse ridondanti.
Questo è particolarmente vero per i nodi master, che possono avere costi significativi indipendentemente dal modo in cui sono ospitati (in loco o nel cloud).
Alcuni servizi Kubernetes gestiti, come o , forniscono uno strato di gestione gratuitamente. In questo caso, la questione dei costi è meno pressante.
Ci sono anche servizi gestiti che addebitano una tariffa fissa per il funzionamento di ogni cluster Kubernetes (ad esempio, ).
+ Amministrazione efficace
È più facile gestire un solo cluster piuttosto che più di uno.
L'amministrazione può includere le seguenti attività:
- aggiornamento della versione di Kubernetes;
- configurazione del pipeline CI/CD;
- installazione di un plugin CNI;
- configurazione del sistema di autenticazione degli utenti;
- installazione di un controller di accesso;
e molte altre…
Nel caso di un solo cluster, tutte queste attività dovranno essere svolte solo una volta.
Per molte operazioni nei cluster, sarà necessario ripetere i processi più volte, il che probabilmente richiederà una certa automazione e strumenti per garantire coerenza e uniformità.
Ora alcune parole sugli svantaggi.
− Punto unico di guasto
In caso di guasto dell'unico cluster, tutte tutti le workload smetteranno di funzionare!
Ci sono molteplici varianti in cui qualcosa potrebbe andare male:
- un aggiornamento di Kubernetes porta a effetti collaterali imprevisti;
- un componente del cluster (ad esempio, un plugin CNI) inizia a funzionare diversamente da quanto previsto;
- uno dei componenti del cluster è configurato in modo errato;
- un malfunzionamento nell'infrastruttura sottostante.
Un singolo incidente può causare seri danni a tutte le workload ospitate nel cluster condiviso.
− Mancanza di isolamento rigoroso
Lavorare in un cluster condiviso significa che le applicazioni condividono le risorse hardware, le capacità di rete e il sistema operativo sui nodi del cluster.
In un certo senso, due contenitori con due applicazioni diverse che operano sullo stesso nodo sono simili a due processi che funzionano sulla stessa macchina sotto la gestione dello stesso kernel del sistema operativo.
I contenitori Linux forniscono una certa forma di isolamento, ma è lontano dall'essere forte come quello offerto, ad esempio, dalle macchine virtuali. In sostanza, il processo in un contenitore è lo stesso processo in esecuzione nel sistema operativo host.
Questo può diventare un problema dal punto di vista della sicurezza: una tale organizzazione consente teoricamente a applicazioni non correlate di interagire tra 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 servizi di altre applicazioni nel cluster.
Tutti i punti sopra elencati possono avere rilevanza diversa a seconda dei requisiti di sicurezza delle applicazioni.
Kubernetes fornisce vari strumenti per prevenire problemi di sicurezza, come e . Tuttavia, per la loro corretta configurazione è necessaria una certa esperienza; inoltre, non riescono a coprire tutte le vulnerabilità di sicurezza.
È importante ricordare sempre che Kubernetes è stato progettato principalmente per la condivisione, e non per l'isolamento e la sicurezza..
− Mancanza di una vera multi-tenancy.
Considerando l'abbondanza di risorse condivise nel cluster Kubernetes, ci sono molti modi in cui diverse applicazioni possono "calpestarsi" a vicenda.
Ad esempio, un'applicazione può monopolizzare una risorsa condivisa (come la CPU o la memoria) e privare altre applicazioni, in esecuzione sullo stesso nodo, dell'accesso ad essa.
Kubernetes fornisce vari meccanismi per controllare questo 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 tutti gli effetti collaterali imprevisti.
− Un gran numero di utenti.
Nel caso di un cluster unico, è necessario concedere accesso a molte persone. Maggiore è il numero di utenti, maggiore è il rischio che possano "rompere" qualcosa.
All'interno del cluster è possibile controllare chi e cosa può fare grazie a (vedi l'articolo "» — nota del traduttore.). Tuttavia, questo 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 sorge un altro problema: i cluster in Kubernetes non possono crescere all'infinito.
Esiste un limite teorico alla dimensione del cluster. In Kubernetes, questo limite è di circa .
Tuttavia, nella vita reale, i problemi possono iniziare molto prima — per esempio, già a .
Il punto è che i cluster di grandi dimensioni esercitano un alto carico sul livello di gestione di Kubernetes. In altre parole, per mantenere un cluster funzionante e utilizzare le risorse in modo efficiente, è necessaria una configurazione accurata.
Questo problema è trattato in un articolo correlato nel blog originale intitolato «».
Ma consideriamo l'approccio opposto: molti piccoli cluster.
2. Molti piccoli cluster specializzati
Con questo approccio, usi un cluster separato per ogni elemento distribuito:
Molti piccoli cluster
Ai fini di questo articolo, per elemento distribuito si intende un'istanza dell'applicazione — ad esempio, una versione dev di un'applicazione separata.
In questa strategia, Kubernetes è utilizzato come un ambiente di esecuzione specializzato per istanze dell'applicazione.
Esaminiamo i pro e i contro di questo approccio.
+ Raggio d'esplosione limitato
In caso di «guasto» del cluster, le conseguenze negative si limitano solo ai carichi di lavoro distribuiti in quel cluster. Tutti gli altri workload rimangono intatti.
+ Isolamento
I carichi di lavoro collocati in cluster dedicati non condividono risorse come CPU, memoria, sistema operativo, rete o altri servizi.
Di conseguenza, otteniamo un'isolamento rigido tra applicazioni non collegate, il che può migliorare la loro sicurezza.
+ Numero limitato di utenti
Poiché in ogni cluster è presente solo un numero limitato di carichi di lavoro, il numero di utenti con accesso è ridotto.
Meno persone hanno accesso al cluster, minore è il rischio che qualcosa si rompa.
Esaminiamo gli svantaggi.
− Utilizzo inefficiente delle risorse
Come menzionato in precedenza, ogni cluster Kubernetes richiede un certo insieme di risorse di gestione: nodi master, componenti del piano di controllo, soluzioni per il monitoraggio e la registrazione.
Con un numero elevato di cluster piccoli, è necessario dedicare una quota maggiore delle risorse alla gestione.
− Costosità
L'utilizzo inefficiente delle risorse porta automaticamente a costi elevati.
Ad esempio, avere 30 nodi master invece di tre con la stessa potenza di calcolo si tradurrà inevitabilmente in costi maggiori.
− Complessità di gestione
Gestire numerosi cluster Kubernetes è molto più complicato rispetto a lavorare con uno solo.
Ad esempio, sarà necessario configurare l'autenticazione e l'autorizzazione per ciascun cluster. Aggiornare la versione di Kubernetes richiederà anche più operazioni.
Probabilmente sarà necessario implementare l'automazione per ottimizzare tutte queste attività.
Ora consideriamo scenari meno estremi.
3. Un cluster per ciascuna applicazione
Con questo approccio, crei un cluster separato per tutte le istanze di una specifica applicazione:
Cluster per applicazione
Questo approccio può essere visto come un'estensione del principio "un cluster per team", poiché generalmente un team di ingegneri si occupa dello sviluppo di una o più applicazioni.
Esaminiamo i pro e i contro di questo approccio.
+ Il cluster può essere personalizzato per l'applicazione
Se un'applicazione ha esigenze specifiche, queste possono essere soddisfatte nel cluster senza influenzare gli altri cluster.
Tali esigenze possono includere worker con GPU, determinati plugin CNI, service mesh o qualche altro servizio.
Ogni cluster può essere adattato all'applicazione in esecuzione al suo interno, in modo che contenga solo ciò che è necessario.
− Ambienti diversi in un unico cluster
Il difetto di questo approccio è che le istanze delle applicazioni di ambienti diversi coesistono all'interno di un unico cluster.
Ad esempio, la versione prod dell'applicazione funziona nello stesso cluster della versione dev. Questo significa anche che gli sviluppatori operano nello stesso cluster in cui è in uso la versione di produzione dell'applicazione.
Se a causa delle azioni degli sviluppatori o di bug nella versione dev si verifica un guasto nel cluster, la versione prod potrebbe subire danni — un enorme svantaggio di questo approccio.
Infine, l'ultimo scenario della nostra lista.
4. Un cluster per ogni ambiente
Questo scenario prevede l'assegnazione 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 determinato ambiente.
Ecco i pro e i contro di questo approccio.
+ Isolamento dell'ambiente di produzione
In base a questo approccio, tutti gli ambienti risultano isolati l'uno dall'altro. Tuttavia, nella pratica, questo è particolarmente importante per l'ambiente di produzione.
Le versioni di produzione dell'applicazione non dipendono ora 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 configurato in base al suo ambiente. Ad esempio, è possibile:
- installare strumenti di sviluppo e debug nel cluster di sviluppo;
- installare framework e strumenti di test nel cluster; test;
- utilizzare hardware e bande più potenti nel cluster. prod.
Questo consente di aumentare l'efficienza sia nello sviluppo che nell'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 significativamente il numero di persone che vi hanno accesso.
Si può andare oltre e negare completamente l'accesso a questo cluster, eseguendo tutte le distribuzioni attraverso uno strumento automatizzato CI/CD. Questo approccio ridurrà al minimo il rischio di errori umani proprio nei punti più critici.
Ora alcune parole sugli svantaggi.
− Mancanza di isolamento tra le applicazioni
Il principale svantaggio di questo approccio è l'assenza di isolamento hardware e delle risorse tra le applicazioni.
Applicazioni non correlate condividono risorse del cluster: nucleo del sistema, CPU, memoria e alcuni altri servizi.
Come già accennato, questo può risultare 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, ogni cluster deve avere almeno un worker con GPU (anche se viene utilizzata solo da quell'applicazione).
Di conseguenza, rischiamo di avere costi più elevati e un utilizzo inefficiente delle risorse.
Conclusione
Con un certo insieme di applicazioni, è possibile distribuirle in diversi grandi cluster o in molti piccoli.
Nell'articolo vengono esaminati i pro e i contro dei diversi approcci, che vanno da un singolo cluster globale a più cluster piccoli e specializzati:
- un grande cluster comune;
- numerosi piccoli cluster specializzati;
- un cluster per ogni applicazione;
- un cluster per ogni ambiente.
Quindi, quale approccio scegliere?
Come sempre, 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, si possono organizzare un paio di cluster per ciascun team: un cluster per lo sviluppo (in cui ci saranno gli ambienti dev e test) e un cluster per produzione (dove si trova l'ambiente di produzione).
Basandosi sulle informazioni di questo articolo, si potrà ottimizzare adeguatamente i pro e i contro per uno scenario specifico. Buona fortuna!
P.S.
Leggete anche nel nostro blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
