Дөрөвдүгээр сарын 27-нд чуулган дээр , "DevOps" хэсгийн нэг хэсэг болгон "Кубернетес дэх автомат масштабын болон нөөцийн менежмент" тайланг өгсөн. Энэ нь таны хэрэглээний өндөр хүртээмжийг хангах, дээд зэргийн гүйцэтгэлийг хангахын тулд K8s-ийг хэрхэн ашиглах талаар ярьдаг.
Уламжлал ёсоор бид танилцуулахдаа таатай байна (44 минут, нийтлэлээс хамаагүй илүү мэдээлэлтэй) болон текст хэлбэрээр үндсэн хураангуй. Яв!
Илтгэлийн сэдвийг үгээр нь задлан шинжилж, төгсгөлөөс нь эхэлцгээе.
Kubernetes
Манай хост дээр Docker контейнер байна гэж бодъё. Юуны төлөө? Дахин давтагдах байдал, тусгаарлалтыг хангахын тулд CI/CD нь энгийн бөгөөд сайн байрлуулах боломжийг олгодог. Манайд чингэлэгтэй ийм машин олон бий.
Энэ тохиолдолд Кубернетес юу өгдөг вэ?
- Бид эдгээр машинуудын талаар бодохоо больж, "үүл"-тэй ажиллаж эхэлдэг. савны бөөгнөрөл эсвэл хонхорцог (савны бүлгүүд).
- Түүгээр ч зогсохгүй, бид бие даасан хонхорцогуудын талаар огт боддоггүй, гэхдээ илүү ихийг удирддагоилүү том бүлгүүд. Ийм өндөр түвшний командууд Тодорхой ажлын ачааллыг ажиллуулах загвар байдаг бөгөөд үүнийг ажиллуулахад шаардлагатай тооны тохиолдлууд энд байна гэж хэлэхийг зөвшөөрнө үү. Хэрэв бид дараа нь загварыг өөрчилбөл бүх тохиолдлууд өөрчлөгдөх болно.
- Тусламжийн тусламжтайгаар тунхаглалын API Бид тодорхой тушаалын дарааллыг гүйцэтгэхийн оронд Кубернетесийн бүтээсэн "дэлхийн бүтцийг" (YAML дээр) дүрсэлдэг. Дахин хэлэхэд: тайлбар өөрчлөгдөхөд түүний бодит дэлгэц өөрчлөгдөнө.
Нөөцийн менежмент
CPU-ийн
Сервер дээр nginx, php-fpm, mysql ажиллуулъя. Эдгээр үйлчилгээнүүд нь бүр илүү олон процессуудтай байх бөгөөд тэдгээр нь тус бүр нь тооцоолох нөөц шаарддаг:
(слайд дээрх тоонууд нь "тоть", тооцоолох хүчин чадалд зориулсан процесс бүрийн хийсвэр хэрэгцээ)
Үүнтэй ажиллахад хялбар болгохын тулд процессуудыг бүлгүүдэд нэгтгэх нь логик юм (жишээлбэл, бүх nginx процессуудыг нэг бүлэг "nginx" болгон). Үүнийг хийх энгийн бөгөөд ойлгомжтой арга бол бүлэг бүрийг саванд хийх явдал юм.
Үргэлжлүүлэхийн тулд та контейнер гэж юу болохыг санах хэрэгтэй (Линукс дээр). Тэдний гадаад төрх байдал нь цөм дэх гурван үндсэн функцийн ачаар боломжтой болсон бөгөөд нэлээд эрт дээр үеэс хэрэгжсэн: , и . Цаашдын хөгжлийг бусад технологиуд (үүнд Docker гэх мэт тохиромжтой "бүрхүүл") хөнгөвчилсөн.
Тайлангийн хүрээнд бид зөвхөн сонирхож байна бүлэг, учир нь хяналтын бүлгүүд нь нөөцийн удирдлагыг хэрэгжүүлдэг контейнеруудын (Docker гэх мэт) функциональ хэсэг юм. Бидний хүссэнээр бүлэг болгон нэгтгэсэн процессууд нь хяналтын бүлгүүд юм.
Эдгээр процессуудын хувьд CPU-ийн шаардлагууд руу буцаж орцгооё, одоо бүлэг процессуудын хувьд:
(Бүх тоо нь нөөцийн хэрэгцээний хийсвэр илэрхийлэл гэдгийг би давтан хэлье)
Үүний зэрэгцээ CPU өөрөө тодорхой хязгаарлагдмал нөөцтэй байдаг (жишээнд энэ нь 1000 байна), энэ нь хүн бүрт дутагдаж магадгүй (бүх бүлгийн хэрэгцээний нийлбэр нь 150+850+460=1460). Энэ тохиолдолд юу болох вэ?
Цөм нь нөөцийг хуваарилж эхэлдэг бөгөөд үүнийг "шударга" хийж, бүлэг бүрт ижил хэмжээний нөөцийг өгдөг. Гэхдээ эхний тохиолдолд шаардлагатай хэмжээнээс олон (333>150) байгаа тул илүүдэл нь (333-150=183) нөөцөд үлддэг бөгөөд энэ нь бусад хоёр саванд тэнцүү хуваарилагдана.
Үүний үр дүнд: эхний саванд хангалттай нөөц байсан, хоёр дахь нь хангалттай нөөцгүй, гурав дахь нь хангалттай нөөцгүй байсан. Энэ бол үйл ажиллагааны үр дүн юм Линукс дээрх "шударга" хуваарьлагч - . Даалгаврыг ашиглан түүний ажиллагааг тохируулж болно жин сав бүр. Жишээлбэл, иймэрхүү:
Хоёрдахь саванд (php-fpm) нөөц дутагдсан тохиолдлыг авч үзье. Контейнерийн бүх нөөцийг процессуудын хооронд тэнцүү хуваарилдаг. Үүний үр дүнд мастер процесс сайн ажилладаг боловч бүх ажилчид удааширч, шаардлагатай байгаа зүйлийн талаас бага хувийг авдаг.
CFS төлөвлөгч ингэж ажилладаг. Бид чингэлэгт оноож буй жинг цаашид нэрлэх болно хүсэлтүүд. Яагаад ийм байна вэ - цааш нь харна уу.
Нөхцөл байдлыг бүхэлд нь нөгөө талаас нь харцгаая. Та бүхний мэдэж байгаагаар бүх замууд Ром руу, харин компьютерийн хувьд CPU руу хүргэдэг. Нэг CPU, олон даалгавар - танд гэрлэн дохио хэрэгтэй. Нөөцийг удирдах хамгийн энгийн арга бол "гэрлэн дохио" юм: тэд нэг процесст CPU-д тогтмол хандах хугацааг өгсөн, дараа нь дараагийнх гэх мэт.
Энэ аргыг хатуу квот гэж нэрлэдэг (хатуу хязгаарлах). Үүнийг энгийнээр санацгаая хязгаар. Гэсэн хэдий ч, хэрэв та бүх контейнерт хязгаарлалтыг хуваарилах юм бол асуудал гарч ирнэ: mysql зам дагуу явж байсан бөгөөд зарим үед CPU-ийн хэрэгцээ дуусч, бусад бүх процессууд нь CPU дуустал хүлээхээс өөр аргагүй болно. сул зогсолт.
Линуксийн цөм болон түүний CPU-тэй харилцах харилцаанд эргэн оръё - ерөнхий зураг нь дараах байдалтай байна.
cgroup нь хоёр тохиргоотой - үндсэндээ эдгээр нь дараахь зүйлийг тодорхойлох боломжийг олгодог хоёр энгийн "мушгиа" юм.
- чингэлэгт зориулсан жин (хүсэлт) байна хувьцаа;
- Контейнерийн даалгавар (хязгаарлалт) дээр ажиллахад зориулсан CPU-ийн нийт цагийн хувь квот.
CPU-ийг хэрхэн хэмжих вэ?
Янз бүрийн арга байдаг:
- гэж юу вэ тоть, хэн ч мэдэхгүй - та үргэлж хэлэлцээр хийх хэрэгтэй.
- Хүү илүү ойлгомжтой, гэхдээ харьцангуй: 50 цөмтэй, 4 цөмтэй серверийн 20% нь огт өөр зүйл юм.
- Та аль хэдийн дурдсаныг ашиглаж болно жин, үүнийг Линукс мэддэг, гэхдээ тэдгээр нь бас харьцангуй юм.
- Хамгийн тохиромжтой сонголт бол тооцоолох нөөцийг хэмжих явдал юм секунд. Тэдгээр. Бодит цагийн секундтэй харьцуулахад процессорын цагийн секундээр: 1 секундэд процессорын 1 секундын хугацаа өгсөн - энэ нь бүхэл бүтэн CPU цөм юм.
Хэлэхэд илүү хялбар болгохын тулд тэд шууд хэмжиж эхлэв цөм, энэ нь тэдний CPU-ийн цаг нь бодиттой харьцуулахад ижил байна гэсэн үг. Линукс нь жинг ойлгодог ч CPU-ийн цаг/цөм тийм ч их биш тул нэгээс нөгөө рүү хөрвүүлэх механизм хэрэгтэй болсон.
3 CPU-ийн цөмтэй серверийн энгийн жишээг авч үзье, үүнд гурван хонхорцог жинг (500, 1000, 1500) өгөх бөгөөд тэдгээрт хуваарилагдсан цөмүүдийн харгалзах хэсгүүдэд (0,5, 1, 1,5) амархан хувирдаг.
Хэрэв та хоёр дахин олон цөм (6) байх хоёрдахь серверийг авч, тэнд ижил хонхорцог байрлуулбал 2-оор (1, 2 ба 3) үржүүлснээр цөмийн тархалтыг хялбархан тооцоолж болно. Гэхдээ чухал мөч энэ сервер дээр гарч ирэх дөрөв дэх подволк гарч ирэх бөгөөд жин нь тав тухтай байхын тулд 3000 байна. Энэ нь CPU-ийн нөөцийн нэг хэсгийг (цөмийн тэн хагасыг) авч, үлдсэн хэсгүүдийн хувьд тэдгээрийг дахин тооцоолно (хагас багасгасан):
Kubernetes болон CPU-ийн нөөц
Kubernetes-д CPU-ийн нөөцийг ихэвчлэн хэмждэг миллиадракс, өөрөөр хэлбэл 0,001 цөмийг үндсэн жин болгон авна. (Linux/cgroups-ийн нэр томъёонд ижил зүйлийг CPU-ийн хувьцаа гэж нэрлэдэг, гэхдээ илүү нарийвчлалтай хэлэхэд 1000 милликор = 1024 CPU-ийн хувьцаа.) K8s нь сервер дээр бүх pods-ийн жингийн нийлбэрээр CPU-ийн нөөцөөс илүү олон pods байрлуулахгүй байхыг баталгаажуулдаг.
Энэ нь яаж болдог вэ? Та Кубернетес кластерт сервер нэмэх үед түүнд хичнээн CPU цөм байгаа талаар мэдээлнэ. Мөн шинэ pod үүсгэх үед Kubernetes төлөвлөгч нь энэ подволд хэдэн цөм хэрэгтэй болохыг мэддэг. Тиймээс pod нь хангалттай цөмтэй серверт хуваарилагдах болно.
Хэрвээ яах бол үгүй хүсэлтийг тодорхойлсон (жишээ нь, pod нь шаардлагатай тодорхой тооны цөмгүй байна)? Кубернетес нөөцийг ерөнхийд нь хэрхэн тооцдогийг олж мэдье.
Тавцангийн хувьд та хүсэлт (CFS төлөвлөгч) болон хязгаарыг (гэрлэн дохиог санаж байна уу?) хоёуланг нь зааж өгч болно.
- Хэрэв тэдгээр нь тэнцүү гэж заасан бол pod-д QoS анги оноогдоно баталгаатай. Энэ тооны цөм үргэлж бэлэн байх нь баталгаатай.
- Хэрэв хүсэлт нь хязгаараас бага бол - QoS анги тэсрэх боломжтой. Тэдгээр. Жишээлбэл, бид pod нь үргэлж 1 цөмийг ашиглахыг хүлээж байгаа боловч энэ утга нь үүнд хязгаарлалт биш юм: заримдаа pod илүү ихийг ашиглах боломжтой (серверт үүнд зориулж үнэгүй нөөц байгаа үед).
- Мөн QoS анги байдаг хамгийн сайн хүчин чармайлт - энэ нь хүсэлтийг заагаагүй ижил подволуудыг агуулдаг. Тэдэнд нөөцийг хамгийн сүүлд өгдөг.
санах ойн
Санах ойн хувьд нөхцөл байдал ижил төстэй боловч арай өөр байдаг - эцэст нь эдгээр нөөцийн мөн чанар өөр өөр байдаг. Ерөнхийдөө аналоги нь дараах байдалтай байна.
Санах ойд хүсэлтүүд хэрхэн хэрэгжиж байгааг харцгаая. Санах ойн хэрэглээг өөрчилснөөр нэг нь том болж, санах ой нь дуусч дуустал нь подкуудыг сервер дээр суулгаарай. Энэ тохиолдолд OOM алуурчин гарч ирэн хамгийн том процессыг устгадаг:
Энэ нь бидэнд үргэлж тохирохгүй тул ямар үйл явц нь бидний хувьд чухал, алагдах ёсгүйг зохицуулах боломжтой юм. Үүнийг хийхийн тулд параметрийг ашиглана уу oom_score_adj.
CPU-ийн QoS ангиуд руу буцаж, pods-ийн санах ойн хэрэглээний тэргүүлэх чиглэлийг тодорхойлдог oom_score_adj утгуудын аналогийг зурцгаая.
- Pod-ийн хамгийн бага oom_score_adj утга - -998 нь ийм хонхорцог хамгийн сүүлд устгах ёстой гэсэн үг юм. баталгаатай.
- Хамгийн өндөр нь 1000 байна хамгийн сайн хүчин чармайлт, ийм хонхорхойг эхлээд устгадаг.
- Үлдсэн утгыг тооцоолохын тулд (тэсрэх боломжтой) нэг томьёо байдаг бөгөөд түүний мөн чанар нь хонхорцог хэдий чинээ их нөөц шаардана, төдий чинээ үхэх магадлал багатай байдаг.
Хоёр дахь "мушгиа" - байтаар_хязгаарлах - хязгаарын хувьд. Үүний тусламжтайгаар бүх зүйл илүү хялбар байдаг: бид олгосон санах ойн хамгийн их хэмжээг хуваарилдаг бөгөөд энд (CPU-ээс ялгаатай нь) үүнийг (санах ой) хэрхэн хэмжих талаар асуулт байхгүй.
Нийт
Кубернетес дэх под бүрийг өгсөн requests и limits - CPU болон санах ойн хоёр параметр:
- Хүсэлт дээр үндэслэн Кубернетес хуваарьлагч ажилладаг бөгөөд энэ нь серверүүдийн хооронд pods хуваарилдаг;
- бүх параметр дээр үндэслэн pod-ийн QoS ангиллыг тодорхойлно;
- Харьцангуй жинг CPU-ийн хүсэлт дээр үндэслэн тооцдог;
- CFS хуваарилагчийг CPU-ийн хүсэлт дээр үндэслэн тохируулсан;
- OOM алуурчин нь санах ойн хүсэлт дээр үндэслэн тохируулагдсан;
- CPU-ийн хязгаарлалт дээр үндэслэн "гэрлэн дохио" тохируулагдсан;
- Санах ойн хязгаарлалт дээр үндэслэн бүлгийн хязгаарыг тохируулсан.
Ерөнхийдөө энэ зураг нь Кубернетес дэх нөөцийн менежментийн гол хэсэг хэрхэн явагддаг тухай бүх асуултанд хариулдаг.
Автоматаар масштаблах
K8s кластер-автомат масштаблагч
Бүхэл бүтэн кластер аль хэдийн эзлэгдсэн бөгөөд шинэ pod үүсгэх шаардлагатай байна гэж төсөөлөөд үз дээ. Под гарч ирэх боломжгүй ч гэсэн статустай байна хүлээгдэж буй. Үүнийг гарч ирэхийн тулд бид кластерт шинэ сервер холбох эсвэл... cluster-autoscaler суулгаж, энэ нь бидэнд үүнийг хийх болно: үүлэн үйлчилгээ үзүүлэгчээс виртуал машин захиалж (API хүсэлт ашиглан) кластерт холбох боломжтой. , үүний дараа pod нэмэх болно.
Энэ бол Кубернетес кластерын автомат масштабтай бөгөөд маш сайн ажилладаг (бидний туршлага дээр). Гэсэн хэдий ч бусад газруудын нэгэн адил энд зарим нэг нюансууд байдаг ...
Бид кластерийн хэмжээг нэмэгдүүлснээр бүх зүйл зүгээр байсан, гэхдээ кластер болоход юу тохиолдох вэ өөрийгөө чөлөөлж эхлэв? Асуудал нь подкуудыг шилжүүлэх (хостуудыг чөлөөлөх) нь техникийн хувьд маш хэцүү бөгөөд нөөцийн хувьд үнэтэй байдаг. Кубернетес огт өөр аргыг ашигладаг.
Байрлуулалттай 3 серверийн кластерийг авч үзье. Энэ нь 6 подтой: одоо сервер бүрт 2 байна. Зарим шалтгааны улмаас бид серверүүдийн аль нэгийг унтраахыг хүссэн. Үүнийг хийхийн тулд бид командыг ашиглана kubectl drain, аль нь:
- энэ сервер рүү шинэ pods илгээхийг хориглоно;
- сервер дээр байгаа pods устгах болно.
Кубернетес нь хонхорцог (6) тоог хадгалах үүрэгтэй тул энгийн дахин бүтээх болно тэдгээрийг бусад зангилаанууд дээр, гэхдээ идэвхгүй болсон зангилаа дээр биш, учир нь энэ нь шинэ pods байрлуулах боломжгүй гэж тэмдэглэгдсэн байдаг. Энэ бол Кубернетесийн үндсэн механик юм.
Гэсэн хэдий ч энд бас нэг нюанс бий. Үүнтэй төстэй нөхцөл байдалд StatefulSet-ийн хувьд (байршуулахын оронд) үйлдлүүд өөр байх болно. Одоо бид аль хэдийн төлөвтэй програмтай болсон - жишээлбэл, MongoDB-тэй гурван pods, тэдгээрийн нэг нь ямар нэгэн асуудалтай (өгөгдөл эвдэрсэн эсвэл pod-ыг зөв эхлүүлэхэд саад болсон өөр алдаа). Бид дахин нэг серверийг идэвхгүй болгохоор шийдсэн. Юу тохиолдох вэ?
МонгоБ чадна үхэх, учир нь энэ нь чуулга хэрэгтэй: гурван суулгацын кластерын хувьд дор хаяж хоёр нь ажиллах ёстой. Гэсэн хэдий ч энэ болохгүй байна - баярлалаа PodDisruptionBudget. Энэ параметр нь шаардлагатай хамгийн бага тооны ажлын тавиурыг тодорхойлдог. MongoDB pods-ийн аль нэг нь ажиллахаа больсон, мөн PodDisruptionBudget-г MongoDB-д тохируулсан болохыг олж мэдсэн. minAvailable: 2, Kubernetes танд pod устгахыг зөвшөөрөхгүй.
Доод шугам: кластер гарах үед подкуудын хөдөлгөөн (болон үнэн хэрэгтээ дахин үүсгэх) зөв ажиллахын тулд PodDisruptionBudget-ийг тохируулах шаардлагатай.
Хэвтээ масштаб
Өөр нэг нөхцөл байдлыг авч үзье. Kubernetes-д Deployment хэлбэрээр ажиллаж байгаа програм байна. Хэрэглэгчийн урсгал нь түүний хонхорцог руу ирдэг (жишээлбэл, тэдгээрийн гурав нь байдаг) бөгөөд бид тэдгээрийн дотор тодорхой үзүүлэлтийг хэмждэг (CPU ачаалал гэх мэт). Ачаалал ихсэх үед бид үүнийг хуваарь дээр тэмдэглэж, хүсэлтийг түгээхийн тулд подын тоог нэмэгдүүлнэ.
Өнөөдөр Кубернетес дээр үүнийг гараар хийх шаардлагагүй: хэмжсэн ачааллын индикаторын утгуудаас хамааран хонгилын тоог автоматаар нэмэгдүүлэх / багасгахыг тохируулдаг.
Энд байгаа гол асуултууд нь: яг юуг хэмжих вэ и хэрхэн тайлбарлах вэ олж авсан утгууд (хоолны тоог өөрчлөх шийдвэр гаргахад). Та маш их хэмжиж болно:
Техникийн хувьд үүнийг хэрхэн хийх вэ - хэмжигдэхүүнийг цуглуулах гэх мэт. -Би тайландаа дэлгэрэнгүй ярьсан . Мөн оновчтой параметрүүдийг сонгох гол зөвлөгөө бол туршилт!
Байдаг (Ашиглалтын ханалт ба алдаа), утга нь дараах байдалтай байна. Ямар үндэслэлээр жишээ нь php-fpm-ийг масштаблах нь утга учиртай вэ? Ажилчид дуусч байгааг үндэслэн энэ ашиглалт. Хэрэв ажилчид дуусч, шинэ холболтыг хүлээн авахгүй бол энэ нь аль хэдийн байна ханасан. Эдгээр хоёр параметрийг хоёуланг нь хэмжих шаардлагатай бөгөөд утгуудаас хамааран масштабыг хийх ёстой.
Оронд дүгнэлтийг
Тайлан нь үргэлжлэлтэй: босоо масштабын тухай, зөв нөөцийг хэрхэн сонгох талаар. Би энэ талаар дараагийн видеон дээр ярих болно - алдахгүйн тулд бүртгүүлээрэй!
Видео болон слайд
Тоглолтын видео (44 минут):
Илтгэлийн танилцуулга:
PS
Манай блог дээрх Кубернетесийн талаархи бусад мэдээллүүд:
- «» (Андрей Половов; 8 оны 2019-р сарын XNUMX, Saint HighLoad++ дээр);
- «» (Дмитрий Столяров; 8 оны 2018-р сарын XNUMX, HighLoad++ дээр);
- «» (Дмитрий Столяров; 28 оны 2018-р сарын XNUMX-нд RootConf дээр);
- «» (Дмитрий Столяров; 7 оны 2017-р сарын XNUMX, HighLoad++ дээр);
- «» (Дмитрий Столяров; 6 оны 2017-р сарын XNUMX-нд RootConf дээр).
Эх сурвалж: www.habr.com