Kubernetes болон автоматжуулалтын ачаар хоёр цагийн дотор үүлэн рүү хэрхэн шилжих вэ

Kubernetes болон автоматжуулалтын ачаар хоёр цагийн дотор үүлэн рүү хэрхэн шилжих вэ

URUS компани Kubernetes-ийг өөр өөр хэлбэрээр туршиж үзсэн: нүцгэн металл дээр, Google Cloud дээр бие даасан байршуулалт, дараа нь платформоо Mail.ru Cloud Solutions (MCS) үүл рүү шилжүүлсэн. Игорь Шишкин тэд шинэ үүлэн үйлчилгээ үзүүлэгчийг хэрхэн сонгож, хоёр цагийн дотор түүн рүү хэрхэн шилжиж чадсан тухайгаа ярьжээ (t3ran), URUS-ийн ахлах системийн администратор.

URUS юу хийдэг вэ?

Хотын орчны чанарыг сайжруулах олон арга зам байдгийн нэг нь байгаль орчинд ээлтэй болгох явдал юм. URUS - Smart Digital Services компани яг ийм зүйл дээр ажиллаж байна. Энд тэд аж ахуйн нэгжүүдэд байгаль орчны чухал үзүүлэлтүүдийг хянах, байгаль орчинд үзүүлэх сөрөг нөлөөллийг бууруулахад туслах шийдлүүдийг хэрэгжүүлдэг. Мэдрэгч нь агаарын найрлага, дуу чимээний түвшин болон бусад үзүүлэлтүүдийн талаарх мэдээллийг цуглуулж, дараа нь URUS-Ekomon нэгдсэн платформд дүн шинжилгээ хийх, зөвлөмж гаргах зорилгоор илгээдэг.

URUS хэрхэн дотроос ажилладаг

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

Kubernetes болон автоматжуулалтын ачаар хоёр цагийн дотор үүлэн рүү хэрхэн шилжих вэ
H2S агууламжийн мониторингийн график нь ойролцоох үйлдвэрээс шөнийн цагаар тогтмол ялгардаг утааг харуулж байна

Бидний URUS-д ашигладаг төхөөрөмжүүд нь хүрээлэн буй орчны нөхцөл байдлыг үнэлэхийн тулд тодорхой хийн агууламж, дуу чимээний түвшин болон бусад өгөгдлийг цуглуулдаг хэд хэдэн мэдрэгчийг агуулдаг. Мэдрэгчийн нарийн тоог үргэлж тодорхой даалгавраар тодорхойлдог.

Kubernetes болон автоматжуулалтын ачаар хоёр цагийн дотор үүлэн рүү хэрхэн шилжих вэ
Хэмжилтийн онцлогоос хамааран мэдрэгч бүхий төхөөрөмжүүдийг барилгын хана, шон болон бусад дурын газруудад байрлуулж болно. Ийм төхөөрөмж бүр мэдээлэл цуглуулж, нэгтгэж, өгөгдөл хүлээн авах гарц руу илгээдэг. Тэнд бид өгөгдлийг удаан хугацаанд хадгалах зорилгоор хадгалж, дараагийн шинжилгээнд зориулж урьдчилан боловсруулдаг. Шинжилгээний үр дүнд бидний олж авдаг хамгийн энгийн жишээ бол AQI гэж нэрлэгддэг агаарын чанарын индекс юм.

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

Бид өгөгдлийг хэрхэн хадгалах. Нүцгэн металл дээрх Кубернетесийн түүх

URUS байгаль орчны мониторингийн төсөл нь хэд хэдэн мэдээллийн агуулахтай. Нэгд нь бид "түүхий" өгөгдлийг хадгалдаг - бидний төхөөрөмжөөс шууд хүлээн авсан зүйл. Энэхүү хадгалалт нь хуучин хуурцаг дээрх шиг бүх үзүүлэлтийн түүхтэй "соронзон" соронзон хальс юм. Хоёрдахь төрлийн хадгалалтыг урьдчилан боловсруулсан өгөгдөлд ашигладаг - мэдрэгчүүдийн хоорондох холболт, төхөөрөмжийн уншилтын талаархи мета өгөгдлөөр баяжуулсан төхөөрөмжүүдийн өгөгдөл, байгууллага, байршил гэх мэт. Энэ мэдээлэл нь тодорхой үзүүлэлт хэрхэн байгааг динамикаар үнэлэх боломжийг олгодог. тодорхой хугацаанд өөрчлөгдсөн. Бид "түүхий" өгөгдлийн санг нөөц болгон ашигладаг бөгөөд хэрэв шаардлагатай бол урьдчилан боловсруулсан өгөгдлийг сэргээхэд ашигладаг.

