Quando si crea un cluster Kubernetes possono sorgere domande: quanti nodi lavorativi configurare e di che tipo? Cosa è meglio per un cluster on-premise: acquistare alcuni server potenti o utilizzare una dozzina di vecchie macchine nel tuo data center? E nel cloud è meglio optare per otto istanze a un nucleo o due a quattro nuclei?
Le risposte a queste domande sono nell'articolo nella traduzione del team .
Capacità del cluster
In generale, un cluster Kubernetes può essere visto come un grande "super nodo". La sua potenza computazionale totale è la somma delle potenze di tutti i nodi componenti.
Ci sono diversi modi per raggiungere la capacità target desiderata del cluster. Ad esempio, abbiamo bisogno di un cluster con una capacità totale di 8 core CPU e 32 GB di RAM, perché la suite di applicazioni richiede tale quantità di risorse. Possiamo quindi installare due nodi da 16 GB di memoria o quattro nodi da 8 GB di memoria, due processori a quattro nuclei o quattro a due nuclei.
Questi sono solo due modi possibili per creare un cluster:
Entrambe le opzioni forniscono 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.
Quale opzione è migliore?
Per rispondere a questa domanda, esaminiamo i vantaggi di entrambe le opzioni. Li abbiamo riassunti in una tabella.
Pochi nodi grandi
Molti nodi piccoli
Gestione più semplice del cluster (se è on-premise)
Scalabilità automatica fluida
Più economico (se on-premise)
Il prezzo è poco diverso (nel cloud)
Possono essere eseguite applicazioni assetate di risorse
Replica completa
Le risorse vengono utilizzate in modo più efficiente (minore overhead per i demoni di sistema)
Maggiore resilienza del cluster
Nota che parliamo solo dei nodi lavorativi. La scelta del numero e della dimensione dei nodi master è un argomento completamente diverso.
Dunque, esaminiamo più dettagliatamente ogni punto della tabella.
Prima opzione: pochi nodi grandi
L'opzione più estrema è un nodo lavorativo per tutta la capacità del cluster. Nell'esempio precedente, sarebbe un nodo lavorativo con 16 core CPU e 16 GB di RAM.
Pro
Vantaggio n. 1. Gestione più semplice
È più facile gestire più macchine rispetto a un'intera flotta. È più veloce applicare aggiornamenti e correzioni, più semplice sincronizzare. Anche il numero di guasti in cifre assolute è inferiore.
Si noti che quanto sopra si riferisce all'hardware di proprietà, ai propri server, e non alle istanze cloud.
Nel cloud la situazione è diversa. L'amministrazione è gestita dal fornitore di servizi cloud. Pertanto, gestire dieci nodi in cloud non è particolarmente diverso dal gestire un solo nodo.
Il routing del traffico e il bilanciamento del carico tra i pod nel cloud : il traffico proveniente da Internet viene indirizzato al bilanciatore di carico principale, che reindirizza il traffico alla porta di uno dei nodi (il servizio NodePort espone una porta nell'intervallo 30000-32767 su ciascun nodo del cluster). Le regole stabilite da kube-proxy reindirizzano il traffico dal nodo al pod. Ecco come appare per dieci pod su due nodi:
Vantaggio n. 2. Meno costi per nodo
Una macchina potente è più costosa, ma l'aumento del prezzo non è necessariamente lineare. In altre parole, un server con dieci core e 10 GB di RAM è generalmente più economico di dieci server mononucleari con la stessa memoria.
Ma si noti che questa regola di solito non si applica ai servizi cloud. Negli attuali schemi di pricing, i prezzi di tutti i principali fornitori di servizi cloud aumentano linearmente con l'aumento della capacità.
Pertanto, nel cloud di solito non è possibile risparmiare su server più potenti.
Vantaggio n. 3. È possibile eseguire applicazioni ad alta intensità di risorse
Alcune applicazioni richiedono server potenti nel cluster. Ad esempio, se un sistema di machine learning richiede 8 GB di memoria, non sarà possibile eseguirlo su nodi da 1 GB, ma solo in presenza di almeno un nodo di lavoro grande.
Contro
Svantaggio n. 1. Molti pod su un nodo
Se lo stesso compito è eseguito su un numero minore di nodi, allora naturalmente ci saranno più pod su ciascuno di essi.
Questo può diventare un problema.
Il motivo è che ogni modulo introduce alcune sovraccarichi nell'ambiente di esecuzione del contenitore (ad esempio, Docker), così come kubelet e cAdvisor.
Ad esempio, kubelet controlla regolarmente la salute di tutti i contenitori su un nodo: più contenitori ci sono, più lavoro ha kubelet.
CAdvisor raccoglie statistiche sull'uso delle risorse di tutti i contenitori sul nodo, mentre kubelet richiede regolarmente queste informazioni e le fornisce tramite API. Ancora una volta, più contenitori ci sono, maggiore è il lavoro sia per cAdvisor che per kubelet.
Se il numero di moduli aumenta, questo può rallentare il sistema e persino minare la sua affidabilità.
Nel repository di Kubernetes alcuni , che i nodi oscillano tra gli stati Ready/NotReady, poiché i controlli regolari di kubelet su tutti i contenitori del nodo richiedono troppo tempo.
Per questa ragione, Kubernetes . A seconda delle prestazioni del nodo, è possibile eseguire più pod per nodo, ma è difficile prevedere se si verificheranno problemi o se tutto funzionerà bene. È consigliabile testare in anticipo il funzionamento.
Svantaggio n. 2. Limitazione alla replica
Un numero troppo ridotto di nodi limita l'efficacia del grado di replicazione delle applicazioni. Ad esempio, se hai un'applicazione ad alta disponibilità composta da cinque repliche, ma solo due nodi, il grado effettivo di replicazione dell'applicazione si riduce a due.
Cinque repliche possono essere distribuite solo su due nodi e, se uno di essi si guasta, vengono immediatamente messe fuori uso più repliche.
Se hai cinque nodi o più, ogni 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. Conseguenze peggiori del guasto
Con un numero ridotto di nodi, ogni guasto comporta conseguenze più gravi. Ad esempio, se hai solo due nodi e uno di essi si guasta, sparisce immediatamente metà dei tuoi moduli.
Certo, Kubernetes trasferirà il carico di lavoro dal nodo guasto ad altri. Ma se sono pochi, potrebbe non esserci abbastanza capacità libera. Di conseguenza, parte delle tue applicazioni saranno inaccessibili finché non riavvii il nodo guasto.
Pertanto, più nodi ci sono, minore è l'impatto dei guasti hardware.
Svantaggio n. 4. Maggiori passaggi per l'autoscaling
In Kubernetes, esiste un sistema di autoscalamento del cluster per l'infrastruttura cloud, che consente di aggiungere o rimuovere automaticamente i nodi in base alle attuali esigenze. Con nodi più grandi, l'autoscalamento diventa più brusco e goffo. Ad esempio, su due nodi, l'aggiunta di un nodo supplementare aumenterà la capacità del cluster immediatamente del 50%. E dovrete pagare per queste risorse, anche se non vi servono.
Pertanto, se prevedete di utilizzare l'autoscalamento del cluster, più piccoli sono i nodi, più flessibile ed economico sarà lo scaling che otterrete.
Ora consideriamo i vantaggi e gli svantaggi di avere un gran numero di piccoli nodi.
Seconda opzione: molti piccoli nodi
I vantaggi di questo approccio derivano sostanzialmente dagli svantaggi dell'opzione opposta con pochi nodi grandi.
Pro
Vantaggio n. 1. Minori conseguenze in caso di guasto
Più nodi ci sono, meno pod ci sono su ciascun nodo. Ad esempio, se avete cento pod su dieci nodi, su ogni nodo ci saranno in media dieci pod.
Pertanto, se uno dei nodi si guasta, perdete 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, è probabile che ci siano risorse libere sufficienti per il carico di lavoro del nodo guasto, consentendo a Kubernetes di riplanificare liberamente i pod e le vostre applicazioni tornano relativamente rapidamente a uno stato funzionale.
Vantaggio n. 2. Buona replicazione
Se ci sono abbastanza nodi, lo scheduler di Kubernetes può assegnare a ciascuna replica nodi diversi. In questo modo, in caso di guasto di un nodo, verrà colpita solo una replica e l'applicazione rimarrà disponibile.
Contro
Svantaggio n. 1. Gestione più difficile
Gestire un gran numero di nodi è più complicato. Ad esempio, ogni nodo di Kubernetes deve interagire con tutti gli altri, il che significa che il numero di collegamenti cresce in modo quadratico e tutti questi collegamenti devono essere monitorati.
Il controller dei nodi nel gestore di controller di Kubernetes controlla regolarmente tutti i nodi nel cluster per verificarne la funzionalità: più nodi ci sono, maggiore è il carico sul controller.
Aumenta anche il carico sul database etcd: ogni kubelet e kube-proxy chiama per etcd (tramite API), a cui 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 gran numero di nodi di lavoro, è consigliabile scegliere nodi principali più performanti. Ad esempio, kube-up la dimensione corretta della VM per il nodo principale in base al numero di nodi di lavoro. Cioè, più nodi di lavoro ci sono, più performanti devono essere i nodi principali.
Per affrontare questi problemi specifici, ci sono sviluppi speciali, come . Questo sistema consente di aggirare le limitazioni e costruire cluster con un numero enorme di nodi di lavoro.
Problema n. 2. Maggiore overhead
Su ogni nodo di lavoro, Kubernetes avvia un insieme di demoni di sistema – tra questi ci sono l'ambiente di esecuzione dei container (ad es. Docker), kube-proxy e kubelet, compreso cAdvisor. Insieme, consumano una certa quantità fissa di risorse.
Se hai molti nodi piccoli, la proporzione di questi overhead su ogni nodo è maggiore. Ad esempio, immagina che tutti i demoni di sistema di un nodo utilizzino insieme 0,1 core di CPU e 0,1 GB di RAM. Se hai un nodo da dieci core con 10 GB di RAM, i demoni consumano l'1% della capacità del cluster. D'altra parte, su dieci nodi a un core ciascuno con 1 GB di RAM, i demoni porteranno via il 10% della capacità del cluster.
Quindi, meno nodi hai, più efficacemente viene utilizzata l'infrastruttura.
Problema n. 3. Utilizzo inefficiente delle risorse
Su nodi piccoli può verificarsi la situazione in cui i frammenti rimanenti di risorse sono troppo piccoli per assegnare loro un carico di lavoro, quindi rimangono inutilizzati.
Ad esempio, ogni pod richiede 0,75 GB di RAM. Se hai dieci nodi, e ciascuno ha 1 GB di RAM, puoi avviare dieci pod – alla fine, su ogni nodo rimarranno 0,25 GB di RAM non utilizzata.
Ciò significa che il 25% della RAM dell'intero cluster viene sprecato.
Su un nodo grande con 10 GB di RAM puoi avviare 13 di questi moduli – e rimarrà solo un frammento non utilizzato di 0,25 GB.
In questo caso, solo il 2,5% della RAM viene sprecato.
Così, nelle grandi nodi si ottimizzano meglio le risorse.
Diversi grandi nodi o molti piccoli?
Quindi, cosa è meglio: diversi grandi nodi in un cluster o molti piccoli? Come sempre, non esiste una risposta univoca. Molto dipende dal tipo di applicazione.
Ad esempio, se un'applicazione richiede 10 GB di memoria, la scelta dei grandi nodi è ovvia. Ma se l'applicazione richiede una replica dieci volte per alta disponibilità, è poco saggio rischiare posizionando le repliche su soli due nodi: ci devono essere almeno dieci nodi nel cluster.
In situazioni intermedie, fai la tua scelta in base ai vantaggi e agli svantaggi di ciascuna opzione. Potrebbe essere che alcuni argomenti siano più pertinenti per la tua situazione rispetto ad altri.
Non è affatto necessario avere tutti i nodi della stessa dimensione. Niente ti impedisce di sperimentare inizialmente con nodi della stessa dimensione e poi aggiungere nodi di dimensioni diverse, combinandoli nel cluster. I nodi di lavoro di 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 il lavoro in produzione rivelerà la verità.
Traduzione preparata dal team della piattaforma cloud .
Ancora su Kubernetes: .
Fonte: habr.com
