Хөөе Хабр!
Бид Exness платформын багийг төлөөлдөг. Өмнө нь манай хамт олон энэ тухай нийтлэл бичсэн байсан . Өнөөдөр бид Kubernetes руу шилжүүлэх үйлчилгээний туршлагаа хуваалцахыг хүсч байна.
Юуны өмнө хэлэлцэхийг илүү сайн ойлгохын тулд бид танд хэдэн тоо санал болгож байна.
- Манай хөгжлийн хэлтэс нь 100 гаруй хүнээс бүрддэг бөгөөд үүнд бие даасан QA, DevOps болон Scrum процессуудтай 10 гаруй өөр баг багтдаг. Хөгжлийн стек - Python, PHP, C++, Java болон Golang.
- Туршилтын болон үйлдвэрлэлийн орчны хэмжээ тус бүр нь 2000 орчим сав байна. Тэд Rancher v1.6-г өөрсдийн виртуалчлал дээр болон VMware доор ажиллуулж байна.
Хүсэл тэмүүлэл
Тэдний хэлснээр юу ч үүрд үргэлжлэхгүй бөгөөд Ранчер 1.6 хувилбарыг дэмжихээ нэлээд эрт зарласан. Тиймээ, гурван жил гаруйн хугацаанд бид үүнийг хэрхэн бэлдэж, үүссэн асуудлыг шийдэж сурсан ч хэзээ ч засч залруулах боломжгүй асуудлуудтай байнга тулгардаг. Rancher 1.6 нь эрх олгох ясжуулсан системтэй бөгөөд та бараг бүх зүйлийг хийх эсвэл юу ч хийх боломжгүй юм.
Хэдийгээр өмчийн виртуалчлал нь өгөгдөл хадгалах, түүний аюулгүй байдалд илүү их хяналт тавих боломжийг олгодог боловч компанийн байнгын өсөлт, төслийн тоо, тэдэнд тавигдах шаардлагуудыг харгалзан үзэхэд хэцүү байсан үйл ажиллагааны зардал гаргасан.
Бид IaC стандартыг дагаж мөрдөж, шаардлагатай бол аль ч газарзүйн байршилд, худалдагчийн түгжээгүйгээр хүчин чадлыг хурдан олж авах, мөн үүнийг хурдан орхихыг хүссэн.
эхний алхам
Юуны өмнө бид багууд илүү хурдан хөгжлийн мөчлөгтэй байх, эрчим хүч өгдөг платформтой харилцах үйл ажиллагааны зардлыг багасгах боломжийг олгодог орчин үеийн технологи, шийдлүүдэд найдахыг хүссэн.
Мэдээжийн хэрэг, бидний санаанд хамгийн түрүүнд бодсон зүйл бол Кубернетес байсан ч бид сэтгэл хөдөлсөнгүй, энэ нь зөв сонголт эсэхийг шалгахын тулд бага зэрэг судалгаа хийсэн. Бид зөвхөн нээлттэй эх сурвалжийн шийдлүүдийг үнэлсэн бөгөөд шударга бус тулалдаанд Кубернетес болзолгүйгээр ялсан.
Дараа нь кластер үүсгэх хэрэгсэл сонгох тухай асуулт гарч ирэв. Бид хамгийн алдартай шийдлүүдийг харьцуулсан: kops, kubespray, kubeadm.
Эхлээд kubeadm нь "унадаг дугуй" зохион бүтээгч шиг хэтэрхий төвөгтэй зам мэт санагдаж байсан бөгөөд kops нь хангалттай уян хатан чанаргүй байв.
Тэгээд ялагч нь:
Бид өөрсдийн виртуалчлал болон AWS-тэй туршилт хийж, хүн бүр ижил "кластер"-ыг хуваалцдаг өмнөх нөөцийн менежментийн загвартай бараг төстэй зүйлийг дахин бүтээхийг хичээж эхэлсэн. Одоо бид 10 жижиг виртуал машинуудын анхны кластертай болсон бөгөөд тэдгээрийн хэд нь AWS-д байрладаг. Бид тэнд багуудыг шилжүүлэх гэж оролдож эхэлсэн, бүх зүйл "сайн" юм шиг санагдаж, түүх дуусч магадгүй байсан ч...
Эхний асуудлууд
Ansible бол kubespray дээр суурилдаг зүйл бөгөөд энэ нь IaC-г дагаж мөрдөх боломжийг олгодог хэрэгсэл биш юм: зангилаануудыг ашиглалтад оруулах/ашиглах үед ямар нэг зүйл байнга буруу болж, ямар нэгэн хөндлөнгийн оролцоо шаардлагатай байсан бөгөөд өөр өөр үйлдлийн системүүдийг ашиглах үед тоглоомын ном өөр өөрөөр ажилладаг байв. . Кластер дахь баг, зангилааны тоо өсөхийн хэрээр тоглоомын дэвтрийг дуусгахад илүү урт хугацаа шаардагдаж байгааг анзаарч эхэлсэн бөгөөд үүний үр дүнд бидний дээд амжилт 3,5 цаг болсон, таных яах вэ? 🙂
Мөн kubespray бол зүгээр л Ansible юм шиг санагдаж байгаа бөгөөд бүх зүйл эхлээд харахад ойлгомжтой, гэхдээ:
Аялалын эхэнд хүчин чадлыг зөвхөн AWS болон виртуалчлал дээр эхлүүлэх даалгавар байсан боловч дараа нь ихэвчлэн тохиолддог шиг шаардлага өөрчлөгддөг.
Үүнээс харахад манай нөөцийг нэг зохион байгуулалтын системд нэгтгэх хуучин загвар нь кластерууд маш алслагдсан бөгөөд өөр өөр үйлчилгээ үзүүлэгчээр удирддаг тохиолдолд тохиромжгүй болох нь тодорхой болсон.
Цаашид илүү. Бүх багууд нэг кластер дотор ажиллах үед буруу суулгасан NodeSelectors бүхий янз бүрийн үйлчилгээнүүд өөр багийн "гадаадын" хост руу нисч, тэнд байгаа нөөцийг ашиглах боломжтой байсан бөгөөд хэрэв бохирдол тохируулагдсан бол энэ эсвэл өөр үйлчилгээ ажиллахгүй байна гэсэн хүсэлт байнга ирдэг. хүний хүчин зүйлээс болж зөв хуваарилагдаагүй. Өөр нэг асуудал бол зардлыг тооцоолох, ялангуяа үйлчилгээг зангилаагаар түгээхтэй холбоотой асуудлуудыг авч үзэх явдал байв.
Тусдаа түүх бол ажилчдад эрх олгох явдал байв: баг бүр кластерын "толгойд" байж, түүнийг бүрэн удирдахыг хүсч байсан бөгөөд энэ нь багууд үндсэндээ бие биенээсээ хараат бус байдаг тул бүрэн уналтад хүргэж болзошгүй юм.
Яаж?
Дээр дурдсан зүйлс болон багуудын илүү бие даасан байх хүслийг харгалзан бид энгийн дүгнэлтийг хийсэн: нэг баг - нэг кластер.
Тиймээс бид хоёр дахь нь байна:
Тэгээд гурав дахь кластер:
Дараа нь бид бодож эхлэв: нэг жилийн дараа манай багууд нэгээс олон кластертай болно гэж бодъё? Газарзүйн өөр өөр бүс нутагт, жишээлбэл, эсвэл өөр өөр үйлчилгээ үзүүлэгчийн хяналтанд байдаг уу? Тэдний зарим нь зарим туршилтын түр зуурын кластерийг хурдан байршуулахыг хүсэх болно.
Бүтэн Kubernetes ирэх болно! Энэ бол нэг төрлийн MultiKubernetes юм.
Үүний зэрэгцээ бид бүгдээрээ эдгээр бүх кластеруудыг ямар нэгэн байдлаар хадгалах, тэдгээрт хандах хандалтыг хялбархан удирдах, мөн шинээр бий болгох, хуучин кластеруудыг гар ажиллагаагүйгээр устгах шаардлагатай болно.
Кубернетесийн ертөнцөд аялж эхэлснээс хойш хэсэг хугацаа өнгөрсөн бөгөөд бид боломжтой шийдлүүдийг дахин судлахаар шийдсэн. Энэ нь зах зээл дээр аль хэдийн бий болсон нь тогтоогдсон - Rancher 2.2.
Судалгааны эхний шатанд Rancher Labs 2-р хувилбарын анхны хувилбарыг аль хэдийн гаргасан байсан ч гаднаас хамааралгүй хэд хэдэн параметр бүхий савыг хөөргөх эсвэл албан ёсны HELM Chart ашиглан маш хурдан өсгөх боломжтой байсан ч энэ нь бүдүүлэг мэт санагдаж байв. Бид энэ шийдвэрт найдах эсэхээ мэдэхгүй байсан бөгөөд үүнийг боловсруулах эсвэл хурдан орхих уу. UI дээрх кластер = товшилтын парадигм нь өөрөө бидэнд тохирохгүй байсан бөгөөд бид RKE-тэй холбогдохыг хүсээгүй, учир нь энэ нь маш нарийн төвлөрсөн хэрэгсэл юм.
Rancher 2.2 хувилбар нь аль хэдийн илүү ажиллахад тохиромжтой дүр төрхтэй байсан бөгөөд өмнөх хувилбаруудын хамт олон гадаад үйлчилгээ үзүүлэгчидтэй нэгтгэх, эрхийг түгээх нэг цэг, kubeconfig файлууд, kubectl-ийг эхлүүлэх гэх мэт олон сонирхолтой шинж чанаруудтай байсан. UI, nested namespaces буюу төслүүдэд өөрийн эрх бүхий зураг.
Мөн Rancher 2-ын эргэн тойронд аль хэдийн байгуулагдсан нийгэмлэг байсан бөгөөд үүнийг удирдахын тулд HashiCorp Terraform нэртэй үйлчилгээ үзүүлэгчийг байгуулсан нь бүх зүйлийг нэгтгэхэд бидэнд тусалсан.
Юу болов
Үүний үр дүнд бид Rancher-ийг ажиллуулж байгаа, бусад бүх кластерууд болон түүнтэй холбогдсон олон кластеруудад хандах боломжтой жижиг кластертай болсон бөгөөд эдгээрийн аль нэгэнд нь ldap директорт хэрэглэгч нэмэхээс үл хамааран хандах боломжтой болсон. хаана байрладаг, ямар үйлчилгээ үзүүлэгчийн нөөцийг ашигладаг.
Gitlab-ci болон Terraform програмуудыг ашиглан үүлэн үйлчилгээ үзүүлэгч эсвэл манай дэд бүтцэд дурын тохиргооны кластер үүсгэж, тэдгээрийг Rancher-тэй холбох боломжийг олгодог системийг бий болгосон. Энэ бүгдийг IaC хэв маягаар хийдэг бөгөөд кластер бүрийг репозитороор дүрсэлж, төлөвийг нь хувилбараар нь гаргадаг. Үүний зэрэгцээ ихэнх модулиуд нь гадаад агуулахаас холбогдсон тул хувьсагчийг дамжуулах эсвэл жишээнүүдийн хувийн тохиргоог тайлбарлахад л үлддэг бөгөөд энэ нь кодын давталтын хувийг бууруулахад тусалдаг.
Мэдээжийн хэрэг, бидний аялал дуусаагүй байгаа бөгөөд аливаа кластерын бүртгэл, хэмжигдэхүүнтэй ажиллах нэг цэг, үйлчилгээний тор, олон кластерт ачааллыг удирдах гитоп болон бусад олон сонирхолтой ажлууд байна. Бидний туршлага танд сонирхолтой байх болно гэж найдаж байна!
Уг нийтлэлийг платформын инженерүүд А.Антипов, А.Гануш нар бичсэн.
Эх сурвалж: www.habr.com