Când creați un cluster Kubernetes, pot apărea întrebări: câte noduri de lucru trebuie să configurați și ce tip? Ce este mai bun pentru un cluster on-premise: cumpărați mai multe servere puternice sau folosiți o duzină de mașini vechi în centrul dvs. de date? Este mai bine să luați opt instanțe single-core sau două quad-core în cloud?
Răspunsurile la aceste întrebări sunt în articol. în traducerea comenzii .
Capacitatea clusterului
În general, un cluster Kubernetes poate fi considerat ca un „supernod” mare. Puterea sa totală de calcul este suma puterilor tuturor nodurilor sale constitutive.
Există mai multe moduri de a atinge obiectivul dorit de capacitate a clusterului. De exemplu, avem nevoie de un cluster cu o capacitate totală de 8 nuclee de procesor și 32 GB de RAM deoarece un set de aplicații necesită atât de multe resurse. Apoi puteți instala două noduri cu 16 GB de memorie sau patru noduri cu 8 GB de memorie, două procesoare quad-core sau patru dual-core.
Iată doar două moduri posibile de a crea un cluster:
Ambele opțiuni produc un cluster cu aceeași capacitate, dar configurația de jos are patru noduri mai mici, iar configurația de sus are două noduri mai mari.
Care varianta este mai buna?
Pentru a răspunde la această întrebare, să ne uităm la avantajele ambelor opțiuni. Le-am rezumat într-un tabel.
Câteva noduri mari
Multe noduri mici
Gestionare mai ușoară a clusterului (dacă este on-premise)
Autoscaling lină
Mai ieftin (dacă la sediu)
Prețul este puțin diferit (în cloud)
Poate rula aplicații consumatoare de resurse
Replicare completă
Resursele sunt utilizate mai eficient (mai puțină suprasarcină pentru demonii de sistem
Toleranță mai mare la erori ale clusterului
Vă rugăm să rețineți că vorbim doar despre noduri de lucru. Alegerea numărului și dimensiunii nodurilor principale este un subiect complet diferit.
Deci, să discutăm mai detaliat fiecare punct din tabel.
Prima opțiune: mai multe noduri mari
Opțiunea cea mai extremă este un nod de lucru pentru întreaga capacitate a clusterului. În exemplul de mai sus, acesta ar fi un singur nod de lucru cu 16 nuclee CPU și 16 GB de RAM.
Pro
Plus nr. 1. Gestionare mai ușoară
Este mai ușor să gestionezi câteva mașini decât o întreagă flotă. Este mai rapid să lansați actualizări și remedieri și este mai ușor de sincronizat. Numărul de eșecuri în cifre absolute este, de asemenea, mai mic.
Vă rugăm să rețineți că toate cele de mai sus se aplică hardware-ului dvs., serverelor dvs. și nu instanțelor cloud.
Situația este diferită în cloud. Acolo, gestionarea este gestionată de furnizorul de servicii cloud. Astfel, gestionarea a zece noduri în cloud nu este mult diferită de gestionarea unui nod.
Dirijarea traficului și distribuția încărcării între poduri în cloud : traficul care vine de pe Internet este trimis către echilibratorul de încărcare principal, care redirecționează traficul către portul unuia dintre noduri (serviciul NodePort setează portul în intervalul 30000-32767 în fiecare nod de cluster). Regulile stabilite de kube-proxy redirecționează traficul de la nod la pod. Iată cum arată pentru zece pod-uri pe două noduri:
Pro #2: Cost mai mic 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 cu 10 GB de memorie este de obicei mai ieftin decât zece servere single-core 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 prețuri ale tuturor furnizorilor importanți de cloud, prețurile cresc liniar cu capacitatea.
Astfel, în cloud de obicei nu poți salva pe servere mai puternice.
Pro # 3: Puteți rula aplicații care necesită mult resurse
Unele aplicații necesită servere puternice într-un cluster. De exemplu, dacă un sistem de învățare automată necesită 8 GB de memorie, nu îl veți putea rula pe noduri de 1 GB, ci numai cu cel puțin un nod de lucru mare.
Contra
Dezavantajul nr. 1. Multe păstăi pe nod
Dacă aceeași sarcină este efectuată pe mai puține noduri, atunci fiecare dintre ele va avea în mod natural mai multe poduri.
Aceasta ar putea fi o problemă.
Motivul este că fiecare modul introduce o suprasarcină în timpul de rulare a containerului (de exemplu, Docker), precum și pentru kubelet și cAdvisor.
De exemplu, un kubelet sondează în mod regulat toate containerele de pe un nod pentru supraviețuire - cu cât mai multe containere, cu atât mai multă muncă trebuie să facă kubelet.
CAdvisor colectează statistici de utilizare a resurselor pentru toate containerele de pe un nod, iar kubelet interogează regulat aceste informații și le furnizează printr-un API. Din nou, mai multe containere înseamnă mai multă muncă atât pentru cAdvisor, cât și pentru kubelet.
Dacă numărul de module crește, acesta poate încetini sistemul și chiar submina fiabilitatea acestuia.
În depozitul Kubernetes unele că nodurile trec între stările Ready/NotReady deoarece verificările regulate kubelet ale tuturor containerelor de pe un nod durează prea mult.
Din acest motiv Kubernetes . În funcție de performanța nodului, puteți rula mai multe poduri pe nod, dar este greu de prezis dacă vor apărea probleme sau dacă totul va funcționa bine. Merită să testați lucrarea în avans.
Dezavantajul nr. 2. Limitarea replicării
Prea puține noduri limitează gradul efectiv de replicare a aplicației. De exemplu, dacă aveți o aplicație de înaltă disponibilitate cu cinci replici, dar numai două noduri, atunci gradul efectiv de replicare al aplicației este redus la două.
Cinci replici pot fi distribuite doar pe două noduri, iar dacă unul dintre ele eșuează, va elimina mai multe replici simultan.
Dacă aveți cinci noduri sau mai multe, fiecare replică va rula pe un nod separat, iar eșecul unui nod va elimina cel mult o replică.
Astfel, cerințele de înaltă disponibilitate pot necesita un anumit număr minim de noduri în cluster.
Dezavantajul nr. 3. Consecințele mai grave ale eșecului
Cu un număr mic de noduri, fiecare defecțiune are consecințe mai grave. De exemplu, dacă aveți doar două noduri și unul dintre ele eșuează, jumătate dintre module dispar imediat.
Desigur, Kubernetes va migra volumul de lucru de la nodul eșuat la alții. Dar dacă sunt puține, atunci este posibil să nu existe suficientă capacitate liberă. Ca urmare, unele dintre aplicațiile dvs. vor fi indisponibile până când veți afișa nodul eșuat.
Astfel, cu cât sunt mai multe noduri, cu atât impactul defecțiunilor hardware este mai mic.
Dezavantajul #4: Mai mulți pași de autoscaling
Kubernetes are un sistem de scalare automată a clusterului pentru infrastructura cloud, care vă permite să adăugați sau să eliminați automat noduri în funcție de nevoile dvs. actuale. Cu noduri mai mari, scalarea automată devine mai bruscă și mai greoaie. De exemplu, pe două noduri, adăugarea unui nod suplimentar va crește imediat capacitatea clusterului cu 50%. Și va trebui să plătești pentru acele resurse, chiar dacă nu ai nevoie de ele.
Astfel, dacă intenționați să utilizați scalarea automată a clusterelor, cu cât nodurile sunt mai mici, cu atât veți obține scalarea mai flexibilă și mai rentabilă.
Acum să ne uităm la avantajele și dezavantajele unui număr mare de noduri mici.
A doua opțiune: multe noduri mici
Avantajele acestei abordări provin în principal din dezavantajele opțiunii opuse cu mai multe noduri mari.
Pro
Pro #1: Impact mai mic al eșecului
Cu cât sunt mai multe noduri, cu atât mai puține poduri pe fiecare nod. De exemplu, dacă aveți o sută de module la zece noduri, atunci fiecare nod va avea o medie de zece module.
În acest fel, dacă unul dintre noduri eșuează, pierzi doar 10% din volumul de muncă. Sunt șanse ca doar un număr mic de replici să fie afectat și aplicația generală să rămână operațională.
În plus, nodurile rămase vor avea probabil suficiente resurse gratuite pentru a face față sarcinii de lucru a nodului eșuat, astfel încât Kubernetes poate reprograma liber pod-urile și aplicațiile dvs. vor reveni la o stare funcțională relativ rapid.
Pro #2: Replicare bună
Dacă există suficiente noduri, planificatorul Kubernetes poate aloca noduri diferite tuturor replicilor. În acest fel, dacă un nod eșuează, o singură replică va fi afectată și aplicația va rămâne disponibilă.
Contra
Dezavantajul nr. 1. Greu de controlat
Un număr mare de noduri este mai dificil de gestionat. De exemplu, fiecare nod Kubernetes trebuie să comunice cu toate celelalte, adică numărul de conexiuni crește pătratic și toate aceste conexiuni trebuie urmărite.
Controlerul de noduri din Kubernetes Controller Manager parcurge în mod regulat toate nodurile din cluster pentru a verifica starea - cu cât sunt mai multe noduri, cu atât este mai mare sarcina controlerului.
Încărcarea bazei de date etcd este, de asemenea, în creștere - fiecare apel kubelet și kube-proxy pentru etcd (prin API), către care etcd ar trebui să transmită actualizări de obiecte.
În general, fiecare nod de lucru impune încărcare suplimentară asupra componentelor de sistem ale nodurilor master.
Kubernetes acceptă oficial clustere cu . Cu toate acestea, în practică există deja 500 de noduri .
Pentru a gestiona un număr mare de noduri de lucru, ar trebui să alegeți noduri master mai puternice. De exemplu, kube-up dimensiunea corectă a VM pentru nodul master, în funcție de numărul de noduri de lucru. Adică, cu cât mai multe noduri de lucru, cu atât ar trebui să fie mai productive nodurile master.
Pentru a rezolva aceste probleme specifice există dezvoltări speciale, cum ar fi . Acest sistem vă permite să ocoliți restricțiile și să construiți clustere cu un număr mare de noduri de lucru.
Dezavantajul #2: Mai multe costuri generale.
Pe fiecare nod de lucru, Kubernetes rulează un set de demoni de sistem - acestea includ timpul de rulare a containerului (cum ar fi Docker), kube-proxy și kubelet, inclusiv cAdvisor. Împreună consumă o anumită cantitate fixă de resurse.
Dacă aveți multe noduri mici, proporția acestei supraîncărcări pe fiecare nod este mai mare. De exemplu, imaginați-vă că toți demonii de sistem de pe un singur nod folosesc împreună 0,1 nuclee CPU și 0,1 GB de memorie. Dacă aveți un nod cu zece nuclee cu 10 GB de memorie, atunci demonii consumă 1% din capacitatea clusterului. Pe de altă parte, pe zece noduri single-core cu 1 GB de memorie, demonii vor ocupa 10% din capacitatea clusterului.
Astfel, cu cât sunt mai puține noduri, cu atât infrastructura este utilizată mai eficient.
Dezavantajul nr. 3. Utilizarea ineficientă a resurselor
Pe nodurile mici, este posibil ca bucățile de resurse rămase să fie prea mici pentru a le aloca vreo sarcină de lucru, așa că rămân neutilizate.
De exemplu, fiecare pod necesită 0,75 GB de memorie. Dacă aveți zece noduri, fiecare cu 1 GB de memorie, puteți rula zece pod-uri, lăsând fiecare nod cu 0,25 GB de memorie nefolosită.
Aceasta înseamnă că 25% din memoria întregului cluster este irosită.
Pe un nod mare cu 10 GB de memorie, puteți rula 13 dintre aceste module - și va exista un singur fragment neutilizat de 0,25 GB.
În acest caz, doar 2,5% din memorie este irosită.
Astfel, resursele sunt utilizate mai optim pe noduri mai mari.
Mai multe noduri mari sau multe mici?
Deci, care este mai bine: câteva noduri mari într-un cluster sau multe altele mici? Ca întotdeauna, nu există un răspuns clar. Depinde mult de tipul de aplicare.
De exemplu, dacă o aplicație necesită 10 GB de memorie, nodurile mai mari sunt o alegere evidentă. Și dacă aplicația necesită replicare de zece ori pentru o disponibilitate ridicată, nu merită riscul de a plasa replici pe doar două noduri - trebuie să existe minimum zece noduri în cluster.
În situații intermediare, faceți o alegere în funcție de avantajele și dezavantajele fiecărei opțiuni. Poate că unele argumente sunt mai relevante pentru situația ta decât altele.
Și nu este deloc necesar să faceți toate nodurile de aceeași dimensiune. Nimic nu vă împiedică să experimentați mai întâi cu noduri de aceeași dimensiune, apoi să adăugați noduri de o dimensiune diferită, combinându-le într-un cluster. Nodurile de lucru dintr-un cluster Kubernetes pot fi complet eterogene. Deci puteți încerca să combinați avantajele ambelor abordări.
Nu există o singură rețetă, iar fiecare situație are propriile sale nuanțe și numai producția va arăta adevărul.
Traducere pregătită de echipa platformei cloud .
Mai multe despre Kubernetes: .
Sursa: www.habr.com