Хэдэн жилийн өмнө бид хадгалах асуудлаа шийдэх гэж байхад бид хоёр платформын сонголттой байсан: Kubernetes болон OpenStack. Гэхдээ сүүлийнх нь маш аймшигтай харагддаг тул (үүнд итгэлтэй байхын тулд архитектурыг нь хараарай) бид Кубернетес дээр суурьшсан. Үүнийг дэмжсэн өөр нэг аргумент бол харьцангуй энгийн програм хангамжийн хяналт, нөөцийн дагуу техник хангамжийн зангилааг хүртэл илүү уян хатан тайрах чадвар байв.

Kubernetes-ийг өөрөө эзэмшихийн зэрэгцээ бид өгөгдөл хадгалах арга замыг судалж, Кубернетес дэх бүх хадгалалтаа өөрийн техник хангамж дээр хадгалахын зэрэгцээ маш сайн туршлага олж авсан. Бидний Кубернетес дээр амьдарч байсан бүх зүйл: бүрэн хадгалалт, хяналтын систем, CI/CD. Кубернетес бол бидний хувьд нэгдмэл платформ болсон.

Гэхдээ бид Кубернетестэй үйлчилгээ болгон хамтран ажиллахыг хүсч, дэмжлэг, хөгжилд оролцохгүй байхыг хүссэн. Нэмж хэлэхэд, бид үүнийг нүцгэн металл дээр хадгалахад хичнээн их зардал гаргасанд дургүй байсан бөгөөд бидэнд байнга хөгжүүлэлт хэрэгтэй байсан! Жишээлбэл, хамгийн эхний ажлуудын нэг бол Kubernetes Ingress хянагчдыг манай байгууллагын сүлжээний дэд бүтцэд нэгтгэх явдал байв. Тухайн үед DNS бүртгэл, IP хаягийг хуваарилах гэх мэт программчлагдсан нөөцийн менежментэд юу ч бэлэн байгаагүй гэдгийг бодоход энэ нь төвөгтэй ажил юм. Дараа нь бид гадаад өгөгдөл хадгалах туршилт хийж эхэлсэн. Бид PVC хянагчийг хэзээ ч хэрэгжүүлж чадаагүй ч энэ нь тусгай мэргэжилтнүүд шаарддаг маш том ажлын хэсэг болох нь тодорхой болсон.

Google Cloud Platform руу шилжих нь түр зуурын шийдэл юм

Үүнийг үргэлжлүүлэх боломжгүй гэдгийг бид ойлгож, өгөгдлөө нүцгэн металлаас Google Cloud Platform руу шилжүүлсэн. Үнэн хэрэгтээ, тэр үед Оросын компанид тийм ч сонирхолтой сонголт байгаагүй: Google Cloud Platform-ээс гадна зөвхөн Амазон үүнтэй төстэй үйлчилгээг санал болгодог байсан ч бид Google-ийн шийдэл дээр шийдсэн хэвээр байна. Дараа нь энэ нь бидэнд эдийн засгийн хувьд илүү ашигтай, Upstream-д ойр, тэр ч байтугай Google өөрөө үйлдвэрлэлийн PoC Kubernetes-ийн нэг төрөл гэдгийг дурдахгүй мэт санагдсан.

Манай үйлчлүүлэгчдийн тоо өсөхийн хэрээр анхны томоохон асуудал гарч ирэв. Хувийн мэдээллийг хадгалах шаардлагатай болсон үед бид Google-тэй хамтран ажиллаж, Оросын хууль тогтоомжийг зөрчих, эсвэл ОХУ-д өөр хувилбар хайх гэсэн сонголттой тулгарсан. Сонголтыг бүхэлд нь урьдчилан таамаглах боломжтой байсан. 🙂

Бид хамгийн тохиромжтой үүлэн үйлчилгээг хэрхэн олж харав

