Cube-on-cube, metaclusters, honeycombs, нөөцийн хуваарилалт

Цагаан будаа. 1. Alibaba Cloud дээрх Кубернетес экосистем

2015 оноос хойш Alibaba Cloud Container Service for Kubernetes (ACK) нь Alibaba Cloud дахь хамгийн хурдацтай хөгжиж буй үүлэн үйлчилгээний нэг юм. Энэ нь олон тооны үйлчлүүлэгчдэд үйлчилдэг бөгөөд Алибабагийн дотоод дэд бүтэц болон компанийн бусад үүлэн үйлчилгээг дэмждэг.

Дэлхийн жишигт нийцсэн үүлэн үйлчилгээ үзүүлэгчдийн ижил төрлийн контейнер үйлчилгээний нэгэн адил бидний тэргүүлэх чиглэл бол найдвартай байдал, хүртээмж юм. Тиймээс хэдэн арван мянган Kubernetes кластерт зориулж өргөтгөх боломжтой, дэлхийн хэмжээнд хүртээмжтэй платформыг бий болгосон.

Энэ нийтлэлд бид үүлэн дэд бүтэц дээр олон тооны Kubernetes кластеруудыг удирдах туршлага, мөн үндсэн платформын архитектурыг хуваалцах болно.

нэвтрэх

Kubernetes нь үүлэн доторх олон төрлийн ажлын ачааллын де факто стандарт болсон. Зурагт үзүүлсэн шиг. Дээрх 1-ээс харахад одоо улам олон Alibaba Cloud програмууд Kubernetes кластерууд дээр ажиллаж байна: төлөв болон харьяалалгүй програмууд, мөн програмын менежерүүд. Кубернетес менежмент нь дэд бүтэц барьж, засвар үйлчилгээ хийдэг инженерүүдийн хувьд үргэлж сонирхолтой бөгөөд ноцтой хэлэлцүүлгийн сэдэв байсаар ирсэн. Alibaba Cloud гэх мэт үүл үйлчилгээ үзүүлэгчдийн тухай ярихад масштабын асуудал гарч ирдэг. Kubernetes кластеруудыг ийм хэмжээнд хэрхэн удирдах вэ? Бид 10 зангилаатай Кубернетес кластеруудыг удирдах шилдэг туршлагуудыг аль хэдийн авч үзсэн. Мэдээжийн хэрэг, энэ нь масштабтай холбоотой сонирхолтой асуудал юм. Гэхдээ өөр нэг хэмжүүр байдаг: тоо хэмжээ кластерууд өөрсдөө.

Бид энэ сэдвийг олон ACK хэрэглэгчидтэй ярилцсан. Тэдний ихэнх нь хэдэн зуу биш юмаа гэхэд хэдэн арван жижиг эсвэл дунд хэмжээний Кубернетес кластеруудыг ажиллуулахаар сонгодог. Үүнд сайн шалтгаан бий: болзошгүй хохирлыг хязгаарлах, өөр өөр багуудад кластеруудыг тусгаарлах, туршилт хийх виртуал кластер үүсгэх. Хэрэв ACK нь энэхүү хэрэглээний загвараар дэлхийн үзэгчдэд үйлчлэхийг зорьж байгаа бол 20 гаруй бүс нутагт олон тооны кластеруудыг найдвартай, үр дүнтэй удирдах ёстой.

Цагаан будаа. 2. Маш олон тооны Kubernetes кластеруудыг удирдахад тулгардаг асуудлууд

Энэ хэмжээнд кластеруудыг удирдахад тулгарч буй гол бэрхшээлүүд юу вэ? Зурагт үзүүлсэнчлэн шийдвэрлэх дөрвөн асуудал байна.

• Нэг төрлийн бус байдал

ACK нь стандарт, сервергүй, Edge, Windows болон бусад хэд хэдэн кластеруудыг дэмжих ёстой. Өөр өөр кластерууд нь өөр өөр сонголт, бүрэлдэхүүн хэсэг, байршуулах загвар шаарддаг. Зарим үйлчлүүлэгчид тухайн тохиолдлуудад тохируулга хийхэд тусламж хэрэгтэй байдаг.

