Quando si crea un cluster Kubernetes, possono sorgere domande: quanti nodi di lavoro configurare e di che tipo? È meglio per un cluster on-premise acquistare alcuni server potenti o utilizzare una decina di vecchine nel proprio data center? E nel cloud è meglio optare per otto istanze a singolo core o due istanze a quattro core?
Le risposte a queste domande sono nell'articolo nella traduzione del team .
Capacità del cluster
In generale, un cluster Kubernetes può essere considerato come un grande "supernodo". La sua potenza di calcolo totale è la somma delle potenze di tutti i nodi costituenti.
Esistono diversi modi per raggiungere la capacità target desiderata del cluster. Ad esempio, se abbiamo bisogno di un cluster con una capacità totale di 8 core CPU e 32 GB di RAM, perché il set di applicazioni richiede quella quantità di risorse. Possiamo quindi installare due nodi da 16 GB di memoria o quattro nodi da 8 GB di memoria, due processori quad-core o quattro processori dual-core.
Ecco solo due possibili modalità di creazione di un cluster:
Entrambe le opzioni offrono un cluster con la stessa capacità, ma nella configurazione in basso ci sono quattro nodi più piccoli, mentre nella configurazione in alto ci sono due nodi più grandi.
Qual è l'opzione migliore?
Per rispondere a questa domanda, consideriamo i vantaggi di entrambe le opzioni. Li abbiamo riassunti in una tabella.
Diversi nodi grandi
Molti piccoli nodi
Gestione del cluster più semplice (se è on-premise)
Autoscaling fluido
Più economico (se on-premise)
Il prezzo è simile (in cloud)
Possibilità di eseguire applicazioni intensive in termini di risorse
Replica completa
Le risorse vengono utilizzate in modo più efficiente (meno overhead per i demoni di sistema)
Maggiore resilienza del cluster
Si noti che stiamo parlando solo di nodi di lavoro. La scelta del numero e delle dimensioni dei nodi principali è un argomento del tutto diverso.
Quindi, esaminiamo più da vicino ciascun punto della tabella.
Prima opzione: diversi nodi grandi
L'opzione più estrema è avere un solo nodo di lavoro per l'intera capacità del cluster. Nell'esempio sopra, sarebbe un solo nodo di lavoro con 16 core CPU e 16 GB di RAM.
Pro
Vantaggio n. 1. Gestione più semplice
È più semplice gestire più macchine che un'intera flotta. È più veloce applicare aggiornamenti e patch, ed è più facile sincronizzare. Anche il numero di guasti in termini assoluti è inferiore.
Si prega di notare che quanto sopra si riferisce all'hardware di proprietà, ai propri server, e non alle istanze cloud.
Nel cloud la situazione è diversa. La gestione è a carico del fornitore di servizi cloud. Pertanto, gestire dieci nodi nel cloud non è molto diverso dalla gestione di un singolo nodo.
Il routing del traffico e la distribuzione del carico tra i pod nel cloud : il traffico in arrivo da Internet viene indirizzato al bilanciatore di carico principale, che reindirizza il traffico a una delle porte di uno dei nodi (il servizio NodePort espone porte nel range 30000-32767 su ogni nodo del cluster). Le regole stabilite da kube-proxy reindirizzano il traffico dal nodo al pod. Ecco come si presenta per dieci pod su due nodi:
Vantaggio n. 2. Costi inferiori per nodo
Una macchina potente costa di più, 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 un core con la stessa quantità di memoria.
Ma tenete presente che questa regola di solito non si applica ai servizi cloud. Nei modelli di prezzo attuali, tutti i principali fornitori di servizi cloud aumentano i prezzi linearmente con l'aumento della capacità.
Di conseguenza, nel cloud di solito non è possibile risparmiare su server più potenti.
Vantaggio n. 3. È possibile eseguire applicazioni esigenti in termini di risorse
Alcune applicazioni richiedono server potenti nel cluster. Ad esempio, se un sistema di apprendimento automatico necessita di 8 GB di memoria, non è possibile eseguirlo su nodi da 1 GB, ma solo avendone almeno uno grande all'interno del cluster.
Svantaggi
Svantaggio n. 1. Molti pod su un nodo
Se lo stesso compito viene eseguito su un numero inferiore di nodi, naturalmente ci saranno più pod su ciascuno di essi.
Questo può diventare un problema.
La ragione è che ogni modulo comporta alcune spese generali per l'ambiente di esecuzione del contenitore (ad esempio, Docker), oltre a kubelet e cAdvisor.
Ad esempio, kubelet controlla regolarmente la vitalità di tutti i container su un nodo: più container ci sono, maggiore è il lavoro per kubelet.
CAdvisor raccoglie statistiche sull'uso delle risorse di tutti i container su un nodo, mentre kubelet richiede regolarmente queste informazioni e le fornisce tramite API. Ancora una volta, più container ci sono, maggiore è il lavoro sia per cAdvisor che per kubelet.
Se il numero di moduli aumenta, questo potrebbe rallentare il sistema e addirittura comprometterne l'affidabilità.
Nel repository di Kubernetes, alcuni , che i nodi oscillano tra gli stati Ready/NotReady, poiché i controlli regolari di kubelet su tutti i container su un nodo richiedono troppo tempo.
Per questo motivo, Kubernetes . A seconda delle prestazioni del nodo, potresti essere in grado di eseguire più pod per nodo, ma è difficile prevedere se ci saranno problemi o se tutto funzionerà bene. È consigliabile testare il funzionamento in anticipo.
Svantaggio n. 2. Limiti sulla replica.
Un numero insufficiente di nodi limita il livello di replica delle applicazioni. Ad esempio, se hai un'applicazione ad alta disponibilità con cinque repliche, ma solo due nodi, il livello di replica effettivo dell'applicazione si riduce a due.
Le cinque repliche possono essere distribuite solo su due nodi e se uno di essi non funziona, si compromettono immediatamente più repliche.
Se hai cinque nodi o più, ciascuna replica verrà eseguita su un nodo separato e il guasto di un nodo eliminerà al massimo una replica.
Pertanto, i requisiti di alta disponibilità possono richiedere un numero minimo di nodi nel cluster.
Svantaggio n. 3. Peggiori conseguenze del guasto
Con un numero ridotto di nodi, ogni guasto porta conseguenze più gravi. Ad esempio, se hai solo due nodi e uno di essi fallisce, scompare immediatamente metà dei tuoi moduli.
Certo, Kubernetes sposterà il carico di lavoro dal nodo guasto sugli altri. Ma se ce ne sono pochi, la capacità disponibile potrebbe non essere sufficiente. Di conseguenza, parte delle tue applicazioni sarà non disponibile finché non riavvii il nodo guasto.
Così, più nodi ci sono, minore è l'impatto dei guasti hardware.
Contro numero 4. Maggiori passi nell'auto-scaling
In Kubernetes, è attiva una sistema di auto-scaling dei cluster per l'infrastruttura cloud, che consente di aggiungere o rimuovere nodi automaticamente in base alle esigenze attuali. Con nodi più grandi, l'auto-scaling diventa più brusco e goffo. Ad esempio, con due nodi, l'aggiunta di un ulteriore nodo aumenterà la capacità del cluster immediatamente del 50%. E dovrai pagare per queste risorse, anche se non ti servono.
Pertanto, se prevedi di utilizzare l'auto-scaling del cluster, più nodi hai, più flessibile ed economico sarà lo scaling.
Ora vediamo i pro e contro di avere un gran numero di nodi piccoli.
Seconda opzione: molti nodi piccoli
I vantaggi di questo approccio, in effetti, derivano dagli svantaggi dell'opzione opposta con pochi nodi grandi.
Pro
Pro numero 1. Meno conseguenze di un guasto
Più nodi ci sono, meno pod ci sono su ogni nodo. Ad esempio, se hai cento moduli su dieci nodi, ogni nodo avrà in media dieci moduli.
In questo modo, se uno dei nodi si guasta, perdi solo il 10% del carico di lavoro. È probabile che vengano colpite solo poche repliche, e le applicazioni nel complesso rimarranno operative.
Inoltre, sui nodi rimanenti, ci sono probabilmente sufficienti risorse disponibili per il carico di lavoro del nodo guasto, quindi Kubernetes può riprogrammare liberamente i pod e le tue applicazioni torneranno relativamente rapidamente a uno stato funzionante.
Vantaggio n. 2. Buona replicazione
Se ci sono abbastanza nodi, il planner di Kubernetes può assegnare tutte le repliche a nodi diversi. In questo modo, in caso di guasto di un nodo, verrà colpita solo una replica e l'applicazione rimarrà accessibile.
Svantaggi
Svantaggio n. 1. Maggiore difficoltà di gestione
Gestire un numero elevato di nodi è più complicato. Ad esempio, ogni nodo Kubernetes deve interagire con tutti gli altri, il che significa che il numero di connessioni cresce quadraticamente e tutte queste connessioni devono essere monitorate.
Il controller dei nodi nel gestore dei controller Kubernetes esegue regolarmente il checkup di tutti i nodi nel cluster per verificarne il funzionamento: più nodi ci sono, maggiore è il carico sul controller.
Aumenta anche il carico sul database etcd: ogni kubelet e kube-proxy richiamano per etcd (tramite API), al quale etcd deve trasmettere gli aggiornamenti dell'oggetto.
In generale, ogni nodo di lavoro aggiunge ulteriore carico sui componenti di sistema dei nodi principali.
Kubernetes supporta ufficialmente cluster con . Tuttavia, nella pratica, già 500 nodi .
Per gestire un numero elevato di nodi di lavoro, è consigliabile scegliere nodi principali più performanti. Ad esempio, kube-up la dimensione VM corretta per il nodo principale in base al numero di nodi di lavoro. Ciò significa che più nodi di lavoro ci sono, più performanti devono essere i nodi principali.
Per affrontare queste problematiche specifiche, sono disponibili soluzioni specializzate come . Questo sistema consente di superare i limiti e creare cluster con un numero enorme di nodi di lavoro.
Svantaggio n. 2. Maggiori costi operativi
Su ogni nodo di lavoro, Kubernetes avvia un insieme di demoni di sistema, tra cui l'ambiente di esecuzione dei contenitori (ad esempio, Docker), kube-proxy e kubelet, incluso cAdvisor. Insieme consumano una quantità fissa di risorse.
Se hai molti nodi piccoli, la quota di questi costi operativi per ogni nodo è maggiore. Ad esempio, immagina che tutti i demoni di sistema di un nodo insieme utilizzino 0,1 core CPU e 0,1 GB di memoria. Se hai un nodo con dieci core e 10 GB di memoria, i demoni consumano il 1% della capacità del cluster. D'altra parte, su dieci nodi con un core ciascuno e 1 GB di memoria, i demoni occuperanno il 10% della capacità del cluster.
Pertanto, meno nodi hai, più efficiente è l'utilizzo dell'infrastruttura.
Svantaggio n. 3. Utilizzo inefficiente delle risorse
Su nodi piccoli, potrebbe capitare che i frammenti rimanenti di risorse siano troppo piccoli per assegnarvi un carico di lavoro, quindi rimangono inutilizzati.
Ad esempio, ogni pod richiede 0,75 GB di memoria. Se hai dieci nodi, e ciascuno di essi ha 1 GB di memoria, puoi avviare dieci pod: in questo modo ogni nodo avrà 0,25 GB di memoria inutilizzata.
Ciò significa che il 25% della memoria dell'intero cluster è sprecato.
Su un grande nodo con 10 GB di memoria, puoi eseguire 13 di questi moduli, rimanendo con un solo frammento inutilizzato di 0,25 GB.
In questo caso, solo il 2,5% della memoria è sprecato.
Pertanto, su nodi più grandi le risorse vengono utilizzate in modo più efficiente.
Diversi nodi grandi o molti piccoli?
Quindi, cosa è meglio: diversi nodi grandi nel cluster o molti piccoli? Come sempre, non c'è una risposta univoca. Molto dipende dal tipo di applicazione.
Ad esempio, se l'applicazione richiede 10 GB di memoria, la scelta a favore dei nodi grandi è evidente. Ma se l'applicazione richiede una replica dieci volte per alta disponibilità, probabilmente non vale la pena rischiare di posizionare le repliche su soli due nodi: nel cluster devono esserci almeno dieci nodi.
In situazioni intermedie, fai la scelta in base ai vantaggi e agli svantaggi di ciascuna opzione. È possibile che alcuni argomenti siano più rilevanti per la tua situazione rispetto ad altri.
Non è affatto necessario che tutti i nodi siano della stessa dimensione. Nulla ti impedisce prima di sperimentare con nodi di dimensioni identiche e poi di aggiungere nodi di dimensioni diverse, combinandoli in un cluster. I nodi di lavoro di un cluster Kubernetes possono essere completamente eterogenei. Quindi, puoi provare a mescolare i vantaggi di entrambi gli approcci.
Non esiste una ricetta unica, e ogni situazione ha le sue sfumature. Solo il contesto di produzione rivelerà la verità.
Traduzione a cura del team della piattaforma cloud .
Ulteriori informazioni su Kubernetes: .
Fonte: habr.com
