Энэхүү тайлан нь Кубернетес дэх операторыг хөгжүүлэх, түүний архитектур, үйл ажиллагааны үндсэн зарчмуудыг боловсруулах практик асуудлуудад зориулагдсан болно.
Тайлангийн эхний хэсэгт бид дараахь зүйлийг авч үзэх болно.
- Кубернетес дэх оператор гэж юу вэ, яагаад хэрэгтэй вэ;
- оператор нарийн төвөгтэй системийн удирдлагыг хэрхэн хялбаршуулдаг вэ;
- оператор юу хийж чадах, юу хийж чадахгүй.
Дараа нь операторын дотоод бүтцийн талаар ярилцъя. Операторын архитектур, үйл ажиллагааг алхам алхмаар авч үзье. Үүнийг нарийвчлан авч үзье:
- оператор болон Кубернетес хоорондын харилцан үйлчлэл;
- Оператор ямар үүрэг гүйцэтгэдэг, ямар функцийг Kubernetes-д шилжүүлдэг.
Kubernetes дахь хэлтэрхийнүүд болон мэдээллийн сангийн хуулбарыг удирдахыг харцгаая.
Дараа нь бид өгөгдөл хадгалах асуудлыг хэлэлцэх болно:
- операторын үүднээс Persistent Storage-тэй хэрхэн ажиллах;
- Орон нутгийн хадгалах санг ашиглахад тулгардаг бэрхшээлүүд.
Тайлангийн эцсийн хэсэгт бид хэрэглээний практик жишээг авч үзэх болно Amazon эсвэл Google Cloud Service-тэй. Энэхүү тайланг ClickHouse-д зориулсан операторын хөгжүүлэлт, үйл ажиллагааны туршлагын жишээн дээр үндэслэсэн болно.
Видео:
Намайг Владислав Клименко гэдэг. Өнөөдөр би операторыг хөгжүүлж, ажиллуулж байсан туршлагаа ярихыг хүссэн бөгөөд энэ нь мэдээллийн баазын кластеруудыг удирдах тусгай оператор юм. Жишээлбэл ClickHouse кластерийг удирдах.
Яагаад бидэнд оператор болон ClickHouse-ийн талаар ярих боломж байгаа юм бэ?
- Бид ClickHouse-г дэмжиж хөгжүүлдэг.
- Одоогоор бид ClickHouse-ийн хөгжилд бага багаар хувь нэмрээ оруулахыг хичээж байна. ClickHouse-д хийсэн өөрчлөлтийн хэмжээгээр бид Yandex-ийн дараа хоёрдугаарт ордог.
- Бид ClickHouse экосистемийн нэмэлт төслүүдийг бий болгохыг оролдож байна.
Би эдгээр төслүүдийн нэгийг танд хэлмээр байна. Энэ бол Kubernetes-д зориулсан ClickHouse-операторын тухай юм.
Би тайландаа хоёр сэдвийг хөндөхийг хүсч байна.
- Эхний сэдэв бол манай ClickHouse мэдээллийн сангийн удирдлагын оператор Кубернетес дээр хэрхэн ажилладаг тухай юм.
- Хоёрдахь сэдэв бол аливаа оператор хэрхэн ажилладаг, өөрөөр хэлбэл Кубернетестэй хэрхэн харьцдаг тухай юм.
Гэсэн хэдий ч энэ хоёр асуулт миний тайлангийн туршид огтлолцох болно.
Миний хэлэх гэж байгаа зүйлийг хэн сонсох сонирхолтой байх бол?
- Энэ нь операторуудыг ажиллуулдаг хүмүүст хамгийн их сонирхолтой байх болно.
- Эсвэл дотооддоо энэ нь хэрхэн ажилладаг, оператор Кубернетестэй хэрхэн харьцдаг, ямар бэрхшээл гарч болзошгүйг ойлгохын тулд өөрөө хийхийг хүсдэг хүмүүст зориулагдсан.
Өнөөдөр бидний юу хэлэлцэхээ сайн ойлгохын тулд Кубернетес хэрхэн ажилладагийг мэдэж, үүлний үндсэн сургалтанд хамрагдах нь зүйтэй.
ClickHouse гэж юу вэ? Энэ бол аналитик асуулгыг онлайнаар боловсруулах онцлог шинж чанартай багана хэлбэрийн мэдээллийн сан юм. Мөн энэ нь бүрэн нээлттэй эх сурвалж юм.
Мөн бидний хувьд зөвхөн хоёр зүйлийг мэдэх нь чухал юм. Энэ бол мэдээллийн сан гэдгийг та мэдэх хэрэгтэй, тиймээс миний хэлэх зүйл бараг бүх мэдээллийн санд хэрэгжих болно. ClickHouse DBMS нь маш сайн масштабтай байдаг нь бараг шугаман өргөтгөх чадварыг өгдөг. Тиймээс кластерийн төлөв нь ClickHouse-ийн байгалийн төлөв юм. Мөн бид Кубернетес дэх ClickHouse кластерт хэрхэн үйлчлэх талаар хэлэлцэхийг хамгийн их сонирхож байна.
Тэр яагаад тэнд хэрэгтэй байна вэ? Яагаад бид өөрсдөө үргэлжлүүлэн ажиллуулж болохгүй гэж? Хариултууд нь зарим талаараа техникийн болон зарим талаар зохион байгуулалтын шинж чанартай байдаг.
- Практикт бид томоохон компаниудад бараг бүх бүрэлдэхүүн хэсгүүд аль хэдийн Кубернетес дээр байдаг нөхцөл байдал улам бүр нэмэгдэж байна. Мэдээллийн сан гадна талд үлддэг.
- "Үүнийг дотор нь байрлуулж болох уу?" Гэсэн асуулт улам бүр нэмэгдэж байна. Тиймээс томоохон компаниуд өгөгдлийн агуулахаа хурдан удирдахын тулд менежментийг дээд зэргээр нэгтгэхийг хичээж байна.
- Энэ нь танд ижил зүйлийг шинэ газар давтах хамгийн их боломж, өөрөөр хэлбэл хамгийн их зөөвөрлөх шаардлагатай бол тусалдаг.
Хэр амархан эсвэл хэцүү вэ? Үүнийг мэдээж гараар хийж болно. Гэхдээ энэ нь тийм ч энгийн зүйл биш, учир нь бидэнд Kubernetes-ийг өөрөө удирдах нэмэлт төвөгтэй байдаг, гэхдээ үүнтэй зэрэгцэн ClickHouse-ийн онцлог шинж чанарууд нь давхардсан байдаг. Ийм нэгдэл нь үр дүнд хүргэдэг.
Энэ бүхэн нийлээд нэлээд том технологиудыг өгдөг бөгөөд үүнийг удирдахад нэлээд хэцүү болдог, учир нь Кубернетес өдөр тутмын асуудлаа, ClickHouse нь өөрийн гэсэн асуудлуудыг өдөр тутмын ажилд авчирдаг. Ялангуяа бид хэд хэдэн ClickHouse-тай бол тэдэнтэй байнга ямар нэг зүйл хийх шаардлагатай болдог.
Динамик тохиргоотой бол ClickHouse нь DevOps дээр тогтмол ачаалал үүсгэдэг нэлээд олон тооны асуудалтай байдаг:
- Бид ClickHouse-д ямар нэг зүйлийг өөрчлөхийг хүсвэл, жишээ нь хуулбар эсвэл хэлтэрхий нэмэхийг хүсвэл тохиргоог удирдах хэрэгтэй.
- ClickHouse нь тодорхой хуваах аргатай тул өгөгдлийн схемийг өөрчилнө үү. Тэнд та өгөгдлийн диаграммыг гаргаж, тохиргоог хийх хэрэгтэй.
- Та хяналт тавих хэрэгтэй.
- Шинэ хэлтэрхий, шинэ хуулбарт зориулж лог цуглуулж байна.
- Сэргээх ажилд анхаарал тавь.
- Мөн дахин эхлүүлнэ үү.
Эдгээр нь ашиглахад хялбар болгохыг үнэхээр хүсч буй ердийн ажлууд юм.
Кубернетес өөрөө ажиллахад сайн тусалдаг, гэхдээ системийн үндсэн зүйл дээр.
Кубернетес нь дараах зүйлсийг хөнгөвчлөх, автоматжуулахдаа сайн:
- Сэргээх.
- Дахин ачааллах.
- Хадгалах системийн удирдлага.
Энэ бол сайн, энэ бол зөв чиглэл, гэхдээ тэр мэдээллийн сангийн кластерийг хэрхэн ажиллуулах талаар огт мэдэхгүй байна.
Бид илүү ихийг хүсч байна, бид бүх мэдээллийн баазыг Кубернетес дээр ажиллуулахыг хүсч байна.
Би таны дарах том шидэт улаан товчлуур шиг зүйлийг авахыг хүсч байна, мөн шийдвэрлэх шаардлагатай өдөр тутмын ажлуудтай кластер бүх амьдралынхаа туршид байрлуулж, хадгалагдана. Kubernetes дахь ClickHouse кластер.
Мөн бид ажлыг хөнгөвчлөх шийдэл гаргахыг хичээсэн. Энэ бол Altinity-ийн Kubernetes-д зориулсан ClickHouse-оператор юм.
Оператор бол бусад програмуудыг удирдах үндсэн үүрэг бүхий програм, өөрөөр хэлбэл менежер юм.
Мөн энэ нь зан үйлийн хэв маягийг агуулдаг. Та энэ сэдвийн талбарын талаархи кодлогдсон мэдлэгийг нэрлэж болно.
Түүний гол ажил бол DevOps-ийн амьдралыг хөнгөвчлөх, бичил менежментийг багасгах явдал бөгөөд ингэснээр тэр (DevOps) аль хэдийн өндөр түвшний нэр томъёогоор сэтгэдэг, өөрөөр хэлбэл тэр (DevOps) бичил менежментэд оролцохгүй байх, ингэснээр тэр тохиргоог хийхгүй байх явдал юм. бүх нарийн ширийн зүйлийг гараар.
Зүгээр л оператор бол микро даалгавартай ажилладаг, DevOps-т тусалдаг робот туслах юм.
Танд яагаад оператор хэрэгтэй байна вэ? Тэрээр хоёр чиглэлээр маш сайн ажилладаг:
- ClickHouse-тэй харьцдаг мэргэжилтэн хангалттай туршлагагүй ч ClickHouse-г ажиллуулах шаардлагатай бол оператор нь үйл ажиллагааг хөнгөвчлөх бөгөөд энэ бүхэн хэрхэн ажилладаг талаар нэг их дэлгэрэнгүй ярихгүйгээр нэлээд төвөгтэй тохиргоотой ClickHouse кластерийг ажиллуулах боломжийг танд олгоно. дотор. Чи түүнд зүгээр л өндөр түвшний даалгавар өгөөд л бүтдэг.
- Хамгийн сайн гүйцэтгэдэг хоёр дахь ажил бол олон тооны ердийн даалгавруудыг автоматжуулах шаардлагатай үед юм. Системийн администраторуудаас бичил даалгавруудыг устгадаг.
Энэ нь аялалаа дөнгөж эхэлж буй хүмүүст эсвэл маш их автоматжуулалт хийх шаардлагатай хүмүүст хамгийн их хэрэгтэй байдаг.
Операторт суурилсан арга барил нь бусад системээс юугаараа ялгаатай вэ? Хелм байна. Энэ нь бас ClickHouse-г суулгахад тусалдаг; та бүхэл бүтэн ClickHouse кластерыг суулгаж өгөх удирдамжийн график зурж болно. Оператор ба ижилхэн, жишээлбэл, Helm хоёрын хооронд ямар ялгаа байдаг вэ?
Гол үндсэн ялгаа нь Helm нь багцын менежмент бөгөөд Оператор нь нэг алхам урагшилдаг явдал юм. Энэ бол амьдралын бүх мөчлөгийн дэмжлэг юм. Энэ нь зөвхөн суурилуулалт биш, өдөр тутмын ажил бөгөөд үүнд масштаблах, хуваах, өөрөөр хэлбэл амьдралын мөчлөгийн туршид хийх шаардлагатай бүх зүйл (шаардлагатай бол устгах) - энэ бүгдийг оператор шийддэг. Энэ нь програм хангамжийн амьдралын мөчлөгийг бүхэлд нь автоматжуулах, хадгалахыг оролддог. Энэ бол түүний танилцуулж буй бусад шийдлүүдээс үндсэн ялгаа юм.
Энэ бол оршил хэсэг байсан тул цаашаа явцгаая.
Бид оператороо хэрхэн бүтээх вэ? Бид ClickHouse кластерийг нэг нөөц болгон удирдахын тулд асуудалд хандахыг оролдож байна.
Энд бид зургийн зүүн талд оролтын өгөгдөл байна. Энэ бол кластерын тодорхойлолт бүхий YAML бөгөөд үүнийг kubectl-ээр сонгодог аргаар Кубернетес рүү дамжуулдаг. Тэнд манай оператор түүнийг аваад ид шидээ хийдэг. Мөн гаралт дээр бид дараах схемийг авна. Энэ бол Kubernetes дахь ClickHouse-ийн хэрэгжилт юм.
Дараа нь бид оператор яг хэрхэн ажилладаг, ямар ердийн даалгавруудыг шийдэж болохыг аажмаар харах болно. Бидэнд цаг хугацаа хязгаарлагдмал тул зөвхөн ердийн ажлуудыг авч үзэх болно. Операторын шийдэж чадах бүх зүйлийг хэлэлцэхгүй.
Дадлагаас эхэлцгээе. Манай төсөл бүрэн нээлттэй эх сурвалж тул GitHub дээр хэрхэн ажилладагийг харж болно. Хэрэв та үүнийг зүгээр л эхлүүлэхийг хүсч байвал хурдан эхлүүлэх гарын авлагаас эхэлж болно гэсэн бодлоос цааш үргэлжлүүлж болно.
Хэрэв та нарийвчлан ойлгохыг хүсч байвал бид баримт бичгийг илүү эсвэл бага зохистой хэлбэрээр хадгалахыг хичээдэг.
Практик асуудлаас эхэлье. Бидний эхлэхийг хүсч буй эхний ажил бол эхний жишээг ямар нэгэн байдлаар ажиллуулах явдал юм. Хэрхэн ажилладагийг нь мэдэхгүй байсан ч би операторыг ашиглан ClickHouse-г хэрхэн эхлүүлэх вэ? Бид тунхаг бичиг бичиж байна, учир нь... k8s-тэй харилцах бүх харилцаа нь манифестээр дамжуулан харилцах явдал юм.
Энэ бол ийм нарийн төвөгтэй тунхаг юм. Бидний улаан өнгөөр тодруулсан зүйл бол бидний анхаарах ёстой зүйл юм. Бид оператороос демо нэртэй кластер үүсгэхийг хүсдэг.
Эдгээр нь одоогоор үндсэн жишээ юм. Хадгалалтын талаар хараахан тайлбарлаагүй байгаа ч бид хэсэг хугацааны дараа хадгалах газар руугаа буцах болно. Одоогоор бид кластерын хөгжлийн динамикийг ажиглах болно.
Бид энэ тунхаглалыг бий болгосон. Бид үүнийг оператордоо өгдөг. Тэр ажилласан, тэр ид шид хийсэн.
Бид консолыг харж байна. Гурван бүрэлдэхүүн хэсэг нь сонирхол татдаг: Pod, хоёр үйлчилгээ, StatefulSet.
Оператор ажилласан бөгөөд бид түүний яг юу бүтээснийг харж болно.
Тэр иймэрхүү зүйлийг бүтээдэг. Бид хуулбар бүрт StatefulSet, Pod, ConfigMap, бүх кластерт зориулсан ConfigMap-тай. Үйлчилгээг кластерт нэвтрэх цэг болгон ашиглах шаардлагатай.
Үйлчилгээнүүд нь ачааллын тэнцвэржүүлэгчийн төв үйлчилгээ бөгөөд хуулбар болгонд, хэлтэрхий тус бүрд мөн ашиглаж болно.
Манай үндсэн кластер иймэрхүү харагдаж байна. Энэ нь нэг зангилаанаас гардаг.
Цаашид явж, асуудлыг төвөгтэй болгоё. Бид кластерыг хуваах хэрэгтэй.
Бидний даалгавар нэмэгдэж, динамик эхэлж байна. Бид хэлтэрхий нэмэхийг хүсч байна. Бид хөгжлийг дагадаг. Бид техникийн үзүүлэлтээ өөрчилж байна. Бид хоёр хэлтэрхий хүсч байгаагаа илэрхийлж байна.
Энэ нь системийн өсөлтийг дагаж динамикаар хөгжиж буй ижил файл юм. Хадгалалт байхгүй, хадгалах талаар цаашид хэлэлцэх болно, энэ бол тусдаа сэдэв юм.
Бид YAML операторыг тэжээж, юу болохыг хараарай.
Оператор дараах аж ахуйн нэгжүүдийг бодож, хийсэн. Бидэнд аль хэдийн хоёр Pod, гурван үйлчилгээ, гэнэт 2 StatefulSets бий. Яагаад 2 төлөвтэй багц вэ?
Диаграм дээр ийм байсан - энэ бол бидний нэг хонхорхойтой байх үеийн анхны төлөв юм.
Ийм болсон. Одоогоор бүх зүйл энгийн, давхардсан.
Тэгээд яагаад хоёр Stateful Sets болсон юм бэ? Энд бид Kubernetes-д Pods-ийг хэрхэн удирддаг вэ гэсэн асуултын талаар ярилцах хэрэгтэй.
Загвараас Pod багц үүсгэх боломжийг олгодог StatefulSet нэртэй объект байдаг. Энд гол хүчин зүйл бол Загвар юм. Мөн та нэг StatefulSet-д нэг загвар ашиглан олон Pod ажиллуулж болно. Энд байгаа гол хэллэг бол "нэг загварт зориулсан олон Pod" юм.
Мөн кластерыг бүхэлд нь хийж, нэг StatefulSet-д оруулах маш их уруу таталт байсан. Энэ нь ажиллах болно, үүнд ямар ч асуудал байхгүй. Гэхдээ нэг анхааруулга байна. Хэрэв бид нэг төрлийн бус кластер, өөрөөр хэлбэл ClickHouse-ийн хэд хэдэн хувилбараас цуглуулахыг хүсч байвал асуултууд гарч ирнэ. Тийм ээ, StatefulSet нь эргэлдэж буй шинэчлэлт хийх боломжтой бөгөөд тэнд та шинэ хувилбарыг гаргах боломжтой бөгөөд та нэг дор олон тооны зангилаа оролдох хэрэгтэйг тайлбарлаж болно.
Гэхдээ хэрэв бид даалгаврыг экстраполяци хийж, бид бүрэн ялгаатай кластер хийхийг хүсч байгаа бөгөөд гулсмал шинэчлэлтийг ашиглан хуучин хувилбараас шинэ хувилбар руу шилжихийг хүсэхгүй байгаа бол зүгээр л нэг төрлийн кластер үүсгэхийг хүсч байна. ClickHouse-ийн өөр өөр хувилбарууд болон өөр өөр хадгалалтын хувьд. Жишээлбэл, бид тусдаа диск дээр, удаан дискэн дээр хуулбарлах, ерөнхийдөө нэг төрлийн бус кластер үүсгэхийг хүсч байна. StatefulSet нь нэг загвараас стандарт шийдэл гаргадаг тул үүнийг хийх арга байхгүй.
Хэсэг хугацааны дараа бодсоны эцэст ийм байдлаар хийхээр шийдсэн. Бид хуулбар бүр өөрийн StatefulSet-д байдаг. Энэ шийдэлд зарим сул талууд бий, гэхдээ практик дээр энэ бүгдийг оператор бүрэн багтаасан байдаг. Мөн маш олон давуу талтай. Бид яг хүссэн кластераа, жишээлбэл, туйлын нэг төрлийн бус кластерыг барьж чадна. Тиймээс, нэг хуулбартай хоёр хэлтэрхийтэй кластерт бид 2 StatefulSets ба 2 Pod-той байх болно, учир нь бид нэгэн төрлийн бус кластер үүсгэхийн тулд дээр дурдсан шалтгааны улмаас энэ аргыг сонгосон.
Практик асуудлууд руу буцаж орцгооё. Манай кластерт бид хэрэглэгчдийг тохируулах хэрэгтэй, i.e. Та Kubernetes дахь ClickHouse-ийн зарим тохиргоог хийх хэрэгтэй. Үүний тулд оператор бүх боломжийг бүрдүүлдэг.
Бид хүссэн зүйлээ YAML дээр шууд бичиж болно. Бүх тохиргооны сонголтуудыг энэ YAML-аас ClickHouse тохиргоонд шууд буулгаж, дараа нь кластер даяар тараана.
Та ингэж бичиж болно. Энэ бол жишээ нь. Нууц үгийг шифрлэх боломжтой. Бүх ClickHouse тохиргооны сонголтууд дэмжигддэг. Энд нэг жишээ дурдъя.
Кластерын тохиргоог ConfigMap хэлбэрээр түгээдэг. Практикт ConfigMap-ийн шинэчлэлт шууд хийгддэггүй тул хэрэв кластер том бол тохиргоог түлхэх үйл явц хэсэг хугацаа шаардагдана. Гэхдээ энэ бүхэн ашиглахад маш тохиромжтой.
Даалгаврыг хүндрүүлье. Кластер хөгжиж байна. Бид өгөгдлийг хуулбарлахыг хүсч байна. Өөрөөр хэлбэл, бидэнд аль хэдийн хоёр хэлтэрхий, тус бүр нэг хуулбар байгаа бөгөөд хэрэглэгчид тохируулагдсан байна. Бид өсөн нэмэгдэж байгаа бөгөөд хуулбарлахыг хүсч байна.
Бид хуулбарлахад юу хэрэгтэй вэ?
Бидэнд ZooKeeper хэрэгтэй байна. ClickHouse-д хуулбарыг ZooKeeper ашиглан бүтээдэг. ZooKeeper нь өөр өөр ClickHouse хуулбарууд нь аль өгөгдлийн блокууд дээр байгаа талаар зөвшилцөхөд хэрэгтэй.
ZooKeeper-ийг хэн ч ашиглаж болно. Хэрэв аж ахуйн нэгж гадны ZooKeeper-тэй бол түүнийг ашиглаж болно. Үгүй бол та үүнийг манай репозитороос суулгаж болно. Энэ бүгдийг хөнгөвчлөх суулгагч байдаг.
Бүхэл системийн харилцан үйлчлэлийн диаграм нь иймэрхүү харагдаж байна. Бидэнд Kubernetes платформ байдаг. Энэ нь ClickHouse операторыг гүйцэтгэдэг. Би ZooKeeper-г энд дүрсэлсэн. Мөн оператор нь ClickHouse болон ZooKeeper-тэй харилцдаг. Энэ нь харилцан үйлчлэлийн үр дүн юм.
Энэ бүхэн ClickHouse-д k8-д өгөгдлийг амжилттай хуулбарлахад шаардлагатай.
Одоо даалгаврыг өөрөө, хуулбарлах манифест ямар харагдахыг харцгаая.
Бид манифест дээрээ хоёр хэсгийг нэмж байна. Эхнийх нь ZooKeeper-ийг хаанаас авах вэ, энэ нь Kubernetes дотор эсвэл гадна байж болно. Энэ бол зүгээр л тайлбар юм. Мөн бид хуулбарыг захиалж байна. Тэдгээр. Бид хоёр хуулбарыг хүсч байна. Нийтдээ бид гаралтын хэсэгт 4 хонхорхойтой байх ёстой. Хадгалах талаар бид санаж байна, энэ нь хэсэг хугацааны дараа эргэж ирнэ. Хадгалах нь тусдаа түүх юм.
Ийм л байсан.
Энэ нь иймэрхүү болж хувирдаг. Хуулбарууд нэмэгдсэн. 4 дэх нь таарахгүй, тэнд олон байж магадгүй гэж бид үзэж байна. Мөн хажуу талд ZooKeeper нэмэгдсэн. Схемүүд нь илүү төвөгтэй болж байна.
Мөн дараагийн даалгавраа нэмэх цаг болжээ. Бид байнгын хадгалах санг нэмэх болно.
Байнгын хадгалалтын хувьд бидэнд янз бүрийн сонголтууд бий.
Хэрэв бид үүл үйлчилгээ үзүүлэгч дээр ажиллаж байгаа бол, жишээлбэл, Amazon, Google-ийг ашигладаг бол үүлэн хадгалах санг ашиглах маш их уруу таталт байдаг. Энэ нь маш тохиромжтой, сайн байна.
Мөн хоёр дахь сонголт байна. Энэ нь зангилаа бүр дээр локал дисктэй байх үед дотоод санах ойд зориулагдсан. Энэ сонголтыг хэрэгжүүлэхэд илүү төвөгтэй боловч үүнтэй зэрэгцэн илүү бүтээмжтэй байдаг.
Үүл хадгалах талаар юу байгааг харцгаая.
Давуу тал бий. Энэ нь тохируулахад маш хялбар юм. Бид зүгээр л үүлэн үйлчилгээ үзүүлэгчээс захиалж, бидэнд ийм, тийм, ийм зэрэглэлийн багтаамжийг хадгалахыг хүсч байна. Хичээлүүдийг үйлчилгээ үзүүлэгчид бие даан товлодог.
Мөн сул тал бий. Зарим хүмүүсийн хувьд энэ нь чухал биш сул тал юм. Мэдээж гүйцэтгэлийн зарим асуудал гарна. Энэ нь ашиглахад маш тохиромжтой бөгөөд найдвартай боловч гүйцэтгэлийн зарим сул талууд байдаг.
Тэгээд учир нь ClickHouse нь бүтээмжид онцгой анхаарал хандуулдаг бөгөөд энэ нь чадах бүхнээ шахдаг гэж хэлж болно, иймээс олон үйлчлүүлэгчид хамгийн их бүтээмжийг шахах гэж оролддог.
Үүнээс хамгийн их ашиг хүртэхийн тулд бидэнд орон нутгийн хадгалах сан хэрэгтэй.
Kubernetes нь Кубернетес дэх локал хадгалах санг ашиглах гурван хийсвэрлэлийг өгдөг. Энэ:
- EmptyDir
- HostPath.
- Орон нутгийн
Тэд хэрхэн ялгаатай, хэрхэн адилхан болохыг харцгаая.
Нэгдүгээрт, бүх гурван аргын хувьд бид хадгалах боломжтой - эдгээр нь ижил физик k8s зангилаа дээр байрладаг локал дискүүд юм. Гэхдээ тэдэнд зарим нэг ялгаа бий.
Хамгийн энгийн, өөрөөр хэлбэл emptyDir-ээс эхэлье. Практикт энэ юу вэ? Манай техникийн тодорхойлолтод бид контейнержуулалтын системээс (ихэнхдээ Docker) локал диск дээрх хавтас руу нэвтрэх боломжийг олгохыг хүсдэг.
Практикт Docker өөрийн зам дагуу хаа нэгтээ түр хавтас үүсгэж, түүнийг урт хэш гэж нэрлэдэг. Мөн түүнд хандах интерфейсийг өгдөг.
Энэ нь гүйцэтгэлийн хувьд хэрхэн ажиллах вэ? Энэ нь локал дискний хурдаар ажиллах болно, өөрөөр хэлбэл. Энэ бол таны шураг руу бүрэн нэвтрэх явдал юм.
Гэхдээ энэ хэрэг сул талтай. Тууштай байх нь энэ асуудалд нэлээд эргэлзээтэй юм. Докер анх удаа контейнертэй хөдөлж байх үед Persistent алга болно. Хэрэв Kubernetes энэ Pod-г ямар нэг шалтгаанаар өөр диск рүү зөөхийг хүсвэл өгөгдөл устах болно.
Энэ арга нь туршилтанд тохиромжтой, учир нь энэ нь аль хэдийн хэвийн хурдыг харуулж байгаа боловч ноцтой зүйлд энэ сонголт тохиромжгүй юм.
Тиймээс хоёрдахь арга бий. Энэ бол hostPath. Хэрэв та өмнөх слайд болон энэ слайдыг харвал зөвхөн нэг ялгааг харж болно. Манай хавтас Docker-оос шууд Kubernetes зангилаа руу шилжсэн. Энд арай энгийн. Бид өгөгдлөө хадгалахыг хүссэн локал файлын систем дээрх замыг шууд зааж өгдөг.
Энэ арга нь давуу талтай. Энэ бол аль хэдийн жинхэнэ Persistent, бас сонгодог юм. Бид ямар нэгэн хаягаар дискэн дээр бичигдсэн өгөгдөлтэй байх болно.
Мөн сул талууд бий. Энэ бол менежментийн нарийн төвөгтэй байдал юм. Манай Kubernetes Pod-г өөр физик зангилаа руу шилжүүлэхийг хүсч магадгүй юм. Эндээс л DevOps гарч ирдэг. Тэр бүх системд эдгээр хонхорцогуудыг зөвхөн эдгээр замуудын дагуу ямар нэгэн зүйл суурилуулсан зангилаанууд руу зөөж, нэг удаад нэгээс илүүгүй зангилаа руу шилжүүлж болно гэдгийг зөв тайлбарлах ёстой. Энэ нь нэлээд хэцүү юм.
Ялангуяа эдгээр зорилгын үүднээс бид энэ бүх нарийн төвөгтэй байдлыг нуухын тулд оператор дээрээ загваруудыг хийсэн. Та зүгээр л ингэж хэлж болно: "Би физик зангилаа болон ийм зам дагуу ClickHouse-ийн нэг жишээтэй байхыг хүсч байна."
Гэхдээ энэ хэрэгцээ цорын ганц бидэнд биш тул Кубернетесийн ноёд хүмүүс физик дискэнд хандахыг хүсдэг гэдгийг ойлгодог тул гурав дахь давхаргыг өгдөг.
Үүнийг орон нутгийн гэж нэрлэдэг. Өмнөх слайдаас бараг ялгаа байхгүй. Зөвхөн өмнө нь бид эдгээр хонхорцогуудыг зангилаанаас зангилаа руу шилжүүлэх боломжгүй гэдгийг гараар баталгаажуулах шаардлагатай байсан, учир нь тэдгээр нь локал физик диск рүү ямар нэгэн замаар залгагдсан байх ёстой, гэхдээ одоо энэ бүх мэдлэгийг Кубернетес дотор багтаасан болно. Мөн үүнийг тохируулах нь илүү хялбар болсон.
Практик асуудалдаа эргэн оръё. YAML загвар руу буцаж орцгооё. Энд бидэнд жинхэнэ хадгалах сан байна. Бид буцаж ирлээ. Бид сонгодог VolumeClaim загварыг k8s шиг тохируулсан. Мөн бид ямар төрлийн хадгалахыг хүсч байгаагаа тайлбарладаг.
Үүний дараа k8s хадгалах хүсэлт гаргах болно. Үүнийг StatefulSet-д бидэнд хуваарилах болно. Эцэст нь энэ нь ClickHouse-ийн мэдэлд байх болно.
Бидэнд ийм схем байсан. Бидний байнгын хадгалалт улаан өнгөтэй байсан нь үүнийг хийх шаардлагатайг илтгэж байв.
Тэгээд ногоон болж хувирна. Одоо ClickHouse on k8s кластерын схемийг бүрэн боловсруулж дууслаа. Бидэнд хэлтэрхийнүүд, хуулбарууд, ZooKeeper байдаг, бидэнд ямар нэг байдлаар хэрэгждэг жинхэнэ Persistent бий. Уг схем аль хэдийн бүрэн хэрэгжиж эхэлсэн.
Бид амьдарсаар л байна. Манай кластер хөгжиж байна. Алексей оролдоод ClickHouse-ийн шинэ хувилбарыг гаргасан.
ClickHouse-ийн шинэ хувилбарыг манай кластер дээр турших нь практик даалгавар гарч ирж байна. Мэдээжийн хэрэг, та үүнийг бүгдийг нь гаргахыг хүсэхгүй байна; та шинэ хувилбарыг хамгийн хол буланд хаа нэгтээ нэг хуулбарт оруулахыг хүсч байна, магадгүй нэг шинэ хувилбар биш, гэхдээ нэг дор хоёр хувилбарыг оруулахыг хүсч байна, учир нь тэдгээр нь байнга гарч ирдэг.
Энэ талаар бид юу хэлж чадах вэ?
Энд бидэнд яг ийм боломж байна. Эдгээр нь pod загварууд юм. Манай оператор танд нэг төрлийн бус кластер байгуулах боломжийг бүрэн олгодог гэж та бичиж болно. Тэдгээр. бүх хуулбараас эхлээд хувийн хуулбар бүрээр дуусч, ClickHouse-ын аль хувилбарыг, ямар хувилбарыг хадгалахыг хүсэж байгааг тохируулна уу. Бид кластерыг шаардлагатай тохиргоогоор бүрэн тохируулах боломжтой.
Дотор нь жаахан гүнзгий орцгооё. Үүнээс өмнө бид ClickHouse-ийн онцлогтой холбоотой ClickHouse-оператор хэрхэн ажилладаг талаар ярилцсан.
Одоо би ямар ч оператор ерөнхийдөө хэрхэн ажилладаг, мөн K8-тэй хэрхэн харьцдаг талаар хэдэн үг хэлмээр байна.
Эхлээд K8-тай хэрхэн харьцаж байгааг харцгаая. Бид kubectl-г хэрэглэх үед юу болох вэ? Манай объектууд API-ээр дамжуулан etcd дээр гарч ирдэг.
Жишээлбэл, Kubernetes-ийн үндсэн объектууд: pod, StatefulSet, үйлчилгээ гэх мэт жагсаалтын доор байна.
Үүний зэрэгцээ бие махбодийн хувьд юу ч тохиолдоогүй байна. Эдгээр объектуудыг кластерт материалжуулсан байх ёстой.
Энэ зорилгоор хянагч гарч ирнэ. Хянагч нь эдгээр тайлбарыг хэрэгжүүлэх боломжтой тусгай k8s бүрэлдэхүүн хэсэг юм. Тэр бие махбодийн хувьд яаж, юу хийхээ мэддэг. Тэр чингэлэгийг хэрхэн ажиллуулах, сервер ажиллахын тулд тэнд юу тохируулах хэрэгтэйг мэддэг.
Мөн энэ нь бидний объектуудыг K8-д материалжуулдаг.
Гэхдээ бид зөвхөн pods болон StatefulSets-тэй ажиллахыг хүсэж байгаа төдийгүй, ClickHouseInstallation буюу ClickHouse төрлийн объектыг бүхэлд нь ашиглахыг хүсэж байна. Одоогоор тийм боломж алга.
Гэхдээ K8s-д дараах сайхан зүйл бий. Манай кластерийг pods болон StatefulSet-ээс угсарч болох ийм цогц бүтэцтэй газар байгаасай гэж бид хүсч байна.
Мөн үүний тулд юу хийх хэрэгтэй вэ? Нэгдүгээрт, Custom Resource Definition зураг дээр гарч ирнэ. Энэ юу вэ? Энэ бол K8-д зориулсан тайлбар бөгөөд танд өөр нэг өгөгдлийн төрөл байх болно, бид pod-д тусгай нөөцийг нэмэхийг хүсч байгаа StatefulSet, дотор нь төвөгтэй байх болно. Энэ бол өгөгдлийн бүтцийн тодорхойлолт юм.
Бид үүнийг kubectl application-р илгээдэг. Кубернетес үүнийг баяртайгаар хүлээж авав.
Одоо манай санд, etcd дахь объект нь ClickHouseInstallation нэртэй тусгай нөөцийг бичих боломжтой болсон.
Гэхдээ одоохондоо цаашид юу ч болохгүй. Өөрөөр хэлбэл, хэрэв бид одоо хэлтэрхий болон хуулбарыг дүрсэлсэн YAML файлыг үүсгээд "kubectl хэрэглэнэ" гэж хэлвэл Кубернетес үүнийг хүлээн авч, etcd дотор оруулаад: "Гайхалтай, гэхдээ би юу хийхээ мэдэхгүй байна. түүнтэй хамт. Би ClickHouseInstallation-г хэрхэн хадгалахаа мэдэхгүй байна."
Үүний дагуу бидэнд Кубернетесэд шинэ өгөгдлийн төрөлд үйлчлэхэд туслах хүн хэрэгтэй байна. Зүүн талд бид уугуул өгөгдлийн төрлүүдтэй ажилладаг Kubernetes хянагчтай. Баруун талд бид өөрчлөн өгөгдлийн төрлүүдтэй ажиллах боломжтой өөрчлөн хянагчтай байх ёстой.
Мөн өөр байдлаар үүнийг оператор гэж нэрлэдэг. Би үүнийг Kubernetes гэж энд тусгайлан оруулсан, учир нь үүнийг K8-ээс гадуур гүйцэтгэх боломжтой. Мэдээжийн хэрэг, бүх операторуудыг Кубернетес дээр гүйцэтгэдэг боловч гадаа зогсоход юу ч саад болдоггүй тул энд тусгайлан гадаа шилжүүлдэг.
Мөн эргээд оператор гэгддэг захиалгат хянагч нь API-ээр дамжуулан Kubernetes-тэй харилцдаг. Энэ нь API-тай хэрхэн харилцахаа аль хэдийн мэддэг болсон. Мөн тэрээр бидний захиалгат нөөцөөс бүтээхийг хүсч буй нарийн төвөгтэй хэлхээг хэрхэн бодит болгохыг аль хэдийн мэддэг. Үүнийг оператор яг хийдэг.
Оператор хэрхэн ажилладаг вэ? Тэр үүнийг хэрхэн хийхийг харахын тулд баруун талыг харцгаая. Оператор энэ бүхнийг хэрхэн хэрэгжүүлж, K8-тэй цаашдын харилцан үйлчлэл хэрхэн явагддагийг олж мэдье.
Оператор бол програм юм. Тэр үйл явдалд чиглэсэн. Оператор нь Kubernetes API ашиглан үйл явдалд бүртгүүлдэг. Kubernetes API нь үйл явдалд бүртгүүлэх боломжтой нэвтрэх цэгүүдтэй. Хэрэв K8-д ямар нэг зүйл өөрчлөгдвөл Кубернетес бүх хүмүүст үйл явдлуудыг илгээдэг, жишээлбэл. Энэ API цэгт бүртгүүлсэн хүн мэдэгдэл хүлээн авах болно.
Оператор үйл явдалд бүртгүүлдэг бөгөөд ямар нэгэн хариу үйлдэл үзүүлэх ёстой. Түүний үүрэг бол шинээр гарч ирж буй үйл явдлуудад хариу өгөх явдал юм.
Үйл явдлууд нь тодорхой шинэчлэлтүүдээр үүсгэгддэг. ClickHouseInstallation-ийн тайлбартай манай YAML файл ирлээ. Тэр kubectl application дамжуулан etcd руу очсон. Тэнд үйл явдал өрнөж, үр дүнд нь энэ үйл явдал ClickHouse-операторт ирсэн. Оператор энэ тайлбарыг хүлээн авсан. Тэгээд тэр ямар нэг зүйл хийх ёстой. Хэрэв ClickHouseInstallation объектын шинэчлэлт ирсэн бол та кластерийг шинэчлэх хэрэгтэй. Мөн операторын үүрэг бол кластерыг шинэчлэх явдал юм.
Тэр юу хийж байна вэ? Юуны өмнө бид энэ шинэчлэлтээр юу хийх талаар үйл ажиллагааны төлөвлөгөө гаргах хэрэгтэй. Шинэчлэлтүүд нь маш бага байж болно, i.e. YAML-ийн гүйцэтгэлд бага боловч кластерт маш том өөрчлөлт оруулж болно. Тиймээс оператор төлөвлөгөө гаргаж, дараа нь түүнийгээ дагаж мөрддөг.
Энэ төлөвлөгөөний дагуу тэрээр хонхорцог, үйлчилгээ, өөрөөр хэлбэл материалжуулахын тулд энэ бүтцийг дотор нь хоол хийж эхэлдэг. түүний гол үүрэг бол юу хийх. Kubernetes-д ClickHouse кластерийг хэрхэн бүтээх вэ.
Одоо нэг ийм сонирхолтой зүйлийг хөндье. Энэ нь Кубернетес ба операторын хоорондох хариуцлагын хуваарилалт юм, i.e. Кубернетес юу хийдэг, оператор юу хийдэг, тэд хоорондоо хэрхэн харьцдаг.
Кубернетес нь системийн зүйлсийг хариуцдаг, өөрөөр хэлбэл. системийн хамрах хүрээ гэж тайлбарлаж болох объектуудын үндсэн багцын хувьд. Кубернетес нь подволкуудыг хэрхэн эхлүүлэх, савыг хэрхэн дахин эхлүүлэх, эзлэхүүнийг хэрхэн холбох, ConfigMap-тай хэрхэн ажиллах, i.e. систем гэж хэлж болох бүх зүйл.
Операторууд домэйн дээр ажилладаг. Оператор бүр өөр өөрийн сэдвийн хүрээнд хийгдсэн. Бид үүнийг ClickHouse-д зориулж хийсэн.
Мөн оператор нь хуулбар нэмэх, диаграмм хийх, хяналт тавих гэх мэт сэдвийн хүрээнд яг нарийн харилцдаг. Үүний үр дүнд хуваагдал үүсдэг.
Хуулбар нэмэх үйлдлийг хийх үед энэхүү хариуцлагын хуваарилалт хэрхэн явагддаг практик жишээг харцгаая.
Оператор нь хуулбарыг нэмэх даалгавар хүлээн авдаг. Оператор юу хийдэг вэ? Оператор шинэ StatefulSet үүсгэх шаардлагатайг тооцоолох бөгөөд үүнд ийм болон ийм загварууд, эзлэхүүний нэхэмжлэлийг дүрсэлсэн байх ёстой.
Тэр бүгдийг бэлдэж, K8-д дамжуулдаг. Түүнд ConfigMap, StatefulSet, Volume хэрэгтэй гэж тэр хэлэв. Кубернетес ажиллаж байна. Тэрээр ажиллаж байгаа үндсэн нэгжүүдээ материалжуулж байна.
Тэгээд ClickHouse-оператор дахин тоглох болно. Түүнд аль хэдийн ямар нэгэн зүйл хийж чадах бие махбодь байгаа. ClickHouse-оператор дахин домэйны нэр томъёогоор ажилладаг. Тэдгээр. Ялангуяа ClickHouse-д хуулбарыг кластерт оруулахын тулд эхлээд энэ кластерт байгаа өгөгдлийн схемийг тохируулах хэрэгтэй. Хоёрдугаарт, энэ хуулбарыг тодорхой мөрдөхийн тулд хяналтанд оруулах ёстой. Оператор үүнийг аль хэдийн тохируулсан байна.
Үүний дараа л ClickHouse өөрөө гарч ирнэ, өөрөөр хэлбэл. өөр дээд түвшний байгууллага. Энэ бол аль хэдийн мэдээллийн сан юм. Энэ нь кластерт нэгдэхэд бэлэн өөр тохируулагдсан хуулбартай өөрийн гэсэн жишээтэй.
Хуулбар нэмэхэд гүйцэтгэх гинжин хэлхээ, хариуцлагын хуваарилалт нэлээд урт байдаг.
Бид практик даалгавраа үргэлжлүүлсээр байна. Хэрэв танд кластер байгаа бол тохиргоог шилжүүлж болно.
Бид үүнийг ClickHouse-ын ойлгодог одоо байгаа xml-ээр дамжуулан буулгах боломжтой болгосон.
Та ClickHouse-г нарийн тааруулж болно. Зүгээр л бүсчилсэн байршуулалт нь hostPath, локал хадгалалтын талаар тайлбарлахдаа миний ярьсан зүйл юм. Ингэж бүсчилсэн байршуулалтыг хэрхэн зөв хийх вэ.
Дараагийн практик ажил бол мониторинг юм.
Хэрэв манай кластер өөрчлөгдвөл бид хяналтыг үе үе тохируулах хэрэгтэй.
Диаграмыг харцгаая. Бид энд байгаа ногоон сумнуудыг аль хэдийн харсан. Одоо улаан сумнуудыг харцгаая. Бид кластераа ингэж хянамаар байна. ClickHouse кластерийн хэмжүүрүүд хэрхэн Прометей, дараа нь Графана руу ордог.
Хяналт тавихад ямар хүндрэл гардаг вэ? Үүнийг яагаад ямар нэгэн ололт гэж танилцуулж байна вэ? Хэцүү байдал нь динамик байдалд оршдог. Хэрэв бид нэг кластертай бөгөөд энэ нь статик байвал бид хяналтыг нэг удаа тохируулж, дахиж төвөг учруулахгүй.
Гэхдээ хэрэв бид маш олон кластертай эсвэл ямар нэг зүйл байнга өөрчлөгдөж байвал үйл явц нь динамик юм. Хяналт-шинжилгээг байнга дахин тохируулах нь нөөц, цагийг дэмий үрэх явдал юм. тэр ч байтугай зүгээр л залхуурал. Үүнийг автоматжуулах шаардлагатай. Хэцүү байдал нь үйл явцын динамик байдалд оршдог. Мөн оператор үүнийг маш сайн автоматжуулдаг.
Манай кластер хэрхэн хөгжсөн бэ? Эхэндээ тэр тийм байсан.
Дараа нь тэр ийм байсан.
Эцэст нь тэр ийм болсон.
Мөн хяналтыг оператор автоматаар хийдэг. Нэг нэвтрэх цэг.
Яг гарцан дээр бид Графана хяналтын самбарыг харж, бидний кластерын амьдрал дотор нь хэрхэн буцалж байгааг харах болно.
Дашрамд хэлэхэд, Grafana хяналтын самбарыг манай оператортой шууд эх кодоор нь түгээдэг. Та холбогдож ашиглаж болно. Манай DevOps надад энэ дэлгэцийн агшинг өгсөн.
Бид дараа нь хаашаа явахыг хүсч байна вэ? Энэ:
- Туршилтын автоматжуулалтыг хөгжүүлэх. Гол ажил бол шинэ хувилбаруудыг автоматжуулсан туршилт юм.
- Мөн бид ZooKeeper-тэй нэгтгэхийг автоматжуулахыг үнэхээр хүсч байна. Мөн ZooKeeper-оператортой нэгдэх төлөвлөгөө бий. Тэдгээр. ZooKeeper-д зориулж оператор бичсэн бөгөөд илүү тохиромжтой шийдлийг бий болгохын тулд хоёр оператор нэгдэж эхлэх нь логик юм.
- Бид илүү нарийн төвөгтэй амин чухал шинж тэмдгүүд хийхийг хүсч байна.
- Бид Загваруудын өв залгамжлалд ойртож байгааг би ногоон өнгөөр тодруулсан - ДУУССАН, өөрөөр хэлбэл операторын дараагийн хувилбарыг гаргаснаар бид загваруудыг аль хэдийн өвлүүлэх болно. Энэ бол нарийн төвөгтэй тохиргоог хэсгүүдээс бүтээх боломжийг олгодог хүчирхэг хэрэгсэл юм.
- Мөн бид нарийн төвөгтэй ажлуудыг автоматжуулахыг хүсч байна. Хамгийн гол нь дахин хуваах явдал юм.
Завсрын үр дүнг авч үзье.
Үүний үр дүнд бид юу авах вэ? Үүнийг хийх нь үнэ цэнэтэй юу, үгүй юу? Мэдээллийн санг Kubernetes руу чирч, ерөнхийдөө оператор, ялангуяа Alitnity операторыг ашиглахыг оролдох шаардлагатай юу?
Гаралт дээр бид дараахь зүйлийг авна.
- Тохиргоо, байршуулалт, засвар үйлчилгээг ихээхэн хялбаршуулж, автоматжуулах.
- Нэн даруй суурилуулсан хяналт.
- Мөн нарийн төвөгтэй нөхцөл байдалд ашиглахад бэлэн кодлогдсон загварууд. Хуулбар нэмэх гэх мэт үйлдлийг гараар хийх шаардлагагүй. Оператор үүнийг хийдэг.
Сүүлийн ганц асуулт үлдлээ. Бид Kubernetes-д виртуалчлалын мэдээллийн сантай болсон. Ялангуяа ClickHouse нь гүйцэтгэлийн хувьд оновчтой болсон тул ийм шийдлийн гүйцэтгэлийн талаар юу хэлэх вэ?
Хариулт нь бүх зүйл сайхан байна! Би дэлгэрэнгүй ярихгүй, энэ бол тусдаа тайлангийн сэдэв юм.
Харин TSBS гэж ийм төсөл бий. Түүний гол үүрэг юу вэ? Энэ бол мэдээллийн сангийн гүйцэтгэлийн тест юм. Энэ бол дулааныг дулаан, зөөлөн, зөөлөн харьцуулах оролдлого юм.
Тэр яаж ажилладаг вэ? Нэг өгөгдлийн багц үүсгэгдсэн. Дараа нь энэ багц өгөгдлүүд нь ижил багц тестийг ашиглан өөр өөр мэдээллийн сан дээр ажиллана. Мөн өгөгдлийн сан бүр өөрийн мэддэг арга замаар нэг асуудлыг шийддэг. Дараа нь та үр дүнг харьцуулж болно.
Энэ нь аль хэдийн олон тооны мэдээллийн санг дэмждэг. Би үндсэн гурван зүйлийг тодорхойлсон. Энэ:
- Цагийн хуваарьDB.
- InfluxDB.
- ClickHouse.
Өөр ижил төстэй шийдэлтэй харьцуулалт хийсэн. RedShift-тэй харьцуулах. Амазон дээр харьцуулалт хийсэн. ClickHouse нь энэ асуудалд хүн бүрээс түрүүлж байна.
Миний хэлсэн зүйлээс ямар дүгнэлт хийж болох вэ?
- Kubernetes дахь DB боломжтой. Магадгүй аль нь ч боломжтой, гэхдээ ерөнхийдөө энэ нь боломжтой юм шиг харагдаж байна. Кубернетес дэх ClickHouse нь манай операторын тусламжтайгаар боломжтой.
- Оператор нь үйл явцыг автоматжуулахад тусалдаг бөгөөд амьдралыг үнэхээр хялбар болгодог.
- Гүйцэтгэл хэвийн байна.
- Үүнийг ашиглах боломжтой, ашиглах ёстой юм шиг санагдаж байна.
Нээлттэй эх сурвалж - бидэнтэй нэгдээрэй!
Би аль хэдийн хэлсэнчлэн оператор нь бүрэн нээлттэй эхийн бүтээгдэхүүн тул хамгийн их хүн ашигладаг бол маш сайн байх болно. Бидэнтэй нэгд! Бид та бүхнийг хүлээж байна!
Бүгдэд нь баярлалаа!
Асуултууд
Мэдээлэл өгсөнд баярлалаа! Намайг Антон гэдэг. Би SEMrush-аас ирсэн. Мод бэлтгэж байгаа нь яадаг юм бол гэж бодож байна. Бид мониторингийн талаар сонсдог, гэхдээ бүхэл бүтэн кластерын талаар ярих юм бол мод бэлтгэх талаар юу ч байхгүй. Жишээлбэл, бид техник хангамж дээр кластер босгосон. Мөн бид төвлөрсөн бүртгэлийг ашигладаг бөгөөд тэдгээрийг стандарт хэрэгслээр нийтлэг овоолго болгон цуглуулдаг. Тэгээд тэндээс бид сонирхож буй өгөгдлийг олж авдаг.
Сайн асуулт, өөрөөр хэлбэл хийх зүйлсийн жагсаалтад нэвтэрч байна. Манай оператор үүнийг автоматжуулаагүй байна. Энэ нь хөгжиж байна, төсөл нь нэлээд залуу хэвээр байна. Мод бэлтгэх хэрэгцээг бид ойлгож байна. Энэ бол бас маш чухал сэдэв юм. Мөн энэ нь хяналтаас дутахааргүй чухал юм. Гэхдээ хэрэгжүүлэх жагсаалтын эхнийх нь хяналт байв. Мод бэлтгэх болно. Мэдээжийн хэрэг, бид кластерын амьдралын бүх талыг автоматжуулахыг хичээдэг. Тиймээс, одоогоор оператор харамсалтай нь үүнийг яаж хийхээ мэдэхгүй байгаа, гэхдээ энэ нь төлөвлөгөөнд байгаа, бид үүнийг хийх болно гэсэн хариулт байна. Хэрэв та нэгдэхийг хүсвэл хүсэлтээ гаргана уу.
Сайн уу? Мэдээлэл өгсөнд баярлалаа! Надад Persistent Volumes-тэй холбоотой стандарт асуулт байна. Бид энэ оператортой тохиргоо хийх үед ямар зангилаа дээр бидний тодорхой диск эсвэл хавтас хавсаргасан байгааг оператор хэрхэн тодорхойлох вэ? Бид эхлээд түүнд ClickHouse-ыг дисктэй эдгээр зангилаанууд дээр байрлуулна уу гэдгийг тайлбарлах ёстой.
Миний ойлгож байгаагаар энэ асуулт нь орон нутгийн хадгалалтын үргэлжлэл, ялангуяа hostPath хэсэг юм. Энэ нь ийм ийм замын дагуу суурилуулсан физик холболттой дисктэй ийм зангилаа дээр подволкийг эхлүүлэх шаардлагатайг бүхэл системд тайлбарлахтай адил юм. Энэ бол бүхэл бүтэн хэсэг бөгөөд хариулт нь нэлээд том учраас би маш өнгөцхөн хөндсөн.
Товчхондоо иймэрхүү харагдаж байна. Мэдээжийн хэрэг, бид эдгээр хэмжээг хангах ёстой. Одоогийн байдлаар дотоод санах ойд динамик хангамж байхгүй тул DevOps нь эдгээр эзэлхүүнтэй дискүүдийг өөрсдөө таслах ёстой. Мөн тэд Kubernetes-ийн заалтыг тайлбарлах ёстой, танд ийм, тийм төрлийн зангилаанууд дээр байрлах ийм ангиллын байнгын эзлэхүүнүүд байх болно. Дараа нь та Kubernetes-д ийм, тийм локал хадгалах анги шаарддаг подкуудыг зөвхөн шошго ашиглан ийм ийм зангилаа руу чиглүүлэх шаардлагатайг тайлбарлах хэрэгтэй болно. Эдгээр зорилгын үүднээс оператор нь ямар нэгэн төрлийн шошго болон хостын тохиолдол бүрт нэгийг зааж өгөх чадвартай. Зөвхөн энгийн үгээр хэлбэл, шошго, шаардлагад нийцсэн зангилаанууд дээр ажиллахын тулд pods-ыг Kubernetes чиглүүлэх болно. Администраторууд шошго оноож, дискийг гараар хангадаг. Тэгээд масштабтай.
Энэ нь орон нутгийн гуравдахь сонголт бөгөөд үүнийг бага зэрэг хөнгөвчлөхөд тусалдаг. Би аль хэдийн онцолсончлан, энэ нь тааруулах шаргуу ажил бөгөөд эцэст нь хамгийн их гүйцэтгэлийг олж авахад тусалдаг.
Үүнтэй холбоотой хоёр дахь асуулт надад байна. Кубернетес нь зангилаа алдах эсэх нь бидэнд хамаагүй байхаар бүтээгдсэн. Хэрэв бидний хэлтэрхий өлгөгдсөн зангилааг алдсан бол энэ тохиолдолд бид яах ёстой вэ?
Тийм ээ, Кубернетес эхлээд бидний хонхорхойтой харьцах харьцаа нь үхэр шиг байдаг гэж байр сууриа илэрхийлсэн боловч энд диск бүр гэрийн тэжээвэр амьтан шиг зүйл болж хувирдаг. Тэднийг зүгээр хаячихаж болохгүй тийм асуудал бий. Мөн Кубернетесийн хөгжил нь үүнийг бүрэн хаясан нөөц юм шиг философийн үүднээс бүрэн эмчлэх боломжгүй гэсэн чиглэлд явж байна.
Одоо практик асуултын тухай. Хэрэв та диск дээр байсан зангилааг алдсан бол яах вэ? Энд асуудлыг илүү өндөр түвшинд шийдэж байна. ClickHouse-ийн хувьд бид илүү өндөр түвшинд ажилладаг хуулбаруудтай, i.e. ClickHouse түвшинд.
Үүний үр дүнд ямар хандлага гарч байна вэ? DevOps нь өгөгдөл алдагдахгүй байх үүрэгтэй. Тэр хуулбарыг зөв тохируулах ёстой бөгөөд хуулбар ажиллаж байгаа эсэхийг баталгаажуулах ёстой. ClickHouse түвшний хуулбар нь давхардсан өгөгдөлтэй байх ёстой. Энэ нь операторын шийдэх ажил биш юм. Мөн Кубернетес өөрөө шийддэг асуудал биш. Энэ нь ClickHouse түвшинд байна.
Хэрэв таны төмөр зангилаа унавал яах вэ? Мөн та хоёрдахь суулгаж, дискийг зохих ёсоор байрлуулж, шошго наах хэрэгтэй болно. Үүний дараа энэ нь Kubernetes-ийн түүн дээр инстанцын pod ажиллуулж болох шаардлагыг хангана. Kubernetes үүнийг эхлүүлэх болно. Таны хонхорхойн тоо заасан тоонд хүрэлцэхгүй байна. Энэ нь миний үзүүлсэн мөчлөгийг туулах болно. Хамгийн дээд түвшинд ClickHouse нь хуулбарыг оруулсан, энэ нь хоосон хэвээр байгаа бөгөөд бид түүн рүү өгөгдөл шилжүүлж эхлэх хэрэгтэй гэдгийг ойлгох болно. Тэдгээр. Энэ үйл явц хараахан сайн автоматжаагүй байна.
Мэдээлэл өгсөнд баярлалаа! Бүх төрлийн таагүй зүйл тохиолдоход оператор эвдэрч, дахин ачаалж, тэр үед үйл явдал ирэхэд та үүнийг ямар нэгэн байдлаар зохицуулдаг уу?
Оператор осолдож, дахин ачаалвал яах вэ?
Тиймээ. Тэгээд тэр мөчид үйл явдлууд ирэв.
Энэ тохиолдолд юу хийх вэ гэдэг даалгаврыг оператор болон Кубернетес хоёрын хооронд хэсэгчлэн хуваалцдаг. Кубернетес нь болсон үйл явдлыг дахин тоглуулах чадвартай. Тэр дахин тоглодог. Операторын даалгавар бол үйл явдлын бүртгэлийг түүн дээр дахин тоглуулах үед эдгээр үйл явдлууд үл хамаарах эсэхийг шалгах явдал юм. Нэг үйл явдал давтагдах нь бидний тогтолцоог эвдэхгүй байхын тулд. Манай оператор энэ ажлыг даван туулж байна.
Сайн уу? Мэдээлэл өгсөнд баярлалаа! Дмитрий Завьялов, компани Смедова. Операторт haproxy-ээр тохируулах чадварыг нэмэхээр төлөвлөж байна уу? Би стандартаас гадна өөр тэнцвэржүүлэгчийг сонирхож байгаа бөгөөд энэ нь ухаалаг бөгөөд ClickHouse үнэхээр тэнд байгааг ойлгох болно.
Та Ингрессийн тухай ярьж байна уу?
Тийм ээ, Ingress-ийг гапроксигоор солино. Хапроксид та хуулбарласан кластерын топологийг зааж өгч болно.
Бид энэ талаар хараахан бодож амжаагүй байна. Хэрэв танд хэрэгтэй, яагаад хэрэгтэй байгааг тайлбарлаж чадвал хэрэгжүүлэх боломжтой, ялангуяа та оролцохыг хүсч байвал үүнийг хэрэгжүүлэх боломжтой болно. Бид сонголтыг авч үзэхдээ баяртай байх болно. Богино хариулт бол үгүй, одоогоор бидэнд ийм функц байхгүй байна. Зөвлөгөө өгсөнд баярлалаа, бид энэ асуудлыг авч үзэх болно. Хэрэв та мөн ашиглалтын тохиолдол болон практикт яагаад хэрэгтэй байгааг тайлбарлавал, жишээлбэл, GitHub дээр асуудал үүсгэвэл энэ нь маш сайн байх болно.
Аль хэдийн байна.
Сайн байна. Бид аливаа санал хүсэлтэд нээлттэй. Мөн haproxy хийх зүйлсийн жагсаалтад нэмэгдсэн. Хийх зүйлсийн жагсаалт өссөөр байгаа ч одоохондоо багасаагүй байна. Гэхдээ энэ нь сайн, энэ нь бүтээгдэхүүн эрэлт хэрэгцээтэй байна гэсэн үг юм.
Эх сурвалж: www.habr.com