• Төрөл бүрийн кластерын хэмжээ

Бөөгнөрөл нь янз бүрийн хэмжээтэй байдаг: хэд хэдэн хонхорцогтой хос зангилаанаас эхлээд хэдэн мянган хонхорхойтой хэдэн арван мянган зангилаа хүртэл. Нөөцийн шаардлага ч маш их ялгаатай. Нөөцийн буруу хуваарилалт нь гүйцэтгэлд нөлөөлж, бүр бүтэлгүйтэлд хүргэж болзошгүй.

• Өөр өөр хувилбарууд

Кубернетес маш хурдан хөгжиж байна. Шинэ хувилбарууд нь хэдэн сар тутамд гардаг. Үйлчлүүлэгчид шинэ боломжуудыг туршиж үзэхэд үргэлж бэлэн байдаг. Тиймээс тэд туршилтын ачааллыг Kubernetes-ийн шинэ хувилбарууд дээр, үйлдвэрлэлийн ачааллыг тогтвортой хувилбарууд дээр байрлуулахыг хүсч байна. Энэ шаардлагыг хангахын тулд ACK нь тогтвортой хувилбаруудыг хадгалахын зэрэгцээ Kubernetes-ийн шинэ хувилбаруудыг хэрэглэгчдэд байнга хүргэж байх ёстой.

• Аюулгүй байдлын нийцэл

Кластерууд нь өөр өөр бүс нутагт тархсан байдаг. Тиймээс тэд аюулгүй байдлын янз бүрийн шаардлага, албан ёсны дүрэм журмыг дагаж мөрдөх ёстой. Жишээлбэл, Европ дахь кластер нь GDPR-д нийцсэн байх ёстой бол Хятад дахь санхүүгийн үүл нь нэмэлт хамгаалалтын давхаргатай байх ёстой. Эдгээр шаардлагууд нь заавал байх ёстой бөгөөд тэдгээрийг үл тоомсорлох нь хүлээн зөвшөөрөгдөхгүй, учир нь энэ нь үүлэн платформын үйлчлүүлэгчдэд асар их эрсдэл үүсгэдэг.

ACK платформ нь дээрх асуудлуудын ихэнхийг шийдвэрлэхэд зориулагдсан. Одоогоор дэлхий даяар 10 мянга гаруй Kubernetes кластерийг найдвартай, тогтвортой удирдаж байна. Хэд хэдэн гол дизайн/архитектурын зарчмуудаар дамжуулан үүнд хэрхэн хүрсэнийг харцгаая.

Зураг төсөл

Куб-он-шоо ба зөгийн сархинаг

Төвлөрсөн шатлалаас ялгаатай нь үүрэн дээр суурилсан архитектур нь платформыг нэг мэдээллийн төвөөс хэтрүүлэх эсвэл гамшгийн үед сэргээн босгох хүрээг өргөжүүлэхэд ашиглагддаг.

Alibaba Cloud дахь бүс бүр хэд хэдэн бүсээс (AZ) бүрддэг бөгөөд ихэвчлэн тодорхой мэдээллийн төвтэй тохирдог. Томоохон бүс нутагт (жишээ нь Хуанжоу) ACK ажиллуулдаг олон мянган Kubernetes клиент кластерууд байдаг.

ACK нь Kubernetes-ийг өөрөө ашиглан эдгээр Кубернетес кластеруудыг удирддаг бөгөөд энэ нь бид үйлчлүүлэгчийн Kubernetes кластеруудыг удирдахын тулд ажиллаж байгаа Kubernetes метакластертай гэсэн үг юм. Энэ архитектурыг мөн "kube-on-kube" (KoK) гэж нэрлэдэг. Кластер байршуулах нь энгийн бөгөөд тодорхойлогддог тул KoK архитектур нь үйлчлүүлэгчийн кластеруудын удирдлагыг хялбаршуулдаг. Хамгийн чухал нь бид Kubernetes-ийн уугуул онцлогуудыг дахин ашиглах боломжтой. Жишээлбэл, API серверүүдийг байршуулах замаар удирдах, олон etcd-г удирдахын тулд etcd операторыг ашиглах. Ийм рекурс нь үргэлж онцгой таашаал авчирдаг.

