Minden Kubernetes-erőforráshoz kétféle követelményt konfigurálhat – kéréseket és korlátokat. Az első a tároló vagy pod futtatásához szükséges ingyenes csomóponti erőforrások elérhetőségének minimális követelményeit írja le, a második szigorúan korlátozza a tároló számára elérhető erőforrásokat.
Amikor a Kubernetes besorolásokat ütemez, nagyon fontos, hogy a tárolók elegendő erőforrással rendelkezzenek a megfelelő működéshez. Ha egy nagyméretű alkalmazást tervez üzembe helyezni egy erőforrás-korlátozott csomóponton, akkor lehetséges, hogy az nem fog futni, mert a csomópontban kevés a memória, vagy kifogy a CPU-teljesítmény. Ebben a cikkben megvizsgáljuk, hogyan oldhatja meg a számítási teljesítmény hiányát az erőforráskérések és -korlátok segítségével.
A kérések és korlátok olyan mechanizmusok, amelyeket a Kubernetes az erőforrások, például a CPU és a memória kezelésére használ. A kérések biztosítják, hogy a tároló megkapja a kért erőforrást. Ha egy tároló erőforrást kér, a Kubernetes csak olyan csomópontra ütemezi, amelyik képes biztosítani. Korlátozza a szabályozást, hogy a tároló által kért erőforrások soha ne lépjenek túl egy bizonyos értéket.
Egy konténer csak egy bizonyos határig tudja növelni a számítási teljesítményét, utána korlátozott lesz. Lássuk, hogyan működik. Tehát kétféle erőforrás létezik - processzor és memória. A Kubernetes ütemező ezekre az erőforrásokra vonatkozó adatokat használja fel, hogy kitalálja, hol futtassa a podokat. A pod tipikus erőforrás-specifikációja így néz ki.
A podban minden konténer beállíthatja a saját lekérdezéseit és korlátait, mindez additív. A processzor erőforrásait millicore-ban határozzák meg. Ha a konténernek két teljes magra van szüksége a működéshez, állítsa be az értéket 2000 m-re. Ha a konténernek csak a mag 1/4-ének kell a teljesítménye, akkor az érték 250 m lesz. Ne feledje, hogy ha a legnagyobb csomópont magjainál nagyobb CPU-erőforrás értéket rendel hozzá, akkor a pod egyáltalán nem lesz ütemezve. Hasonló helyzet fordul elő, ha van egy Pod, amelyhez négy magra van szükség, és a Kubernetes-fürt csak két fő virtuális gépből áll.
Hacsak az alkalmazást nem kifejezetten több mag kihasználására tervezték (olyan programok jutnak eszünkbe, mint az összetett tudományos számítástechnika és az adatbázis-műveletek), akkor a legjobb gyakorlat az, ha a CPU-kéréseket 1-re vagy alacsonyabbra állítja, majd több replikát futtat a méretezhetőség érdekében. Ez a megoldás nagyobb rugalmasságot és megbízhatóságot biztosít a rendszernek.
Ha a CPU korlátairól van szó, a dolgok érdekesebbé válnak, mivel tömöríthető erőforrásnak tekintik. Ha az alkalmazás elkezdi megközelíteni a processzorteljesítmény-korlátot, a Kubernetes lelassítja a tárolót a CPU-szabályozás segítségével – csökkentve a processzor frekvenciáját. Ez azt jelenti, hogy a CPU-t mesterségesen leszabályozzák, ami potenciálisan rosszabb teljesítményt biztosít az alkalmazásnak, de a folyamat nem kerül leállításra vagy kivonásra.
A memória erőforrásait bájtokban határozzák meg. A beállítások értéke általában mebibájtban, Mib-ben van mérve, de tetszőleges értéket beállíthat, bájttól petabájtig. Itt is ugyanaz a helyzet, mint a CPU-nál – ha a csomópontokon lévő memória mennyiségénél nagyobb memóriamennyiséget kér, akkor az adott pod nem lesz ütemezve a végrehajtásra. De a CPU-erőforrásokkal ellentétben a memória nincs tömörítve, mert nincs mód a használat korlátozására. Ezért a tároló végrehajtása leáll, amint túllépi a számára lefoglalt memóriát.
Fontos megjegyezni, hogy nem konfigurálhat olyan kéréseket, amelyek meghaladják a csomópontok által biztosított erőforrásokat. A GKE virtuális gépek megosztott erőforrás-specifikációi a videó alatti linkeken találhatók.
Egy ideális világban a tároló alapértelmezett beállításai elegendőek lennének a munkafolyamatok zökkenőmentes működéséhez. De a való világ nem ilyen, az emberek könnyen elfelejthetik az erőforrások felhasználásának konfigurálását, vagy a hackerek olyan kéréseket és korlátozásokat állítanak fel, amelyek meghaladják az infrastruktúra valós képességeit. Az ilyen forgatókönyvek előfordulásának megakadályozása érdekében konfigurálhatja a ResourceQuota és LimitRange erőforráskvótákat.
A névtér létrehozása után kvóták segítségével blokkolható. Például, ha rendelkezik a prod és a dev névterekkel, akkor a minta az, hogy egyáltalán nincsenek gyártási kvóták, és nagyon szigorú fejlesztési kvóták. Ez lehetővé teszi, hogy a prod a forgalom hirtelen megugrása esetén átvegye a teljes rendelkezésre álló erőforrást, teljesen blokkolva a fejlesztőt.
Az erőforráskvóta így nézhet ki. Ebben a példában 4 szakasz van – ez a kód 4 alsó sora.
Nézzük meg mindegyiket. A Requests.cpu a kombinált CPU-kérések maximális száma, amelyek a névtér összes tárolójából származhatnak. Ebben a példában lehet 50 konténer 10 méteres kéréssel, öt konténer 100 méteres kéréssel, vagy csak egy konténer 500 méteres kéréssel. Mindaddig, amíg egy adott névtér összes requests.cpu-jának száma kevesebb, mint 500 m, addig minden rendben lesz.
Memóriaigényelt kérések.memory a kombinált memóriakérelmek maximális mennyisége, amellyel a névtérben lévő összes tároló rendelkezhet. Az előző esethez hasonlóan itt is rendelkezhet 50 2 mib tárolóval, öt 20 mib tárolóval vagy egyetlen 100 mib tárolóval, amíg a névtérben kért memória teljes mennyisége kevesebb, mint 100 mebibyte.
A Limits.cpu az a maximális kombinált processzorteljesítmény, amelyet a névtérben lévő összes tároló használhat. Ezt tekinthetjük a processzor teljesítményigényének határának.
Végül a limits.memory a megosztott memória maximális mennyisége, amelyet a névtérben lévő összes tároló használhat. Ez az összes memóriakérelem korlátja.
Tehát alapértelmezés szerint a Kubernetes-fürt tárolói korlátlan számítási erőforrással futnak. Az erőforráskvóták segítségével a fürtrendszergazdák korlátozhatják az erőforrás-felhasználást és az erőforrás-létrehozást a névtér alapján. Egy névtérben egy pod vagy tároló annyi CPU-teljesítményt és memóriát fogyaszthat, amennyit a névtér erőforráskvóta határoz meg. Aggodalomra ad okot azonban, hogy egyetlen tok vagy konténer monopolizálhatja az összes rendelkezésre álló erőforrást. Ennek a helyzetnek a megelőzése érdekében egy korlát tartományt használnak – egy házirendet, amely korlátozza az erőforrások (a sorba rendezések vagy tárolók) elosztását a névtérben.
A határérték tartomány olyan korlátozásokat tartalmaz, amelyek:
- Biztosítani kell a számítási erőforrások minimális és maximális kihasználását a névtér minden moduljához vagy tárolójához;
- a minimális és maximális Starage Request tárolási kérelmek érvényesítése minden egyes PersistentVolumeClaim esetén a névtérben;
- kapcsolat érvényesítése egy névtérben lévő erőforrás kérelme és korlátja között;
- állítsa be az alapértelmezett kéréseket/korlátokat a számítási erőforrásokhoz a névtérben, és futás közben automatikusan beillessze őket a tárolókba.
Így létrehozhat egy határtartományt a névterében. A kvótától eltérően, amely a teljes névtérre vonatkozik, a Limit Range az egyes tárolókhoz használatos. Ez megakadályozhatja, hogy a felhasználók nagyon apró vagy éppen ellenkezőleg, gigantikus konténereket hozzanak létre a névtéren belül. A Limit Range így nézhet ki.
Az előző esethez hasonlóan itt is 4 szakasz különíthető el. Nézzük meg mindegyiket.
Az alapértelmezett szakasz beállítja a podban lévő tároló alapértelmezett korlátait. Ha ezeket az értékeket a szélső tartományra állítja, akkor minden olyan tároló, amelyhez ezek az értékek nincsenek kifejezetten beállítva, az alapértelmezett értékeket fogják követni.
Az alapértelmezett kérelem szakasz defaultRequest konfigurálja a podban lévő tároló alapértelmezett kéréseit. Ismét, ha ezeket az értékeket a szélső tartományra állítja, akkor minden olyan tároló, amely nem állítja be kifejezetten ezeket a beállításokat, alapértelmezés szerint ezeket az értékeket fogja használni.
A max szakasz meghatározza a podban lévő tárolóhoz beállítható maximális korlátokat. Az alapértelmezett szakasz értékei és a tárolókorlátok nem állíthatók be e határérték fölé. Fontos megjegyezni, hogy ha az érték max-ra van állítva, és nincs alapértelmezett szakasz, akkor a maximális érték lesz az alapértelmezett érték.
A min szakasz megadja a minimális kéréseket, amelyek egy podban lévő tárolóhoz beállíthatók. Az alapértelmezett szakasz értékei és a tároló lekérdezései azonban nem állíthatók e határérték alá.
Ismét fontos megjegyezni, hogy ha ez az érték be van állítva, az alapértelmezett nem, akkor a minimális érték lesz az alapértelmezett prompt.
Ezeket az erőforrás-kérelmeket végül a Kubernetes ütemező használja a munkaterhelések végrehajtására. A konténerek helyes konfigurálásához nagyon fontos megérteni, hogyan működik. Tegyük fel, hogy több sorba rendezést szeretne futtatni a fürtben. Feltételezve, hogy a pod-specifikációk érvényesek, a Kubernetes ütemezése körmérkőzéses kiegyensúlyozást használ a munkaterhelés futtatásához szükséges csomópont kiválasztásához.
A Kubernetes ellenőrzi, hogy az 1. csomópont rendelkezik-e elegendő erőforrással a pod-tárolóktól érkező kérések teljesítéséhez, és ha nem, akkor továbblép a következő csomópontra. Ha a rendszer egyik csomópontja sem tudja kielégíteni a kéréseket, a podok Függő állapotba kerülnek. A Google Kubernetes motorfunkcióinak, például a csomópontok automatikus skálázásának használatával a GKE automatikusan észleli a várakozási állapotot, és több további csomópontot is létrehozhat.
Ha ezt követően elfogy a csomópont kapacitása, az automatikus skálázás csökkenti a csomópontok számát, így pénzt takarít meg. Ez az oka annak, hogy a Kubernetes kérések alapján ütemezi a podkat. A korlát azonban magasabb lehet, mint a kérések, és bizonyos esetekben a csomópont valóban kifogyhat az erőforrásokból. Ezt az állapotot túlvállalási állapotnak nevezzük.
Ahogy mondtam, ha a CPU-ról van szó, a Kubernetes korlátozni fogja a podokat. Minden egyes pod annyit kap, amennyit kért, de ha nem éri el a korlátot, akkor a szabályozás elkezdődik.
Ami a memória-erőforrásokat illeti, a Kubernetes kénytelen dönteni arról, hogy mely podokat törölje, és melyeket tartsa meg, amíg fel nem szabadítja a rendszer erőforrásait, különben az egész rendszer összeomlik.
Képzeljünk el egy forgatókönyvet, amikor egy gép memóriája kifogy – hogyan kezelné ezt a Kubernetes?
A Kubernetes olyan podokat fog keresni, amelyek több erőforrást használnak, mint amennyit kértek. Tehát ha a tárolóinak egyáltalán nincs kérése, az azt jelenti, hogy alapértelmezés szerint többet használnak, mint amennyit kértek, egyszerűen azért, mert egyáltalán nem kértek semmit! Az ilyen konténerek a leállítás első számú jelöltjévé válnak. A következő jelöltek azok a konténerek, amelyek minden kérésüket teljesítették, de még mindig a maximális korlát alatt vannak.
Tehát ha a Kubernetes több olyan sorba rendezést talál, amely túllépte a kérési paramétereit, akkor prioritás szerint rendezi őket, majd eltávolítja a legalacsonyabb prioritású sorba rendezéseket. Ha minden podnak azonos prioritása van, akkor a Kubernetes leállítja azokat a sorba rendezéseket, amelyek nagyobb mértékben haladják meg a kéréseiket, mint a többi pod.
Nagyon ritka esetekben a Kubernetes megszakíthatja azokat a podkat, amelyek még mindig a kérelmeik hatókörén belül vannak. Ez akkor fordulhat elő, ha a kritikus rendszerelemek, például a Kubelet-ügynök vagy a Docker több erőforrást fogyasztanak, mint amennyit számukra fenntartottak.
Tehát a kisvállalatok korai szakaszában a Kubernetes-fürt jól működhet erőforráskérések és -korlátozások beállítása nélkül, de ahogy a csapatok és a projektek mérete növekedni kezd, fennáll a veszélye, hogy problémákba ütközik ezen a területen. Lekérdezések és kényszerek hozzáadása a modulokhoz és névterekhez nagyon kevés extra erőfeszítést igényel, és sok gondot megtakaríthat.
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com