Kubernetes klaszter létrehozásakor felmerülhetnek kérdések: hány munkacsoportot állítsunk be és milyen típusút? Mi a jobb az on-premise klaszterhez: vásároljunk néhány erős szervert, vagy használjunk fel egy tucat régi gépet a saját adatközpontunkban? És felhőben inkább nyolc egymagos, vagy két négymagos példányt válasszunk?
A kérdésekre a cikk ad választ a csapat fordításában .
A klaszter kapacitása
Általánosságban a Kubernetes klasztert egy nagy "szupercsomópontként" lehet tekinteni. A teljes számítási teljesítménye az összes alkotócsomópont teljesítményének összege.
Több módja van a kívánt klaszterkapacitás elérésének. Például szükségünk van egy klaszterre, amelynek összkapacitása 8 CPU mag és 32 GB RAM, mert az alkalmazáscsomag ennyi erőforrást igényel. Akkor telepíthetünk két 16 GB-os csomópontot, vagy négy 8 GB-os csomópontot, két négymagos processzort, vagy négy kétmagos processzort.
Itt van csak két lehetséges mód a klaszter létrehozására:
Mindkét lehetőség ugyanazt a kapacitású klasztert adja, de az alsó konfiguráción négy kisebb csomópont, míg a felső konfiguráción két nagyobb csomópont található.
Melyik opció a jobb?
A kérdés megválaszolásához nézzük meg mindkét opció előnyeit. Összefoglaltuk őket egy táblázatban.
Néhány nagy csomópont
Sok kis csomópont
Egyszerűbb a klaszter kezelése (ha on-premise)
Zökkenőmentes automatikus skálázás
Olcsóbb (ha on-premise)
Az ár alig különbözik (a felhőben)
Erőforrás-igényes alkalmazások futtatása lehetséges
Teljes körű replikáció
Az erőforrások hatékonyabban hasznosulnak (kevesebb túlfejlesztés a rendszerdémonok miatt)
Magasabb a klaszter rendelkezésre állása
Ne feledjük, hogy csak a munkacsoportokról beszélünk. A fő csomópontok számának és méretének megválasztása teljesen más téma.
Tehát részletesebben beszéljük meg a táblázat minden egyes pontját.
Az első opció: néhány nagy csomópont
A legextremistább opció egy munkacsoport az egész klaszter kapacitására. A fenti példában ez egy munkacsoport lenne 16 CPU maggal és 16 GB RAM-mal.
Előnyök
Előny #1. Egyszerűbb a kezelés
Könnyebb több gépet kezelni, mint egy teljes flottát. Gyorsabb a frissítések és javítások telepítése, könnyebb a szinkronizálás. Az abszolút számokban is kevesebb a meghibásodás.
Vegye figyelembe, hogy mindez a saját hardverére, saját szervereire vonatkozik, nem pedig a felhőbeli példányokra.
A felhőben más a helyzet. Ott a felhőszolgáltató kezeli az üzemeltetést. Így a felhőben tíz node kezelése nem sokban különbözik az egy node kezelésétől.
A forgalom irányítása és a terhelés megosztása a felhőbeli podok között : az internetről érkező forgalom a fő terheléselosztóra érkezik, amely a forgalmat egy node egy portjára irányítja (a NodePort szolgáltatás 30000-32767 közötti portot állít be minden klaszter node-on). A kube-proxy által beállított szabályok a forgalmat a nodról a podra irányítják. Így néz ki tíz pod esetén két node-on:
Plusz #2. Kevesebb költség nodonként
Egy erősebb gép drágább, de az ár növekedése nem feltétlenül lineáris. Más szóval, egy tízmagos szerver 10 GB RAM-mal általában olcsóbb, mint tíz egymagos szerver ugyanannyi RAM-mal.
De vegye figyelembe, hogy ez a szabály általában nem érvényes a felhőszolgáltatásokra. A jelenlegi árképzési modellekben a legtöbb felhőszolgáltató ára lineárisan emelkedik a kapacitás növelésével.
Így a felhőben általában nem lehet spórolni a nagyobb teljesítményű szervereken.
Plusz #3. Erőforrás-igényes alkalmazások futtatása
Néhány alkalmazásnak erős szerverekre van szüksége a klaszterben. Például, ha egy gépi tanulási rendszernek 8 GB RAM-ra van szüksége, azt nem lehet 1 GB-os node-on futtatni, csak legalább egy nagyobb munkához szükséges node mellett.
Hátrányok
Kérdés #1. Sok pod egy node-on
Ha ugyanaz a feladat kevesebb node-on történik, akkor természetesen minden node-on több pod lesz.
Ez problémát okozhat.
Az a probléma, hogy minden modul hozzájárul a konténer futtatási környezetének költségeihez (például Docker), valamint a kubelethez és a cAdvisorhoz.
Például a kubelet rendszeresen ellenőrzi a node összes konténerének élhetőségét — minél több konténer van, annál több munka hárul a kubeletre.
A CAdvisor összegyűjti a node-on található összes konténer erőforrás-használati statisztikáit, amelyeket a kubelet rendszeresen lekérdez, és az API-n keresztül biztosít. Ismételten, minél több konténer van, annál több munka hárul a cAdvisor-ra és a kubelet-re is.
Amennyiben a modulok száma megnő, az lelassíthatja a rendszert, és akár a megbízhatóságát is veszélyeztetheti.
A Kubernetes tárolójában néhányan , hogy a node-ok a Ready/NotReady státuszok között ugrálnak, mivel a kubelet rendszeres ellenőrzései a node-on lévő konténerek esetében túl sok időt vesznek igénybe.
Ezért a Kubernetes . A node teljesítményétől függően több pod-ot is futtathat egy node-on, de nehéz megjósolni, hogy lesznek-e problémák, vagy minden jól fog működni. Érdemes előre tesztelni a működést.
2. számú hátrány. A replikációs korlátozás
A túl kevés node korlátozza az alkalmazások hatékony replikációs fokát. Például, ha van egy ötre replikált magas rendelkezésre állású alkalmazás, de csak két node-od van, akkor az alkalmazás hatékony replikációs foka kétre csökken.
Az öt replikát csak két node-on lehet elosztani, és ha az egyik nem működik, az több replikát is azonnal leállít.
Ha öt vagy annál több node-od van, minden replikát külön node-on futtatnak, és egy node leállása legfeljebb egy replikát távolít el.
Így a magas rendelkezésre állás követelményei megkövetelhetik a klaszterben egy bizonyos minimális node számot.
3. számú hátrány. A leállás következményei súlyosabbak
Kis számú node mellett minden leállás súlyosabb következményekkel jár. Például, ha csak két node-od van, és az egyik meghibásodik, akkor azonnal eltűnik a modulok fele.
Természetesen a Kubernetes áthelyezi a leállt node terhelését a többi node-ra. De ha kevés van belőlük, lehet, hogy nincs elegendő szabad kapacitás. Ennek eredményeként néhány alkalmazásod nem lesz elérhető, amíg nem indítod újra a leállt node-ot.
Így minél több node van, annál kisebb a hardveres meghibásodások hatása.
4. számú hátrány. További lépések az automatikus skálázáshoz
A Kubernetes-ben a felhőinfrastruktúrához automatikus klaszterszabályozó rendszer működik, amely lehetővé teszi csomópontok automatikus hozzáadását vagy eltávolítását a jelenlegi igényeknek megfelelően. Nagy csomópontok esetén az automatikus szabályozás élesebbé és ügyetlenné válik. Például két csomópont esetén egy további csomópont hozzáadása azonnal 50%-kal növeli a klaszter kapacitását. És ezekért az erőforrásokért fizetnie kell, még ha éppen nincs is szüksége rájuk.
Így ha automatikus klaszterszabályozást tervez, akkor minél kisebbek a csomópontok, annál rugalmasabb és gazdaságosabb szabályozást kap.
Most nézzük meg a sok kis csomópont előnyeit és hátrányait.
Második lehetőség: sok kis csomópont
Ennek a megközelítésnek az előnyei lényegében az ellentétes lehetőség, azaz a few nagy csomópont hátrányaiból adódnak.
Előnyök
Előny #1. Kevesebb hiba következménye
Minél több csomópont van, annál kevesebb pod van minden csomóponton. Például, ha száz modul van tíz csomóponton, akkor minden csomóponton átlagosan tíz modul lesz.
Így ha egy csomópont leáll, csak a munkaterhelés 10%-át veszítjük el. Valószínű, hogy csak néhány replikát érint, míg az alkalmazások összességében működőképesek maradnak.
Ezenkívül a megmaradt csomópontokon valószínűleg elegendő szabad erőforrás áll rendelkezésre a leállt csomópont munkaterheléséhez, így a Kubernetes szabadon átcsoportosíthatja a podokat, és az alkalmazások viszonylag gyorsan visszatérnek a működő állapotba.
Előny #2. Jó replikáció
Ha elegendő csomópont van, a Kubernetes ütemező minden replikának különböző csomópontokat tud kijelölni. Így, ha egy csomópont hibát észlel, csak egy replika érintett, és az alkalmazás elérhető marad.
Hátrányok
Hátrány #1. Nehezebb kezelés
Sok csomópontot nehezebb kezelni. Például minden Kubernetes-csomópontnak interakcióba kell lépnie az összes többi csomóponttal, tehát a kapcsolatok száma négyzetesen nő, és ezeket mind nyomon kell követni.
A Kubernetes vezérlő managerének csomópont-ellenőrzője rendszeresen bejár minden csomópontot a klaszterben a működőképesség ellenőrzésére — minél több a csomópont, annál nagyobb a terhelés a vezérlőn.
Növekszik a terhelés az etcd adatbázison is — minden kubelet és kube-proxy hívást indít. az etcd (API-n keresztül), amely számára az etcd frissítéseket kell transzponálnia.
Általában minden munkaknot hozzáad egy extra terhelést a fő csomópontok rendszerkomponenseire.
Hivatalosan a Kubernetes támogatja a klasztereket Viszont a gyakorlatban már 500 csomópont .
A nagy számú munkacsomópont megfelelő kezeléséhez érdemes erősebb főcsomópontokat választani. Például a kube-up a főcsomópont helyes VM méretét a munkacsomópontok száma alapján. Tehát minél több munkacsomópont van, annál erősebbeknek kell lenniük a főcsomópontoknak.
Ezekre a specifikus problémákra vannak speciális fejlesztések, mint például Ez a rendszer lehetővé teszi a korlátok megkerülését és hatalmas munkacsomópontokkal rendelkező klaszterek építését.
A hátrány 2. Magasabb adminisztratív költségek.
A Kubernetes minden munkacsomóponton egy sor rendszer démonját futtat — ezek közé tartozik a konténer futtatási környezet (például Docker), kube-proxy és kubelet, beleértve a cAdvisor-t. Összességében ezek meghatározott, fix mennyiségű erőforrást fogyasztanak.
Ha sok kis csomópont van, akkor ezen csomópontok minden egyes adminisztratív költsége nagyobb. Például képzelje el, hogy egy csomópont minden rendszerdémona együtt 0,1 CPU magot és 0,1 GB memóriát használ. Ha van egy tízmagos csomópontja 10 GB memóriával, akkor a démonok a klaszter kapacitásának 1%-át fogyasztják. Ezzel szemben tíz egymagos csomóponton 1 GB memóriával a démonok a klaszter kapacitásának 10%-át fogják el.
Ezért minél kevesebb csomópont van, annál hatékonyabban használják ki az infrastruktúrát.
A hátrány 3. Erőforrások nem hatékony használata.
Kis csomópontok esetén előfordulhat, hogy a fennmaradó erőforrás-foszlányok túl kicsik ahhoz, hogy valamilyen terhelést rendeljenek hozzájuk, ezért kihasználatlanok maradnak.
Például minden pod 0,75 GB memóriát igényel. Ha van tíz csomópontja, és mindegyiken 1 GB memória van, akkor tíz podot tud futtatni — így végül minden csomóponton 0,25 GB kihasználatlan memória marad.
Ez azt jelenti, hogy a klaszter teljes memóriájának 25%-a nem hasznosul.
Egy nagy csomóponton 10 GB memóriával 13 ilyen podot tud futtatni — és csak 0,25 GB kihasználatlan fragmens marad.
Ebben az esetben csak a memória 2,5%-a pazarolódik el.
Így a nagyobb klaszterekben optimálisabban használják fel az erőforrásokat.
Több nagy klaszter vagy sok kisebb?
Tehát mi a jobb: néhány nagy klaszter a klaszterben vagy sok kicsi? Mint mindig, nincs egyértelmű válasz. Sok minden attól függ, hogy milyen típusú alkalmazásról van szó.
Például, ha az alkalmazásnak 10 GB memória szükséges, nyilvánvaló a választás a nagyobb klaszterek mellett. Ha viszont az alkalmazás tízszeres replikációt igényel a magas rendelkezésre állás érdekében, valószínűleg nem érdemes kockáztatni, és replikákat csak két klaszteren tárolni - a klaszternek legalább tíz klaszterből kell állnia.
Köztes helyzetekben válasszon az egyes lehetőségek előnyei és hátrányai alapján. Lehet, hogy egyes érvek relevánsabbak az ön helyzetében, mint mások.
Egyáltalán nem kötelező, hogy minden klaszter egyformán nagy legyen. Semmi nem akadályozza meg, hogy először azonos méretű klaszterekkel kísérletezzen, majd hozzáadjon más méretű klasztereket, kombinálva őket a klaszterben. A Kubernetes klaszter munkaklaszterei teljesen heterogének lehetnek. Tehát kipróbálhatja mindkét megközelítés előnyeit.
Nincs egyetlen recept, és minden helyzetnek megvannak a saját árnyalata, csak a termelés fogja megmutatni az igazságot.
A fordítást a felhőplatform csapata készítette. .
További információk a Kubernetesről: .
Forrás: habr.com
