Kubernetes-ийн нөөц бүрийн хувьд та хоёр төрлийн шаардлагыг тохируулах боломжтой - Хүсэлт ба Хязгаарлалт. Эхнийх нь контейнер эсвэл pod ажиллуулахад шаардлагатай чөлөөт зангилааны нөөцийн хүртээмжтэй байх хамгийн бага шаардлагыг тодорхойлсон бол хоёр дахь нь контейнерт байгаа нөөцийг хатуу хязгаарладаг.
Kubernetes pods хуваарь гаргахдаа савнууд зөв ажиллахад хангалттай нөөцтэй байх нь маш чухал юм. Хэрэв та нөөц хязгаарлагдмал зангилаа дээр том хэмжээний програм байрлуулахаар төлөвлөж байгаа бол уг зангилаа санах ой багассан эсвэл CPU-ийн хүч дуусч байгаа тул ажиллахгүй байх магадлалтай. Энэ нийтлэлд бид нөөцийн хүсэлт, хязгаарлалтыг ашиглан тооцоолох эрчим хүчний хомсдолыг хэрхэн шийдвэрлэх талаар авч үзэх болно.
Хүсэлт ба хязгаарлалт нь Кубернетесийн CPU болон санах ой зэрэг нөөцийг удирдахад ашигладаг механизм юм. Хүсэлт нь чингэлэг хүссэн нөөцийг хүлээн авах баталгаа юм. Хэрэв контейнер нөөц хүсэх юм бол Кубернетес үүнийг зөвхөн хангаж чадах цэг дээр хуваарьлана. Контейнерийн хүссэн нөөц хэзээ ч тодорхой утгаас хэтрэхгүй байх хяналтыг хязгаарладаг.
Контейнер нь тооцоолох хүчин чадлаа тодорхой хязгаар хүртэл нэмэгдүүлэх боломжтой бөгөөд дараа нь хязгаарлагдах болно. Энэ нь хэрхэн ажилладагийг харцгаая. Тиймээс процессор ба санах ой гэсэн хоёр төрлийн нөөц байдаг. Kubernetes хуваарьлагч нь эдгээр нөөцийн талаарх өгөгдлийг ашиглан таны подкуудыг хаана ажиллуулахаа тодорхойлдог. Под-д зориулсан ердийн нөөцийн тодорхойлолт иймэрхүү харагдаж байна.
Под дахь сав бүр өөрийн хүсэлт, хязгаарлалтыг тохируулах боломжтой бөгөөд энэ нь бүгд нэмэлт юм. Процессорын нөөцийг милликороор тодорхойлдог. Хэрэв таны савыг ажиллуулахын тулд хоёр бүтэн цөм шаардлагатай бол та утгыг 2000м болгож тохируулна уу. Хэрэв саванд зөвхөн цөмийн 1/4-ийн хүч шаардлагатай бол үнэ нь 250м болно. Хэрэв та хамгийн том зангилааны цөмийн тооноос их CPU-ийн нөөцийн утгыг оноож өгвөл таны pod-ыг эхлүүлэхээр төлөвлөхгүй гэдгийг санаарай. Хэрэв танд дөрвөн цөм шаардлагатай Pod байгаа бол Kubernetes кластер нь зөвхөн хоёр үндсэн виртуал машинаас бүрддэг бол үүнтэй төстэй нөхцөл байдал үүсэх болно.
Таны аппликейшн нь олон цөмийн давуу талыг ашиглахаар тусгайлан бүтээгдээгүй бол (шинжлэх ухааны нарийн төвөгтэй тооцоолол, мэдээллийн сангийн үйл ажиллагаа гэх мэт програмууд санаанд орж ирдэг) хамгийн сайн туршлага бол CPU-ийн хүсэлтийг 1 эсвэл түүнээс доош болгож, дараа нь өргөтгөх боломжтой болгохын тулд илүү олон хуулбарыг ажиллуулах явдал юм. Энэхүү шийдэл нь системд илүү уян хатан, найдвартай байдлыг өгөх болно.
CPU-ийн хязгаарлалтын тухай ярихад энэ нь шахагдах нөөц гэж тооцогддог тул бүх зүйл илүү сонирхолтой болдог. Хэрэв таны програм процессорын чадлын хязгаарт ойртож эхэлбэл Kubernetes процессорын давтамжийг бууруулж, CPU Throttling ашиглан таны савыг удаашруулж эхэлнэ. Энэ нь CPU-г зохиомлоор багасгаж, програмын гүйцэтгэлийг муутгаж болзошгүй боловч процессыг зогсоох эсвэл устгахгүй гэсэн үг юм.
Санах ойн нөөцийг байтаар тодорхойлно. Ихэвчлэн тохиргоон дахь утгыг Миб мебибайтаар хэмждэг боловч та байтаас петабайт хүртэл ямар ч утгыг тохируулж болно. CPU-тэй ижил нөхцөл байдал энд хамаарна - хэрэв та өөрийн зангилаанууд дээрх санах ойн хэмжээнээс илүү санах ойн хэмжээ авах хүсэлт тавьбал уг подкастыг ажиллуулахаар төлөвлөхгүй. Гэхдээ CPU-ийн нөөцөөс ялгаатай нь санах ой нь шахагддаггүй, учир нь түүний ашиглалтыг хязгаарлах арга байхгүй. Тиймээс контейнерт хуваарилагдсан санах ойн хэмжээнээс хэтэрмэгц гүйцэтгэл нь зогсох болно.
Та зангилаануудынхаа өгч чадах нөөцөөс хэтэрсэн хүсэлтийг тохируулах боломжгүй гэдгийг санах нь чухал. GKE виртуал машинуудын хуваалцсан нөөцийн үзүүлэлтүүдийг энэ видеоны доорх холбоосоос олж болно.
Тохиромжтой ертөнцөд контейнерын анхдагч тохиргоо нь ажлын урсгалыг жигд явуулахад хангалттай байх болно. Гэвч бодит ертөнц тийм биш, хүмүүс нөөцийн ашиглалтыг тохируулахаа амархан мартдаг, эсвэл хакерууд дэд бүтцийн бодит боломжоос давсан хүсэлт, хязгаарлалт тавьдаг. Ийм тохиолдол гарахаас урьдчилан сэргийлэхийн тулд та ResourceQuota болон LimitRange нөөцийн квотыг тохируулж болно.
Нэрийн орон зайг үүсгэсний дараа үүнийг квот ашиглан хааж болно. Жишээлбэл, хэрэв танд бүтээгдэхүүн болон хөгжүүлэлтийн нэрийн орон зай байгаа бол үйлдвэрлэлийн квот огт байхгүй бөгөөд хөгжүүлэх квот маш хатуу байдаг. Энэ нь траффик огцом нэмэгдсэн тохиолдолд үйлдвэрлэгчид боломжтой нөөцийг бүхэлд нь авч, програмыг бүрэн хаах боломжийг олгодог.
Нөөцийн квот иймэрхүү харагдаж болно. Энэ жишээнд 4 хэсэг байна - эдгээр нь кодын 4 доод мөр юм.
Тэдгээрийг тус бүрээр нь харцгаая. Requests.cpu нь нэрийн талбар дахь бүх контейнерээс ирж болох CPU-ийн хосолсон хүсэлтийн дээд хэмжээ юм. Энэ жишээнд та 50м хүсэлттэй 10 чингэлэг, 100м хүсэлттэй таван чингэлэг эсвэл 500м хүсэлттэй нэг чингэлэгтэй байж болно. Өгөгдсөн нэрийн талбарын нийт хүсэлт.cpu тоо 500м-ээс бага байвал бүх зүйл сайхан болно.
Санах ойн хүсэлт.санах ой нь нэрийн талбар дахь бүх контейнерт байж болох хосолсон санах ойн хүсэлтийн дээд хэмжээ юм. Өмнөх тохиолдлын нэгэн адил нэрийн талбарт хүссэн санах ойн нийт хэмжээ 50 мебибайтаас бага бол та 2 20 миб контейнер, 100 миб багтаамжтай таван контейнер эсвэл нэг 100 миб контейнертэй байж болно.
Limits.cpu нь нэрийн талбар дахь бүх контейнер ашиглаж болох CPU-ийн хүчин чадлын дээд хэмжээ юм. Үүнийг бид процессорын тэжээлийн хүсэлтийн хязгаар гэж үзэж болно.
Эцэст нь, limits.memory нь нэрийн талбар дахь бүх контейнер ашиглаж болох хуваалцсан санах ойн дээд хэмжээ юм. Энэ нь нийт санах ойн хүсэлтийн хязгаар юм.
Тиймээс, анхдагчаар Kubernetes кластер дахь контейнерууд хязгааргүй тооцоолох нөөцөөр ажилладаг. Нөөцийн квотоор кластерын администраторууд нэрийн орон зайд тулгуурлан нөөцийн хэрэглээ болон нөөц үүсгэхийг хязгаарлах боломжтой. Нэрийн орон зайд pod эсвэл контейнер нь нэрийн зайны нөөцийн квотоор тодорхойлогдох хэмжээний CPU-ийн хүч болон санах ойг хэрэглэж болно. Гэсэн хэдий ч нэг хонхорцог эсвэл чингэлэг нь байгаа бүх нөөцийг монопольчлох вий гэсэн болгоомжлол бий. Ийм нөхцөл байдлаас урьдчилан сэргийлэхийн тулд хязгаарын хүрээг ашигладаг - нэрийн талбар дахь нөөцийн хуваарилалтыг (под эсвэл контейнерийн хувьд) хязгаарлах бодлого.
Хязгаарлалтын хүрээ нь дараахь хязгаарлалтуудыг өгдөг.
- Нэрийн орон зай дахь модуль эсвэл контейнер тус бүрийн тооцоолох нөөцийг хамгийн бага ба хамгийн их ашиглахыг баталгаажуулах;
- нэрийн талбар дахь PersistentVolumeClaim бүрийн хамгийн бага ба хамгийн их Starage Request хадгалах хүсэлтийг хэрэгжүүлэх;
- нэрийн талбар дахь нөөцийн Хүсэлт ба Хязгаарлалтын хоорондын хамаарлыг хэрэгжүүлэх;
- нэрийн талбарт тооцоолох нөөцийн өгөгдмөл Хүсэлт/Хязгаарыг тохируулж, тэдгээрийг ажиллах үед автоматаар контейнерт оруулна.
Ингэснээр та өөрийн нэрийн талбарт хязгаарын хүрээ үүсгэж болно. Бүхэл бүтэн нэрийн талбарт хамаарах квотоос ялгаатай нь Хязгаарлалтын хүрээ нь тусдаа контейнерт ашиглагддаг. Энэ нь хэрэглэгчдэд нэрийн талбарт маш өчүүхэн, эсвэл эсрэгээрээ аварга том сав үүсгэхээс сэргийлж чадна. Хязгаарын хүрээ иймэрхүү харагдаж болно.
Өмнөх тохиолдлын нэгэн адил энд 4 хэсгийг ялгаж болно. Тус бүрийг нь харцгаая.
Өгөгдмөл хэсэг нь pod дахь контейнерийн өгөгдмөл хязгаарыг тогтоодог. Хэрэв та эдгээр утгыг туйлын хязгаарт тохируулсан бол эдгээр утгыг тодорхой заагаагүй аливаа контейнер нь анхдагч утгуудыг дагаж мөрдөх болно.
Өгөгдмөл хүсэлтийн хэсэг defaultRequest нь pod дахь контейнерийн өгөгдмөл хүсэлтүүдийг тохируулдаг. Дахин хэлэхэд, хэрэв та эдгээр утгыг туйлын хязгаарт тохируулсан бол эдгээр тохиргоог тодорхой заагаагүй аливаа контейнер нь эдгээр утгыг анхдагчаар тохируулна.
Макс хэсэг нь савны саванд тохируулж болох дээд хязгаарыг зааж өгдөг. Өгөгдмөл хэсгийн утгууд болон савны хязгаарыг энэ хязгаараас дээш тогтоох боломжгүй. Хэрэв утгыг max гэж тохируулсан бөгөөд анхдагч хэсэг байхгүй бол хамгийн их утга нь үндсэн утга болно гэдгийг анхаарах нь чухал.
Min хэсэг нь pod дахь контейнерт тохируулж болох хамгийн бага хүсэлтийг тодорхойлдог. Гэсэн хэдий ч, анхдагч хэсэг дэх утгууд болон контейнерийн асуулга нь энэ хязгаараас доогуур байж болохгүй.
Дахин хэлэхэд, хэрэв энэ утгыг тохируулсан бол өгөгдмөл биш бол хамгийн бага утга нь өгөгдмөл сануулга болно гэдгийг анхаарах нь чухал.
Эдгээр нөөцийн хүсэлтийг эцсийн дүндээ Kubernetes төлөвлөгч таны ажлын ачааллыг гүйцэтгэхэд ашигладаг. Контейнерээ зөв тохируулахын тулд энэ нь хэрхэн ажилладагийг ойлгох нь маш чухал юм. Та кластертаа олон pods ажиллуулахыг хүсч байна гэж бодъё. Под техникийн үзүүлэлтүүд хүчинтэй гэж үзвэл Кубернетес хуваарь нь ажлын ачааллыг ажиллуулах зангилааг сонгохдоо дугуй тэнцвэржүүлэлтийг ашиглана.
Кубернетес 1-р зангилаа нь под контейнерийн хүсэлтийг биелүүлэх хангалттай нөөцтэй эсэхийг шалгах бөгөөд хэрэв байхгүй бол дараагийн зангилаа руу шилжих болно. Хэрэв системийн аль ч зангилаа хүсэлтийг хангаж чадахгүй бол хонхорцог Хүлээгдэж буй төлөвт шилжинэ. Google Kubernetes системийн зангилааг автоматаар масштаблах зэрэг функцуудыг ашигласнаар GKE хүлээлгийн төлөвийг автоматаар илрүүлж, хэд хэдэн нэмэлт зангилаа үүсгэх боломжтой.
Хэрэв та дараа нь зангилааны хүчин чадал дуусвал автоматаар масштаблах нь мөнгө хэмнэхийн тулд зангилааны тоог багасгах болно. Тийм ч учраас Кубернетес хүсэлт дээр үндэслэн pods хуваарь гаргадаг. Гэсэн хэдий ч, хязгаар нь хүсэлтээс өндөр байж болох бөгөөд зарим тохиолдолд зангилаа үнэхээр нөөцгүй болж магадгүй юм. Үүнийг бид төрийн хэт их үүрэг хариуцлага гэж нэрлэдэг.
Миний хэлсэнчлэн, CPU-ийн тухай ярихад Kubernetes подкуудыг хязгаарлаж эхэлнэ. Под бүр хүссэн хэмжээгээрээ хүлээн авах боловч хязгаарт хүрэхгүй бол тохируулагч хэрэгжиж эхэлнэ.
Санах ойн нөөцийн тухайд Кубернетес системийн нөөцийг чөлөөлөх хүртэл аль хэсгийг нь устгах, аль нь хадгалахаа шийдэхээс өөр аргагүйд хүрдэг.
Таны санах ой дуусч байгаа машин байгаа хувилбарыг төсөөлөөд үз дээ - Кубернетес үүнийг хэрхэн зохицуулах вэ?
Кубернетес хүссэнээсээ илүү их нөөц ашиглаж байгаа pods хайх болно. Хэрэв таны контейнерт ямар ч хүсэлт байхгүй бол тэд юу ч хүсээгүй учраас тэд хүссэнээсээ илүү ихийг ашигладаг гэсэн үг юм! Ийм чингэлэг нь хаагдах гол нэр дэвшигч болдог. Дараагийн нэр дэвшигчид бол бүх хүсэлтээ хангасан боловч дээд хязгаараас доогуур байгаа контейнерууд юм.
Тиймээс хэрэв Кубернетес хүсэлтийн параметрүүдээсээ хэтэрсэн хэд хэдэн подволк олдвол тэдгээрийг давуу эрхээр нь ангилж, дараа нь хамгийн бага ач холбогдолтой pods-ыг устгана. Хэрэв бүх pods ижил ач холбогдолтой бол Кубернетес бусад pods-ээс илүү хүсэлтээсээ давсан pods-уудыг зогсооно.
Маш ховор тохиолдлуудад Кубернетес нь тэдний хүсэлтийн хүрээнд байгаа pods-ыг цуцалж болно. Энэ нь Кубелет агент эсвэл Докер зэрэг системийн чухал бүрэлдэхүүн хэсгүүд нь нөөцөөс илүү их нөөцийг хэрэглэж эхлэх үед тохиолдож болно.
Тиймээс жижиг компаниудын эхний үе шатанд Kubernetes кластер нь нөөцийн хүсэлт, хязгаарлалт хийхгүйгээр сайн ажиллах боломжтой боловч танай баг, төслүүд томорч эхлэх тусам энэ чиглэлээр асуудал гарах эрсдэлтэй. Өөрийн модулиуд болон нэрийн зайд асуулга, хязгаарлалт нэмэх нь маш бага нэмэлт хүчин чармайлт шаарддаг бөгөөд маш их төвөг учруулдаг.
Зарим зар 🙂
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com