A Kubernetes teljes elsajátításához ismernie kell a fürterőforrások méretezésének különböző módjait: by , ez a Kubernetes egyik fő feladata. Magas szintű áttekintést adtunk a vízszintes és függőleges automatikus skálázási és fürtméretezési mechanizmusokról, valamint javaslatokat adtunk azok hatékony használatára.
cikk az automatikus skálázást megvalósító csapat fordítása .
Miért fontos a méretezésre gondolni?
- eszköz az erőforrás-kezeléshez és a hangszereléshez. Természetesen jó trükközni a pod-ok telepítésének, figyelésének és kezelésének nagyszerű funkcióival (a pod olyan konténerek csoportja, amelyeket kérésre indítanak el).
Érdemes azonban elgondolkodni a következő kérdéseken is:
- Hogyan lehet skálázni a modulokat és az alkalmazásokat?
- Hogyan lehet a konténereket működőképesnek és hatékonynak tartani?
- Hogyan reagáljunk a kód és a felhasználói terhelés állandó változásaira?
A Kubernetes-fürtök konfigurálása az erőforrások és a teljesítmény egyensúlyba hozása kihívást jelenthet, és szakértői ismereteket igényel a Kubernetes belső működéséről. Alkalmazásának vagy szolgáltatásainak terhelése a nap folyamán vagy akár egy órán keresztül is ingadozhat, ezért a kiegyensúlyozást a legjobb folyamatos folyamatnak tekinteni.
Kubernetes automatikus skálázási szintek
A hatékony automatikus skálázáshoz két szint közötti koordináció szükséges:
- Pod-szint, beleértve a vízszintes (Horizontal Pod Autoscaler, HPA) és a függőleges autoscaler (Vertical Pod Autoscaler, VPA). Ezzel méretezheti a tárolóihoz rendelkezésre álló erőforrásokat.
- Fürtszint, amelyet a Cluster Autoscaler (CA) kezel, amely növeli vagy csökkenti a fürtön belüli csomópontok számát.
Horizontal Autoscaler (HPA) modul
Ahogy a neve is sugallja, a HPA skálázza a pod-replikák számát. A legtöbb devop CPU- és memóriaterhelést használ triggerként a replikák számának megváltoztatásához. Ez alapján azonban lehet méretezni a rendszert , őket vagy .
Magas szintű HPA működési diagram:
- A HPA 30 másodperces alapértelmezett időközönként folyamatosan ellenőrzi a telepítés során megadott metrikus értékeket.
- A HPA megkísérli növelni a modulok számát, ha eléri a megadott küszöböt.
- A HPA frissíti a replikák számát a telepítési/replikációs vezérlőn belül.
- A telepítési/replikációs vezérlő ezután telepíti a szükséges további modulokat.
A HPA elindítja a modul üzembe helyezési folyamatát egy metrikus küszöb elérésekor
HPA használatakor vegye figyelembe a következőket:
- Az alapértelmezett HPA-ellenőrzési időköz 30 másodperc. A zászló határozza meg horizontal-pod-autoscaler-sync-period a kontroller menedzserben.
- Az alapértelmezett relatív hiba 10%.
- A modulok számának legutóbbi növelése után a HPA arra számít, hogy a mutatók három percen belül stabilizálódnak. Ezt az intervallumot a zászló határozza meg horizontális-pod-autoscaler-upscale-delay.
- A modulok számának utolsó csökkentése után a HPA öt percet vár a stabilizálásra. Ezt az intervallumot a zászló határozza meg horizontal-pod-autoscaler-downscale-delay.
- A HPA a replikációs vezérlők helyett a telepítési objektumokkal működik a legjobban. A vízszintes automatikus skálázás nem kompatibilis a folyamatos frissítéssel, amely közvetlenül manipulálja a replikációs vezérlőket. A telepítés során a replikák száma közvetlenül függ a telepítési objektumoktól.
A hüvelyek függőleges automatikus skálázása
A függőleges automatikus skálázás (VPA) több (vagy kevesebb) CPU-időt vagy memóriát rendel a meglévő podokhoz. Alkalmas állapottartó vagy állapot nélküli podokhoz, de főleg állapotalapú szolgáltatásokhoz. Használhatja azonban a VPA-t állapot nélküli modulokhoz is, ha automatikusan módosítania kell az eredetileg lefoglalt erőforrások mennyiségét.
A VPA az OOM (out of memory) eseményekre is válaszol. A CPU-idő és a memória megváltoztatásához újra kell indítani a podokat. Újraindításkor az VPA tiszteletben tartja az allokációs költségvetést () a minimálisan szükséges modulszám garantálása érdekében.
Minden modulhoz beállíthatja a minimális és maximális erőforrást. Így a lefoglalt memória maximális mennyiségét 8 GB-ra korlátozhatja. Ez akkor hasznos, ha az aktuális csomópontok biztosan nem tudnak 8 GB-nál több memóriát lefoglalni tárolónként. A részletes specifikációkat és a működési mechanizmust a .
Ezen kívül a VPA-nak van egy érdekes ajánló funkciója (VPA Recommender). Figyeli az összes modul erőforrás-használatát és OOM eseményeit, hogy új memória- és CPU-időértékeket javasoljon egy intelligens algoritmus alapján, amely a múltbeli metrikákon alapul. Van egy API is, amely egy pod-leírót vesz fel, és a javasolt erőforrásértékeket adja vissza.
Érdemes megjegyezni, hogy a VPA Recommender nem követi nyomon az erőforrás-korlátot. Ez azt eredményezheti, hogy a modul monopolizálja az erőforrásokat a csomópontokon belül. A hatalmas memória- vagy CPU-felhasználás elkerülése érdekében jobb a névtér szintjén beállítani a korlátot.
Magas szintű VPA működési séma:
- A VPA folyamatosan ellenőrzi a telepítés során megadott metrikus értékeket, alapértelmezett 10 másodperces időközönként.
- Ha eléri a megadott küszöbértéket, a VPA megpróbálja módosítani az erőforrások lefoglalt mennyiségét.
- A VPA frissíti az erőforrások számát a telepítési/replikációs vezérlőn belül.
- A modulok újraindításakor minden új erőforrás alkalmazásra kerül a létrehozott példányokra.
A VPA hozzáadja a szükséges mennyiségű erőforrást
Kérjük, tartsa szem előtt a következő pontokat a VPA használatakor:
- A méretezéshez a pod kötelező újraindítása szükséges. Erre azért van szükség, hogy elkerüljük a változtatások utáni instabil működést. A megbízhatóság érdekében a modulokat újraindítják, és az újonnan lefoglalt erőforrások alapján szétosztják a csomópontok között.
- A VPA és a HPA még nem kompatibilis egymással, és nem futhat ugyanazon a podokon. Ha mindkét skálázási mechanizmust ugyanabban a fürtben használja, győződjön meg arról, hogy beállításai megakadályozzák, hogy ugyanazokon az objektumokon aktiválódjanak.
- A VPA csak a múltbeli és jelenlegi használat alapján hangolja az erőforrásokra vonatkozó tárolókéréseket. Nem határoz meg erőforrás-használati korlátokat. Problémák adódhatnak azzal, hogy az alkalmazások nem működnek megfelelően, és egyre több erőforrást kezdenek átvenni, ez ahhoz vezet, hogy a Kubernetes kikapcsolja ezt a pod.
- A VPA még a fejlesztés korai szakaszában van. Készüljön fel arra, hogy a rendszer a közeljövőben változásokon megy keresztül. Olvashatsz róla и . Így a tervek között szerepel a VPA és a HPA közös működtetése, valamint a modulok telepítése, valamint a hozzájuk tartozó vertikális automatikus skálázási politika (például speciális „VPA szükséges” címke).
Kubernetes-fürt automatikus skálázása
A Cluster Autoscaler (CA) módosítja a csomópontok számát a várakozó sorok száma alapján. A rendszer időszakonként ellenőrzi a függőben lévő modulokat – és növeli a fürt méretét, ha több erőforrásra van szükség, és ha a fürt nem lépi túl a megállapított korlátokat. A CA kommunikál a felhőszolgáltatóval, további csomópontokat kér tőle, vagy tétleneket bocsát ki. A CA első általánosan elérhető verziója a Kubernetes 1.8-ban jelent meg.
Az SA működésének magas szintű sémája:
- A CA 10 másodperces alapértelmezett időközönként ellenőrzi a függőben lévő modulokat.
- Ha egy vagy több pod készenléti állapotban van, mert a fürt nem rendelkezik elegendő erőforrással a lefoglalásukhoz, akkor megpróbál egy vagy több további csomópontot kiépíteni.
- Amikor a felhőszolgáltató lefoglalja a szükséges csomópontot, csatlakozik a fürthöz, és készen áll a pod-ok kiszolgálására.
- A Kubernetes ütemező függőben lévő sorba rendezéseket oszt el egy új csomópontnak. Ha ezt követően néhány modul továbbra is várakozó állapotban marad, a folyamat megismétlődik, és új csomópontok kerülnek a fürtbe.
A fürtcsomópontok automatikus kiépítése a felhőben
CA használatakor vegye figyelembe a következőket:
- A CA biztosítja, hogy a fürt összes podjának legyen helye a futáshoz, függetlenül a CPU terhelésétől. Azt is megpróbálja biztosítani, hogy ne legyenek felesleges csomópontok a fürtben.
- A CA körülbelül 30 másodperc után regisztrálja a méretezés szükségességét.
- Amint egy csomópontra már nincs szükség, a CA alapértelmezés szerint 10 percet vár a rendszer méretezése előtt.
- Az automatikus skálázási rendszer a bővítők fogalmát tartalmazza. Ezek különböző stratégiák a csomópontok egy csoportjának kiválasztására, amelyekhez új csomópontok kerülnek hozzáadásra.
- Felelősségteljesen használja a lehetőséget cluster-autoscaler.kubernetes.io/safe-to-evict (true). Ha sok podot telepít, vagy ha sok belőlük szétszórva van az összes csomóponton, akkor nagyrészt elveszíti a fürt méretezésének képességét.
- használat hogy megakadályozza a pod-ok törlését, ami az alkalmazás egyes részei teljes meghibásodását okozhatja.
Hogyan lépnek kapcsolatba egymással a Kubernetes autoscalerek
A tökéletes harmónia érdekében az automatikus skálázást a pod (HPA/VPA) és a fürt szintjén egyaránt alkalmazni kell. Viszonylag egyszerűen kommunikálnak egymással:
- A HPA-k vagy VPA-k frissítik a meglévő pod-replikákat vagy erőforrásokat.
- Ha nincs elég csomópont a tervezett méretezéshez, a CA észreveszi a várakozó állapotú podok jelenlétét.
- A CA új csomópontokat foglal le.
- A modulok az új csomópontokhoz kerülnek kiosztásra.
Együttműködő Kubernetes-skálás rendszer
Gyakori hibák a Kubernetes automatikus skálázásban
Számos gyakori probléma merül fel, amelyekbe a devopok ütköznek, amikor megpróbálják megvalósítani az automatikus skálázást.
A HPA és a VPA a mérőszámoktól és néhány előzményadattól függ. Ha nem allokál elegendő erőforrást, a modulok minimálisra csökkennek, és nem lesznek képesek mérőszámokat generálni. Ebben az esetben az automatikus skálázás soha nem fog megtörténni.
Maga a méretezési művelet időérzékeny. Azt akarjuk, hogy a modulok és a fürt gyorsan skálázódjon – még mielőtt a felhasználók bármiféle problémát vagy meghibásodást észlelnének. Ezért figyelembe kell venni a hüvelyek és a fürt átlagos méretezési idejét.
Ideális forgatókönyv – 4 perc:
- 30 másodperc. Célmutatók frissítése: 30–60 másodperc.
- 30 másodperc. A HPA ellenőrzi a metrikus értékeket: 30 másodperc.
- Kevesebb, mint 2 másodperc. A modulok létrejönnek, és várakozási állapotba kerülnek: 1 másodperc.
- Kevesebb, mint 2 másodperc. A CA látja a várakozó modulokat, és hívásokat küld a kiépítési csomópontoknak: 1 másodperc.
- 3 perc. A felhőszolgáltató csomópontokat oszt ki. A K8-ak megvárják, amíg elkészülnek: legfeljebb 10 percig (több tényezőtől függően).
A legrosszabb (reálisabb) forgatókönyv – 12 perc:
- 30 másodperc. Frissítse a célmutatókat.
- 30 másodperc. A HPA ellenőrzi a metrikus értékeket.
- Kevesebb, mint 2 másodperc. A pod-ok létrejönnek, és készenléti állapotba kerülnek.
- Kevesebb, mint 2 másodperc. A CA látja a várakozó modulokat, és hívásokat kezdeményez a csomópontok kiépítéséhez.
- 10 perc. A felhőszolgáltató csomópontokat oszt ki. A K8-ak megvárják, amíg készen állnak. A várakozási idő számos tényezőtől függ, például a szállítói késleltetéstől, az operációs rendszer késleltetésétől és a támogatási eszközöktől.
Ne keverje össze a felhőszolgáltatók méretezési mechanizmusait a CA-val. Ez utóbbi egy Kubernetes-fürtben, míg a felhőszolgáltató motor csomóponti elosztási alapon működik. Nem tudja, mi történik a hüvelyekkel vagy az alkalmazással. Ezek a rendszerek párhuzamosan működnek.
A méretezés kezelése a Kubernetesben
- A Kubernetes egy erőforrás-kezelő és hangszerelő eszköz. A pod-ok és fürterőforrások kezelésével kapcsolatos műveletek kulcsfontosságú mérföldkövet jelentenek a Kubernetes elsajátításában.
- Ismerje meg a pod skálázhatóság logikáját a HPA és a VPA figyelembevételével.
- A CA-t csak akkor szabad használni, ha jól ismeri a hüvelyek és tárolók igényeit.
- A fürt optimális konfigurálásához meg kell értenie, hogyan működnek együtt a különböző skálázási rendszerek.
- A méretezési idő becslésekor tartsa szem előtt a legrosszabb és a legjobb eset forgatókönyvét.
Forrás: will.com