Анхаарна уу. орчуулга.: Европын аялал жуулчлалын нэгтгэгч Омиогийн энэхүү нүдийг олсон түүх нь уншигчдыг үндсэн онолоос Кубернетесийн тохиргооны гайхалтай практик нарийн ширийн зүйлс рүү аваачдаг. Ийм тохиолдлуудтай танилцах нь таны алсын харааг өргөжүүлэхээс гадна өчүүхэн бус асуудлаас урьдчилан сэргийлэхэд тусалдаг.
Та хэзээ нэгэн цагт өргөдөл гацаж, эрүүл мэндийн үзлэгт хариу өгөхөө больж, яагаад гэдгийг нь ойлгохгүй байсан уу? Боломжит нэг тайлбар нь CPU-ийн нөөцийн квотын хязгаарлалттай холбоотой юм. Үүнийг бид энэ нийтлэлд ярих болно.
TL, DR:
Хэрэв та CFS квотын алдаатай Линуксийн цөмийн хувилбарыг ашиглаж байгаа бол бид Kubernetes дахь CPU-ийн хязгаарлалтыг идэвхгүй болгохыг (эсвэл Kubelet дахь CFS квотыг идэвхгүй болгохыг) зөвлөж байна. Гол нь ноцтой ба хэт саармагжуулах, саатуулахад хүргэдэг алдаа.
Омио хотод Бүх дэд бүтцийг Кубернетес удирддаг. Манай улсын болон харьяалалгүй бүх ажлын ачаалал зөвхөн Kubernetes дээр ажилладаг (бид Google Kubernetes Engine ашигладаг). Сүүлийн зургаан сарын хугацаанд бид санамсаргүй удаашралыг ажиглаж эхэлсэн. Аппликешнүүд хөлддөг эсвэл эрүүл мэндийн шалгалтанд хариу өгөхөө больсон, сүлжээнд холболт тасарсан гэх мэт. Энэ зан нь биднийг удаан хугацаанд гайхшруулж, эцэст нь бид асуудлыг нухацтай авч үзэхээр шийдсэн.
Өгүүллийн хураангуй:
- Контейнер болон Кубернетын тухай хэдэн үг;
- CPU-ийн хүсэлт, хязгаарлалт хэрхэн хэрэгждэг вэ;
- CPU-ийн хязгаарлалт нь олон цөмт орчинд хэрхэн ажилладаг;
- CPU-ийн бууралтыг хэрхэн хянах вэ;
- Асуудлын шийдэл ба нюансууд.
Контейнер болон Кубернетын тухай хэдэн үг
Кубернетес бол үндсэндээ дэд бүтцийн ертөнцөд орчин үеийн стандарт юм. Үүний гол үүрэг бол контейнерын найрал хөгжим юм.
Контейнер
Өмнө нь бид сервер дээр ажиллахын тулд Java JAR/WAR, Python Eggs, эсвэл executables гэх мэт олдворуудыг үүсгэх шаардлагатай байсан. Гэсэн хэдий ч тэдгээрийг ажиллуулахын тулд нэмэлт ажил хийх шаардлагатай болсон: ажиллах цагийн орчин (Java/Python) суулгах, шаардлагатай файлуудыг зөв газарт байрлуулах, үйлдлийн системийн тодорхой хувилбартай нийцтэй байдлыг хангах гэх мэт. Өөрөөр хэлбэл, тохиргооны менежментэд (энэ нь ихэвчлэн хөгжүүлэгчид болон системийн администраторуудын хооронд маргаан үүсгэдэг) анхаарал хандуулах шаардлагатай байв.
Контейнер бүх зүйлийг өөрчилсөн. Одоо олдвор нь савны дүрс юм. Үүнийг зөвхөн програм төдийгүй бүрэн гүйцэд гүйцэтгэх орчин (Java/Python/...), түүнчлэн урьдчилан суулгасан, ашиглахад бэлэн шаардлагатай файлууд/багцуудыг агуулсан өргөтгөсөн гүйцэтгэх файл хэлбэрээр илэрхийлж болно. гүйх. Контейнеруудыг ямар ч нэмэлт алхамгүйгээр өөр сервер дээр байрлуулж, ажиллуулж болно.
Нэмж дурдахад, чингэлэгүүд өөрсдийн хамгаалагдсан хязгаарлагдмал орчинд ажилладаг. Тэд өөрсдийн виртуал сүлжээний адаптертай, хязгаарлагдмал хандалттай өөрийн файлын системтэй, үйл явцын өөрийн гэсэн шатлалтай, CPU болон санах ойн хязгаарлалттай гэх мэт. Энэ бүхэн нь Линуксийн цөмийн тусгай дэд систем болох нэрийн орон зайн ачаар хэрэгждэг.
Kubernetes
Өмнө дурьдсанчлан Кубернетес бол контейнер найрал хөгжимчин юм. Энэ нь дараах байдлаар ажилладаг: та түүнд машинуудын цөөрөм өгөөд: "Хөөе, Кубернетес, миний контейнерын 2 процессор, тус бүр 3 ГБ санах ойтой арван тохиолдлыг ажиллуулж, үргэлжлүүлэн ажиллуулцгаая!" Бусдыг нь Кубернетес хариуцна. Энэ нь үнэ төлбөргүй багтаамжийг олж, контейнеруудыг ажиллуулж, шаардлагатай бол дахин эхлүүлэх, хувилбарыг өөрчлөх үед шинэчлэлтүүдийг гаргах гэх мэт. Үндсэндээ Kubernetes нь танд техник хангамжийн бүрэлдэхүүн хэсгийг салгах боломжийг олгож, програмуудыг байрлуулах, ажиллуулахад тохиромжтой олон төрлийн системийг бий болгодог.
Энгийн хүний үүднээс Кубернетес
Кубернетес дэх хүсэлт, хязгаарлалт гэж юу вэ
За, бид савнууд болон Кубернетесийг бүрхсэн. Нэг машин дээр олон сав суулгаж болно гэдгийг бид бас мэднэ.
Нийтийн орон сууцтай ижил төстэй байдлыг зурж болно. Өргөн байр (машин / нэгж) авч, хэд хэдэн түрээслэгчид (контейнер) түрээслүүлнэ. Кубернетес реалтороор ажилладаг. Асуулт гарч ирдэг, түрээслэгчид хоорондоо зөрчилдөхгүй байх вэ? Тэдний нэг нь хагас өдрийн турш угаалгын өрөө зээлэхээр шийдсэн бол яах вэ?
Энд хүсэлт, хязгаарлалтууд гарч ирдэг. CPU авагч зөвхөн төлөвлөлтийн зорилгоор шаардлагатай. Энэ нь савны "хүслийн жагсаалт" шиг зүйл бөгөөд энэ нь хамгийн тохиромжтой зангилааг сонгоход хэрэглэгддэг. Үүний зэрэгцээ CPU хязгаар түрээсийн гэрээтэй харьцуулж болно - бид чингэлэгт зориулж нэгжийг сонгонгуут, the чадахгүй тогтоосон хязгаараас давж гарах. Эндээс л асуудал үүсч байна...
Кубернетес дэх хүсэлт, хязгаарлалтыг хэрхэн хэрэгжүүлдэг вэ
Кубернетес нь CPU-ийн хязгаарлалтыг хэрэгжүүлэхийн тулд цөмд суурилуулсан тохируулагч механизмыг (цагийн циклийг алгасах) ашигладаг. Хэрэв програм хязгаараас хэтэрсэн бол тохируулагчийг идэвхжүүлнэ (өөрөөр хэлбэл CPU-ийн цөөн цикл хүлээн авдаг). Санах ойд зориулсан хүсэлт, хязгаарлалт нь өөр өөр зохион байгуулалттай байдаг тул тэдгээрийг илрүүлэхэд хялбар байдаг. Үүнийг хийхийн тулд pod-ийн хамгийн сүүлийн дахин ачаалах төлөвийг шалгана уу: энэ нь "OOMKilled" эсэх. K8s хэмжигдэхүүнийг бүлгээрээ бус зөвхөн хэрэглээгээр нь ашиглах боломжтой тул CPU-ийг багасгах нь тийм ч хялбар биш юм.
CPU-ийн хүсэлт
CPU-ийн хүсэлт хэрхэн хэрэгждэг
Энгийн болгох үүднээс жишээ болгон 4 цөмт CPU-тэй машин ашиглан үйл явцыг харцгаая.
K8s нь нөөцийн (санах ой, процессор) хуваарилалтыг хянахын тулд хяналтын бүлгийн механизмыг (бүлэгүүд) ашигладаг. Үүнд шаталсан загвар байдаг: хүүхэд эцэг эхийн бүлгийн хязгаарыг өвлөн авдаг. Түгээлтийн дэлгэрэнгүй мэдээллийг виртуал файлын системд хадгалдаг (/sys/fs/cgroup). Процессорын хувьд ийм байна /sys/fs/cgroup/cpu,cpuacct/*.
K8s файлыг ашигладаг cpu.share процессорын нөөцийг хуваарилах. Манай тохиолдолд эх бүлэг нь CPU-ийн нөөцийн 4096 хувийг авдаг - боломжтой процессорын хүчин чадлын 100% (1 цөм = 1024; энэ нь тогтмол утга). Үндэс бүлэг нь бүртгэлтэй үр удмын хувь хэмжээнээс хамааран нөөцийг пропорциональ байдлаар хуваарилдаг cpu.share, мөн тэд эргээд үр удамтайгаа ижил зүйлийг хийдэг гэх мэт. Ердийн Кубернетес зангилаа дээр үндсэн бүлэг гурван хүүхэдтэй: system.slice, user.slice и kubepods. Эхний хоёр дэд бүлгийг системийн чухал ачаалал болон K8-аас гадуурх хэрэглэгчийн программуудын хооронд нөөцийг хуваарилахад ашигладаг. Сүүлчийнх - kubepods — pods хооронд нөөцийг хуваарилахын тулд Кубернетес бүтээсэн.
Дээрх диаграмм нь эхний болон хоёр дахь дэд бүлгүүд тус бүрийг хүлээн авсан болохыг харуулж байна 1024 хуваарь, kuberpod дэд бүлэгт хуваарилагдсан 4096 хувьцаа Энэ нь яаж боломжтой вэ: эцсийн эцэст эх бүлэгт зөвхөн хандах боломжтой 4096 хувьцаа, түүний үр удамын хувьцааны нийлбэр энэ тооноос хамаагүй давсан байна (6144)? Гол нь утга нь логик утга учиртай тул Линукс төлөвлөгч (CFS) үүнийг CPU-ийн нөөцийг пропорциональ хуваарилахад ашигладаг. Манай тохиолдолд эхний хоёр бүлэг хүлээн авдаг 680 бодит хувьцаа (16,6-ийн 4096%), үлдсэн хэсгийг kubepod авдаг 2736 хувьцаа Сул зогсолтын үед эхний хоёр бүлэгт хуваарилагдсан нөөцийг ашиглахгүй.
Аз болоход, төлөвлөгч нь ашиглагдаагүй CPU-ийн нөөцийг дэмий үрэхээс зайлсхийх механизмтай байдаг. Энэ нь "сул зогсолт" хүчин чадлыг дэлхийн сан руу шилжүүлдэг бөгөөд үүнээс нэмэлт процессорын хүч шаардлагатай бүлгүүдэд хуваарилагддаг (бөглөх алдагдлаас зайлсхийхийн тулд шилжүүлгийг багцаар хийдэг). Үүнтэй төстэй аргыг удамшлын бүх үр удамд хэрэглэдэг.
Энэхүү механизм нь процессорын хүчийг шударга хуваарилж, хэн ч бусдаас нөөцийг "хулгайлахгүй" байх боломжийг олгодог.
CPU-ийн хязгаар
K8-ийн хязгаарлалт, хүсэлтийн тохиргоо ижил төстэй харагдаж байгаа ч хэрэгжилт нь эрс ялгаатай: энэ нь хамгийн төөрөгдүүлсэн мөн хамгийн бага баримтжуулсан хэсэг.
K8s ажиллаж байна хязгаарыг хэрэгжүүлэх. Тэдний тохиргоог файлд зааж өгсөн болно cfs_period_us и cfs_quota_us cgroup санд (файл бас тэнд байрладаг cpu.share).
Ялгаатай нь cpu.share, квотыг үндэслэнэ цаг хугацаа, боломжтой процессорын хүчин чадал дээр биш. cfs_period_us хугацааны (эрин үе) үргэлжлэх хугацааг зааж өгдөг - энэ нь үргэлж 100000 мкс (100 мс) байна. K8-д энэ утгыг өөрчлөх сонголт байгаа ч одоогоор зөвхөн альфа хувилбарт ашиглах боломжтой. Хуваарьлагч нь ашигласан квотыг дахин эхлүүлэхийн тулд эрин үеийг ашигладаг. Хоёр дахь файл cfs_quota_us, эрин үе бүрт боломжтой цагийг (квот) зааж өгнө. Үүнийг мөн микросекундээр зааж өгсөн болохыг анхаарна уу. Квот нь эриний уртаас хэтэрч болно; өөрөөр хэлбэл 100 мс-ээс их байж болно.
16 цөмт машинуудын хоёр хувилбарыг харцгаая (бидний Omio-д байдаг хамгийн түгээмэл төрлийн компьютер):
Хувилбар 1: 2 урсгал ба 200 мс хязгаар. Даралт байхгүй
Хувилбар 2: 10 хэлхээ ба 200 мс хязгаар. Тохируулга 20 мс-ийн дараа эхэлж, процессорын нөөцөд хандах хандалт дахин 80 мс дараа сэргэнэ.
Та CPU-ийн хязгаарыг тогтоосон гэж бодъё 2 цөм; Кубернетес энэ утгыг 200 мс болгон хөрвүүлнэ. Энэ нь сав нь хамгийн ихдээ 200ms CPU-ийн хугацааг багасгахгүйгээр ашиглах боломжтой гэсэн үг юм.
Эндээс л зугаа цэнгэл эхэлдэг. Дээр дурдсанчлан, боломжит квот нь 200 мс байна. Хэрэв та зэрэгцээ ажиллаж байгаа бол арван 12 цөмт машин дээрх утаснууд (2-р хувилбарын зургийг харна уу), бусад бүх подволд идэвхгүй байх үед квот ердөө 20 мс (10 * 20 мс = 200 мс-ээс хойш) дуусч, энэ подволын бүх хэлхээ унжина. » (тохируулагч) дараагийн 80 мс. Өмнө дурьдсан , үүнээс болж хэт их саармагжуулж, сав нь одоо байгаа квотыг ч биелүүлж чадахгүй байна.
Хонхорхойд тохируулагчийг хэрхэн үнэлэх вэ?
Зүгээр л pod руу нэвтэрч, ажиллуулна уу cat /sys/fs/cgroup/cpu/cpu.stat.
-
nr_periods- төлөвлөгчийн хугацааны нийт тоо; -
nr_throttled- найрлага дахь тохируулсан үеүүдийн тооnr_periods; -
throttled_time- наносекундэд хуримтлагдсан тохируулсан хугацаа.
Үнэхээр юу болоод байна аа?
Үүний үр дүнд бид бүх програмуудад өндөр тохируулга авдаг. Заримдаа тэр ордог нэг ба хагас удаа тооцоолсноос илүү хүчтэй!
Энэ нь янз бүрийн алдаа гарахад хүргэдэг - бэлэн байдлыг шалгах алдаа, контейнер хөлдөх, сүлжээний холболт тасрах, үйлчилгээний дуудлагын завсарлага. Энэ нь эцсийн дүндээ хоцролт, алдааны түвшин нэмэгдэхэд хүргэдэг.
Шийдвэр ба үр дагавар
Энд бүх зүйл энгийн. Бид CPU-ийн хязгаарлалтаас татгалзаж, кластерууд дахь үйлдлийн системийн цөмийг алдааг зассан хамгийн сүүлийн хувилбар болгон шинэчилж эхэлсэн. Манай үйлчилгээн дэх алдааны тоо (HTTP 5xx) даруй мэдэгдэхүйц буурсан:
HTTP 5xx алдаа
Нэг чухал үйлчилгээний HTTP 5xx алдаа
Хариу өгөх хугацаа p95
Үйлчилгээний хүсэлтийн хоцролт, 95 дахь хувь
Үйл ажиллагааны зардал
Жишээ нь зарцуулсан цагийн тоо
Юу барих вэ?
Өгүүллийн эхэнд дурдсанчлан:
Нийтийн орон сууцтай адилтгаж болно ... Кубернетес реалторын үүрэг гүйцэтгэдэг. Гэхдээ түрээслэгчид хоорондоо зөрчилдөхөөс хэрхэн сэргийлэх вэ? Тэдний нэг нь хагас өдрийн турш угаалгын өрөө зээлэхээр шийдсэн бол яах вэ?
Эндээс барьж авлаа. Нэг хайхрамжгүй сав нь машин дээрх бүх CPU-ийн нөөцийг идэж болно. Хэрэв танд ухаалаг програмын стек байгаа бол (жишээлбэл, JVM, Go, Node VM зөв тохируулагдсан бол) энэ нь асуудал биш юм: та ийм нөхцөлд удаан хугацаанд ажиллах боломжтой. Гэхдээ хэрэв програмууд муу оновчтой эсвэл огт оновчгүй бол (FROM java:latest), нөхцөл байдал хяналтаас гарч болзошгүй. Omio дээр бид үндсэн хэлний стекийн зохих өгөгдмөл тохиргоо бүхий автоматжуулсан үндсэн Docker файлуудтай тул ийм асуудал гараагүй.
Бид хэмжигдэхүүнийг хянахыг зөвлөж байна (ашиглалт, ханалт ба алдаа), API саатал, алдааны түвшин. Үр дүн нь хүлээлтэд нийцэж байгаа эсэхийг шалгаарай.
лавлагаа
Энэ бол бидний түүх. Дараах материалууд юу болж байгааг ойлгоход ихээхэн тусалсан.
- ;
- ;
- ;
- ;
- - "Cpu throttling"-г хайж олоорой.
Kubernetes алдааны тайлан:
- ;
- ;
- .
Та практик дээрээ үүнтэй төстэй асуудалтай тулгарсан уу эсвэл савтай үйлдвэрлэлийн орчинд тохируулагчтай холбоотой туршлагатай юу? Сэтгэгдэл хэсэгт түүхээ хуваалцаарай!
Орчуулагчийн жич
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «".
Эх сурвалж: www.habr.com