Үйлчлүүлэгчдийн тооноос хамааран хэд хэдэн Kubernetes метакластеруудыг нэг бүс нутагт байрлуулдаг. Бид эдгээр метакластеруудыг эс гэж нэрлэдэг. Бүхэл бүтэн бүсийн бүтэлгүйтлээс хамгаалахын тулд ACK нь нэг бүс нутагт олон идэвхтэй байршуулалтыг дэмждэг: метакластер нь Kubernetes клиент кластерийн мастер бүрэлдэхүүн хэсгүүдийг олон бүсэд тарааж, тэдгээрийг нэгэн зэрэг, өөрөөр хэлбэл олон идэвхтэй горимд ажиллуулдаг. Мастерийн найдвартай байдал, үр ашгийг хангахын тулд ACK нь бүрэлдэхүүн хэсгүүдийн байршлыг оновчтой болгож, API сервер болон etcd нь бие биетэйгээ ойрхон байхыг баталгаажуулдаг.

Энэхүү загвар нь Kubernetes-ийг үр ашигтай, уян хатан, найдвартай удирдах боломжийг танд олгоно.

Метакластерын нөөцийн төлөвлөлт

Өмнө дурьдсанчлан, бүс тус бүрийн метакластерын тоо нь үйлчлүүлэгчдийн тооноос хамаарна. Гэхдээ ямар үед шинэ метакластер нэмэх вэ? Энэ бол нөөцийн төлөвлөлтийн ердийн асуудал юм. Дүрмээр бол одоо байгаа метакластерууд бүх нөөцөө шавхсан үед шинээр бий болгох нь заншилтай байдаг.

Жишээлбэл, сүлжээний нөөцийг авч үзье. KoK архитектурт үйлчлүүлэгчийн кластеруудын Kubernetes бүрэлдэхүүн хэсгүүдийг метакластерт pods хэлбэрээр байрлуулдаг. Бидний хэрэглэдэг Тервей (Зураг 3) нь Alibaba Cloud-аас чингэлэг сүлжээний менежментэд зориулагдсан өндөр гүйцэтгэлтэй залгаас юм. Энэ нь аюулгүй байдлын баялаг бодлогыг хангаж, Alibaba Cloud Elastic Networking Interface (ENI)-ээр дамжуулан үйлчлүүлэгчдийн виртуал хувийн үүл (VPC)-тэй холбогдох боломжийг олгодог. Сүлжээний нөөцийг метакластер дахь зангилаа, хонхорцог болон үйлчилгээнүүдэд үр дүнтэй хуваарилахын тулд бид виртуал хувийн үүлсийн метакластер доторх ашиглалтыг сайтар хянах ёстой. Сүлжээний нөөц дуусахад шинэ нүд үүснэ.

Мета кластер бүр дэх үйлчлүүлэгчийн кластерын оновчтой тоог тодорхойлохын тулд бид зардал, нягтралын шаардлага, нөөцийн квот, найдвартай байдлын шаардлага, статистикийг харгалзан үздэг. Энэ бүх мэдээлэлд үндэслэн шинэ метакластер байгуулах шийдвэрийг гаргадаг. Жижиг кластерууд ирээдүйд ихээхэн өргөжих боломжтой тул кластеруудын тоо өөрчлөгдөөгүй байсан ч нөөцийн хэрэглээ нэмэгддэг гэдгийг анхаарна уу. Бид ихэвчлэн кластер бүрт ургах хангалттай зай үлдээдэг.

