2016 онд бид Buffer-д буцаж ирсэн , одоо 60 орчим зангилаа (AWS дээр) болон 1500 контейнер манай k8s кластер дээр ажиллаж байна. . Гэсэн хэдий ч бид туршилт, алдааны замаар микро үйлчилгээ рүү шилжсэн бөгөөд k8s-тэй хэдэн жил ажилласан ч шинэ асуудлуудтай тулгарсаар байна. Энэ нийтлэлд бид энэ тухай ярих болно процессорын хязгаарлалт: яагаад бид тэднийг сайн дасгал гэж бодож байсан ба яагаад тийм ч сайн биш болсон юм бэ?
Процессорын хязгаарлалт ба тохируулагч
Бусад Kubernetes хэрэглэгчдийн нэгэн адил, . Ийм тохиргоо байхгүй бол зангилаа дахь контейнерууд процессорын бүх хүчийг авах боломжтой бөгөөд энэ нь эргээд Кубернетын чухал процессуудыг үүсгэдэг (жишээ нь). kubelet) хүсэлтэд хариу өгөхөө болино. Тиймээс CPU-ийн хязгаарлалтыг тохируулах нь зангилаагаа хамгаалах сайн арга юм.
Процессорын хязгаарлалт нь тухайн контейнерийг тодорхой хугацаанд ашиглаж болох хамгийн их CPU-ийн хугацааг тогтоодог (анхдагч нь 100 мс) бөгөөд контейнер хэзээ ч энэ хязгаараас хэтрэхгүй. Kubernetes-д зориулагдсан бууруулах саванд хийж, хязгаараас хэтрэхээс сэргийлж, тусгай хэрэгсэл ашигладаг , гэхдээ эдгээр хиймэл CPU-ийн хязгаарлалтууд нь гүйцэтгэлд сөргөөр нөлөөлж, таны контейнерийн хариу өгөх хугацааг нэмэгдүүлдэг.
Хэрэв бид процессорын хязгаарлалтыг тогтоохгүй бол юу болох вэ?
Харамсалтай нь бид өөрсдөө энэ асуудалтай тулгарсан. Зангилаа бүр нь савыг удирдах үүрэгтэй процесстой kubelet, мөн тэрээр хүсэлтэд хариу өгөхөө больсон. Энэ нь тохиолдоход зангилаа мужид орно NotReady, мөн үүнээс контейнерууд өөр газар дахин чиглэгдэж, шинэ зангилаанууд дээр ижил асуудал үүсгэх болно. Хамгийн наад зах нь хэлэхэд хамгийн тохиромжтой хувилбар биш.
Даралт ба хариу үйлдэл үзүүлэх асуудлын илрэл
Контейнер хянах гол хэмжүүр нь trottling, энэ нь таны савыг хэдэн удаа дарж байсныг харуулдаг. Процессорын ачаалал хэт их байгаа эсэхээс үл хамааран зарим саванд тохируулагч байгааг бид сонирхож анзаарсан. Жишээ болгон манай үндсэн API-уудын нэгийг харцгаая:
Таны харж байгаагаар бид хязгаарыг тогтоосон 800m (0.8 буюу 80% цөм) ба оргил утга нь хамгийн сайн хүрдэг 200m (20% үндсэн). Үйлчилгээг зогсоохоос өмнө бидэнд процессорын хүч хангалттай байгаа юм шиг санагдаж байна ...
Процессорын ачаалал заасан хэмжээнээс доогуур буюу нэлээд доогуур байгаа ч гэсэн саармагжуулсаар байгааг та анзаарсан байх.
Үүнтэй тулгарсан бид удалгүй хэд хэдэн нөөцийг олж мэдсэн (, , ) бууралтаас болж үйлчилгээний гүйцэтгэл болон хариу өгөх хугацаа буурсан тухай.
Яагаад бид CPU-ийн ачаалал багатай үед бууруулж байгааг харж байна вэ? Богино хувилбар нь: "Линукс цөмд тодорхой процессорын хязгаартай контейнеруудыг шаардлагагүйгээр багасгахад хүргэдэг алдаа байна." Хэрэв та асуудлын мөн чанарыг сонирхож байвал танилцуулгыг уншиж болно ( и сонголтууд) Дэйв Чилук.
CPU-ийн хязгаарлалтыг арилгах (маш болгоомжтой)
Удаан ярилцсаны эцэст бид хэрэглэгчдийнхээ чухал үйл ажиллагаанд шууд болон шууд бусаар нөлөөлсөн бүх үйлчилгээнээс процессорын хязгаарлалтыг арилгахаар шийдсэн.
Бид кластерынхаа тогтвортой байдлыг өндөр үнэлдэг тул шийдвэр гаргахад амаргүй байсан. Өнгөрсөн хугацаанд бид кластерынхаа тогтворгүй байдлыг аль хэдийн туршиж үзсэн бөгөөд дараа нь үйлчилгээнүүд хэт их нөөцийг хэрэглэж, бүх зангилааны ажлыг удаашруулсан. Одоо бүх зүйл арай өөр байсан: бид кластеруудаас юу хүлээж байгаагаа тодорхой ойлгож, төлөвлөсөн өөрчлөлтүүдийг хэрэгжүүлэх сайн стратегитай болсон.
Тууштай асуудлын талаар бизнесийн захидал харилцаа.
Хязгаарлалт цуцлагдах үед зангилаагаа хэрхэн хамгаалах вэ?
"Хязгаарлалтгүй" үйлчилгээг тусгаарлах:
Өмнө нь бид зарим зангилаа төлөв байдалд орохыг аль хэдийн харсан notReady, үндсэндээ хэт их нөөц зарцуулсан үйлчилгээтэй холбоотой.
Бид "холбогдох" үйлчилгээнд саад учруулахгүйн тулд эдгээр үйлчилгээг тусдаа ("шошготой") цэгүүдэд байрлуулахаар шийдсэн. Үүний үр дүнд зарим зангилааг тэмдэглэж, хүлцлийн параметрийг "холбоотой" үйлчилгээнд нэмснээр бид кластерт илүү их хяналт тавьж, зангилааны асуудлыг тодорхойлоход хялбар болсон. Үүнтэй төстэй үйл явцыг өөрөө хийхийн тулд та өөрөө танилцаж болно .
Зөв процессор болон санах ойн хүсэлтийг оноох:
Бидний хамгийн том айдас бол процесс нь хэт их нөөцийг зарцуулж, зангилаа хүсэлтэд хариу өгөхөө больчих вий гэсэн айдас байсан. Одоо (Datadog-ийн ачаар) бид кластер дээрх бүх үйлчилгээг тодорхой хянах боломжтой болсон тул би "холбоотой" гэж тодорхойлохоор төлөвлөж байсан үйлчилгээнийхээ хэдэн сарын үйл ажиллагаанд дүн шинжилгээ хийсэн. Би зүгээр л CPU-ийн ашиглалтын дээд хэмжээг 20%-ийн маржингаар тохируулж, k8s нь зангилаа руу бусад үйлчилгээг оноохыг оролдсон тохиолдолд зангилаанд зай хуваарилсан.
Графикаас харахад процессорын хамгийн их ачаалалд хүрсэн байна 242m CPU-ийн цөм (0.242 процессорын цөм). Процессорын хүсэлтийн хувьд энэ утгаас арай том тоо авахад хангалттай. Үйлчилгээнүүд нь хэрэглэгчдэд төвлөрсөн байдаг тул ачааллын оргил утга нь замын хөдөлгөөнтэй давхцаж байгааг анхаарна уу.
Санах ойн ашиглалт болон асуулгатай ижил зүйлийг хий, мөн voila - та бүгдийг тохируулсан! Аюулгүй байдлыг нэмэгдүүлэхийн тулд та хэвтээ pod autoscaling нэмж болно. Тиймээс нөөцийн ачаалал их байх болгонд автоматаар масштаблах нь шинэ pods үүсгэх бөгөөд кубернетууд тэдгээрийг сул зайтай зангилаа руу тараах болно. Хэрэв кластерт хоосон зай байхгүй бол та өөртөө анхааруулга өгөх эсвэл автомат масштабаар дамжуулан шинэ зангилаа нэмж тохируулах боломжтой.
Сул талуудаас бид "д хожигдсоныг тэмдэглэх нь зүйтэй.", өөрөөр хэлбэл. нэг зангилаа дээр ажиллаж байгаа савны тоо. Замын хөдөлгөөний нягтрал багатай үед бид маш их "тайвшрах" боломжтой бөгөөд та процессорын өндөр ачаалалд хүрэх магадлал өндөр байгаа ч автомат масштабын зангилаа нь сүүлийн үед туслах ёстой.
Результаты
Би сүүлийн хэдэн долоо хоногт хийсэн туршилтуудын эдгээр гайхалтай үр дүнг нийтэлж байгаадаа баяртай байна; бид өөрчлөгдсөн бүх үйлчилгээнүүдийн хариуд мэдэгдэхүйц сайжруулалтыг аль хэдийн харсан:
Бид нүүр хуудсандаа хамгийн сайн үр дүнд хүрсэн (), тэнд үйлчилгээ хурдассан хорин хоёр удаа!
Линуксийн цөмийн алдаа зассан уу?
Тийм ээ, түгээлтийн хувилбар 4.19 ба түүнээс дээш.
Гэсэн хэдий ч уншсаны дараа 2020 оны XNUMX-р сарын хоёрны хувьд Бид ижил төстэй алдаатай Линуксийн зарим төслүүдийн талаар дурдсан хэвээр байна. Зарим Линуксийн түгээлтүүд энэ алдаатай хэвээр байгаа бөгөөд үүнийг засахаар ажиллаж байгаа гэдэгт би итгэж байна.
Хэрэв таны түгээлтийн хувилбар 4.19-ээс бага бол би хамгийн сүүлийн хувилбар руу шинэчлэхийг зөвлөж байна, гэхдээ ямар ч тохиолдолд та процессорын хязгаарлалтыг арилгахыг оролдож, тохируулга хэвээр байгаа эсэхийг шалгах хэрэгтэй. Kubernetes менежментийн үйлчилгээ болон Линукс түгээлтийн хэсэгчилсэн жагсаалтыг доороос харж болно.
- Debian: Түгээлтийн хамгийн сүүлийн хувилбарт нэгтгэсэн засвар, , мөн нэлээд шинэхэн харагдаж байна (). Зарим өмнөх хувилбарууд нь мөн засагдсан байж магадгүй.
- Ubuntu: хамгийн сүүлийн хувилбарт нэгтгэсэн засвар
- EKS одоохондоо засвар хийгээгүй байна . Хэрэв таны хувилбар үүнээс доогуур байвал AMI-г шинэчлэх хэрэгтэй.
- копс: у
kops 1.18+Үндсэн хост зураг нь Ubuntu 20.04 байх болно. Хэрэв таны kops хувилбар хуучин бол засварыг хүлээх хэрэгтэй болж магадгүй юм. Бид өөрсдөө одоо хүлээж байна. - GKE (Google Cloud): Нэгдсэн засвар , гэхдээ тохируулагчтай холбоотой асуудал гардаг .
Хэрэв засвар нь тохируулагчийн асуудлыг зассан бол яах вэ?
Асуудлыг бүрэн шийдсэн гэдэгт би итгэлгүй байна. Бид засварын хамт цөмийн хувилбар руу ороход би кластерыг шалгаж, нийтлэлийг шинэчлэх болно. Хэрэв хэн нэгэн нь аль хэдийн шинэчлэгдсэн бол би таны үр дүнг унших сонирхолтой байх болно.
дүгнэлт
- Хэрэв та Линукс дээр Docker контейнертэй ажилладаг бол (Kubernetes, Mesos, Swarm болон бусад нь хамаагүй) таны контейнерууд сааруулагчаас болж гүйцэтгэлээ алдаж болзошгүй;
- Алдааг аль хэдийн зассан гэж найдаж түгээлтийн хамгийн сүүлийн хувилбар руу шинэчлэхийг оролдоорой;
- Процессорын хязгаарлалтыг арилгах нь асуудлыг шийдэх болно, гэхдээ энэ нь маш болгоомжтой ашиглах ёстой аюултай арга юм (эхлээд цөмийг шинэчилж, үр дүнг харьцуулах нь дээр);
- Хэрэв та CPU-ийн хязгаарлалтыг хассан бол CPU болон санах ойн хэрэглээгээ сайтар хянаж, CPU-ийн нөөц таны хэрэглээнээс хэтэрсэн эсэхийг шалгаарай;
- Аюулгүй сонголт бол өндөр техник хангамжийн ачаалалтай үед шинэ pods үүсгэхийн тулд pods-ыг автоматаар масштаблах бөгөөд ингэснээр kubernetes тэдгээрийг чөлөөт зангилаанд хуваарилах болно.
Энэ нийтлэл нь савны системийн ажиллагааг сайжруулахад тусална гэж найдаж байна.
PS зохиолч уншигчид, тайлбарлагчидтай харилцдаг (англи хэл дээр).
Эх сурвалж: www.habr.com