At the creation of a Kubernetes cluster, questions may arise: how many worker nodes to configure and what types? What is better for an on-premise cluster: to buy several powerful servers or to use a dozen old machines in your data center? And in the cloud, is it better to take eight single-core or two quad-core instances?
The answers to these questions are in the article translated by the team .
Cluster capacity
In general, a Kubernetes cluster can be viewed as a large "super node." Its total computational power is the sum of the capabilities of all its constituent nodes.
There are several ways to achieve the desired target capacity of the cluster. For example, we need a cluster with a total capacity of 8 CPU cores and 32 GB of RAM because the application set requires that many resources. Then we can install two nodes with 16 GB of memory or four nodes with 8 GB of memory, two quad-core processors or four dual-core ones.
Here are just two possible ways to create a cluster:
Both options yield a cluster with the same capacity, but in the bottom configuration, there are four smaller nodes, while in the top configuration, there are two larger ones.
Which option is better?
To answer this question, let’s consider the advantages of both options. We summarized them in a table.
Several large nodes
Many small nodes
Simpler cluster management (if on-premise)
Smooth auto-scaling
Cheaper (if on-premise)
Cost is not significantly different (in the cloud)
Can run resource-intensive applications
Full replication
Resources are used more efficiently (less overhead on system daemons)
Higher cluster fault tolerance
Note that we are only talking about worker nodes. The choice of the number and size of master nodes is a completely different topic.
So, let’s discuss each point from the table in more detail.
The first option: several large nodes
The most extreme option is one worker node for the entire capacity of the cluster. In the example above, this would be one worker node with 16 CPU cores and 16 GB of RAM.
Advantages
Advantage #1. Simpler management
Este mai simplu să gestionezi mai multe mașini decât un întreg parc. Actualizările și corecțiile se aplică mai repede, iar sincronizarea este mai ușoară. De asemenea, numărul de erori în cifre absolute este, de asemenea, mai mic.
Rețineți că toate cele de mai sus se referă la hardware-ul propriu, serverele proprii, și nu la instanțele cloud.
În cloud, situația este diferită. Acolo, furnizorul de servicii cloud se ocupă de gestionare. Prin urmare, gestionarea a zece noduri în cloud nu se deosebește prea mult de gestionarea unui singur nod.
Rutarea traficului și distribuția sarcinii între poduri în cloud : traficul venit din internet este direcționat către principalul balansor de sarcini, care redirecționează traficul către portul unuia dintre noduri (serviciul NodePort alocă un port în intervalul 30000-32767 pentru fiecare nod din cluster). Regulele stabilite de kube-proxy redirecționează traficul de la nod la pod. Iată cum arată acest lucru pentru zece pod-uri pe două noduri:
Plusul nr. 2. Costuri mai reduse pe nod
O mașină puternică este mai scumpă, dar creșterea prețului nu este neapărat liniară. Cu alte cuvinte, un server cu zece nuclee și 10 GB de memorie este, de obicei, mai ieftin decât zece servere cu un singur nucleu, cu aceeași cantitate de memorie.
Dar rețineți că această regulă nu funcționează de obicei în serviciile cloud. În schemele actuale de tarifare ale tuturor furnizorilor principali de servicii cloud, prețurile cresc liniar odată cu creșterea capacității.
Prin urmare, în cloud, de obicei, nu există economii la serverele mai puternice.
Plusul nr. 3. Poți rula aplicații consumatoare de resurse
Unele aplicații necesită servere puternice în cluster. De exemplu, dacă un sistem de învățare automată necesită 8 GB de memorie, nu vei putea să-l rulezi pe noduri cu 1 GB, ci doar dacă există cel puțin un nod de lucru mare.
Dezavantaje
Minusul nr. 1. Multe pod-uri pe nod
Dacă aceeași sarcină este executată pe un număr mai mic de noduri, atunci pe fiecare din acestea, evident, vor fi mai multe pod-uri.
Aceasta poate deveni o problemă.
Motivul este că fiecare modul aduce unele costuri indirecte pentru mediu de rulare al containerului (de exemplu, Docker), precum și kubelet și cAdvisor.
De exemplu, kubelet sondajează cu regularitate despre sănătatea tuturor containerelor de pe nod - cu cât sunt mai multe containere, cu atât mai multă muncă are kubelet.
CAdvisor colectează statistici privind utilizarea resurselor tuturor containerelor de pe nod, iar kubelet solicită în mod regulat aceste informații și le oferă prin API. Din nou, cu cât sunt mai multe containere, cu atât mai multă muncă există pentru cAdvisor și kubelet.
Dacă numărul de module crește, acest lucru poate încetini sistemul și chiar îi poate afecta fiabilitatea.
În repository-ul Kubernetes, unii , că nodurile sar între stările Ready/NotReady, deoarece verificările regulate ale kubelet pentru toate containerele de pe nod durează prea mult timp.
Din acest motiv, Kubernetes . În funcție de performanța nodului, este posibil să puteți rula mai multe pod-uri pe un nod, dar este greu de prezis dacă vor apărea probleme sau dacă totul va funcționa bine. Merită să testați funcționarea din timp.
Contras #2. Limitarea replicării
Un număr prea mic de noduri limitează gradul eficient de replicare a aplicațiilor. De exemplu, dacă aveți o aplicație cu înaltă disponibilitate formată din cinci replici, dar numai două noduri, atunci gradul eficient de replicare al aplicației scade la două.
Cinci replici pot fi distribuite doar pe două noduri, iar dacă unul dintre ele nu funcționează, mai multe replici sunt imediat afectate.
Dacă aveți cinci noduri sau mai multe, fiecare replică va fi executată pe un nod separat, iar defectarea unui nod va elimina nu mai mult de o replică.
Astfel, cerințele de înaltă disponibilitate pot necesita un anumit număr minim de noduri în cluster.
Contras #3. Consecințe mai grave ale defectării
Cu un număr mic de noduri, fiecare defectare are consecințe mai grave. De exemplu, dacă aveți doar două noduri și unul dintre ele se strică, imediat se pierde jumătate din module.
Desigur, Kubernetes va muta sarcina de lucru de pe nodul defect către altele. Dar dacă ele sunt puține, poate să nu existe suficient spațiu disponibil. Ca rezultat, unele dintre aplicațiile dumneavoastră vor fi indisponibile până când veți reporni nodul defect.
Astfel, cu cât sunt mai multe noduri, cu atât mai puțin impact au defectele hardware.
Contras #4. Mai multe etape de autoscalare
În Kubernetes, există un sistem de scalare automată a clusterului pentru infrastructura cloud, care permite adăugarea sau eliminarea automată a nodurilor în funcție de nevoile actuale. Cu noduri mari, scalarea devine mai abruptă și mai neîndemânatică. De exemplu, adăugarea unui nod suplimentar la două noduri va crește capacitatea clusterului imediat cu 50%. Și va trebui să plătiți pentru aceste resurse, chiar dacă nu aveți nevoie de ele.
Astfel, dacă planificați să utilizați scalarea automată a clusterului, cu cât nodurile sunt mai mici, cu atât veți obține o scalare mai flexibilă și mai economică.
Acum să discutăm avantajele și dezavantajele unui număr mare de noduri mici.
A doua variantă: multe noduri mici
Avantajele acestei abordări derivă, în esență, din dezavantajele opțiunii opuse cu câteva noduri mari.
Advantages
Plus #1. Consecințe mai mici în caz de eșec
Cu cât sunt mai multe noduri, cu atât mai puține poduri sunt pe fiecare nod. De exemplu, dacă aveți o sută de module pe zece noduri, atunci pe fiecare nod vor fi în medie zece module.
Astfel, dacă unul dintre noduri eșuează, pierdeți doar 10% din sarcina de lucru. Există o probabilitate ca doar un număr mic de replici să fie afectate, iar aplicațiile în ansamblu să rămână funcționale.
În plus, pe nodurile rămase, este probabil să existe suficiente resurse libere pentru sarcina de lucru a nodului eșuat, astfel încât Kubernetes să poată reprograma liber podurile, iar aplicațiile dvs. să revină relativ rapid în stare operațională.
Plus #2. Replicare bună
Dacă sunt suficiente noduri, programatorul Kubernetes poate aloca tuturor replicilor noduri diferite. Astfel, în caz de eșec al unui nod, va fi afectată doar o singură replică, iar aplicația va rămâne disponibilă.
Dezavantaje
Minus #1. Management mai dificil
Gestionarea unui număr mare de noduri este mai complicată. De exemplu, fiecare nod Kubernetes trebuie să interacționeze cu toate celelalte, adică numărul conexiunilor crește pătratic, iar toate aceste conexiuni trebuie monitorizate.
Controlerul de noduri în managerul de controlere Kubernetes verifică periodic toate nodurile din cluster pentru a verifica funcționalitatea — cu cât sunt mai multe noduri, cu atât mai mare este sarcina pe controler.
De asemenea, crește sarcina asupra bazei de date etcd — fiecare kubelet și kube-proxy efectuează pentru etcd (prin API), la care etcd trebuie să transmită actualizările obiectului.
În general, fiecare nod de lucru impune o sarcină suplimentară asupra componentelor sistemului nodurilor principale.
Kubernetes suportă oficial clustere cu . Totuși, în practică, deja 500 de noduri .
Pentru a gestiona un număr mare de noduri de lucru, este necesar să alegi noduri principale mai performante. De exemplu, kube-up dimensiunea corectă a VM pentru nodul principal în funcție de numărul de noduri de lucru. Cu alte cuvinte, cu cât sunt mai multe noduri de lucru, cu atât nodurile principale trebuie să fie mai performante.
Pentru a aborda aceste probleme specifice, există soluții speciale, cum ar fi . Acest sistem permite ocolirea limitărilor și construirea de clustere cu un număr enorm de noduri de lucru.
Dezavantaj Nr. 2. Mai multe costuri indirecte
Pe fiecare nod de lucru, Kubernetes rulează un set de demoni de sistem — acestea includ mediul de execuție a containerelor (de exemplu, Docker), kube-proxy și kubelet, inclusiv cAdvisor. Împreună, aceste componente consumă o anumită cantitate fixă de resurse.
Dacă ai multe noduri mici, cota acestor costuri indirecte pe fiecare nod este mai mare. De exemplu, imaginează-ți că toți demonii de sistem de pe un nod folosesc împreună 0,1 nuclee CPU și 0,1 GB de memorie. Dacă ai un nod cu zece nuclee și 10 GB de memorie, demonii consumă 1% din capacitatea clusterei. Pe de altă parte, pe zece noduri cu un nucleu fiecare și 1 GB de memorie, demonii vor consuma 10% din capacitatea clusterei.
Prin urmare, cu cât sunt mai puține noduri, cu atât infrastructura este utilizată mai eficient.
Dezavantaj Nr. 3. Utilizarea ineficientă a resurselor
Pe noduri mici, se poate întâmpla ca fragmentele rămase de resurse să fie prea mici pentru a le aloca o sarcină de lucru, astfel că acestea rămân neutilizate.
De exemplu, fiecare pod necesită 0,75 GB de memorie. Dacă ai zece noduri și fiecare are 1 GB de memorie, poți rula zece pod-uri — în final, pe fiecare nod rămâne 0,25 GB de memorie neutilizată.
Aceasta înseamnă că 25% din memoria totală a clusterei este cheltuită fără rost.
Pe un nod mare cu 10 GB de memorie, poți rula 13 astfel de module — și va rămâne doar un fragment neutilizat de 0,25 GB.
În acest caz, doar 2,5% din memorie este cheltuită fără rost.
Astfel, resursele sunt utilizate mai eficient pe noduri mari.
Câteva noduri mari sau multe noduri mici?
Deci, ce este mai bine: câteva noduri mari într-un cluster sau multe noduri mici? Ca de obicei, nu există un răspuns clar. Multe depind de tipul aplicației.
De exemplu, dacă aplicația necesită 10 GB de memorie, alegerea evidentă este nodurile mari. Iar dacă aplicația necesită replicare de zece ori pentru disponibilitate ridicată, cu siguranță nu ar trebui să riscați să plasați replicile pe doar două noduri — ar trebui să existe cel puțin zece noduri în cluster.
În situații intermediare, faceți alegerea în funcție de avantajele și dezavantajele fiecărei opțiuni. Poate că unele argumente sunt mai relevante pentru situația dvs. decât altele.
Și nu este deloc obligatoriu să aveți toate nodurile de aceeași dimensiune. Nimic nu împiedică experimentarea mai întâi cu noduri de aceeași dimensiune, apoi adăugarea de noduri de dimensiuni diferite, combinându-le în cluster. Nodurile de lucru ale clusterului Kubernetes pot fi complet heterogene. Deci, puteți încerca să combinați avantajele ambelor abordări.
Nu există o rețetă unică, iar fiecare situație are nuanțele sale, iar doar producția va arăta adevărul.
Traducerea a fost pregătită de echipa platformei de cloud .
Încă despre Kubernetes: .
Sursa: habr.com