Цагаан будаа. 3. Terway сүлжээний архитектур

Үйлчлүүлэгч кластерууд дахь шидтэний бүрэлдэхүүн хэсгүүдийг масштаблах

Шидтэний бүрэлдэхүүн хэсгүүд нь өөр өөр нөөцийн хэрэгцээтэй байдаг. Эдгээр нь кластер дахь зангилаа ба хонгилын тоо, APIServer-тэй харьцаж буй стандарт бус хянагч/операторуудын тооноос хамаарна.

ACK-д Kubernetes клиент кластер бүр хэмжээ болон ажиллах хугацааны шаардлагаар ялгаатай байдаг. Шидтэний бүрэлдэхүүн хэсгүүдийг байрлуулах бүх нийтийн тохиргоо байдаггүй. Хэрэв бид том үйлчлүүлэгчдэд бага нөөцийн хязгаарыг андуурсан бол түүний кластер ачааллыг даван туулах боломжгүй болно. Хэрэв та бүх кластеруудад консерватив өндөр хязгаар тогтоовол нөөцийг дэмий үрэх болно.

Найдвартай байдал, өртөг хоёрын хоорондох нарийн зөрүүг олохын тулд ACK төрлийн системийг ашигладаг. Тухайлбал, бид жижиг, дунд, том гэсэн гурван төрлийн кластерийг тодорхойлдог. Төрөл бүр нь тусдаа нөөцийн хуваарилалтын профайлтай байдаг. Төрөл нь шидтэний бүрэлдэхүүн хэсгүүдийн ачаалал, зангилааны тоо болон бусад хүчин зүйл дээр тулгуурлан тодорхойлогддог. Кластерын төрөл цаг хугацааны явцад өөрчлөгдөж болно. ACK нь эдгээр хүчин зүйлсийг байнга хянаж байдаг бөгөөд үүний дагуу дээш/доош бичиж болно. Кластерын төрлийг өөрчилсний дараа нөөцийн хуваарилалт нь хэрэглэгчийн хамгийн бага оролцоотойгоор автоматаар шинэчлэгддэг.

Бид энэ системийг илүү нарийн масштабаар сайжруулж, илүү нарийвчлалтай төрлийг шинэчлэхээр ажиллаж байгаа бөгөөд ингэснээр эдгээр өөрчлөлтүүд илүү саадгүй явагдаж, эдийн засгийн хувьд илүү ач холбогдолтой болно.

Цагаан будаа. 4. Ухаалаг олон үе шаттай төрөл солих

Үйлчлүүлэгч кластеруудын хувьсал нь цар хүрээтэй

Өмнөх хэсгүүдэд олон тооны Kubernetes кластеруудыг удирдах зарим асуудлыг авч үзсэн. Гэсэн хэдий ч шийдвэрлэх шаардлагатай өөр нэг асуудал бий: кластеруудын хувьсал.

Кубернетес бол үүл ертөнцийн "Линукс" юм. Энэ нь тасралтгүй шинэчлэгдэж, илүү модульчлагдсан болно. Бид хэрэглэгчдэдээ шинэ хувилбаруудыг байнга хүргэж, эмзэг байдлыг засч, одоо байгаа кластеруудыг шинэчлэхээс гадна олон тооны холбогдох бүрэлдэхүүн хэсгүүдийг (CSI, CNI, Device Plugin, Scheduler Plugin болон бусад олон) удирдах ёстой.

Kubernetes бүрэлдэхүүн хэсгийн менежментийг жишээ болгон авч үзье. Эхлэхийн тулд бид эдгээр бүх холбогдсон бүрэлдэхүүн хэсгүүдийг бүртгэх, удирдах төвлөрсөн системийг боловсруулсан.

Цагаан будаа. 5. Уян хатан, залгууртай эд ангиуд

