A Kubernetes-fürt létrehozásakor kérdések merülhetnek fel: hány dolgozó csomópontot kell konfigurálni és milyen típusú? Mi a jobb egy helyszíni fürt számára: vásároljon több nagy teljesítményű szervert, vagy használjon egy tucat régi gépet az adatközpontjában? Jobb nyolc egymagos vagy két négymagos példányt vinni a felhőbe?
Ezekre a kérdésekre a válasz a cikkben található. a parancs fordításában .
Klaszter kapacitás
Általában a Kubernetes-fürt egy nagy "szupercsomópontnak" tekinthető. Teljes számítási teljesítménye az összes alkotó csomópont teljesítményének összege.
Számos módja van a kívánt fürtkapacitási cél elérésének. Például szükségünk van egy fürtre, amelynek teljes kapacitása 8 processzormag és 32 GB RAM, mivel egy alkalmazáskészlet sok erőforrást igényel. Ezután telepíthet két csomópontot 16 GB memóriával vagy négy csomópontot 8 GB memóriával, két négymagos processzort vagy négy kétmagos processzort.
Íme csak két lehetséges módszer a fürt létrehozására:
Mindkét lehetőség azonos kapacitású fürtöt hoz létre, de az alsó konfigurációban négy kisebb, a felső konfigurációban pedig két nagyobb csomópont található.
Melyik lehetőség jobb?
A kérdés megválaszolásához nézzük meg mindkét lehetőség előnyeit. Ezeket egy táblázatban foglaltuk össze.
Több nagy csomópont
Sok kis csomópont
Egyszerűbb fürtkezelés (ha helyszíni)
Sima automatikus skálázás
Olcsóbb (ha a helyszínen)
Az ár kicsit más (a felhőben)
Erőforrás-igényes alkalmazásokat futtathat
Teljes replikáció
Az erőforrásokat hatékonyabban használják fel (kevesebb többletköltség a rendszerdémonokon
Magasabb klaszter hibatűrés
Kérjük, vegye figyelembe, hogy csak dolgozó csomópontokró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 beszéljük meg részletesebben a táblázat egyes pontjait.
Első lehetőség: több nagy csomópont
A legszélsőségesebb lehetőség egy dolgozó csomópont a teljes fürt kapacitásához. A fenti példában ez egyetlen dolgozó csomópont lenne 16 CPU maggal és 16 GB RAM-mal.
Érvek
Plusz No. 1. Könnyebb kezelés
Könnyebb néhány gépet kezelni, mint egy teljes flottát. Gyorsabb a frissítések és javítások bevezetése, és egyszerűbb a szinkronizálás. A meghibásodások száma abszolút számokban is kevesebb.
Felhívjuk figyelmét, hogy a fentiek mindegyike az Ön hardverére, szervereire vonatkozik, nem pedig a felhőpéldányokra.
Más a helyzet a felhőben. Ott a kezelést a felhőszolgáltató végzi. Így tíz csomópont kezelése a felhőben nem sokban különbözik egy csomópont kezelésétől.
Forgalomirányítás és terheléselosztás a felhőben lévő podok között : az internetről érkező forgalom a fő terheléselosztóhoz kerül, amely az egyik csomópont portjára továbbítja a forgalmat (a NodePort szolgáltatás a 30000-32767 portot minden fürtcsomópontban állítja be). A kube-proxy által beállított szabályok átirányítják a forgalmat a csomópontból a podba. Így néz ki tíz hüvely két csomóponton:
Pro #2: Kevesebb csomópontonkénti költség
Egy erős autó drágább, de az áremelkedés nem feltétlenül lineáris. Más szóval, egy tízmagos szerver 10 GB memóriával általában olcsóbb, mint tíz egymagos szerver ugyanennyi memóriával.
De vegye figyelembe, hogy ez a szabály általában nem működik felhőszolgáltatásokban. Az összes nagyobb felhőszolgáltató jelenlegi árazási rendszerében az árak lineárisan nőnek a kapacitással.
Így a felhőben általában nem tud spórolni erősebb szervereken.
Pro #3: Erőforrás-igényes alkalmazásokat futtathat
Egyes alkalmazások nagy teljesítményű kiszolgálókat igényelnek egy fürtben. Például, ha egy gépi tanulási rendszer 8 GB memóriát igényel, akkor nem tudja futtatni 1 GB-os csomópontokon, hanem csak legalább egy nagy munkavégző csomóponttal.
Hátrányok
1. számú hátrány. Sok hüvely csomópontonként
Ha ugyanazt a feladatot kevesebb csomóponton hajtják végre, akkor természetesen mindegyiknek több podja lesz.
Ez probléma lehet.
Ennek az az oka, hogy minden modul bevezet némi többletterhelést a konténer futási környezetébe (pl. Docker), valamint a kubeletbe és a cAdvisorba.
Például egy kubelet rendszeresen megvizsgál egy csomóponton lévő összes tárolót a túlélés érdekében – minél több konténer, annál több munkát kell végeznie a kubeletnek.
A CAdvisor összegyűjti az erőforrás-használati statisztikákat a csomóponton lévő összes tárolóhoz, és a kubelet rendszeresen lekérdezi ezeket az információkat, és egy API-n keresztül biztosítja. Ismét több konténer több munkát jelent mind a cAdvisor, mind a kubelet számára.
Ha növekszik a modulok száma, az lelassíthatja a rendszert, sőt alááshatja a megbízhatóságát.
A Kubernetes adattárban néhány hogy a csomópontok a Ready/Not Ready állapotok között ugrálnak, mert a csomóponton lévő összes tároló rendszeres kubelet ellenőrzése túl sokáig tart.
Emiatt Kubernetes . A csomópont teljesítményétől függően több pod is futtatható csomópontonként, de nehéz megjósolni, hogy lesznek-e problémák, vagy minden jól fog működni. Érdemes előre tesztelni a munkát.
2. számú hátrány. A replikáció korlátozása
A túl kevés csomópont korlátozza az alkalmazás replikációjának hatékony terjedelmét. Ha például rendelkezik egy magas rendelkezésre állású alkalmazással öt replikával, de csak két csomóponttal, akkor az alkalmazás tényleges replikációs foka kettőre csökken.
Öt replikát csak két csomópont között lehet elosztani, és ha az egyik meghibásodik, egyszerre több replikát vesz le.
Ha öt vagy több csomópontja van, minden replika külön csomóponton fog futni, és egy csomópont meghibásodása legfeljebb egy replikát távolít el.
Így a magas rendelkezésre állási követelmények bizonyos minimális számú csomópontot igényelhetnek a fürtben.
3. számú hátrány. A kudarc rosszabb következményei
Kis számú csomópont esetén minden meghibásodás súlyosabb következményekkel jár. Például, ha csak két csomópontja van, és az egyik meghibásodik, akkor a modulok fele azonnal eltűnik.
Természetesen a Kubernetes áttelepíti a munkaterhelést a meghibásodott csomópontról másokra. De ha kevés van belőlük, akkor előfordulhat, hogy nincs elég szabad kapacitás. Ennek eredményeként egyes alkalmazásai nem lesznek elérhetők, amíg meg nem jeleníti a hibás csomópontot.
Így minél több csomópont, annál kisebb a hardverhibák hatása.
4. hátrány: Több automatikus skálázási lépés
A Kubernetes rendelkezik egy fürt automatikus skálázó rendszerrel a felhő-infrastruktúrához, amely lehetővé teszi a csomópontok automatikus hozzáadását vagy eltávolítását az aktuális igényektől függően. Nagyobb csomópontok esetén az automatikus skálázás hirtelenebbé és ügyetlenebbé válik. Például két csomóponton egy további csomópont hozzáadása azonnal 50%-kal növeli a fürt kapacitását. És fizetnie kell ezekért az erőforrásokért, még akkor is, ha nincs rájuk szüksége.
Így, ha automatikus fürtméretezést tervez használni, minél kisebbek a csomópontok, annál rugalmasabb és költséghatékonyabb skálázást kap.
Most nézzük meg a nagyszámú 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 alapvetően a több nagy csomóponttal ellentétes lehetőség hátrányaiból fakadnak.
Érvek
Pro #1: A meghibásodás kisebb hatása
Minél több csomópont, annál kevesebb pod minden csomóponton. Például, ha tíz csomópontonként száz modul van, akkor mindegyik csomóponton átlagosan tíz modul lesz.
Ily módon, ha az egyik csomópont meghibásodik, csak a terhelés 10%-át veszíti el. Valószínű, hogy csak kis számú replikát érint ez, és a teljes alkalmazás továbbra is működőképes marad.
Ezenkívül a fennmaradó csomópontok valószínűleg elegendő szabad erőforrással rendelkeznek a meghibásodott csomópont munkaterhelésének kezelésére, így a Kubernetes szabadon ütemezheti a podokat, és az alkalmazások viszonylag gyorsan visszatérnek működőképes állapotba.
Pro #2: Jó replikáció
Ha van elég csomópont, a Kubernetes ütemező az összes replikához különböző csomópontokat rendelhet. Így, ha egy csomópont meghibásodik, csak egy replika lesz érintett, és az alkalmazás elérhető marad.
Hátrányok
1. számú hátrány. Nehezen irányítható
Nagyszámú csomópontot nehezebb kezelni. Például minden Kubernetes csomópontnak kommunikálnia kell az összes többivel, vagyis a kapcsolatok száma négyzetesen növekszik, és ezeket a kapcsolatokat nyomon kell követni.
A Kubernetes Controller Manager csomópontvezérlője rendszeresen végigjárja a fürt összes csomópontját, hogy ellenőrizze az állapotot – minél több csomópont, annál nagyobb terhelés a vezérlőn.
Az etcd adatbázis terhelése is növekszik – minden kubelet és kube-proxy hív az etcd-hez (az API-n keresztül), amelyre az etcd-nek objektumfrissítéseket kell sugároznia.
Általában minden dolgozó csomópont további terhelést ró a fő csomópontok rendszerösszetevőire.
A Kubernetes hivatalosan támogatja a fürtöket . A gyakorlatban azonban már 500 csomópont létezik .
Nagyszámú munkavégző csomópont kezeléséhez nagyobb teljesítményű főcsomópontokat kell választania. Például a kube-up a főcsomópont megfelelő virtuálisgép-mérete a munkavégző csomópontok számától függően. Vagyis minél több dolgozó csomópont, annál termelékenyebbnek kell lennie a fő csomópontoknak.
Ezen speciális problémák megoldására speciális fejlesztések vannak, mint pl . Ez a rendszer lehetővé teszi a korlátozások megkerülését és a fürtök felépítését hatalmas számú dolgozó csomóponttal.
2. hátrány: Több rezsiköltség.
A Kubernetes minden egyes munkavégző csomóponton rendszerdémonok készletét futtatja – ezek közé tartozik a konténer futtatókörnyezete (például a Docker), a kube-proxy és a kubelet, beleértve a cAdvisort is. Együtt meghatározott mennyiségű erőforrást fogyasztanak el.
Ha sok kis csomópontja van, akkor ennek a többletnek az aránya az egyes csomópontokon nagyobb. Képzelje el például, hogy egyetlen csomóponton lévő összes rendszerdémon 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 fürt kapacitásának 1%-át fogyasztják. Másrészt tíz, 1 GB memóriával rendelkező egymagos csomóponton a démonok a fürt kapacitásának 10%-át veszik igénybe.
Így minél kevesebb csomópont, annál hatékonyabban használják az infrastruktúrát.
3. számú hátrány. Az erőforrások nem hatékony felhasználása
Kis csomópontokon előfordulhat, hogy a fennmaradó erőforrásdarabok túl kicsik ahhoz, hogy bármilyen munkaterhelést hozzárendeljenek, ezért használaton kívül maradnak.
Például minden pod 0,75 GB memóriát igényel. Ha tíz csomópontja van, mindegyik 1 GB memóriával, tíz pod futtatható, így mindegyik csomóponton 0,25 GB kihasználatlan memória marad.
Ez azt jelenti, hogy a teljes fürt memóriájának 25%-a elpazarolt.
Egy 10 GB memóriával rendelkező nagy csomóponton 13 modult futtathat – és csak egy 0,25 GB-os fel nem használt töredék marad.
Ebben az esetben a memória mindössze 2,5%-a megy kárba.
Így az erőforrásokat a nagyobb csomópontokon optimálisabban használják fel.
Több nagy csomópont vagy sok kicsi?
Szóval, melyik a jobb: néhány nagy csomópont egy fürtben vagy sok kicsi? Mint mindig, most sincs egyértelmű válasz. Sok függ az alkalmazás típusától.
Például, ha egy alkalmazás 10 GB memóriát igényel, a nagyobb csomópontok kézenfekvő választás. És ha az alkalmazás tízszeres replikációt igényel a magas rendelkezésre állás érdekében, aligha éri meg a kockázatot, hogy a replikákat csak két csomópontra helyezze el – a fürtben legalább tíz csomópontnak kell lennie.
Köztes helyzetekben válasszon az egyes lehetőségek előnyei és hátrányai alapján. Talán néhány érv relevánsabb az Ön helyzetében, mint mások.
És egyáltalán nem szükséges az összes csomópontot azonos méretűvé tenni. Semmi sem akadályozza meg, hogy először azonos méretű csomópontokkal kísérletezzen, majd más méretű csomópontokat adjon hozzájuk, és egyesítse őket egy fürtben. A Kubernetes-fürt dolgozói csomópontjai teljesen heterogének lehetnek. Tehát megpróbálhatja kombinálni a két megközelítés előnyeit.
Nincs egyetlen recept, és minden helyzetnek megvannak a maga árnyalatai, és csak a gyártás mutatja meg az igazságot.
A fordítást a felhőplatform csapata készítette .
Bővebben a Kubernetesről: .
Forrás: will.com