Хайлтын эхэнд бид ирээдүйн үүлэн үйлчилгээ үзүүлэгчээс юу авахыг хүсч байгаагаа аль хэдийн мэдэж байсан. Бид ямар үйлчилгээ хайж байсан бэ?

  • Хурдан, уян хатан. Ингэснээр бид ямар ч үед хурдан шинэ зангилаа нэмэх эсвэл ямар нэг зүйлийг байрлуулах боломжтой.
  • Хямдхан. Бид нөөц бололцоо хязгаарлагдмал байсан тул санхүүгийн асуудалд маш их санаа зовж байсан. Бид Кубернетестэй хамтран ажиллах хүсэлтэй байгаагаа аль хэдийн мэдэж байсан бөгөөд одоо энэ шийдлийг ашиглах үр ашгийг нэмэгдүүлэх эсвэл дор хаяж хадгалахын тулд түүний өртөгийг багасгах нь даалгавар байв.
  • Автоматжуулсан. Бид менежер, утасны дуудлага, яаралтай горимд хэдэн арван зангилааг гараар босгох шаардлагатай нөхцөл байдалгүйгээр API-ээр дамжуулан үйлчилгээтэй ажиллахаар төлөвлөж байсан. Бидний ихэнх үйл явц автоматжуулсан тул бид үүлэн үйлчилгээнээс ижил зүйлийг хүлээж байсан.
  • ОХУ-ын серверүүдтэй. Мэдээжийн хэрэг, бид Оросын хууль тогтоомж, 152-ФЗ-ийг дагаж мөрдөхөөр төлөвлөж байсан.

Тухайн үед Орост Kubernetes aaS үйлчилгээ үзүүлэгч цөөхөн байсан бөгөөд үйлчилгээ үзүүлэгчийг сонгохдоо бид тэргүүлэх чиглэлээ алдахгүй байх нь чухал байсан. Бидний ажиллаж эхэлсэн бөгөөд одоо ч хамтран ажиллаж байгаа Mail.ru Cloud Solutions баг нь бидэнд API дэмжлэг, Horizon-ийг багтаасан тохиромжтой хяналтын самбар бүхий бүрэн автомат үйлчилгээ үзүүлсэн - үүний тусламжтайгаар бид дурын тооны зангилаануудыг хурдан өсгөх боломжтой болсон.

Бид хоёр цагийн дотор MCS рүү хэрхэн шилжиж чадсан бэ

Ийм алхам хийхэд олон компани хүндрэл, бэрхшээл тулгардаг боловч манайд тийм ч байсангүй. Бид азтай байсан: шилжүүлэлт эхлэхээс өмнө бид Кубернетес дээр ажиллаж байсан тул гурван файлыг засч, шинэ үүлэн платформ болох MCS дээр үйлчилгээгээ эхлүүлсэн. Тэр үед бид эцэст нь нүцгэн металлыг орхиж, Google Cloud Platform дээр амьдарч байсныг танд сануулъя. Тиймээс, нүүлгэн шилжүүлэлт нь өөрөө хоёр цагаас илүүгүй хугацаа шаардагдахаас гадна бидний төхөөрөмжөөс өгөгдлийг хуулбарлахад бага зэрэг хугацаа (нэг цаг) зарцуулсан. Тэр үед бид Spinnaker (Тасралтгүй хүргэх үйлчилгээ үзүүлэх олон үүлэн CD үйлчилгээ) аль хэдийн ашиглаж байсан. Бид үүнийг шинэ кластерт хурдан нэмж, ердийнхөөрөө үргэлжлүүлэн ажиллав.

Хөгжлийн үйл явц болон CI/CD-ийн автоматжуулалтын ачаар URUS дахь Kubernetes-ийг нэг мэргэжилтэн (мөн би) хариуцдаг. Зарим үе шатанд өөр нэг системийн администратор надтай хамт ажиллаж байсан боловч дараа нь бид бүх үндсэн горимыг автоматжуулсан бөгөөд бидний үндсэн бүтээгдэхүүн дээр илүү олон үүрэг даалгавар гарч ирсэн тул нөөцийг үүнд чиглүүлэх нь утга учиртай болсон.

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

