Quan es crea un clúster de Kubernetes, poden sorgir preguntes: quants nodes de treball configurar i quin tipus? Què és millor per a un clúster local: compreu diversos servidors potents o utilitzeu una dotzena de màquines antigues al vostre centre de dades? És millor prendre vuit instàncies d'un sol nucli o dues de quatre nuclis al núvol?
Les respostes a aquestes preguntes es troben a l'article. en la traducció de l'ordre .
Capacitat del clúster
En general, un clúster de Kubernetes es pot considerar un gran "supernode". La seva potència de càlcul total és la suma de les potències de tots els seus nodes constitutius.
Hi ha diverses maneres d'assolir l'objectiu de capacitat del clúster desitjat. Per exemple, necessitem un clúster amb una capacitat total de 8 nuclis de processador i 32 GB de RAM perquè un conjunt d'aplicacions requereix molts recursos. A continuació, podeu instal·lar dos nodes amb 16 GB de memòria o quatre nodes amb 8 GB de memòria, dos processadors de quatre nuclis o quatre de doble nucli.
Aquí només hi ha dues maneres possibles de crear un clúster:
Ambdues opcions produeixen un clúster amb la mateixa capacitat, però la configuració inferior té quatre nodes més petits i la configuració superior dos nodes més grans.
Quina opció és millor?
Per respondre a aquesta pregunta, mirem els avantatges d'ambdues opcions. Els hem resumit en una taula.
Diversos nodes grans
Molts nodes petits
Gestió de clústers més fàcil (si és on-premise)
Autoescala suau
Més barat (si és local)
El preu és una mica diferent (al núvol)
Pot executar aplicacions que consumeixen molts recursos
Replicació completa
Els recursos s'utilitzen de manera més eficient (menys sobrecàrrega en els dimonis del sistema
Major tolerància a fallades del clúster
Tingueu en compte que només estem parlant de nodes de treball. Escollir el nombre i la mida dels nodes principals és un tema completament diferent.
Per tant, analitzem cada punt de la taula amb més detall.
Primera opció: diversos nodes grans
L'opció més extrema és un node de treball per a tota la capacitat del clúster. A l'exemple anterior, aquest seria un únic node de treball amb 16 nuclis de CPU i 16 GB de RAM.
Pros
Plus núm. 1. Gestió més fàcil
És més fàcil gestionar unes poques màquines que tota una flota. És més ràpid llançar actualitzacions i correccions, i és més fàcil de sincronitzar. El nombre de fallades en nombres absoluts també és menor.
Tingueu en compte que tot l'anterior s'aplica al vostre maquinari, als vostres servidors i no a les instàncies del núvol.
La situació és diferent al núvol. Allà, la gestió la gestiona el proveïdor de serveis al núvol. Per tant, gestionar deu nodes al núvol no és gaire diferent de gestionar un node.
Encaminament del trànsit i distribució de càrrega entre pods al núvol : el trànsit procedent d'Internet s'envia a l'equilibrador de càrrega principal, que reenvia el trànsit al port d'un dels nodes (el servei NodePort estableix el port en el rang 30000-32767 a cada node del clúster). Les regles establertes per kube-proxy redirigeixen el trànsit del node al pod. A continuació es mostra com es veuen deu pods en dos nodes:
Pro #2: Menys cost per node
Un cotxe potent és més car, però l'augment del preu no és necessàriament lineal. En altres paraules, un servidor de deu nuclis amb 10 GB de memòria sol ser més barat que deu servidors d'un sol nucli amb la mateixa quantitat de memòria.
Però tingueu en compte que aquesta regla no sol funcionar als serveis al núvol. En els esquemes de preus actuals de tots els principals proveïdors de núvol, els preus augmenten de manera lineal amb la capacitat.
Així, al núvol normalment no pots desar en servidors més potents.
Pro núm. 3: podeu executar aplicacions que consumeixen molts recursos
Algunes aplicacions requereixen servidors potents en un clúster. Per exemple, si un sistema d'aprenentatge automàtic requereix 8 GB de memòria, no podreu executar-lo en nodes d'1 GB, però només amb almenys un node de treball gran.
Contres
Desavantatge número 1. Molts pods per node
Si es realitza la mateixa tasca en menys nodes, llavors cadascun d'ells tindrà, naturalment, més beines.
Això podria ser un problema.
El motiu és que cada mòdul introdueix una mica de sobrecàrrega al temps d'execució del contenidor (per exemple, Docker), així com al kubelet i al cAdvisor.
Per exemple, un kubelet sondeja regularment tots els contenidors d'un node per a la supervivència: com més contenidors, més feina ha de fer el kubelet.
CAdvisor recopila estadístiques d'ús de recursos per a tots els contenidors d'un node i kubelet consulta regularment aquesta informació i la proporciona mitjançant una API. De nou, més contenidors significa més feina tant per a cAdvisor com per a kubelet.
Si augmenta el nombre de mòduls, pot alentir el sistema i fins i tot minar la seva fiabilitat.
Al repositori de Kubernetes alguns que els nodes salten entre els estats Ready/NotReady perquè les comprovacions regulars de kubelet de tots els contenidors d'un node triguen massa.
Per aquest motiu Kubernetes . Depenent del rendiment del node, podeu executar més pods per node, però és difícil predir si hi haurà problemes o si tot funcionarà bé. Val la pena provar el treball amb antelació.
Desavantatge núm. 2. Limitació de la replicació
Massa pocs nodes limiten l'extensió efectiva de la replicació de l'aplicació. Per exemple, si teniu una aplicació d'alta disponibilitat amb cinc rèpliques però només dos nodes, el grau efectiu de replicació de l'aplicació es redueix a dos.
Cinc rèpliques només es poden distribuir entre dos nodes i, si un d'ells falla, elimina diverses rèpliques alhora.
Si teniu cinc nodes o més, cada rèplica s'executarà en un node independent i la fallada d'un node eliminarà com a màxim una rèplica.
Així, els requisits d'alta disponibilitat poden requerir un nombre mínim de nodes al clúster.
Desavantatge núm. 3. Pitjors conseqüències del fracàs
Amb un nombre reduït de nodes, cada fallada té conseqüències més greus. Per exemple, si només teniu dos nodes i un d'ells falla, la meitat dels vostres mòduls desapareixen immediatament.
Per descomptat, Kubernetes migrarà la càrrega de treball del node fallit a altres. Però si n'hi ha pocs, és possible que no hi hagi prou capacitat lliure. Com a resultat, algunes de les vostres aplicacions no estaran disponibles fins que aparegueu el node fallit.
Així, com més nodes, menor serà l'impacte dels errors de maquinari.
Desavantatge núm. 4: més passos d'escala automàtica
Kubernetes té un sistema d'escalat automàtic de clúster per a la infraestructura del núvol, que us permet afegir o eliminar automàticament nodes en funció de les vostres necessitats actuals. Amb nodes més grans, l'escala automàtica es torna més brusca i complicada. Per exemple, en dos nodes, afegir un node addicional augmentarà immediatament la capacitat del clúster en un 50%. I haureu de pagar per aquests recursos, encara que no els necessiteu.
Per tant, si teniu previst utilitzar l'escala automàtica del clúster, com més petits siguin els nodes, més flexible i rendible obtindreu l'escala.
Vegem ara els avantatges i els desavantatges d'un gran nombre de nodes petits.
Segona opció: molts nodes petits
Els avantatges d'aquest enfocament deriven essencialment dels desavantatges de l'opció oposada amb diversos nodes grans.
Pros
Pro #1: Menys impacte del fracàs
Com més nodes, menys beines a cada node. Per exemple, si teniu cent mòduls per cada deu nodes, llavors cada node tindrà una mitjana de deu mòduls.
D'aquesta manera, si un dels nodes falla, només es perd el 10% de la càrrega de treball. El més probable és que només un nombre reduït de rèpliques es vegi afectat i que l'aplicació general continuï operativa.
A més, els nodes restants probablement tindran prou recursos gratuïts per gestionar la càrrega de treball del node fallit, de manera que Kubernetes pot reprogramar lliurement els pods i les vostres aplicacions tornaran a un estat funcional relativament ràpid.
Pro #2: Bona replicació
Si hi ha prou nodes, el planificador de Kubernetes pot assignar diferents nodes a totes les rèpliques. D'aquesta manera, si un node falla, només una rèplica es veurà afectada i l'aplicació romandrà disponible.
Contres
Desavantatge núm. 1. Difícil de controlar
Un gran nombre de nodes és més difícil de gestionar. Per exemple, cada node de Kubernetes ha de comunicar-se amb tots els altres, és a dir, el nombre de connexions creix quadràticament i cal fer un seguiment de totes aquestes connexions.
El controlador de nodes de Kubernetes Controller Manager recorre regularment tots els nodes del clúster per comprovar l'estat: com més nodes, més càrrega al controlador.
La càrrega de la base de dades etcd també està creixent: cada kubelet i kube-proxy criden per a etcd (mitjançant l'API), al qual etcd hauria de transmetre actualitzacions d'objectes.
En general, cada node de treball imposa una càrrega addicional als components del sistema dels nodes mestres.
Kubernetes admet oficialment clústers amb . Tanmateix, a la pràctica ja hi ha 500 nodes .
Per gestionar un gran nombre de nodes de treball, hauríeu de triar nodes mestres més potents. Per exemple, kube-up la mida de VM correcta per al node mestre en funció del nombre de nodes de treball. És a dir, com més nodes de treball, més productius haurien de ser els nodes mestres.
Per resoldre aquests problemes específics hi ha desenvolupaments especials, com ara . Aquest sistema us permet evitar les restriccions i crear clústers amb un gran nombre de nodes de treball.
Desavantatge número 2: més costos generals.
A cada node de treball, Kubernetes executa un conjunt de dimonis del sistema: aquests inclouen el temps d'execució del contenidor (com ara Docker), kube-proxy i kubelet, inclòs cAdvisor. Junts consumeixen una certa quantitat fixa de recursos.
Si teniu molts nodes petits, la proporció d'aquesta sobrecàrrega a cada node és més gran. Per exemple, imagineu que tots els dimonis del sistema d'un sol node junts utilitzen 0,1 nuclis de CPU i 0,1 GB de memòria. Si teniu un node de deu nuclis amb 10 GB de memòria, els dimonis consumeixen l'1% de la capacitat del clúster. D'altra banda, en deu nodes d'un sol nucli amb 1 GB de memòria, els dimonis ocuparan el 10% de la capacitat del clúster.
Així, com menys nodes, més eficient s'utilitza la infraestructura.
Desavantatge núm. 3. Ús ineficient dels recursos
Als nodes petits, pot ser que els fragments de recursos restants siguin massa petits per assignar-hi cap càrrega de treball, de manera que no s'utilitzen.
Per exemple, cada pod requereix 0,75 GB de memòria. Si teniu deu nodes, cadascun amb 1 GB de memòria, podeu executar deu pods, deixant cada node amb 0,25 GB de memòria no utilitzada.
Això significa que es malgasta el 25% de la memòria del clúster.
En un node gran amb 10 GB de memòria, podeu executar 13 d'aquests mòduls, i només hi haurà un fragment no utilitzat de 0,25 GB.
En aquest cas, només es malgasta el 2,5% de la memòria.
Així, els recursos s'utilitzen de manera més òptima en nodes més grans.
Diversos nodes grans o molts de petits?
Aleshores, què és millor: uns quants nodes grans en un clúster o molts de petits? Com sempre, no hi ha una resposta clara. Molt depèn del tipus d'aplicació.
Per exemple, si una aplicació requereix 10 GB de memòria, els nodes més grans són una opció òbvia. I si l'aplicació requereix una rèplica deu vegades per a una alta disponibilitat, no val la pena el risc de col·locar rèpliques només en dos nodes: hi ha d'haver un mínim de deu nodes al clúster.
En situacions intermèdies, feu una tria en funció dels avantatges i desavantatges de cada opció. Potser alguns arguments són més rellevants per a la vostra situació que d'altres.
I no és gens necessari que tots els nodes tinguin la mateixa mida. Res no us impedeix experimentar primer amb nodes de la mateixa mida i després afegir-hi nodes d'una mida diferent i combinar-los en un clúster. Els nodes de treball en un clúster de Kubernetes poden ser completament heterogenis. Així que podeu intentar combinar els avantatges dels dos enfocaments.
No hi ha una recepta única, i cada situació té els seus propis matisos, i només la producció mostrarà la veritat.
Traducció elaborada per l'equip de la plataforma núvol .
Més informació sobre Kubernetes: .
Font: www.habr.com
