Анхаарна уу. орчуулга.: GitLab дээр Kubernetes үрчлэгдсэн нь компанийн өсөлтөд нөлөөлж буй хоёр гол хүчин зүйлийн нэг гэж тооцогддог. Гэсэн хэдий ч саяхныг хүртэл GitLab.com онлайн үйлчилгээний дэд бүтэц нь виртуал машинууд дээр баригдсан байсан бөгөөд ердөө нэг жилийн өмнө K8s руу шилжиж эхэлсэн бөгөөд одоо болтол дуусаагүй байна. Энэ нь хэрхэн болдог, төсөлд оролцож буй инженерүүд ямар дүгнэлт хийдэг тухай GitLab SRE инженерийн саяхан бичсэн нийтлэлийг орчуулан хүргэж байгаадаа таатай байна.
Жил орчмын хугацаанд манай дэд бүтцийн хэлтэс GitLab.com дээр ажилладаг бүх үйлчилгээг Kubernetes руу шилжүүлж байна. Энэ хугацаанд бид зөвхөн Кубернетес рүү үйлчилгээ шилжүүлэхээс гадна шилжилтийн үед хайбрид байршуулалтыг удирдахтай холбоотой сорилтуудтай тулгарсан. Бидний олж авсан үнэ цэнэтэй сургамжуудыг энэ өгүүллээр хэлэлцэх болно.
GitLab.com-ын эхэн үеэс эхлэн серверүүд нь виртуал машинууд дээр үүлэн дотор ажилладаг байсан. Эдгээр виртуал машинуудыг тогооч удирдаж, манайхыг ашиглан суулгадаг . Хэрэв програмыг шинэчлэх шаардлагатай бол CI дамжуулах хоолойг ашиглан серверийн флотыг зохицуулалттай, дараалсан байдлаар шинэчлэхээс бүрдэнэ. Энэ арга нь удаан, бага зэрэг боловч - GitLab.com нь офлайн хэрэглэгчидтэй адил суулгац, тохиргооны практикийг ашигладаг болохыг баталгаажуулдаг (өөрийгөө удирддаг) Үүний тулд манай Линукс багцуудыг ашиглан GitLab суулгацууд.
GitLab-ийн хуулбарыг суулгаж, тохируулахдаа нийгэмлэгийн жирийн гишүүдийн мэдэрдэг бүх уй гашуу, баяр баясгаланг мэдрэх нь туйлын чухал учраас бид энэ аргыг ашигладаг. Энэ арга нь хэсэг хугацаанд сайн ажилласан боловч GitLab дээрх төслийн тоо 10 саяас давахад энэ нь бидний өргөтгөх, байршуулах хэрэгцээг хангахаа больсныг бид ойлгосон.
Kubernetes болон үүлд суурилсан GitLab руу хийх эхний алхамууд
Төсөл нь 2017 онд байгуулагдсан GitLab-ийг үүлэн хэрэглээнд бэлтгэх, мөн GitLab-ийг Кубернетес кластер дээр суулгах боломжийг хэрэглэгчдэд олгох. GitLab-ийг Kubernetes руу шилжүүлснээр SaaS платформын өргөтгөх чадварыг нэмэгдүүлж, байршуулалтыг хялбарчилж, тооцоолох нөөцийн үр ашгийг дээшлүүлнэ гэдгийг бид тэр үед мэдэж байсан. Үүний зэрэгцээ, манай програмын олон функц нь NFS хуваалтуудаас хамаардаг бөгөөд энэ нь виртуал машинаас шилжих явцыг удаашруулсан юм.
Клоуд болон Кубернетес рүү чиглэсэн түлхэлт нь манай инженерүүдэд аажмаар шилжих шилжилтийг төлөвлөх боломжийг олгосон бөгөөд ингэснээр бид шинэ функцуудыг үргэлжлүүлэн хөгжүүлэхийн зэрэгцээ програмын сүлжээний хадгалалтаас хамаарах зарим хамаарлыг орхисон. Бид 2019 оны зун шилжилт хөдөлгөөнийг төлөвлөж эхэлснээс хойш эдгээр хязгаарлалтуудын ихэнх нь шийдэгдсэн бөгөөд GitLab.com-ыг Кубернетес рүү шилжүүлэх үйл явц одоо амжилттай явагдаж байна!
Kubernetes дахь GitLab.com-ийн онцлогууд
GitLab.com-ийн хувьд бид бүх програмын урсгалыг зохицуулдаг нэг бүс нутгийн GKE кластер ашигладаг. Шилжилтийн (аль хэдийн төвөгтэй) нарийн төвөгтэй байдлыг багасгахын тулд бид орон нутгийн хадгалалт эсвэл NFS-д найддаггүй үйлчилгээнүүдэд анхаарлаа хандуулдаг. GitLab.com нь голчлон цул Rails кодын баазыг ашигладаг бөгөөд бид ажлын ачааллын шинж чанарт тулгуурлан урсгалыг өөр өөр төгсгөлийн цэгүүд рүү чиглүүлдэг.
Frontend-ийн хувьд эдгээр төрлүүдийг вэб, API, Git SSH/HTTPS болон Бүртгэлийн хүсэлт гэж хуваадаг. Backend-ийн хувьд бид дараалалд байгаа ажлуудыг янз бүрийн шинж чанарын дагуу хуваадаг , энэ нь бидэнд янз бүрийн ажлын ачаалалд Үйлчилгээний Түвшний Зорилтууд (SLO) тохируулах боломжийг олгодог.
Эдгээр бүх GitLab.com үйлчилгээ нь өөрчлөгдөөгүй GitLab Helm диаграмыг ашиглан тохируулагдсан. Тохируулга нь дэд диаграммд хийгдсэн бөгөөд бид үйлчилгээг аажмаар кластер руу шилжүүлэх үед сонгон идэвхжүүлж болно. Бид Redis, Postgres, GitLab Pages, Gitaly зэрэг зарим төрийн үйлчилгээгээ шилжилт хөдөлгөөнд оруулахгүй байхаар шийдсэн ч Kubernetes-ийг ашигласнаар тогоочийн удирдаж буй VM-ийн тоог эрс багасгах боломжтой.
Kubernetes тохиргооны харагдах байдал ба менежмент
Бүх тохиргоог GitLab өөрөө удирддаг. Үүний тулд Terraform болон Helm дээр суурилсан гурван тохиргооны төслийг ашигладаг. Бид GitLab-г ажиллуулахын тулд GitLab-г өөрөө ашиглахыг хичээдэг ч үйл ажиллагааны хувьд тусдаа GitLab суулгацтай байдаг. Энэ нь GitLab.com байршуулалт, шинэчлэлтийг хийхдээ GitLab.com-ын бэлэн эсэхээс хамаарахгүй байхын тулд шаардлагатай.
Хэдийгээр бидний Kubernetes кластерт зориулсан дамжуулах шугамууд нь тусдаа GitLab суулгац дээр ажилладаг боловч дараах хаягууд дээр олон нийтэд нээлттэй кодын агуулахын толин тусгалууд байдаг:
- — GitLab Helm диаграмын GitLab.com тохиргооны хүрээ;
- - GitLab програмтай шууд холбоогүй үйлчилгээний тохиргоог агуулсан. Үүнд бүртгэл хөтлөх, кластер хянах тохиргоо, түүнчлэн PlantUML зэрэг нэгдсэн хэрэгслүүд орно;
- — Kubernetes болон хуучин VM дэд бүтцэд зориулсан Terraform тохиргоо. Энд та кластер өөрөө, зангилааны сан, үйлчилгээний бүртгэл, IP хаягийн захиалга зэрэг кластерыг ажиллуулахад шаардлагатай бүх нөөцийг тохируулна.
Өөрчлөлт хийх үед олон нийтэд харагдана. кластерт өөрчлөлт оруулахын өмнө SRE-ийн дүн шинжилгээ хийдэг нарийвчилсан ялгааны холбоосын хамт.
SRE-ийн хувьд холбоос нь GitLab суулгацын нарийвчилсан ялгааг бий болгодог бөгөөд үүнийг үйлдвэрлэхэд ашигладаг бөгөөд нэвтрэх боломж хязгаарлагдмал байдаг. Энэ нь үйл ажиллагааны төсөлд (зөвхөн SRE-д нээлттэй) нэвтрэхгүйгээр ажилчид болон олон нийтэд санал болгож буй тохиргооны өөрчлөлтийг харах боломжийг олгодог. Кодын нийтийн GitLab жишээг CI дамжуулах хоолойн хувийн жишээтэй хослуулснаар бид тохиргооны шинэчлэлтийн хувьд GitLab.com-оос хараат бус байдлыг хангахын зэрэгцээ нэг ажлын урсгалыг хангадаг.
Шилжин суурьших явцад бидний олж мэдсэн зүйл
Шилжилтийн явцад бид Кубернетес дэх шинэ шилжилт хөдөлгөөн, байршуулалтад ашиглах туршлага хуримтлуулсан.
1. Хүртээмжтэй бүс хоорондын замын хөдөлгөөний улмаас зардал нэмэгдсэн
GitLab.com дээрх Git репозиторын флотын өдөр тутмын гаралтын статистик (өдөрт байт)
Google сүлжээгээ бүс нутагт хуваадаг. Эдгээр нь эргээд хүртээмжийн бүсэд (AZ) хуваагддаг. Git хостинг нь их хэмжээний өгөгдөлтэй холбоотой тул сүлжээний гаралтыг хянах нь бидний хувьд чухал юм. Дотоод траффикийн хувьд гадагш гарах нь зөвхөн ижил боломжтой бүсэд байгаа тохиолдолд л үнэ төлбөргүй байдаг. Үүнийг бичиж байх үед бид ердийн ажлын өдөрт ойролцоогоор 100 TB өгөгдөлд үйлчилж байна (энэ нь зөвхөн Git репозиторуудад зориулагдсан). Манай хуучин VM-д суурилсан топологийн ижил виртуал машинд байрладаг үйлчилгээнүүд одоо өөр өөр Kubernetes pods дээр ажилладаг. Энэ нь өмнө нь VM-д локал байсан зарим траффик нь боломжтой бүсээс гадуур явж болзошгүй гэсэн үг юм.
Бүс нутгийн GKE кластерууд нь танд олон Боломжит бүсийг нөөцлөх боломжийг олгодог. Бид боломжийн талаар бодож байгаа их хэмжээний урсгалыг бий болгодог үйлчилгээний хувьд. Энэ нь кластерын түвшний нөөцийг хадгалахын зэрэгцээ гарах зардлыг бууруулна.
2. Хязгаарлалт, нөөцийн хүсэлт, масштаб
Registry.gitlab.com дээрх үйлдвэрлэлийн урсгалыг боловсруулж буй хуулбарын тоо. Замын хөдөлгөөний хамгийн дээд цэг нь UTC ~15:00 цагт.
Бидний шилжилт хөдөлгөөний түүх 2019 оны XNUMX-р сард анхны үйлчилгээ болох GitLab Контейнер Бүртгэлээ Кубернетес рүү шилжүүлснээр эхэлсэн. Чухал ач холбогдолтой, ачаалал ихтэй энэхүү үйлчилгээ нь гадны хамаарал багатай, харьяалалгүй программ учраас анхны шилжилт хөдөлгөөнд тохиромжтой сонголт байсан. Бидний тулгарсан хамгийн эхний асуудал бол зангилаанууд дээр санах ойн хомсдолоос болж олон тооны нүүлгэн шилжүүлэлтүүд байсан. Үүнээс болоод бид хүсэлт, хязгаарлалтыг өөрчлөх шаардлагатай болсон.
Санах ойн хэрэглээ цаг хугацааны явцад нэмэгддэг програмын хувьд хүсэлтийн бага утга (под тус бүрийн санах ойн нөөц) нь ашиглалтын "өгөөмөр" хатуу хязгаарлалттай хослуулан ханасан байдалд хүргэсэн болохыг олж мэдсэн. (ханалт) зангилаа болон өндөр түвшний нүүлгэн шилжүүлэлт. Энэ асуудлыг шийдэхийн тулд ийм байсан . Энэ нь зангилааны даралтыг арилгаж, зангилаанууд нь зангилаанд хэт их дарамт учруулахгүй амьдралын мөчлөгтэй болсон. Одоо бид өгөөмөр (бас бараг ижил) хүсэлт, хязгаарын утгуудтай шилжилт хөдөлгөөнийг эхлүүлж, шаардлагатай бол тохируулж байна.
3. Хэмжилт ба бүртгэл
Дэд бүтцийн хэлтэс нь суулгасан суулгацын хоцролт, алдааны түвшин, ханалт зэрэгт анхаарлаа хандуулдаг (SLO) -тай холбогдсон .
Өнгөрсөн нэг жилийн хугацаанд дэд бүтцийн салбарт гарсан гол үйл явдлуудын нэг нь ТҮГ-ын хяналт, хамтын ажиллагааг сайжруулсан явдал юм. SLO-ууд нь шилжилт хөдөлгөөний явцад анхааралтай ажиглаж байсан бие даасан үйлчилгээний зорилгоо тодорхойлох боломжийг бидэнд олгосон. Гэсэн хэдий ч ажиглалт сайжирсан ч хэмжигдэхүүн болон дохиоллын тусламжтайгаар асуудлыг шууд харах боломжгүй байдаг. Жишээлбэл, хоцролт болон алдааны түвшинд анхаарлаа хандуулснаар бид шилжилт хөдөлгөөнд хамрагдаж буй үйлчилгээний бүх ашиглалтын тохиолдлыг бүрэн хамрахгүй.
Зарим ачааллыг кластер руу шилжүүлсний дараа энэ асуудлыг бараг тэр даруй илрүүлсэн. Хүсэлтийн тоо бага боловч тохиргооноос маш тодорхой хамааралтай функцүүдийг шалгах шаардлагатай болсон үед энэ нь ялангуяа хурц болсон. Шилжилтийн гол сургамжуудын нэг нь хяналт тавихдаа зөвхөн хэмжүүр төдийгүй гуалин болон "урт сүүл"-ийг харгалзан үзэх шаардлагатай байв. (энэ тухай график дээр - ойролцоогоор. орчуул.) алдаа. Одоо шилжилт хөдөлгөөн бүрийн хувьд бид бүртгэлийн асуулгын дэлгэрэнгүй жагсаалтыг оруулсан болно (логийн асуулга) мөн асуудал гарвал нэг ээлжээс нөгөөд шилжүүлэх боломжтой тодорхой буцаах процедурыг төлөвлөх.
Хуучин VM дэд бүтэц болон Kubernetes-д суурилсан шинэ дэд бүтцэд ижил хүсэлтийг зэрэгцүүлэн өгөх нь өвөрмөц сорилт болж байна. Өргөх, шилжүүлэх шилжилт хөдөлгөөнөөс ялгаатай (хэрэглээг шинэ дэд бүтцэд "байгаагаар нь" хурдан шилжүүлэх; дэлгэрэнгүй мэдээллийг уншиж болно, жишээлбэл, - ойролцоогоор. орчуул.), "хуучин" VM болон Kubernetes дээр зэрэгцэн ажиллах нь хяналтын хэрэгслүүд нь хоёр орчинд нийцэж, хэмжигдэхүүнийг нэг харагдац болгон нэгтгэх чадвартай байхыг шаарддаг. Шилжилтийн үед байнгын ажиглалтад хүрэхийн тулд бид ижил хяналтын самбар болон бүртгэлийн асуулга ашиглах нь чухал юм.
4. Замын хөдөлгөөнийг шинэ кластер руу шилжүүлэх
GitLab.com-ын хувьд серверүүдийн нэг хэсэг нь зориулагдсан . Канар Парк нь манай дотоод төслүүдэд үйлчилдэг бөгөөд бас боломжтой . Гэхдээ энэ нь үндсэндээ дэд бүтэц, хэрэглээнд хийсэн өөрчлөлтийг турших зорилготой юм. Эхний шилжүүлсэн үйлчилгээ нь хязгаарлагдмал хэмжээний дотоод урсгалыг хүлээн авснаар эхэлсэн бөгөөд бид кластер руу бүх урсгалыг илгээхийн өмнө SLO-г хангасан эсэхийг баталгаажуулахын тулд энэ аргыг үргэлжлүүлэн ашигладаг.
Шилжилтийн хувьд энэ нь дотоод төслүүдийн хүсэлтийг эхлээд Кубернетес рүү илгээж, дараа нь бид HAProxy-ээр дамжуулан арын хэсгийн жинг өөрчилснөөр бусад урсгалыг кластер руу аажмаар шилжүүлдэг гэсэн үг юм. VM-ээс Кубернетес рүү шилжих явцад хуучин болон шинэ дэд бүтцийн хооронд урсгалыг хялбархан чиглүүлэх, үүний дагуу шилжилтийн дараах эхний хэдэн хоногт хуучин дэд бүтцийг буцаахад бэлэн байлгах нь маш ашигтай байсан нь тодорхой болсон.
5. Буурцагны нөөцийн хүчин чадал, ашиглалт
Бараг тэр даруй дараах асуудал илэрсэн: Бүртгэлийн үйлчилгээнд зориулсан pods хурдан ажиллаж эхэлсэн боловч Sidekiq-д зориулсан подкуудыг эхлүүлэх нь . Ажлыг хурдан боловсруулж, цар хүрээг нэмэгдүүлэх шаардлагатай ажилчдад зориулж Кубернетес рүү ажлын ачааллыг шилжүүлж эхлэхэд Sidekiq pods-ийн урт хугацаа нь асуудал болсон.
Энэ тохиолдолд сургамж нь Kubernetes's Horizontal Pod Autoscaler (HPA) нь замын хөдөлгөөний өсөлтийг сайн зохицуулдаг ч ажлын ачааллын шинж чанарыг харгалзан үзэх, савны нөөц хүчин чадлыг хуваарилах нь чухал юм (ялангуяа эрэлт жигд бус тархсан үед). Манай тохиолдолд ажлын байр гэнэт нэмэгдэж, хурдацтай томроход хүргэсэн бөгөөд энэ нь зангилааны сангийн хэмжээг томруулж амжихаас өмнө CPU-ийн нөөцөөр хангагдахад хүргэсэн.
Кластераас аль болох ихийг нь шахах уруу таталт үргэлж байдаг, гэвч эхэндээ гүйцэтгэлийн асуудалтай тулгарсан тул бид одоо өгөөмөр pod төсвөөс эхэлж, дараа нь багасгаж, SLO-г анхааралтай ажиглаж байна. Sidekiq үйлчилгээнд зориулж pods эхлүүлэх нь мэдэгдэхүйц хурдасч, одоо дунджаар 40 секунд зарцуулдаг. GitLab.com болон албан ёсны GitLab Helm диаграммтай ажилладаг өөрөө удирддаг суулгацын хэрэглэгчид хоёуланд нь ялалт байгууллаа.
дүгнэлт
Үйлчилгээ бүрийг шилжүүлсний дараа бид Kubernetes-ийг үйлдвэрлэлд ашигласны үр өгөөжид баярласан: программыг илүү хурдан бөгөөд аюулгүй байршуулах, масштабыг нэмэгдүүлэх, нөөцийн илүү үр ашигтай хуваарилалт. Түүнчлэн шилжилт хөдөлгөөний давуу тал нь GitLab.com үйлчилгээнээс давж гардаг. Албан ёсны Helm графикийн сайжруулалт бүр хэрэглэгчиддээ ашигтай байдаг.
Манай Кубернетес нүүдлийн адал явдлын түүх танд таалагдсан гэж найдаж байна. Бид бүх шинэ үйлчилгээг кластер руу шилжүүлсээр байна. Нэмэлт мэдээллийг дараах хэвлэлээс олж болно.
- «";
- «";
- .
Орчуулагчийн жич
Мөн манай блог дээрээс уншина уу:
- «";
- «";
- «";
- «".
Эх сурвалж: www.habr.com