Hisobot Kubernetesda operatorni rivojlantirish, uning arxitekturasini loyihalash va ishlashning asosiy tamoyillarini amaliy masalalariga bag'ishlangan.
Hisobotning birinchi qismida biz quyidagilarni ko'rib chiqamiz:
- Kubernetesda operator nima va u nima uchun kerak;
- operator murakkab tizimlarni boshqarishni qanday soddalashtiradi;
- operator nima qila oladi va nima qila olmaydi.
Keyinchalik, biz operatorning ichki tuzilishini muhokama qilishga o'tamiz. Operatorning arxitekturasi va ishlashini bosqichma-bosqich ko'rib chiqing. Keling, batafsil tahlil qilaylik:
- operator va Kubernetes o'rtasidagi o'zaro ta'sir;
- operator qanday funktsiyalarni oladi va Kubernetesga nima delegatlar beradi.
Kubernetes-da parchalar va ma'lumotlar bazasi replikalarini boshqarishni ko'rib chiqing.
Keyinchalik, ma'lumotlarni saqlash masalalarini muhokama qilamiz:
- operator nuqtai nazaridan Persistent Storage bilan qanday ishlash kerak;
- Mahalliy xotiradan foydalanishning tuzoqlari.
Hisobotning yakuniy qismida biz qo'llashning amaliy misollarini ko'rib chiqamiz Amazon yoki Google Cloud xizmati bilan. Hisobot operatorning ClickHouse uchun ishlab chiqish va ishlash tajribasi misoliga asoslangan.
Video:
Mening ismim Vladislav Klimenko. Bugun men operatorni ishlab chiqish va boshqarish bo'yicha tajribamiz haqida gapirmoqchi edim va bu ma'lumotlar bazasi klasterlarini boshqarish uchun ixtisoslashgan operator. Masalan ClickHouse klasterini boshqarish uchun.
Nima uchun operator va ClickHouse haqida gapirish imkoniga egamiz?
- Biz ClickHouse-ni qo'llab-quvvatlaymiz va ishlab chiqamiz.
- Ayni paytda biz asta-sekin ClickHouse rivojiga o'z hissamizni qo'shishga harakat qilmoqdamiz. ClickHouse-da kiritilgan o'zgarishlar miqdori bo'yicha esa biz Yandexdan keyin ikkinchi o'rindamiz.
- Biz ClickHouse ekotizimiga qo'shimcha loyihalar yaratishga harakat qilmoqdamiz.
Men ushbu loyihalardan biri haqida gapirmoqchiman. Bu Kubernetes uchun ClickHouse-operatori haqida.
Hisobotimda men ikkita mavzuga to'xtalib o'tmoqchiman:
- Birinchi mavzu - bizning ClickHouse ma'lumotlar bazasi operatorimiz Kubernetesda qanday ishlashi.
- Ikkinchi mavzu - har qanday operator qanday ishlaydi, ya'ni Kubernetes bilan qanday aloqada bo'ladi.
Biroq, bu ikki savol mening hisobotim davomida kesishadi.
Aytmoqchi bo'lganlarimni kim eshitishga qiziqadi?
- Eng qiziqarli operatorlarni ekspluatatsiya qiladiganlar bo'ladi.
- Yoki uning ichida qanday ishlashini, operator Kubernetes bilan qanday munosabatda bo'lishini va qanday tuzoqlar paydo bo'lishi mumkinligini tushunish uchun o'zini yaratmoqchi bo'lganlar uchun.
Bugun biz nimani muhokama qilishimizni yaxshiroq tushunish uchun Kubernetes qanday ishlashini bilish va bulutli hisoblashda asosiy ma'lumotga ega bo'lish yaxshi bo'lar edi.
ClickHouse nima? Bu analitik so'rovlarni onlayn qayta ishlashning o'ziga xos xususiyatlariga ega ustun ma'lumotlar bazasi. Va u butunlay ochiq manba.
Va biz faqat ikkita narsani bilishimiz kerak. Bu ma'lumotlar bazasi ekanligini bilishingiz kerak, shuning uchun men sizga aytadigan narsa deyarli har qanday ma'lumotlar bazasiga tegishli bo'ladi. ClickHouse DBMS juda yaxshi miqyosda bo'lishi esa o'lchovni deyarli chiziqli qiladi. Shunday qilib, klaster holati ClickHouse uchun tabiiy holatdir. Va bizni Kubernetesda ClickHouse klasteriga qanday xizmat ko'rsatishni muhokama qilish qiziqtiradi.
Nega u erda kerak? Nega biz uni o'zimiz boshqarishda davom eta olmaymiz? Va javoblar qisman texnik va qisman tashkiliy.
- Amalda, biz katta kompaniyalarda deyarli barcha komponentlar allaqachon Kubernetesda bo'lganida bunday vaziyatga tez-tez duch kelamiz. Ma'lumotlar bazalarini tashqarida qoldiring.
- Va tobora ko'proq savol so'raladi: "Uni ichkariga qo'yish mumkinmi?". Shu sababli, yirik kompaniyalar o'zlarining ma'lumotlar omborlarini tezda boshqarish imkoniyatiga ega bo'lish uchun boshqaruvni maksimal darajada birlashtirishga harakat qilmoqdalar.
- Va bu, ayniqsa, sizga xuddi shu narsani yangi joyda takrorlash uchun maksimal imkoniyat, ya'ni maksimal ko'chirish kerak bo'lsa yordam beradi.
Bu qanchalik oson yoki qiyin? Bu, albatta, qo'l bilan amalga oshirilishi mumkin. Ammo bu unchalik oson emas, chunki biz Kubernetes-ni boshqarishning murakkabligini qo'shamiz, lekin shu bilan birga ClickHouse-ning o'ziga xos xususiyatlari yuklangan. Va shunday yig'ilish chiqadi.
Va barchasi birgalikda bu juda katta texnologiyalar to'plamini beradi, ularni boshqarish allaqachon qiyinlashadi, chunki Kubernetes o'zining kundalik muammolarini ishga tushiradi va ClickHouse o'z muammolarini kundalik faoliyatga olib keladi. Ayniqsa, agar bizda bir nechta ClickHouse mavjud bo'lsa va biz ular bilan doimo biror narsa qilishimiz kerak bo'lsa.
Dinamik konfiguratsiyaga ega ClickHouse-da DevOps-ga doimiy yukni keltirib chiqaradigan juda ko'p muammolar mavjud:
- Biz ClickHouse-da biror narsani o'zgartirmoqchi bo'lganimizda, masalan, replika, parcha qo'shing, keyin biz konfiguratsiyani boshqarishimiz kerak.
- Keyin ma'lumotlar sxemasini o'zgartiring, chunki ClickHouse ma'lum bir parchalash usuliga ega. U erda ma'lumotlar sxemasini tuzish, konfiguratsiyalarni joylashtirish kerak.
- Siz monitoringni o'rnatishingiz kerak.
- Yangi parchalar, yangi nusxalar uchun jurnallar to'plami.
- Qayta tiklash haqida g'amxo'rlik qiling.
- Va qayta ishga tushiring.
Bu shunday muntazam ishlarki, men ishlashda yordam berishni juda xohlayman.
Kubernetesning o'zi ishlashda juda ko'p yordam beradi, lekin asosiy tizim narsalarda.
Kubernetes quyidagi kabi narsalarni osonlashtirish va avtomatlashtirishda ajoyib:
- Qayta tiklash.
- Qayta ishga tushirish.
- Saqlash boshqaruvi.
Bu yaxshi, bu to'g'ri yo'nalish, lekin u ma'lumotlar bazasi klasterini qanday boshqarishni mutlaqo bilmaydi.
Men ko'proq narsani xohlayman, men butun ma'lumotlar bazasi biz uchun Kubernetesda ishlashini xohlayman.
Men siz bosgan katta bitta sehrli qizil tugmaga o'xshash narsani olishni xohlayman va sizda hal qilinishi kerak bo'lgan kundalik vazifalar bilan butun hayot tsikli davomida joylashtirilgan va qo'llab-quvvatlanadigan klaster mavjud. Kubernetesdagi ClickHouse klasteri.
Va biz ishni osonlashtirishga yordam beradigan yechim topishga harakat qildik. Bu Altinity-dan Kubernetes uchun ClickHouse-operatori.
Operator - bu asosiy vazifasi boshqa dasturlarni boshqarish bo'lgan dastur, ya'ni u menejer.
Va unda xulq-atvor namunalari mavjud. Siz uni mavzu bo'yicha kodlangan bilim deb atashingiz mumkin.
Va uning asosiy vazifasi DevOps uchun hayotni osonlashtirish va mikro boshqaruvni kamaytirishdir, shunda u (DevOps) allaqachon yuqori darajadagi nuqtai nazardan o'ylaydi, ya'ni u (DevOps) mikromanaj qilmasligi va barcha boshqaruvlarni qo'lda sozlamasligi uchun. tafsilotlar.
Va shunchaki operator - bu mikrovazifalar bilan kurashadigan va DevOps-ga yordam beradigan robot yordamchisi.
Nima uchun operator kerak? U ikki sohada ustunlik qiladi:
- Agar ClickHouse mutaxassisi etarli tajribaga ega bo'lmasa-da, lekin ClickHouse-ni ishlatish allaqachon zarur bo'lsa, operator operatsiyani osonlashtiradi va juda murakkab konfiguratsiyaga ega ClickHouse klasterini boshqarishga imkon beradi, shu bilan birga uning ichida qanday ishlashi haqida juda ko'p tafsilotga kirmaydi. . Siz unga faqat yuqori darajadagi topshiriqlarni berasiz va u ishlaydi.
- Va u o'zini eng yaxshi ko'rsatadigan ikkinchi vazifa - bu juda ko'p sonli odatiy vazifalarni avtomatlashtirish kerak bo'lganda. Mikrotasklarni tizim boshqaruvchilaridan olib tashlaydi.
Bu sayohatni endi boshlayotganlar yoki ko'p avtomatlashtirishni talab qiladiganlar uchun eng zarurdir.
Operatorga asoslangan yondashuvning boshqa tizimlardan farqi nimada? Helm ham bor. Bu shuningdek ClickHouse-ni o'rnatishga yordam beradi, siz hatto butun ClickHouse klasterini o'rnatadigan rul diagrammalarini chizishingiz mumkin. Operator va bir xil, masalan, Helm o'rtasidagi farq nima?
Asosiy asosiy farq shundaki, Helm paketlarni boshqarish bilan bog'liq va operator bir qadam oldinga boradi. Bu butun hayot aylanish jarayonini qo'llab-quvvatlaydi. Bu nafaqat o'rnatish, balki kundalik vazifalar, jumladan, masshtablash, parchalash, ya'ni hayot tsikli davomida bajarilishi kerak bo'lgan hamma narsa (agar kerak bo'lsa, olib tashlash ham) - bularning barchasi operator tomonidan hal qilinadi. U butun dasturiy ta'minotning hayot aylanishini avtomatlashtirishga va xizmat qilishga harakat qiladi. Bu uning taqdim etilgan boshqa echimlardan asosiy farqidir.
Bu kirish qismi edi, keling, davom etaylik.
Biz operatorimizni qanday quramiz? Biz ClickHouse klasterini yagona resurs sifatida boshqarish uchun muammoga yondashishga harakat qilmoqdamiz.
Bu erda biz rasmning chap tomonida kirish ma'lumotlariga egamiz. Bu klaster spetsifikatsiyasiga ega YAML bo'lib, kubectl orqali Kubernetesga klassik tarzda uzatiladi. U erda bizning operatorimiz uni oladi, sehrini qiladi. Va natijada biz bunday sxemani olamiz. Bu Kubernetes-da ClickHouse-ning amalga oshirilishi.
Va keyin biz asta-sekin operator qanday ishlashini, qanday tipik vazifalarni hal qilish mumkinligini ko'rib chiqamiz. Biz faqat odatiy vazifalarni ko'rib chiqamiz, chunki vaqtimiz cheklangan. Va operator qaror qilishi mumkin bo'lgan hamma narsa haqida aytilmaydi.
Amaliyotdan boshlaylik. Bizning loyihamiz butunlay ochiq manbadir, shuning uchun siz uning GitHub-da qanday ishlashini ko'rishingiz mumkin. Va siz mulohazalardan davom etishingiz mumkin, agar siz shunchaki boshlamoqchi bo'lsangiz, Tez boshlash qo'llanmasidan boshlashingiz mumkin.
Agar siz batafsil tushunishni istasangiz, biz hujjatlarni ko'proq yoki kamroq munosib shaklda saqlashga harakat qilamiz.
Keling, amaliy muammodan boshlaylik. Biz hammamiz boshlamoqchi bo'lgan birinchi vazifa qandaydir tarzda birinchi misolni ishga tushirishdir. ClickHouse-ni qanday ishlashini bilmasdan turib, operator yordamida qanday ishga tushirish mumkin? Biz manifest yozyapmiz, chunki k8s bilan barcha aloqa manifest orqali aloqadir.
Mana shunday murakkab manifest. Biz qizil rang bilan ta'kidlagan narsaga e'tibor qaratishimiz kerak. Biz operatordan demo nomli klaster yaratishni so'raymiz.
Hozircha bu asosiy misollar. Saqlash hali tavsiflanmagan, ammo biz birozdan keyin xotiraga qaytamiz. Hozircha biz klaster rivojlanishini dinamikada kuzatamiz.
Biz ushbu manifestni yaratdik. Biz uni operatorimizga beramiz. U ishladi, sehr qildi.
Biz konsolga qaraymiz. Uchta komponent qiziqish uyg'otadi - bular Pod, ikkita Service-a, StatefulSet.
Operator ishladi va biz aynan nimani yaratganini ko'rishimiz mumkin.
U shunga o'xshash narsani yaratadi. Bizda har bir replika uchun StatefulSet, Pod, ConfigMap, butun klaster uchun ConfigMap mavjud. Majburiy xizmatlar klasterga kirish nuqtasi sifatida.
Xizmatlar markaziy yuk balansi xizmatidir va u har bir replika, har bir parcha uchun mumkin.
Mana bizning asosiy klasterimiz shunday ko'rinadi. U bitta tugundan.
Keling, oldinga boraylik, biz murakkablashamiz. Siz klasterni bo'laklashingiz kerak.
Vazifalarimiz ortib bormoqda, dinamika boshlanmoqda. Biz parcha qo'shmoqchimiz. Biz rivojlanishni kuzatib boramiz. Biz spetsifikatsiyamizni o'zgartiramiz. Biz ikkita bo'lakni xohlayotganimizni bildiramiz.
Bu biz tizimning o'sishi bilan dinamik ravishda rivojlanayotgan bir xil fayl. Saqlash yo'q, saqlash haqida keyinroq muhokama qilinadi, bu alohida masala.
Biz YAML operatorini ovqatlantiramiz va nima sodir bo'lishini ko'ramiz.
Operator o'yladi va quyidagi ob'ektlarni qildi. Bizda allaqachon ikkita Pod, uchta Xizmat va to'satdan ikkita StatefulSets mavjud. Nima uchun 2 StatefulSets?
Diagrammada shunday edi - bu bizning dastlabki holatimiz, bizda bitta pod bo'lgan.
Bu shunday bo'ldi. Hozirgacha hamma narsa oddiy, u takrorlangan.
Va nima uchun StatefulSet ikkitaga aylandi? Bu erda biz Kubernetes-da podlar qanday boshqarilishi haqidagi savolni chetlab o'tishimiz va muhokama qilishimiz kerak.
StatefulSet deb nomlangan bunday ob'ekt mavjud bo'lib, u shablondan Podlar to'plamini yaratishga imkon beradi. Bu erda asosiy omil shablondir. Va siz bir shablonga ko'ra bir StatefulSetda ko'plab podlarni ishga tushirishingiz mumkin. Va bu erda asosiy ibora "bir shablon ko'p podalar".
Va butun klasterni bitta StatefulSetga to'plash uchun ajoyib vasvasa bor edi. Bu ishlaydi, unda hech qanday muammo yo'q. Ammo bitta ogohlantirish bor. Agar biz heterojen klasterni, ya'ni ClickHouse-ning bir nechta versiyalaridan yig'moqchi bo'lsak, unda savollarimiz boshlanadi. Ha, StatefulSet yangilanishni amalga oshirishi mumkin, ammo u erda siz yangi versiyani chiqarishingiz mumkin, bir vaqtning o'zida juda ko'p tugunlarni sinab ko'rishingiz kerakligini tushuntiring.
Ammo agar biz vazifani ekstrapolyatsiya qilsak va biz butunlay heterojen klaster yaratmoqchimiz va yangilanish yordamida eski versiyadan yangisiga o'tishni xohlamaymiz, balki shunchaki turli xil versiyalar bo'yicha heterojen klaster yaratmoqchimiz. ClickHouse va turli xil saqlash nuqtai nazaridan. Biz, masalan, alohida disklarda, sekin disklarda ba'zi nusxalarni yaratishni, umuman olganda, heterojen klasterni to'liq qurishni xohlaymiz. Va StatefulSet bitta shablondan standartlashtirilgan yechim ishlab chiqaradi, shuning uchun buni qilishning hech qanday usuli yo'q.
Biroz o'ylab, biz shunday qilishga qaror qildik. Bizda har bir nusxa o'z StatefulSet-da mavjud. Ushbu yechimning ba'zi kamchiliklari bor, lekin amalda bularning barchasi operatorni to'liq qamrab oladi. Va juda ko'p foydalari bor. Biz butunlay shunday klasterni o'zimiz xohlagancha qurishimiz mumkin, masalan, mutlaqo heterojen. Shuning uchun, bizda bitta replika bilan ikkita parcha bo'lgan klasterda biz 2 ta StatefulSets va 2 Podga ega bo'lamiz, chunki biz heterojen klasterni yaratish qobiliyati uchun yuqoridagi sabablarga ko'ra ushbu yondashuvni tanladik.
Keling, amaliy vazifalarga qaytaylik. Bizning klasterimizda biz foydalanuvchilarni sozlashimiz kerak, ya'ni. Kubernetes-da ClickHouse-ning ba'zi konfiguratsiyasini bajarishingiz kerak. Buning uchun operator barcha imkoniyatlarni taqdim etadi.
Biz xohlagan narsani to'g'ridan-to'g'ri YAMLda yozishimiz mumkin. Barcha konfiguratsiya opsiyalari toʻgʻridan-toʻgʻri ushbu YAML dan ClickHouse konfiguratsiyalariga joylashtiriladi va ular keyinchalik klaster boʻylab joylashtiriladi.
Siz ham shunday yozishingiz mumkin. Bu misol uchun. Parol shifrlangan bo'lishi mumkin. Mutlaqo barcha ClickHouse konfiguratsiya variantlari qo'llab-quvvatlanadi. Bu yerda faqat bir misol.
Klaster konfiguratsiyasi ConfigMap sifatida taqsimlanadi. Amalda, ConfigMap yangilanishi bir zumda sodir bo'lmaydi, shuning uchun katta klaster mavjud bo'lsa, unda konfiguratsiyani surish jarayoni biroz vaqt talab etadi. Lekin bularning barchasi foydalanish uchun juda qulay.
Biz vazifani murakkablashtiramiz. Klaster rivojlanmoqda. Biz ma'lumotlarni takrorlashni xohlaymiz. Ya'ni, bizda allaqachon ikkita parcha bor, har birida bitta replika, foydalanuvchilar sozlangan. Biz o'sib bormoqdamiz va takrorlashni xohlaymiz.
Replikatsiya qilish uchun bizga nima kerak?
Bizga ZooKeeper kerak. ClickHouse-da replikatsiya ZooKeeper yordamida qurilgan. ZooKeeper turli xil ClickHouse replikalarida qaysi ma'lumotlar bloklari qaysi ClickHouse-da ekanligi to'g'risida konsensusga ega bo'lishi uchun kerak.
ZooKeeper-dan har kim foydalanishi mumkin. Agar korxonada tashqi ZooKeeper bo'lsa, undan foydalanish mumkin. Agar yo'q bo'lsa, bizning omborimizdan o'rnatishingiz mumkin. Hamma narsani osonlashtiradigan o'rnatuvchi mavjud.
Va butun tizimning o'zaro ta'siri sxemasi shunday chiqadi. Bizda platforma sifatida Kubernetes bor. U ClickHouse bayonotini bajaradi. ZooKeeper men bu erda tasvirlanganman. Operator ham ClickHouse, ham ZooKeeper bilan o'zaro ishlaydi. Ya'ni, o'zaro ta'sir olinadi.
Va bularning barchasi ClickHouse uchun ma'lumotlarni k8-larga muvaffaqiyatli takrorlash uchun zarur.
Keling, vazifaning o'zini ko'rib chiqaylik, replikatsiya uchun manifest qanday ko'rinishini.
Manifestimizga ikkita bo'lim qo'shamiz. Birinchisi, ZooKeeperni qaerdan olish kerak, u Kubernetes ichida yoki tashqi bo'lishi mumkin. Bu shunchaki tavsif. Va biz nusxalarni buyurtma qilamiz. Bular. Biz ikkita nusxani xohlaymiz. Hammasi bo'lib chiqishda bizda 4 ta podka bo'lishi kerak. Saqlash haqida eslaymiz, u biroz keyinroq qaytib keladi. Saqlash - bu alohida qo'shiq.
Bu shunday edi.
Bu shunday bo'ladi. Replikalar qo'shiladi. 4-chi mos kelmadi, biz ularning ko'p bo'lishi mumkinligiga ishonamiz. Va yon tomonda ZooKeeper qo'shilgan. Shakllar yanada murakkablashmoqda.
Va keyingi vazifani qo'shish vaqti keldi. Biz doimiy xotirani qo'shamiz.
Doimiy saqlash uchun bizda turli xil variantlar mavjud.
Agar biz bulutli provayderda ishlayotgan bo'lsak, masalan, Amazon, Google-dan foydalanayotgan bo'lsak, bulutli saqlashdan foydalanish uchun ajoyib vasvasa mavjud. Bu juda qulay, yaxshi.
Va ikkinchi variant bor. Bu har bir tugunda mahalliy disklar mavjud bo'lganda mahalliy saqlash uchun. Ushbu variantni amalga oshirish ancha qiyin, lekin ayni paytda u samaraliroq.
Keling, bulutli saqlash haqida nima borligini ko'rib chiqaylik.
Fazilatlari bor. Buni sozlash juda oson. Biz shunchaki bulutli provayderga buyurtma beramiz, iltimos, bizga falon sig'imni, falon sinfni saqlashni bering. Sinflar provayderlar tomonidan mustaqil ravishda bo'yalgan.
Va bir kamchilik bor. Ba'zilar uchun bu tanqidiy kamchilik. Albatta, ba'zi ishlash ko'rsatkichlari bo'ladi. Foydalanish juda qulay, ishonchli, ammo ishlashda ba'zi kamchiliklar mavjud.
Va shundan beri ClickHouse ishlashga e'tibor qaratadi, hatto u mumkin bo'lgan hamma narsani siqib chiqaradi, deb ayta olasiz, shuning uchun ko'plab mijozlar maksimal ishlashni siqib chiqarishga harakat qilishadi.
Va undan maksimal darajada foydalanish uchun bizga mahalliy saqlash kerak.
Kubernetes Kubernetesda mahalliy xotiradan foydalanish uchun uchta abstraktsiyani taqdim etadi. Bu:
- EmptyDir
- HostPath.
- mahalliy
Ular qanday farq qilishini, qanday o'xshashligini ko'rib chiqing.
Birinchidan, uchta yondashuvda bizda saqlash mavjud - bular bir xil jismoniy k8s tugunida joylashgan mahalliy disklar. Ammo ularning ba'zi farqlari bor.
Eng oddiy, ya'ni emptyDir bilan boshlaylik. Amalda nima bor? Aynan biz konteynerlashtirish tizimidan (ko'pincha Docker) bizning spetsifikatsiyamizdan mahalliy diskdagi papkaga kirishni so'raymiz.
Amalda, docker o'z yo'llaridagi biror joyda vaqtinchalik papka yaratadi va uni uzoq xesh deb ataydi. Va unga kirish uchun interfeysni taqdim etadi.
U ishlash nuqtai nazaridan qanday ishlaydi? Bu mahalliy disk tezligida ishlaydi, ya'ni. bu sizning vintingizga to'liq kirishdir.
Ammo bu ishning kamchiliklari bor. Bu holatda qat'iylik juda shubhali. Dockerning konteynerlar bilan birinchi harakatida Persistent yo'qoladi. Agar Kubernetes ushbu Podni biron sababga ko'ra boshqa diskka ko'chirmoqchi bo'lsa, u holda ma'lumotlar yo'qoladi.
Ushbu yondashuv testlar uchun yaxshi, chunki u allaqachon normal tezlikni ko'rsatadi, ammo bu variant jiddiy narsa uchun mos emas.
Shuning uchun ikkinchi yondashuv mavjud. Bu hostPath. Agar oldingi slaydga va bu slaydga qarasangiz, faqat bitta farqni ko'rishingiz mumkin. Bizning papkamiz dockerni to'g'ridan-to'g'ri Kubernetes tuguniga qoldirdi. Bu erda biroz tezroq. Biz to'g'ridan-to'g'ri ma'lumotlarimizni saqlamoqchi bo'lgan mahalliy fayl tizimiga yo'lni yozamiz.
Bu usulning afzalliklari bor. Bu allaqachon haqiqiy Persistent va klassik. Bizning diskimizda ma'lumotlar qandaydir manzilga yoziladi.
Kamchiliklari ham bor. Bu boshqaruvning murakkabligi. Bizning Kubernetlarimiz Podni boshqa jismoniy tugunga ko'chirishni xohlashlari mumkin. Bu erda DevOps o'ynaydi. U butun tizimga to'g'ri tushuntirishi kerakki, siz bu podkalarni faqat shu yo'llar bo'ylab biror narsa o'rnatilgan tugunlarga ko'chirishingiz mumkin va bir vaqtning o'zida bir nechta tugun bo'lmaydi. Bu yetarlicha qiyin.
Ayniqsa, ushbu maqsadlar uchun biz operatorimizda barcha murakkablikni yashirish uchun shablonlarni yaratdik. Va siz shunchaki aytishingiz mumkin: "Men har bir jismoniy tugun va falon yo'l bo'ylab bitta ClickHouse nusxasiga ega bo'lishni xohlayman."
Ammo bu ehtiyoj nafaqat biz uchun, shuning uchun Kubernetesning o'zi ham odamlar jismoniy disklarga kirishni xohlashlarini tushunishadi, shuning uchun ular uchinchi darajani ta'minlaydi.
Bu mahalliy deyiladi. Oldingi slayddan deyarli farq yo'q. Ilgari biz qo'llarimiz bilan bu podlarni tugundan tugunga o'tkaza olmasligimizni amalga oshirishimiz kerak edi, chunki ular falon yo'l bo'ylab mahalliy jismoniy diskka biriktirilishi kerak va endi bu bilimlarning barchasi Kubernetesning o'zida qamrab olingan. Va sozlash ancha oson bo'lib chiqdi.
Keling, amaliy vazifamizga qaytaylik. YAML shabloniga qaytaylik. Bu erda bizda haqiqiy saqlash joyi bor. Biz bunga qaytdik. Biz klassik VolumeClaim shablonini k8s-dagi kabi o'rnatdik. Va biz qanday saqlashni xohlayotganimizni tasvirlaymiz.
Shundan so'ng, k8s saqlashni talab qiladi. Uni StatefulSet-da bizga ajrating. Va oxir-oqibat, bu ClickHouse ixtiyorida bo'ladi.
Bizda shunday sxema bor edi. Bizning doimiy saqlashimiz qizil rangga ega edi, bu buni qilish kerakligini ko'rsatardi.
Va yashil rangga aylanadi. Endi k8s klasteridagi ClickHouse sxemasi to'liq yakunlandi. Bizda parchalar, replikalar, ZooKeeper bor, bizda u yoki bu tarzda amalga oshiriladigan haqiqiy Persistent bor. Sxema allaqachon to'liq ishlaydi.
Biz yashashda davom etamiz. Bizning klasterimiz o'sib bormoqda. Va Aleksey ClickHouse-ning yangi versiyasini chiqarishga harakat qilmoqda.
Amaliy vazifa tug'iladi - ClickHouse-ning yangi versiyasini bizning klasterimizda sinab ko'rish. Va, albatta, men hammasini tarqatishni istamayman, men bitta nusxada uzoq burchakda biron bir joyga yangi versiyani qo'yishni xohlayman yoki ehtimol bitta yangi versiya emas, balki bir vaqtning o'zida ikkita, chunki ular tez-tez chiqadi.
Bu haqda nima deyishimiz mumkin?
Mana bizda shunday imkoniyat bor. Bu pod shablonlari. Siz bo'yashingiz mumkin, bizning operatorimiz sizga heterojen klasterni yaratishga to'liq imkon beradi. Bular. sozlang, barcha replikalardan boshlab, har bir shaxsiy replika bilan tugaydi, qaysi versiyani ClickHouse, qaysi versiyani saqlashni xohlaymiz. Biz klasterni kerakli konfiguratsiyada to'liq sozlashimiz mumkin.
Keling, ichkariga biroz chuqurroq kiraylik. Bundan oldin biz ClickHouse-operatorining ClickHouse-ning o'ziga xos xususiyatlariga nisbatan qanday ishlashi haqida gapirgan edik.
Endi men har qanday operatorning umuman qanday ishlashi, shuningdek, K8s bilan o'zaro aloqasi haqida bir necha so'z aytmoqchiman.
Boshlash uchun K8 bilan o'zaro aloqani ko'rib chiqing. Biz kubectl ilovasini qo'llasak nima bo'ladi? API orqali bizning ob'ektlarimiz etcd da paydo bo'ladi.
Masalan, asosiy Kubernetes ob'ektlari: pod, StatefulSet, xizmat va boshqalar ro'yxat orqali.
Biroq, hali jismoniy hech narsa sodir bo'lmaydi. Ushbu ob'ektlar klasterda amalga oshirilishi kerak.
Bu erda boshqaruvchi kiradi. Tekshirish moslamasi bu tavsiflarni amalga oshirishi mumkin bo'lgan maxsus k8s komponentidir. U jismoniy jihatdan qanday va nima qilishni biladi. U konteynerlarni qanday ishga tushirishni biladi, server ishlashi uchun u erda nimani sozlash kerak.
Va u bizning ob'ektlarimizni K8-larda moddiylashtiradi.
Lekin biz nafaqat pods, StatefulSets bilan ishlashni xohlaymiz, balki u bilan bir butun sifatida ishlash uchun ClickHouseInstallation, ya'ni ClickHouse tipidagi ob'ektni yaratmoqchimiz. Hozircha bunday imkoniyat yo'q.
Ammo K8-ning yana bir yaxshi tomoni bor. Biz shunday murakkab ob'ektga ega bo'lishni xohlaymiz, unda bizning klasterimiz pods va StatefulSet dan yig'iladi.
Va buning uchun nima qilish kerak? Birinchidan, Custom Resource Definition sahnaga kiradi. Bu nima? Bu K8 uchun tavsif boʻlib, sizda biz podkadaga qoʻshmoqchi boʻlgan yana bir maʼlumot turi boʻladi, yaʼni StatefulSet, maxsus resurs ichida murakkab boʻladi. Bu ma'lumotlar strukturasining tavsifi.
Biz uni kubectl application orqali ham yuboramiz. Kubernetes buni mamnuniyat bilan qabul qildi.
Va endi bizning omborimizda etcd-dagi ob'ekt ClickHouseInstallation deb nomlangan maxsus resurs yozish imkoniyatiga ega.
Ammo hozircha boshqa hech narsa bo'lmaydi. Ya'ni, agar biz hozir parcha, replikalar tavsifi bilan ko'rib chiqiladigan YAML faylini yaratsak va "kubectl amal qiladi" deb aytsak, Kubernetes uni qabul qiladi va etcd ga qo'yadi va aytadi: "Ajoyib, lekin men bilmayman. u bilan nima qilish kerak. Men ClickHouseInstallation-ni qanday saqlashni bilmayman."
Shunga ko'ra, bizga Kubernetesga yangi ma'lumotlar turiga xizmat ko'rsatishda yordam beradigan kimdir kerak. Chap tomonda bizda birja ma'lumotlari turlari bilan ishlaydigan aktsiyadorlik Kubernetes kontrolleri mavjud. Va o'ng tomonda, bizda maxsus ma'lumotlar turlari bilan ishlaydigan maxsus kontroller bo'lishi kerak.
Va boshqa yo'l bilan u operator deb ataladi. Men buni maxsus Kubernetes uchun olib chiqdim, chunki u K8-dan tashqarida ham bajarilishi mumkin. Ko'pincha, albatta, barcha bayonotlar Kubernetes-da bajariladi, lekin uning tashqarida turishiga hech narsa to'sqinlik qilmaydi, shuning uchun u bu erda maxsus chiqariladi.
Va allaqachon, o'z navbatida, operator sifatida ham tanilgan maxsus kontroller API orqali Kubernetes bilan o'zaro ishlaydi. U allaqachon API bilan qanday ishlashni biladi. Va u allaqachon biz maxsus resursdan yaratmoqchi bo'lgan murakkab sxemani qanday amalga oshirishni biladi. Bu operator aynan shunday qiladi.
Operator qanday ishlaydi? Keling, u buni qanday qilishini ko'rish uchun o'ng tomonni ko'rib chiqaylik. Operator bularning barchasini qanday amalga oshirishini va K8s bilan keyingi o'zaro ta'sir qanday sodir bo'lishini bilib olamiz.
Operator - bu dastur. U voqealarga yo'naltirilgan. Operator Kubernetes API yordamida voqealarga obuna bo'ladi. Kubernetes API-da tadbirlarga obuna bo'lishingiz mumkin bo'lgan kirish nuqtalari mavjud. Va agar K8-larda biror narsa o'zgarsa, Kubernetes voqealarni hammaga yuboradi, ya'ni. ushbu API nuqtasiga obuna bo'lganlar bildirishnomalarni oladilar.
Operator voqealarga obuna bo'ladi va qandaydir reaktsiyani amalga oshirishi kerak. Uning vazifasi paydo bo'lgan voqealarga javob berishdir.
Voqealar ba'zi yangilanishlar orqali yaratiladi. Bizning YAML faylimiz ClickHouseInstallation tavsifi bilan keladi. U kubectl application orqali etcd ga bordi. U erda bir voqea ishladi, natijada bu voqea ClickHouse-operatoriga keldi. Operator ushbu tavsifni oldi. Va u nimadir qilishi kerak. Agar ClickHouseInstallation ob'ektiga yangilanish kelgan bo'lsa, siz klasterni yangilashingiz kerak. Operatorning vazifasi esa klasterni yangilashdir.
U nima qilyapti? Birinchidan, biz ushbu yangilanish bilan nima qilishimiz uchun harakat rejasini tuzishimiz kerak. Yangilanishlar juda kichik bo'lishi mumkin, ya'ni. YAML bajarilishida kichik, lekin klasterda juda katta o'zgarishlarga olib kelishi mumkin. Shuning uchun operator reja tuzadi, keyin esa unga amal qiladi.
U ushbu rejaga ko'ra, podlarni, xizmatlarni, ya'ni moddiylashtirish uchun bu tuzilmani ichida qaynatishni boshlaydi. uning asosiy vazifasi bo'lgan narsani qilish. Bu Kubernetesda ClickHouse klasterini qurishga o'xshaydi.
Endi shunday qiziq bir narsaga to'xtalib o'tamiz. Bu Kubernetes va operator o'rtasidagi mas'uliyatni taqsimlash, ya'ni. Kubernetes nima qiladi, operator nima qiladi va ular bir-biri bilan qanday munosabatda bo'lishadi.
Kubernetes tizimli narsalar uchun javobgardir, ya'ni. tizim doirasi sifatida talqin qilinishi mumkin bo'lgan asosiy ob'ektlar to'plami uchun. Kubernetes podlarni qanday ishga tushirishni, konteynerlarni qanday qayta ishga tushirishni, hajmlarni o'rnatishni, ConfigMap bilan qanday ishlashni biladi, ya'ni. tizim deb atash mumkin bo'lgan har qanday narsa.
Operatorlar mavzu bo'yicha ishlaydi. Har bir operator o'z predmeti uchun yaratilgan. Biz ClickHouse uchun yaratdik.
Operator esa replika qo'shish, sxema tuzish, monitoringni o'rnatish kabi mavzu sohasi bo'yicha aniq o'zaro ta'sir qiladi. Bunday bo'linish mavjud.
Keling, replika qo'shish amalini bajarganimizda tashvishlarning bu bo'linishi qanday sodir bo'lishining amaliy misolini ko'rib chiqaylik.
Vazifa operatorga keladi - replika qo'shish. Operator nima qiladi? Operator yangi StatefulSet yaratish zarurligini hisoblab chiqadi, unda falon shablonlarni, hajm talabini tavsiflash zarur.
U hammasini tayyorlab, K8larga uzatadi. Uning aytishicha, unga ConfigMap, StatefulSet, Volume kerak. Kubernetes ishlamoqda. U o'zi ishlaydigan asosiy birliklarni moddiylashtiradi.
Va keyin ClickHouse-operator yana ishga tushadi. U allaqachon biror narsa qilishingiz mumkin bo'lgan jismoniy podga ega. Va ClickHouse-operator yana mavzu bo'yicha ishlaydi. Bular. Xususan, ClickHouse, replikani klasterga qo'shish uchun, birinchi navbatda, ushbu klasterda mavjud bo'lgan ma'lumotlar sxemasini sozlashingiz kerak. Va, ikkinchidan, bu eslatma aniq kuzatilishi uchun monitoringga kiritilishi kerak. Operator uni allaqachon o'rnatgan.
Va shundan keyingina ClickHouse o'zi o'yinga kiradi, ya'ni. boshqa yuqori darajadagi shaxs. Bu allaqachon ma'lumotlar bazasi. Uning o'z namunasi, klasterga qo'shilish uchun tayyor bo'lgan keyingi sozlangan nusxasi bor.
Ko'rinib turibdiki, replika qo'shilganda ijro etilish zanjiri va javobgarlikni ajratish etarli darajada uzun.
Biz amaliy vazifalarimizni davom ettiramiz. Agar klaster allaqachon mavjud bo'lsa, siz konfiguratsiyani ko'chirishingiz mumkin.
Biz buni ClickHouse tushunadigan mavjud xml ga o'tish mumkin bo'lishi uchun qildik.
ClickHouse-ni yaxshi sozlashingiz mumkin. Shunchaki zonalarga ajratilgan joylashtirish - bu hostPath, mahalliy saqlashni tushuntirishda gapirgan narsam. Bu qanday qilib rayonlashtirilgan joylashtirishni to'g'ri bajarishdir.
Keyingi amaliy vazifa - bu monitoring.
Agar bizning klasterimiz o'zgarsa, biz vaqti-vaqti bilan monitoringni sozlashimiz kerak.
Keling, diagrammani ko'rib chiqaylik. Biz allaqachon bu erda yashil o'qlarni ko'rib chiqdik. Endi qizil o'qlarni ko'rib chiqaylik. Biz klasterimizni shunday kuzatmoqchimiz. ClickHouse klasteridagi ko'rsatkichlar qanday qilib Prometeyga, keyin esa Grafana-ga kiradi.
Monitoring bilan qanday muammo bor? Nega bu qandaydir yutuq sifatida taqdim etiladi? Qiyinchilik dinamikada yotadi. Agar bizda bitta klaster mavjud bo'lsa va u statik bo'lsa, siz monitoringni bir marta o'rnatishingiz va boshqa bezovta qilmasligingiz mumkin.
Ammo agar bizda juda ko'p klasterlar bo'lsa yoki biror narsa doimo o'zgarib tursa, bu jarayon dinamikdir. Va doimiy ravishda monitoringni qayta sozlash resurslar va vaqtni behuda sarflashdir; hatto shunchaki dangasa. Buni avtomatlashtirish kerak. Qiyinchilik jarayonning dinamikasida. Va operator buni juda yaxshi avtomatlashtiradi.
Bizning klasterimiz qanday rivojlandi? Boshida u shunday edi.
Keyin u shunday edi.
Oxir-oqibat u shunday bo'ldi.
Va monitoring avtomatik ravishda operator tomonidan amalga oshiriladi. Yagona kirish nuqtasi.
Va biz shunchaki Grafana asboblar panelidagi chiqishga qaraymiz, bizning klasterimiz hayoti qanday qaynatiladi.
Aytgancha, Grafana asboblar paneli ham bizning operatorimiz bilan manba kodida tarqatiladi. Siz ulanishingiz va foydalanishingiz mumkin. Ushbu skrinshot menga DevOps tomonidan berilgan.
Keyingi qayerga bormoqchimiz? Bu:
- Sinovlarni avtomatlashtirishni ishlab chiqish. Asosiy vazifa - yangi versiyalarni avtomatlashtirilgan sinovdan o'tkazish.
- Biz ZooKeeper bilan integratsiyani avtomatlashtirishni ham xohlaymiz. Va ZooKeeper-operator bilan integratsiya qilishni rejalashtirmoqda. Bular. ZooKeeper uchun operator yozilgan va bu ikki operator yanada qulayroq yechim yaratish uchun integratsiyaga kirishishi mantiqan to'g'ri.
- Biz yanada murakkab hayot tekshiruvlarini o'tkazmoqchimiz.
- Yo‘lda bizda Shablonlar merosi borligini yashil rang bilan ta’kidladim – BAJARLANDI, ya’ni operatorning keyingi chiqarilishi bilan bizda shablon merosi allaqachon bo‘ladi. Bu qismlardan murakkab konfiguratsiyalarni yaratishga imkon beruvchi kuchli vositadir.
- Va biz murakkab vazifalarni avtomatlashtirishni xohlaymiz. Asosiysi - qayta taqsimlash.
Keling, oraliq natijalarga erishaylik.
Natijada nimaga erishamiz? Va bunga arziydimi yoki yo'qmi? Men ma'lumotlar bazasini Kubernetes-ga sudrab borishga harakat qilishim kerakmi va umuman operatorni va xususan Alitnity operatorini qo'llashim kerakmi?
Chiqishda biz quyidagilarni olamiz:
- Konfiguratsiya, joylashtirish va texnik xizmat ko'rsatishni sezilarli darajada soddalashtiring va avtomatlashtiring.
- Darhol o'rnatilgan monitoring.
- Va murakkab vaziyatlar uchun foydalanishga tayyor kodlangan andozalar. Replika qo'shish uchun turdagi harakatlar allaqachon qo'lda bajarilishi shart emas. Bu operator tomonidan amalga oshiriladi.
Faqat oxirgi savol qoladi. Bizda allaqachon Kubernetesda ma'lumotlar bazasi mavjud, virtualizatsiya. Bunday yechimning ishlashi haqida nima deyish mumkin, ayniqsa ClickHouse ishlash uchun optimallashtirilganligi sababli?
Javob: hammasi yaxshi! Men batafsil bayon qilmayman, bu alohida hisobot mavzusi.
Ammo TSBS kabi loyiha mavjud. Uning asosiy vazifasi nima? Bu ma'lumotlar bazasining ishlash testidir. Bu iliq bilan iliq, yumshoq bilan yumshoq solishtirishga urinishdir.
U qanday ishlaydi? Bitta ma'lumotlar to'plami yaratiladi. Keyin bir xil test to'plamidagi ushbu ma'lumotlar to'plami turli ma'lumotlar bazalarida ishga tushiriladi. Va har bir ma'lumotlar bazasi bitta muammoni imkon qadar hal qiladi. Va keyin siz natijalarni taqqoslashingiz mumkin.
U allaqachon ko'plab ma'lumotlar bazalarini qo'llab-quvvatlaydi. Men uchta asosiy narsani aniqladim. Bu:
- vaqt shkalasi b.
- InfluxDB.
- klik uyi.
Boshqa shunga o'xshash yechim bilan taqqoslash ham amalga oshirildi. RedShift bilan taqqoslash. Taqqoslash Amazonda amalga oshirildi. ClickHouse ham bu borada hammadan ancha oldinda.
Men aytganlarimdan qanday xulosalar chiqarish mumkin?
- Kubernetesda DB mumkin. Ehtimol, siz hamma narsani qila olasiz, lekin umuman olganda, siz qila olasiz. Kubernetesdagi ClickHouse, albatta, bizning operatorimiz yordamida mumkin.
- Operator jarayonlarni avtomatlashtirishga yordam beradi va hayotni haqiqatan ham soddalashtiradi.
- Ishlash normal.
- Va, bizning fikrimizcha, undan foydalanish mumkin va kerak.
Ochiq manba - bizga qo'shiling!
Aytganimdek, operator butunlay ochiq manba mahsulotidir, shuning uchun undan maksimal darajada foydalansa, juda yaxshi bo'lardi. Hoziroq qo'shil! Barchangizni kutamiz!
Barchangizga rahmat!
Sizning savollaringiz
Hisobot uchun rahmat! Mening ismim Anton. Men SEMrushdanman. Menga hayronman, jurnallar nima bo'ldi? Biz monitoring haqida eshitamiz, lekin butun klaster haqida gapiradigan bo'lsak, jurnalga kirish haqida hech narsa yo'q. Misol uchun, bizda apparat bo'yicha klaster mavjud. Va biz markazlashtirilgan jurnallardan foydalanamiz, biz uni standart vositalar yordamida umumiy yig'ma yig'amiz. Va keyin u erdan biz uchun qiziqarli ma'lumotlarni olamiz.
Yaxshi savol, ya'ni vazifalar ro'yxatiga kirish. Bizning operatorimiz buni hali avtomatlashtirmagan. U hali ham rivojlanmoqda, loyiha hali juda yosh. Biz ro'yxatga olish zarurligini tushunamiz. Bu ham juda muhim mavzu. Va bu, ehtimol, monitoringdan kam emas. Lekin amalga oshirish uchun ro'yxatda birinchi navbatda monitoring edi. Jurnal bo'ladi. Tabiiyki, biz klaster hayotining barcha jabhalarini avtomatlashtirishga harakat qilmoqdamiz. Shuning uchun javob shundaki, hozirda operator, afsuski, buni qanday qilishni bilmaydi, lekin bu rejalarda, biz buni qilamiz. Agar siz qo'shilishni istasangiz, iltimos, so'rovni oling.
Salom! Hisobot uchun rahmat! Doimiy jildlar bilan bog'liq standart savolim bor. Ushbu operator bilan konfiguratsiya yaratganimizda, operator qaysi tugunda bizda disk yoki papka borligini qanday aniqlaydi? Biz birinchi navbatda unga tushuntirishimiz kerak, iltimos, bizning ClickHouse-ni diski bo'lgan ushbu tugunlarga qo'yingmi?
Men tushunganimdek, bu savol mahalliy saqlashning davomi, ayniqsa uning hostPath qismi. Bu butun tizimga podning aynan falon tugunda ishga tushirilishi zarurligini tushuntirishga o'xshaydi, unda bizda jismoniy ulangan disk bor, u falon yo'lda o'rnatiladi. Bu men juda yuzaki ta'sir qilgan butun bo'lim, chunki u erda javob juda katta.
Qisqacha aytganda, bu shunday ko'rinadi. Albatta, biz bu hajmlarni ta'minlashimiz kerak. Hozirgi vaqtda mahalliy saqlashda dinamik ta'minot mavjud emas, shuning uchun DevOps disklarni o'zlari kesishi kerak, mana bu hajmlar. Va ular Kubernetes ta'minotini tushuntirishlari kerak, siz falon tugunlarda joylashgan falon sinfning doimiy hajmlariga ega bo'lasiz. Keyin Kubernetesga shunday va shunga o'xshash mahalliy saqlash sinfini talab qiladigan podkastlarni faqat falon tugunlarga teglar bo'yicha rejalashtirish kerakligini tushuntirish kerak bo'ladi. Ushbu maqsadlar uchun operator har bir xost namunasiga qandaydir yorliq va bittadan belgilash imkoniyatiga ega. Va ma'lum bo'lishicha, pods Kubernetes tomonidan faqat oddiy so'z bilan aytganda talablarga, teglarga javob beradigan tugunlarda ishlash uchun yo'naltiriladi. Administratorlar teglarni tayinlaydilar, disklarni qo'lda ta'minlaydilar. Va keyin u kattalashadi.
Va faqat uchinchi mahalliy variant buni biroz osonlashtirishga yordam beradi. Yuqorida ta'kidlaganimdek, bu sozlashning mashaqqatli ishi bo'lib, natijada maksimal ishlashga yordam beradi.
Bu bilan bog'liq ikkinchi savolim bor. Kubernetes shunday yaratilganki, biz tugunni yo'qotamizmi yoki yo'qmi, biz uchun muhim emas. Agar bizda parcha bo'lgan tugunni yo'qotgan bo'lsak, bu holatda nima qilishimiz kerak?
Ha, Kubernetes dastlab bizning podalar bilan bo'lgan munosabatimiz qoramolga o'xshab ketgan, ammo bu erda har bir disk uy hayvoniga o'xshaydi. Bunday muammo borki, biz ularni shunchaki tashlab bo'lmaydi. Va Kubernetesning rivojlanishi shu yo'nalishda ketmoqdaki, unga butunlay falsafiy, butunlay tashlab ketilgan manba sifatida munosabatda bo'lish mumkin emas.
Endi amaliy savol. Disk joylashgan tugunni yo'qotib qo'ysangiz nima qilish kerak? Bu erda muammo yuqori darajada hal qilinadi. ClickHouse misolida bizda yuqori darajada ishlaydigan replikalar mavjud, ya'ni. ClickHouse darajasida.
Moslashuvchanlik nima? DevOps ma'lumotlar yo'qolmasligini ta'minlash uchun javobgardir. U replikatsiyani to'g'ri sozlashi va replikatsiya ishlayotganligini ta'minlashi kerak. ClickHouse darajasidagi replikatsiyada ma'lumotlar takrorlanishi kerak. Bu operator hal qiladigan vazifa emas. Va Kubernetesning o'zi hal qiladigan vazifa emas. Bu ClickHouse darajasida.
Agar temir tuguningiz tushib ketgan bo'lsa, nima qilish kerak? Va ma'lum bo'lishicha, ikkinchisini qo'yish, diskni to'g'ri siljitish, teglarni qo'llash kerak bo'ladi. Shundan so'ng, u Kubernetes pod instansiyasini ishga tushirishi mumkin bo'lgan talablarni qondiradi. Kubernetes uni ishga tushiradi. Ko'rsatilgan podkastlaringiz soni etarli emas. Bu men ko'rsatgan tsikldan o'tadi. Va eng yuqori darajada, ClickHouse bizda replika kiritilganligini tushunadi, u hali ham bo'sh va biz unga ma'lumotlarni uzatishni boshlashimiz kerak. Bular. bu jarayon hali ham yomon avtomatlashtirilgan.
Hisobot uchun rahmat! Har xil noxush hodisalar ro'y berganda, operator ishdan chiqadi va qayta ishga tushadi va o'sha paytda voqealar sodir bo'ladi, siz buni qandaydir tarzda qayta ishlaysizmi?
Agar operator ishlamay qolsa va qayta ishga tushsa nima bo'ladi, ha?
Ha. Va o'sha paytda voqealar yuz berdi.
Bu holatda nima qilish kerakligi vazifasi qisman operator va Kubernetes o'rtasida bo'linadi. Kubernetes sodir bo'lgan voqeani takrorlash qobiliyatiga ega. U takrorlaydi. Operatorning vazifasi esa voqealar jurnali unda takrorlanganda, bu hodisalar idempotent ekanligiga ishonch hosil qilishdir. Va shunday qilib, xuddi shu hodisaning takrorlanishi biz uchun tizimimizni buzmaydi. Va bizning operatorimiz bu vazifani bajaradi.
Salom! Hisobot uchun rahmat! Dmitriy Zavialov, kompaniya Smedov. Operatorga haproxy bilan moslashtirish variantlarini qo'shish rejalashtirilganmi? Ba'zi boshqa muvozanatlashtiruvchi standartdan tashqari qiziqarli, shuning uchun u aqlli va ClickHouse u erda haqiqiy ekanligini tushunadi.
Ingress haqida gapiryapsizmi?
Ha, Ingressni haproksi bilan almashtiring. Haproksida siz replikalarga ega bo'lgan klaster topologiyasini belgilashingiz mumkin.
Hozircha biz bu haqda o'ylamaganmiz. Agar sizga kerak bo'lsa va nima uchun kerakligini tushuntira olsangiz, uni amalga oshirish mumkin bo'ladi, ayniqsa ishtirok etishni xohlasangiz. Variantni ko'rib chiqishdan xursand bo'lamiz. Qisqa javob - yo'q, bizda hozirda bunday funksiya yo'q. Maslahat uchun rahmat, biz buni ko'rib chiqamiz. Agar siz ham foydalanish holatini va nima uchun amalda zarurligini tushuntirsangiz, masalan, GitHub-da muammolarni yaratsangiz, bu juda yaxshi bo'ladi.
Endi bor.
Yaxshi. Biz har qanday takliflarga ochiqmiz. Haproxy esa qilinadigan ishlar ro'yxatiga kiritilgan. Todo ro'yxati o'sib bormoqda, lekin hali qisqarmaydi. Lekin bu yaxshi, demak, mahsulot talabga ega.
Manba: www.habr.com