Урагшлахаасаа өмнө шинэчлэлт амжилттай болсон эсэхийг шалгах хэрэгтэй. Үүнийг хийхийн тулд бид бүрэлдэхүүн хэсгүүдийн ажиллагааг шалгах системийг боловсруулсан. Шалгалт нь шинэчлэлтийн өмнө болон дараа хийгддэг.

Цагаан будаа. 6. Кластерийн бүрэлдэхүүн хэсгүүдийн урьдчилсан шалгалт

Эдгээр бүрэлдэхүүн хэсгүүдийг хурдан бөгөөд найдвартай шинэчлэхийн тулд тасралтгүй байршуулах систем нь хэсэгчилсэн ахиц (саарал), түр зогсоох болон бусад функцийг дэмждэг. Стандарт Kubernetes хянагч нь энэ хэрэглээнд тохиромжгүй. Тиймээс кластерийн бүрэлдэхүүн хэсгүүдийг удирдахын тулд бид залгаас болон туслах хяналтын модуль (хажуугийн удирдлага) зэрэг тусгай хянагчуудыг боловсруулсан.

Жишээлбэл, BroadcastJob хянагч нь ажилчдын машин бүрийн бүрэлдэхүүн хэсгүүдийг шинэчлэх эсвэл машин бүрийн зангилааг шалгах зориулалттай. Broadcast ажил нь DaemonSet шиг кластерын зангилаа бүр дээр pod ажиллуулдаг. Гэсэн хэдий ч DaemonSet нь pod-ыг үргэлж удаан ажиллуулдаг бол BroadcastJob үүнийг нураадаг. Нэвтрүүлгийн хянагч нь шинээр холбогдсон зангилаанууд дээр pod-уудыг ажиллуулж, шаардлагатай бүрэлдэхүүн хэсгүүдтэй зангилаануудыг эхлүүлдэг. 2019 оны XNUMX-р сард бид OpenKruise автоматжуулалтын хөдөлгүүрийн эх кодыг нээсэн бөгөөд бид өөрсдөө компанидаа ашигладаг.

Цагаан будаа. 7. OpenKurise нь бүх зангилаа дээр Broadcast даалгаврын гүйцэтгэлийг зохион байгуулдаг

Үйлчлүүлэгчдэд зөв кластерын тохиргоог сонгоход нь туслахын тулд бид сервергүй, ирмэг, Windows, нүцгэн металл профайл зэрэг урьдчилан тодорхойлсон профайлуудыг өгдөг. Ландшафт өргөжиж, үйлчлүүлэгчдийнхээ хэрэгцээ өсөхийн хэрээр бид уйтгартай тохиргооны процессыг хялбарчлахын тулд илүү олон профайл нэмэх болно.

Цагаан будаа. 8. Төрөл бүрийн хувилбаруудад зориулсан дэвшилтэт, уян хатан кластер профайл

Мэдээллийн төвүүд даяар ажиглагдах боломжтой байдал

Доорх зурагт үзүүлсэн шиг. 9-нд Alibaba Cloud Container үүлэн үйлчилгээг дэлхийн хорин бүс нутагт байршуулсан. Энэ цар хүрээг харгалзан үзвэл, ACK-ийн гол зорилгын нэг нь ажиллаж байгаа кластеруудын төлөв байдлыг хялбархан хянах бөгөөд ингэснээр үйлчлүүлэгч кластерт асуудал тулгарвал бид нөхцөл байдалд хурдан хариу өгөх болно. Өөрөөр хэлбэл, та бүх бүс нутаг дахь үйлчлүүлэгчдийн кластеруудаас бодит цаг хугацаанд статистик мэдээллийг үр дүнтэй, найдвартай цуглуулж, үр дүнг нүдээр харуулах боломжтой шийдлийг олох хэрэгтэй.

Цагаан будаа. 9. Alibaba Cloud Container үйлчилгээг хорин бүс нутагт дэлхийн хэмжээнд нэвтрүүлэх

Kubernetes хяналтын олон системүүдийн нэгэн адил бид Prometheus-ийг үндсэн хэрэгсэл болгон ашигладаг. Мета кластер бүрийн хувьд Prometheus агентууд дараах хэмжүүрүүдийг цуглуулдаг.