Хэрэв би өөрийн туршлагыг Google Cloud Platform-той харьцуулах юм бол тэдний хувьд санал хүсэлтийн товчлуур хаана байгааг ч мэдэхгүй байсан, учир нь энэ нь зүгээр л шаардлагагүй байсан. Хэрэв ямар нэгэн асуудал гарвал Google өөрөө нэг талын мэдэгдэл илгээдэг. Гэхдээ MCS-ийн хувьд Оросын үйлчлүүлэгчид газарзүйн хувьд ч, оюун санааны хувьд ч аль болох ойр байдаг нь том давуу тал гэж би бодож байна.

Ирээдүйд үүлтэй ажиллахыг бид хэрхэн харж байна

Одоо бидний ажил Кубернетестэй нягт холбоотой бөгөөд энэ нь дэд бүтцийн зорилтуудын үүднээс бидэнд бүрэн нийцдэг. Тиймээс бид ердийн ажлуудыг хялбарчлах, шинийг автоматжуулах, үйлчилгээний тогтвортой байдал, найдвартай байдлыг нэмэгдүүлэх зорилгоор шинэ туршлага, үйлчилгээг байнга нэвтрүүлж байгаа хэдий ч хаашаа ч шилжих бодолгүй байна... Бид одоо Chaos Monkey үйлчилгээг (ялангуяа , бид chaoskube ашигладаг, гэхдээ энэ нь үзэл баримтлалыг өөрчлөхгүй: ), анх Netflix үүсгэсэн. Chaos Monkey нэг энгийн зүйлийг хийдэг: энэ нь санамсаргүй үед санамсаргүй Kubernetes pod-ийг устгадаг. Энэ нь манай үйлчилгээ n–1 тохиолдлын тоогоор хэвийн ажиллахад зайлшгүй шаардлагатай тул бид өөрсдийгөө аливаа асуудалд бэлэн байхад сургадаг.

Одоо би гуравдагч талын шийдлүүдийг ашиглах нь залуу компаниудын хувьд цорын ганц зөв зүйл гэж харж байна. Ихэвчлэн аяллынхаа эхэнд тэд хүний ​​нөөц, санхүүгийн хувьд хязгаарлагдмал байдаг бөгөөд өөрсдийн үүл эсвэл дата төвийг барьж, засварлах нь хэтэрхий үнэтэй бөгөөд хөдөлмөр их шаарддаг. Үүлэн үйлчилгээ үзүүлэгч нь эдгээр зардлыг багасгах боломжийг олгодог бөгөөд та эндээс одоо, одоо үйлчилгээ явуулахад шаардлагатай нөөцийг хурдан олж авах боломжтой бөгөөд үүний дараа эдгээр нөөцийн төлбөрийг төлөх боломжтой. URUS компанийн хувьд бид одоохондоо үүлэн доторх Kubernetes-д үнэнч байх болно. Гэхдээ бид газарзүйн хувьд тэлэх эсвэл тодорхой тоног төхөөрөмж дээр суурилсан шийдлүүдийг хэрэгжүүлэх шаардлагатай байж магадгүй юм хэн мэдлээ. Эсвэл зарцуулсан нөөцийн хэмжээ нь хуучин үеийнх шиг нүцгэн металл дээр Кубернетесийг зөвтгөх болно. 🙂

Үүлэн үйлчилгээтэй ажиллахдаа бид юу сурсан

Бид Kubernetes-ийг нүцгэн металл дээр ашиглаж эхэлсэн бөгөөд тэнд ч гэсэн энэ нь өөрийнхөөрөө сайн байсан. Гэхдээ түүний давуу талууд нь үүлэн доторх aaS бүрэлдэхүүн хэсэг болох нь тодорхой болсон. Хэрэв та зорилго тавьж, бүх зүйлийг аль болох автоматжуулж чадвал борлуулагчийг түгжихээс зайлсхийж, үүлэн үйлчилгээ үзүүлэгчдийн хооронд шилжихэд хэдэн цаг шаардагдах бөгөөд мэдрэлийн эсүүд бидэнтэй хамт үлдэх болно. Бид бусад компаниудад зөвлөгөө өгөх боломжтой: хэрэв та хязгаарлагдмал нөөцтэй, хөгжлийн хамгийн дээд хурдтай өөрийн (үүл) үйлчилгээгээ эхлүүлэхийг хүсвэл яг одоо үүлэн нөөцийг түрээслэх замаар эхлүүлж, Forbes таны тухай бичсэний дараа дата төвөө байгуул.

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

сэтгэгдэл нэмэх