Minden Kubernetes erőforrás esetén kétféle követelmény állítható be: a Requests és a Limits. Az első a csomópont szabad erőforrásainak minimális követelményeit határozza meg, amelyek szükségesek a konténer vagy pod elindításához, a második pedig szigorúan korlátozza a konténer rendelkezésére álló erőforrásokat.
Amikor a Kubernetes podot tervez, rendkívül fontos, hogy a konténerek elegendő erőforrással rendelkezzenek a megfelelő működéshez. Ha nagy alkalmazást szeretne telepíteni egy erőforrás-korlátozott csomóponton, valószínű, hogy nem fog megfelelően működni, mert a csomópont memória kifogy, vagy nem áll rendelkezésre elegendő processzorteljesítmény. Ebben a cikkben megvizsgáljuk, hogyan oldhatók meg az informatikai kapacitások hiányosságai a forrásigények és a korlátozások segítségével.
A Requests és a Limits mechanizmusok, amelyeket a Kubernetes használ olyan erőforrások kezelésére, mint például a processzor és a memória. A Requests az, aminek következtében a konténer garantáltan megkapja a kért erőforrást. Ha a konténer erőforrást kér, akkor a Kubernetes csak azon a csomóponton tervezi azt, amelyik képes azt biztosítani. A Limits korlátozza, hogy a konténer által kért erőforrások soha ne haladják meg a meghatározott értéket.
A konténer csak egy bizonyos határig növelheti a számítási kapacitásait, ennélfogva korlátozás alá esik. Nézzük meg, hogyan működik ez. Tehát kétféle erőforrás létezik: processzor és memória. A Kubernetes ütemező felhasználja ezeket az erőforrásokkal kapcsolatos adatokat annak meghatározására, hogy hol indítsa a podjait. A tipikus pod erőforrás-specifikáció így néz ki.
Minden podban található konténer saját kéréseket és korlátokat állíthat be, ezek összeadódnak. A CPU-erőforrásokat milikronokban határozzák meg. Ha a konténered futtatásához két teljes magra van szükséged, akkor a 2000m értéket kell beállítanod. Ha viszont csak ¼ magnyi teljesítményre van szüksége a konténernek, akkor az érték 250m lesz. Ne feledd, ha a CPU-erőforrások értékét a legnagyobb csomópont magjainak száma fölé állítod, a podod elindítását egyáltalán nem ütemezik. Hasonló helyzet áll fenn, ha van egy pod, amelynek négy magra van szüksége, míg a Kubernetes klasztered csupán két alapvető virtuális gépből áll.
Ha az alkalmazásod nem kifejezetten arra lett kifejlesztve, hogy kihasználja a több mag előnyeit (ide tartoznak például a bonyolult tudományos számítások és az adatbázis-műveletek), akkor a legjobb gyakorlat az, ha a CPU kérdéseket 1-re vagy annál alacsonyabbra állítod be, majd több replikát futtatsz a skálázhatóság érdekében. Ez a megoldás nagyobb rugalmasságot és megbízhatóságot biztosít a rendszer számára.
A CPU-korlátok esetében a helyzet egyre érdekesebbé válik, mivel ez egy compresszálható erőforrásnak számít. Ha az alkalmazásod a CPU teljesítménykorlátjához közelít, a Kubernetes elkezdi lelassítani a konténert CPU-throttling segítségével - a processzor órajelének csökkentésével. Ez azt jelenti, hogy a processzor mesterségesen korlátozva lesz, ami potenciálisan rosszabb teljesítményt nyújt az alkalmazás számára, azonban a folyamat nem áll le vagy nem tolakodnak ki.
A memória-erőforrásokat byte-okban határozzák meg. Általában az érték a beállításokban mebibájtban (MiB) mérhető, de bármilyen értéket megadhatsz, a byte-któl a petabájtokig. Itt hasonló helyzet áll fenn, mint a CPU esetében - ha túlléped a csomópontjaidon rendelkezésre álló memória mennyiségét, akkor ennek a podnak a végrehajtása nem lesz ütemezhető. De a CPU-erőforrásokkal ellentétben a memória nem compresszálható, mivel nincs mód a felhasználásának korlátozására. Ezért a konténer végrehajtása megáll, amint túllép a számára kijelölt memória határon.
Fontos megjegyezni, hogy nem állíthat be olyan kéréseket, amelyek meghaladják azokat az erőforrásokat, amelyeket a csomópontjai tudnak biztosítani. A GKE virtuális gépeinek közös erőforrásainak jellemzőit az alábbi videó alatt található linkeken találja.
Ideális esetben az alapértelmezett konténerbeállítások elegendőek lesznek a munkafolyamatok zökkenőmentes lebonyolításához. De a valóság nem ilyen, az emberek könnyen elfelejthetik beállítani az erőforrások használatát, vagy a hackerek olyan kéréseket és korlátozásokat állíthatnak be, amelyek meghaladják az infrastruktúra valódi képességeit. Az ilyen szcenáriók elkerülése érdekében beállíthatja a ResourceQuota erőforrásköltségvetéseket és a LimitRange korlátozásait.
A névtér létrehozása után blokkolhatók költségvetésekkel. Például, ha van prod és dev névtér, lehet egy szabvány, amelyben a termelési költségvetés teljesen hiányzik, míg a fejlesztési költségvetések nagyon szigorúak. Ez lehetővé teszi, hogy a prod hirtelen forgalomnövekedés esetén elvegye az összes elérhető erőforrást, teljesen blokkolva a dev-et.
Aresor-kvóta így nézhet ki. Ebben a példában 4 szakasz van – ez 4 alsó sor kód.
Nézzük meg mindegyiket. A Requests.cpu a maximális kombinált processzorerőforrás-kérések száma, amely a névtér összes konténeréből származhat. Ebben a példában lehet 50 konténer, amelyek 10m kéréseket küldenek, öt konténer 100m kérésekkel, vagy egyszerűen egy konténer 500m kéréssel. Addig, amíg a névtér összes Requests.cpu értéke kevesebb, mint 500m, minden rendben lesz.
A kért memória requests.memory a maximális kombinált memóriaigény, amelyet a névtér összes konténere használhat. Mint az előző esetben, lehet 50 konténer 2 MiB-ra, öt konténer 20 MiB-ra, vagy egyetlen konténer 100 MiB-ra, amíg a névtér összes kért memóriája kevesebb mint 100 mebibájt.
A Limits.cpu a maximális kombinált processzorerőforrás-érték, amelyet a névtér összes konténere használhat. Ezt tekintheti a processzorerőforrások kéréseinek határának.
Végre, limits.memory – a maximális összmemória-mennyiség, amelyet az összes konténer felhasználhat a névtérben. Ez a memóriaigények összesített korlátozása.
Tehát alapértelmezés szerint a Kubernetes klaszterben lévő konténerek korlátlan számítási erőforrásokkal működnek. Az erőforrás-kvóták segítségével a klaszter adminisztrátorai korlátozhatják az erőforrás-felhasználást és létrehozást névterek alapján. A névtérben a pod vagy konténer annyi CPU- és memóriaerőforrást fogyaszthat, amennyi az erőforrás-kvótákban meg van határozva. Azonban fennáll a veszélye, hogy egy pod vagy konténer monopolizálja az összes rendelkezésre álló erőforrást. Ennek megakadályozására a limit Range használatos – a névtérben lévő erőforrások elosztásának korlátozását szolgáló politika (podokhoz vagy konténerekhez).
A limit Range korlátozásokat biztosít, amelyek képesek:
- biztosítani a számítási erőforrások minimális és maximális használatát minden modul vagy konténer számára a névtérben;
- kényszeríteni a minimális és maximális Storage Request tárolási igényt minden PersistentVolumeClaim számára a névtérben;
- kényszeríteni a Request és Limit erőforrások közötti arányt a névtérben;
- alapértelmezett Requests/Limits beállításokat adni a számítási erőforrásokhoz a névtérben, és automatikusan bevezetni őket a konténerekbe futás közben.
Így létrehozhat limit Range-t a névtérben. Ellentétben a kvótával, amely az egész névtérre kiterjed, a Limit Range különálló konténerekre vonatkozik. Ez megakadályozhatja, hogy a felhasználók ilyen apró vagy éppen ellenkezőleg, óriási konténereket hozzanak létre a névtérben. A limit Range így nézhet ki.
Ahogyan az előző esetben, itt is kiemelhetők 4 rész. Tekintsük meg mindegyiket.
A default részben alapértelmezett korlátozások vannak beállítva a podban lévő konténer számára. Ha ezeket az értékeket a limit Range-ben meghatározza, akkor bármilyen konténer, amelynek ezek az értékek nincsenek kifejezetten megadva, az alapértelmezett értékek szerint fog irányulni.
A defaultRequest szakaszban a podban található konténer alapértelmezett kérései vannak beállítva. Ismét, ha ezeket az értékeket a határokon belül állítja be, akkor bármely konténer, amelyhez ezek az értékek kifejezetten nincsenek megadva, az alapértelmezett értékeket fogja használni.
A max szakaszban a podban található konténer számára beállítható maximális korlátok találhatók. Az alapértelmezett szakaszban található értékek és a konténer korlátai nem haladhatják meg ezt a határt. Fontos megjegyezni, hogy ha meg van adva a max érték, és az alapértelmezett szakasz hiányzik, akkor a maximális érték alapértelmezett értékké válik.
A min szakaszban a podban található konténer számára beállítható minimális kérések találhatók. Ebben az esetben az alapértelmezett szakaszban található értékek és a konténer kérései nem lehetnek alacsonyabbak ezen a határon.
Ismét fontos megjegyezni, hogy ha ez az érték be van állítva, az alapértelmezett érték pedig nincs, akkor a minimális érték lesz az alapértelmezett kérés.
Ezeket a forráskéréseket a Kubernetes ütemező használja a munkaterhelések végrehajtásához. Ahhoz, hogy helyesen konfigurálhassa a konténereit, fontos megérteni, hogyan működik ez. Tegyük fel, hogy néhány modult szeretne futtatni a klaszterében. Ha a pod specifikációi érvényesek, akkor a Kubernetes ütemezés körkörös kiegyensúlyozást fog használni a munkaterhelés végrehajtásához szükséges csomópont kiválasztásához.
A Kubernetes ellenőrzi, hogy az 1. számú csomópont elegendő erőforrással rendelkezik-e a pod konténereinek kéréséhez, és ha nem, akkor a következő csomópontra lép. Ha azonban a rendszerben egyetlen csomópont sem képes teljesíteni a kéréseket, a podok várakozó állapotba kerülnek. Az olyan funkciók, mint a Google Kubernetes Engine node auto-scaling, automatikusan képesek azonosítani a várakozó állapotot és további csomópontokat létrehozni.
Ha a későbbiekben a csomópontok fölösleges kapacitása adódik, az auto-scaling funkció csökkenti a számukat, hogy pénzt takarítson meg. Ezért a Kubernetes a kérések alapján ütemezi a podokat. Azonban a limit magasabb lehet, mint a kérések, és bizonyos esetekben a csomópont ténylegesen kimerítheti az erőforrásokat. Ezt az állapotot overcommitment állapotnak nevezzük.
Ahogy már említettem, ha a processzorról van szó, a Kubernetes korlátozni kezdi a podokat. Minden pod annyit kap, amennyit kért, de ha nem éri el a limitet, akkor elkezdődik a throttling.
A memóriaerőforrásokkal kapcsolatban a Kubernetes kénytelen döntéseket hozni arról, hogy mely podokat törölje, és melyeket tartson meg, míg ön nem szabadít fel rendszererőforrásokat, különben az egész rendszer összeomlik.
Képzeljünk el egy olyan forgatókönyvet, ahol van egy gépe, amely már elérte a memória limitet – mit tesz a Kubernetes?
A Kubernetes olyan podokat keres, amelyek több erőforrást használnak, mint amennyit kértek. Tehát ha a konténereidnek egyáltalán nincsenek kérései, az azt jelenti, hogy alapértelmezetten többet használnak, mint amennyit kértek, mert egyszerűen nem kértek semmit! Az ilyen konténerek a legfőbb jelöltek a leállításra. A következő jelöltek azok a konténerek, amelyek kielégítették az összes kérésüket, de még mindig a maximális limit alatt állnak.
Tehát ha a Kubernetes talál néhány podot, amely meghaladta a kérdéseik paramétereit, akkor prioritás szerint rendezi őket, majd eltávolítja a legalacsonyabb prioritású modulokat. Ha minden modul ugyanazzal a prioritással bír, akkor a Kubernetes leállítja azokat a podokat, amelyek jobban meghaladták a kéréseiket, mint a többi pod.
Nagyon ritka esetekben a Kubernetes leállíthatja azokat a podokat is, amelyek még mindig a kéréseik keretein belül vannak. Ez akkor fordulhat elő, amikor olyan kritikus rendszerkomponensek, mint a Kubelet ügynök vagy a Docker, több erőforrást kezdenek el használni, mint amennyit számukra fenntartottak.
Tehát a kis cégek kezdeti szakaszában a Kubernetes klaszter kiválóan működhet anélkül, hogy erőforrás kéréseket és limitációkat állítanánk be, de ahogy a csapatok és projektek bővülnek, kockázatot jelenthet, hogy problémákba ütközik ezen a területen. Az erőforrás kéréseinek és limitációinak hozzáadása a moduljaidhoz és névtérhez nagyon kevés plusz erőfeszítést igényel, és sok gondtól megszabadíthat.
Egy kis reklám 🙂
Köszönjük, hogy velünk maradtál. Tetszenek a cikkeink? Szeretnél több érdekes anyagot látni? Támogass minket, és rendelés leadásával vagy ismerősöknek ajánlással segíts nekünk. , Egyedülálló alternatívája az entry-level szervereknek, amelyet Önnek találtunk ki: (elérhetők RAID1 és RAID10 opciók, akár 24 magig és 40GB DDR4-ig).
Dell R730xd kétszer olcsóbban a Tier IV Equinix adatközpontban Amszterdamban? Csak nálunk Hollandiában! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 dollártól! Olvasd el ezt
Forrás: habr.com