• Хост нөөц (CPU, санах ой, диск гэх мэт) болон сүлжээний зурвасын өргөн гэх мэт үйлдлийн системийн хэмжүүрүүд.
• kube-apiserver, kube-контроллер-менежер, kube-хуваарьлагч зэрэг метакластер болон үйлчлүүлэгчийн кластерын удирдлагын системийн хэмжүүрүүд.
• kubernetes-state-metrics болон cadvisor-ын хэмжүүрүүд.
• диск бичих хугацаа, өгөгдлийн сангийн хэмжээ, зангилаа хоорондын холбоосын дамжуулах чадвар гэх мэт гэх мэт хэмжүүрүүд.

Дэлхийн статистикийг ердийн олон давхаргат нэгтгэх загвар ашиглан цуглуулдаг. Мета кластер бүрийн хяналтын өгөгдлийг эхлээд бүс бүрт нэгтгэж, дараа нь ерөнхий дүр зургийг харуулсан төв сервер рүү илгээдэг. Бүх зүйл холбооны механизмаар явагддаг. Дата төв бүрийн Prometheus сервер нь тухайн өгөгдлийн төвөөс хэмжигдэхүүнүүдийг цуглуулдаг бөгөөд төв Prometheus сервер нь хяналтын өгөгдлийг нэгтгэх үүрэгтэй. AlertManager нь төв Prometheus-тай холбогдож, шаардлагатай бол DingTalk, цахим шуудан, SMS гэх мэтээр сэрэмжлүүлэг илгээдэг. Дүрслэл - Grafana-г ашиглах.

Зураг 10-д хяналтын системийг гурван түвшинд хувааж болно.

• Хилийн түвшин

Төвөөс хамгийн алслагдсан давхарга. Prometheus Edge сервер нь метакластер бүрт ажилладаг бөгөөд нэг сүлжээний домэйн доторх мета болон клиент кластеруудаас хэмжигдэхүүнүүдийг цуглуулдаг.

• Каскадын түвшин

Prometheus каскадын давхаргын үүрэг нь олон бүс нутгаас мониторингийн мэдээлэл цуглуулах явдал юм. Эдгээр серверүүд нь Хятад, Ази, Европ, Америк зэрэг томоохон газарзүйн нэгжүүдийн түвшинд ажилладаг. Кластер өсөхийн хэрээр бүс нутгийг хувааж болох ба дараа нь шинэ том бүс бүрт каскадын түвшний Prometheus сервер гарч ирнэ. Энэ стратегийн тусламжтайгаар та шаардлагатай хэмжээгээр жигд масштабтай болно.

• Төв түвшин

Төв Prometheus сервер нь бүх каскадын серверүүдтэй холбогдож, эцсийн өгөгдлийг нэгтгэх ажлыг гүйцэтгэдэг. Найдвартай байдлын үүднээс ижил каскадын серверт холбогдсон өөр өөр бүсэд хоёр төв Prometheus жишээг суулгасан.

Цагаан будаа. 10. Прометей холбооны механизм дээр суурилсан дэлхийн олон түвшний мониторингийн архитектур

Хураангуй

Кубернетес дээр суурилсан үүлэн шийдлүүд нь манай салбарыг өөрчилсөөр байна. Alibaba Cloud контейнерийн үйлчилгээ нь найдвартай, найдвартай, өндөр гүйцэтгэлтэй хостингоор хангадаг - энэ нь Kubernetes-ийн шилдэг клоуд хостингуудын нэг юм. Alibaba Cloud баг нь Нээлттэй эх сурвалж болон нээлттэй эхийн нийгэмлэгийн зарчимд маш их итгэдэг. Бид үүлэн технологийг ашиглах, удирдах чиглэлээр мэдлэгээ үргэлжлүүлэн хуваалцах нь гарцаагүй.

Эх сурвалж: www.habr.com