Quando si crea un cluster Kubernetes possono sorgere delle domande: quanti nodi di lavoro configurare e di che tipologia? Cosa è meglio per un cluster on-premise: acquistare diversi server potenti o utilizzare una dozzina di vecchie macchine nel tuo data center? È meglio avere otto istanze single-core o due quad-core nel cloud?
Le risposte a queste domande sono nell'articolo. nella traduzione del comando .
Capacità del cluster
In generale, un cluster Kubernetes può essere pensato come un grande "supernodo". La sua potenza di calcolo totale è la somma delle potenze di tutti i suoi nodi costituenti.
Esistono diversi modi per raggiungere l'obiettivo di capacità del cluster desiderato. Ad esempio, abbiamo bisogno di un cluster con una capacità totale di 8 core del processore e 32 GB di RAM perché un insieme di applicazioni richiede così tante risorse. Quindi puoi installare due nodi con 16 GB di memoria o quattro nodi con 8 GB di memoria, due processori quad-core o quattro dual-core.
Ecco solo due modi possibili per creare un cluster:
Entrambe le opzioni producono un cluster con la stessa capacità, ma la configurazione inferiore ha quattro nodi più piccoli e la configurazione superiore ha due nodi più grandi.
Quale opzione è migliore?
Per rispondere a questa domanda, esaminiamo i vantaggi di entrambe le opzioni. Li abbiamo riassunti in una tabella.
Diversi grandi nodi
Molti piccoli nodi
Gestione del cluster più semplice (se è on-premise)
Scalabilità automatica fluida
Più economico (se in sede)
Il prezzo è leggermente diverso (nel cloud)
Può eseguire applicazioni ad uso intensivo di risorse
Replica completa
Le risorse vengono utilizzate in modo più efficiente (meno sovraccarico sui demoni di sistema
Tolleranza agli errori del cluster più elevata
Tieni presente che stiamo parlando solo di nodi di lavoro. La scelta del numero e della dimensione dei nodi principali è un argomento completamente diverso.
Quindi, discutiamo ogni punto della tabella in modo più dettagliato.
Prima opzione: diversi nodi di grandi dimensioni
L'opzione più estrema è un nodo di lavoro per l'intera capacità del cluster. Nell'esempio sopra, si tratterebbe di un singolo nodo di lavoro con 16 core CPU e 16 GB di RAM.
Pro
Plus n. 1. Gestione più semplice
È più semplice gestire poche macchine che un'intera flotta. È più veloce implementare aggiornamenti e correzioni ed è più semplice la sincronizzazione. Anche il numero di fallimenti in numeri assoluti è inferiore.
Tieni presente che tutto quanto sopra si applica al tuo hardware, ai tuoi server e non alle istanze cloud.
Nel cloud la situazione è diversa. Lì, la gestione è affidata al fornitore di servizi cloud. Pertanto, gestire dieci nodi nel cloud non è molto diverso dalla gestione di un nodo.
Instradamento del traffico e distribuzione del carico tra i pod nel cloud : il traffico proveniente da Internet viene inviato al bilanciatore di carico principale, che inoltra il traffico alla porta di uno dei nodi (il servizio NodePort imposta la porta nell'intervallo 30000-32767 in ciascun nodo del cluster). Le regole impostate da kube-proxy reindirizzano il traffico dal nodo al pod. Ecco come appare per dieci pod su due nodi:
Pro n. 2: meno costi per nodo
Un'auto potente è più costosa, ma l'aumento del prezzo non è necessariamente lineare. In altre parole, un server a dieci core con 10 GB di memoria è solitamente più economico di dieci server a core singolo con la stessa quantità di memoria.
Tieni presente, tuttavia, che questa regola di solito non funziona nei servizi cloud. Negli attuali schemi tariffari di tutti i principali fornitori di servizi cloud, i prezzi aumentano in modo lineare con la capacità.
Pertanto, nel cloud di solito non è possibile salvare su server più potenti.
Pro n. 3: puoi eseguire applicazioni ad uso intensivo di risorse
Alcune applicazioni richiedono server potenti in un cluster. Ad esempio, se un sistema di machine learning richiede 8 GB di memoria, non potrai eseguirlo su nodi da 1 GB, ma solo con almeno un nodo di lavoro di grandi dimensioni.
Contro
Svantaggio n. 1. Molti pod per nodo
Se la stessa attività viene eseguita su meno nodi, ognuno di essi avrà naturalmente più pod.
Questo potrebbe essere un problema.
Il motivo è che ogni modulo introduce un sovraccarico nel runtime del contenitore (ad esempio Docker), nonché in kubelet e cAdvisor.
Ad esempio, un kubelet sonda regolarmente la sopravvivenza di tutti i contenitori su un nodo: maggiore è il numero di contenitori, maggiore è il lavoro che il kubelet deve svolgere.
CAdvisor raccoglie le statistiche sull'utilizzo delle risorse per tutti i contenitori su un nodo e kubelet interroga regolarmente queste informazioni e le fornisce tramite un'API. Ancora una volta, più contenitori significano più lavoro sia per cAdvisor che per kubelet.
Se il numero di moduli aumenta, può rallentare il sistema e persino comprometterne l’affidabilità.
Nel repository Kubernetes alcuni che i nodi saltano tra gli stati Pronto/NonPronto perché i controlli kubelet regolari di tutti i contenitori su un nodo richiedono troppo tempo.
Per questo motivo Kubernetes . A seconda delle prestazioni del nodo, puoi eseguire più pod per nodo, ma è difficile prevedere se ci saranno problemi o se tutto funzionerà correttamente. Vale la pena testare il lavoro in anticipo.
Svantaggio n. 2. Limitazione sulla replica
Troppo pochi nodi limitano l'effettiva portata della replica dell'applicazione. Se, ad esempio, si dispone di un'applicazione a disponibilità elevata con cinque repliche ma solo due nodi, il grado di replica effettivo dell'applicazione verrà ridotto a due.
Cinque repliche possono essere distribuite solo su due nodi e, se una di esse fallisce, verranno disattivate più repliche contemporaneamente.
Se disponi di cinque o più nodi, ogni replica verrà eseguita su un nodo separato e il guasto di un nodo rimuoverà al massimo una replica.
Pertanto, i requisiti di elevata disponibilità possono richiedere un certo numero minimo di nodi nel cluster.
Svantaggio n. 3. Peggiori conseguenze del fallimento
Con un numero limitato di nodi, ogni guasto ha conseguenze più gravi. Ad esempio, se hai solo due nodi e uno di essi si guasta, metà dei tuoi moduli scompariranno immediatamente.
Naturalmente, Kubernetes migrerà il carico di lavoro dal nodo guasto ad altri. Ma se ce ne sono pochi, potrebbe non esserci abbastanza capacità libera. Di conseguenza, alcune delle tue applicazioni non saranno disponibili finché non visualizzerai il nodo guasto.
Pertanto, maggiore è il numero di nodi, minore è l'impatto dei guasti hardware.
Svantaggio n. 4: più passaggi di scalabilità automatica
Kubernetes dispone di un sistema di scalabilità automatica del cluster per l'infrastruttura cloud, che ti consente di aggiungere o rimuovere automaticamente i nodi in base alle tue esigenze attuali. Con nodi più grandi, la scalabilità automatica diventa più brusca e goffa. Ad esempio, su due nodi, l'aggiunta di un ulteriore nodo aumenterà immediatamente la capacità del cluster del 50%. E dovrai pagare per quelle risorse, anche se non ti servono.
Pertanto, se prevedi di utilizzare il ridimensionamento automatico del cluster, più piccoli saranno i nodi, più flessibile ed economico otterrai il ridimensionamento.
Consideriamo ora i vantaggi e gli svantaggi di un gran numero di piccoli nodi.
Seconda opzione: tanti piccoli nodi
I vantaggi di questo approccio derivano essenzialmente dagli svantaggi dell’opzione opposta con più nodi di grandi dimensioni.
Pro
Pro n. 1: minore impatto del fallimento
Maggiore è il numero di nodi, minore è il numero di pod su ciascun nodo. Ad esempio, se disponi di cento moduli ogni dieci nodi, ciascun nodo avrà in media dieci moduli.
In questo modo, se uno dei nodi fallisce, perdi solo il 10% del carico di lavoro. È probabile che solo un numero limitato di repliche sarà interessato e l'applicazione complessiva rimarrà operativa.
Inoltre, i nodi rimanenti avranno probabilmente risorse libere sufficienti per gestire il carico di lavoro del nodo guasto, quindi Kubernetes potrà riprogrammare liberamente i pod e le tue applicazioni torneranno a uno stato funzionale in tempi relativamente brevi.
Pro n. 2: buona replica
Se sono presenti abbastanza nodi, lo scheduler Kubernetes può assegnare nodi diversi a tutte le repliche. In questo modo, se un nodo fallisce, solo una replica sarà interessata e l'applicazione rimarrà disponibile.
Contro
Svantaggio n. 1. Difficile da controllare
Un numero elevato di nodi è più difficile da gestire. Ad esempio, ogni nodo Kubernetes deve comunicare con tutti gli altri, ovvero il numero di connessioni cresce quadraticamente e tutte queste connessioni devono essere tracciate.
Il controller del nodo in Kubernetes Controller Manager esamina regolarmente tutti i nodi del cluster per verificarne l'integrità: maggiore è il numero di nodi, maggiore sarà il carico sul controller.
Anche il carico sul database etcd sta crescendo: ogni chiamata kubelet e kube-proxy per etcd (tramite l'API), a cui etcd dovrebbe trasmettere gli aggiornamenti degli oggetti.
In generale, ciascun nodo di lavoro impone un carico aggiuntivo sui componenti di sistema dei nodi master.
Kubernetes supporta ufficialmente i cluster con . Tuttavia in pratica i nodi sono già 500 .
Per gestire un numero elevato di nodi di lavoro, dovresti scegliere nodi master più potenti. Ad esempio, kube-up la dimensione corretta della VM per il nodo master in base al numero di nodi di lavoro. Cioè, maggiore è il numero dei nodi lavoratore, più produttivi dovrebbero essere i nodi master.
Per risolvere questi problemi specifici ci sono sviluppi speciali, come ad esempio . Questo sistema ti consente di aggirare le restrizioni e creare cluster con un numero enorme di nodi di lavoro.
Svantaggio n. 2: maggiori costi generali.
Su ogni nodo di lavoro, Kubernetes esegue una serie di demoni di sistema: questi includono il runtime del contenitore (come Docker), kube-proxy e kubelet, incluso cAdvisor. Insieme consumano una certa quantità fissa di risorse.
Se hai molti nodi piccoli, la proporzione di questo sovraccarico su ciascun nodo sarà maggiore. Ad esempio, immagina che tutti i demoni di sistema su un singolo nodo utilizzino insieme 0,1 core CPU e 0,1 GB di memoria. Se disponi di un nodo a dieci core con 10 GB di memoria, i demoni consumano l'1% della capacità del cluster. Su dieci nodi single-core con 1 GB di memoria, invece, i demoni occuperanno il 10% della capacità del cluster.
Pertanto, minore è il numero di nodi, più efficiente sarà l’utilizzo dell’infrastruttura.
Svantaggio n. 3. Uso inefficiente delle risorse
Sui nodi piccoli, è possibile che i blocchi di risorse rimanenti siano troppo piccoli per essere assegnati a qualsiasi carico di lavoro, quindi rimangono inutilizzati.
Ad esempio, ogni pod richiede 0,75 GB di memoria. Se disponi di dieci nodi, ciascuno con 1 GB di memoria, puoi eseguire dieci pod, lasciando ciascun nodo con 0,25 GB di memoria inutilizzata.
Ciò significa che viene sprecato il 25% della memoria dell'intero cluster.
Su un nodo di grandi dimensioni con 10 GB di memoria, puoi eseguire 13 di questi moduli e rimarrà solo un frammento inutilizzato di 0,25 GB.
In questo caso viene sprecato solo il 2,5% della memoria.
Pertanto, le risorse vengono utilizzate in modo più ottimale sui nodi più grandi.
Diversi nodi grandi o molti piccoli?
Quindi, cosa è meglio: pochi nodi grandi in un cluster o molti nodi piccoli? Come sempre, non esiste una risposta chiara. Molto dipende dal tipo di applicazione.
Se, ad esempio, un'applicazione richiede 10 GB di memoria, i nodi più grandi rappresentano una scelta ovvia. E se l'applicazione richiede dieci volte la replica per garantire un'elevata disponibilità, non vale la pena correre il rischio di posizionare le repliche solo su due nodi: nel cluster devono essere presenti almeno dieci nodi.
Nelle situazioni intermedie, fai una scelta in base ai vantaggi e agli svantaggi di ciascuna opzione. Forse alcuni argomenti sono più rilevanti per la tua situazione rispetto ad altri.
E non è affatto necessario rendere tutti i nodi della stessa dimensione. Niente ti impedisce di sperimentare prima nodi della stessa dimensione, quindi aggiungere ad essi nodi di dimensione diversa, combinandoli in un cluster. I nodi di lavoro in un cluster Kubernetes possono essere completamente eterogenei. Quindi puoi provare a combinare i vantaggi di entrambi gli approcci.
Non esiste una ricetta unica, ogni situazione ha le sue sfumature e solo la produzione mostrerà la verità.
Traduzione preparata dal team della piattaforma cloud .
Ulteriori informazioni su Kubernetes: .
Fonte: habr.com