Би Prometheus экспортлогч Kube Eagle-ийг бүтээсэн. Энэ нь жижиг, дунд кластеруудын нөөцийг илүү сайн ойлгоход тусалдаг гайхалтай зүйл болсон. Эцэст нь би машинуудын зөв төрлийг сонгож, ажлын ачаалалд зориулсан хэрэглээний нөөцийн хязгаарыг тохируулсан учраас би хэдэн зуун доллар хэмнэсэн.
Би танд ашиг тусын талаар хэлье , гэхдээ эхлээд би юунаас болж шуугиан дэгдээсэн, яагаад өндөр чанартай хяналт шаардлагатай байгааг тайлбарлах болно.
Би 4-50 зангилааны хэд хэдэн кластерыг удирдаж байсан. Кластер бүр нь 200 хүртэлх микро үйлчилгээ, програмуудыг агуулдаг. Одоо байгаа техник хангамжийг илүү сайн ашиглахын тулд ихэнх байршуулалтыг тэсрэх боломжтой RAM болон CPU-ийн нөөцөөр тохируулсан. Ингэснээр pods шаардлагатай бол бэлэн нөөцийг авч болох бөгөөд нэгэн зэрэг энэ зангилааны бусад програмуудад саад болохгүй. За, гайхалтай биш гэж үү?
Хэдийгээр кластер нь харьцангуй бага CPU (8%) болон RAM (40%) зарцуулдаг байсан ч зангилаа дээр байгаа санах ойн хэмжээнээс илүү санах ойг хуваарилахыг оролдох үед бид pods-ыг урьдчилан сэргийлэх асуудалтай байнга тулгарч байсан. Тэр үед бид Kubernetes нөөцийг хянах цорын ганц хяналтын самбартай байсан. Үүн шиг:
Зөвхөн cAdvisor хэмжигдэхүүн бүхий Grafana хяналтын самбар
Ийм самбартай бол санах ой, CPU их хэмжээгээр иддэг зангилаануудыг харахад асуудал биш юм. Асуудлын гол нь шалтгаан нь юу болохыг олж мэдэх явдал юм. Будлагуудыг байранд нь байлгахын тулд мэдээж бүх pods дээр баталгаатай нөөцийг (хүссэн нөөцийн хязгаартай тэнцүү) тохируулж болно. Гэхдээ энэ нь техник хангамжийн хамгийн ухаалаг хэрэглээ биш юм. Кластер нь хэдэн зуун гигабайт санах ойтой байсан бол зарим зангилаа өлсөж байсан бол зарим нь 4-10 ГБ-ын нөөцтэй байв.
Kubernetes хуваарь гаргагч нь ажлын ачааллыг боломжит нөөцөөр жигд бус хуваарилсан нь харагдаж байна. Kubernetes төлөвлөгч нь өөр өөр тохиргоог харгалзан үздэг: ойр дотно байдал, хор хөнөөл, хүлцлийн дүрэм, боломжтой зангилаануудыг хязгаарлаж болох зангилаа сонгогчид. Гэхдээ миний хувьд ийм зүйл байгаагүй бөгөөд зангилаа бүр дээр хүссэн нөөцөөс хамааран хонхорцог төлөвлөгдсөн.
Хамгийн их үнэ төлбөргүй нөөцтэй бөгөөд хүсэлтийн нөхцлийг хангасан зангилааг pod-д сонгосон. Зангилаанууд дээрх хүссэн нөөцүүд нь бодит хэрэглээтэй таарахгүй байгааг бид олж мэдсэн бөгөөд Kube Eagle болон түүний нөөцийг хянах чадвар нь эндээс аврах ажилд ирсэн юм.
Би бараг бүх Kubernetes кластеруудыг зөвхөн ашиглан хянадаг и . Node Exporter нь I/O болон диск, CPU, RAM ашиглалтын статистик мэдээллийг өгдөг бол Kube State Metrics нь хүсэлт, CPU болон санах ойн нөөцийн хязгаар зэрэг Kubernetes объектын хэмжүүрүүдийг харуулдаг.
Бид хэрэглээний хэмжигдэхүүнийг Графана дахь хүсэлт, хязгаарлалтын хэмжигдэхүүнтэй хослуулах хэрэгтэй бөгөөд дараа нь бид асуудлын талаархи бүх мэдээллийг авах болно. Энэ нь энгийн мэт санагдаж байгаа ч хоёр хэрэгсэл нь шошгуудыг өөр өөрөөр нэрлэдэг бөгөөд зарим хэмжүүрт мета өгөгдлийн шошго огт байдаггүй. Kube Eagle бүх зүйлийг өөрөө хийдэг бөгөөд самбар дараах байдалтай байна.
Бид нөөц бололцоогоор олон асуудлыг шийдэж, тоног төхөөрөмжийг хэмнэж чадсан.
- Зарим хөгжүүлэгчид бичил үйлчилгээнд хичнээн их нөөц хэрэгтэйг мэддэггүй байсан (эсвэл зүгээр л санаа зовдоггүй). Бидэнд нөөцийн буруу хүсэлтийг олох арга байгаагүй - үүний тулд бид хэрэглээ, хүсэлт, хязгаарлалтыг мэдэх хэрэгтэй. Одоо тэд Prometheus хэмжигдэхүүнийг харж, бодит хэрэглээг хянаж, хүсэлт, хязгаарлалтыг тохируулдаг.
- JVM програмууд нь чадах чинээгээрээ RAM ашигладаг. Хог цуглуулагч нь санах ойг 75% -иас дээш ашигласан тохиолдолд л гаргадаг. Ихэнх үйлчилгээнүүд тэсрэх санах ойтой байдаг тул үүнийг үргэлж JVM эзэлдэг. Тиймээс эдгээр бүх Java үйлчилгээнүүд нь хүлээгдэж байснаас хамаагүй их хэмжээний RAM-ыг идэж байсан.
- Зарим програмууд хэт их санах ой шаардсан бөгөөд Kubernetes төлөвлөгч эдгээр зангилааг бусад аппликешнүүдэд өгөөгүй ч үнэндээ тэдгээр нь бусад зангилаанаас илүү чөлөөтэй байсан. Нэг хөгжүүлэгч санамсаргүйгээр хүсэлтэд нэмэлт цифр нэмж, том хэмжээний RAM-г шүүрэн авчээ: 20 биш харин 2 ГБ. Хэн ч анзаарсангүй. Аппликешн нь 3 хуулбартай байсан тул 3 зангилаа өртсөн.
- Бид нөөцийн хязгаарлалтыг нэвтрүүлж, зөв хүсэлтээр pod-уудыг дахин төлөвлөж, бүх зангилааны техник хангамжийн ашиглалтын хамгийн тохиромжтой тэнцвэрийг олж авсан. Хэд хэдэн зангилааг бүхэлд нь хааж болох байсан. Тэгээд дараа нь бид буруу машинууд (санах ойд биш CPU-д чиглэсэн) байгааг олж харсан. Бид төрлийг өөрчилж, хэд хэдэн зангилааг устгасан.
Үр дүн
Кластер дахь тэсрэх боломжтой нөөцийн тусламжтайгаар та боломжтой техник хангамжийг илүү үр дүнтэй ашигладаг боловч Kubernetes хуваарьлагч нь нөөцийн хүсэлт дээр үндэслэн pods хуваарь гаргадаг бөгөөд энэ нь маш их юм. Хоёр шувууг нэг чулуугаар алахын тулд: бэрхшээлээс зайлсхийх, нөөцийг бүрэн ашиглахын тулд танд сайн хяналт хэрэгтэй. Ийм учраас энэ нь ашигтай байх болно (Prometheus экспортлогч болон Grafana хяналтын самбар).
Эх сурвалж: www.habr.com