Hesabat Kubernetes-də operatorun inkişafı, onun arxitekturasının dizaynı və əsas iş prinsiplərinin praktiki məsələlərinə həsr olunub.
Hesabatın birinci hissəsində aşağıdakıları nəzərdən keçirəcəyik:
- Kubernetes-də operator nədir və niyə lazımdır;
- operator mürəkkəb sistemlərin idarə edilməsini necə dəqiqliklə sadələşdirir;
- operator nəyi bacarır və nəyi edə bilmir.
Daha sonra operatorun daxili strukturunun müzakirəsinə keçək. Operatorun arxitekturasını və işini addım-addım nəzərdən keçirin. Gəlin ətraflı təhlil edək:
- operator və Kubernetes arasında qarşılıqlı əlaqə;
- operator hansı funksiyaları yerinə yetirir və Kubernetes-ə hansı nümayəndələr verir.
Kubernetes-də qırıntıları və verilənlər bazası replikalarını idarə etməyi nəzərdən keçirin.
Sonra məlumatların saxlanması məsələlərini müzakirə edəcəyik:
- operator baxımından Persistent Storage ilə necə işləmək;
- Yerli Yaddaşdan istifadənin tələləri.
Hesabatın yekun hissəsində tətbiqin praktiki nümunələrini nəzərdən keçirəcəyik Amazon və ya Google Bulud Xidməti ilə. Hesabat operatorun ClickHouse üçün inkişafı və əməliyyat təcrübəsi nümunəsinə əsaslanır.
Video:
Mənim adım Vladislav Klimenkodur. Bu gün mən operatorun yaradılması və istismarı üzrə təcrübəmizdən danışmaq istədim və bu, verilənlər bazası klasterlərini idarə etmək üçün ixtisaslaşmış operatordur. Misal üçün ClickHouse klasterini idarə etmək üçün.
Nə üçün operator və ClickHouse haqqında danışmaq imkanımız var?
- Biz ClickHouse-u dəstəkləyirik və inkişaf etdiririk.
- Hazırda biz yavaş-yavaş ClickHouse-un inkişafına öz töhfəmizi verməyə çalışırıq. Biz isə ClickHouse-da edilən dəyişikliklərin miqdarına görə Yandex-dən sonra ikinciyik.
- Biz ClickHouse ekosistemi üçün əlavə layihələr hazırlamağa çalışırıq.
Mən bu layihələrdən biri haqqında danışmaq istərdim. Bu Kubernetes üçün ClickHouse-operatoru haqqındadır.
Hesabatımda iki mövzuya toxunmaq istərdim:
- Birinci mövzu ClickHouse verilənlər bazası operatorumuzun Kubernetes-də necə işlədiyidir.
- İkinci mövzu hər hansı bir operatorun necə işlədiyi, yəni Kubernetes ilə necə qarşılıqlı əlaqədə olmasıdır.
Ancaq bu iki sual mənim hesabatım boyunca kəsişəcək.
Deməyə çalışdığımı eşitmək kimdə maraqlı olardı?
- Ən maraqlısı operatorları istismar edənlər olacaq.
- Və ya içəridə necə işlədiyini, operatorun Kubernetes ilə necə qarşılıqlı əlaqədə olduğunu və hansı tələlərin görünə biləcəyini başa düşmək üçün özlərini yaratmaq istəyənlər üçün.
Bu gün nəyi müzakirə edəcəyimizi daha yaxşı başa düşmək üçün Kubernetes-in necə işlədiyini bilmək və bulud hesablamalarında əsas biliklərə sahib olmaq yaxşı olardı.
ClickHouse nədir? Bu, analitik sorğuların onlayn işlənməsi xüsusiyyətlərinə malik sütun verilənlər bazasıdır. Və tamamilə açıq mənbədir.
Və yalnız iki şeyi bilməliyik. Bunun bir verilənlər bazası olduğunu bilməlisiniz, ona görə də sizə deyəcəklərim demək olar ki, hər bir verilənlər bazası üçün uyğun olacaq. Və ClickHouse DBMS-nin çox yaxşı tərəzi olması, miqyaslanma qabiliyyətini demək olar ki, xətti verir. Buna görə də, klasterin vəziyyəti ClickHouse üçün təbii vəziyyətdir. Bizi ən çox Kubernetes-də ClickHouse klasterinə necə xidmət göstərməyi müzakirə etmək istəyirik.
O, orda niyə lazımdır? Niyə biz özümüz fəaliyyət göstərməyə davam edə bilmirik? Cavablar qismən texniki, qismən də təşkilati xarakter daşıyır.
- Təcrübədə, böyük şirkətlərdə demək olar ki, bütün komponentlər artıq Kubernetes-də olduqda belə bir vəziyyətlə daha tez-tez qarşılaşırıq. Məlumat bazalarını kənarda saxlayın.
- Və getdikcə daha tez-tez sual verilir: "Onu içəriyə qoymaq olar?". Buna görə də, böyük şirkətlər məlumat anbarlarını tez idarə edə bilmək üçün idarəetmənin maksimum birləşməsini yaratmağa çalışırlar.
- Və bu, xüsusən də eyni şeyi yeni bir yerdə təkrarlamaq üçün maksimum fürsətə, yəni maksimum daşınma qabiliyyətinə ehtiyacınız olduqda kömək edir.
Nə qədər asan və ya çətindir? Bu, əlbəttə ki, əl ilə edilə bilər. Ancaq bu o qədər də asan deyil, çünki biz Kubernetes-in özünü idarə etməyin mürəkkəbliyini əlavə edirik, lakin eyni zamanda ClickHouse-un xüsusiyyətləri tətbiq olunur. Və belə bir birləşmə ortaya çıxır.
Və hamısı birlikdə, bu, idarə etmək artıq olduqca çətinləşən kifayət qədər böyük bir texnologiya dəstini verir, çünki Kubernetes gündəlik məsələlərini işə salır, ClickHouse isə problemlərini gündəlik işə gətirir. Xüsusilə bir neçə ClickHouse-umuz varsa və onlarla daim nəsə etməliyik.
Dinamik konfiqurasiyaya malik ClickHouse-da DevOps-da daimi yük yaradan kifayət qədər çox sayda problem var:
- Biz ClickHouse-da nəyisə dəyişdirmək istədikdə, məsələn, replika, parça əlavə edin, onda konfiqurasiyanı idarə etməliyik.
- Sonra məlumat sxemini dəyişdirin, çünki ClickHouse-un xüsusi bir parçalanma üsulu var. Orada məlumat sxemini tərtib etmək, konfiqurasiyaları tərtib etmək lazımdır.
- Monitorinqi qurmaq lazımdır.
- Yeni fraqmentlər, yeni replikalar üçün qeydlər toplusu.
- Sağalmağa diqqət yetirin.
- Və yenidən başladın.
Bunlar elə adi işlərdir ki, əməliyyatda köməklik etmək istərdim.
Kubernetes özü əməliyyatda çox kömək edir, lakin əsas sistem şeylərində.
Kubernetes aşağıdakıları asanlaşdırmaqda və avtomatlaşdırmaqda əladır:
- Qurtarma.
- Yenidən başlamaq.
- Saxlama idarəetməsi.
Bu yaxşıdır, bu düzgün istiqamətdir, lakin o, verilənlər bazası klasterini necə idarə etməkdən tamamilə uzaqdır.
Mən daha çox istəyirəm, bütün verilənlər bazasının Kubernetes-də bizim üçün işləməsini istəyirəm.
Mən basdığınız böyük bir sehrli qırmızı düymə kimi bir şey əldə etmək istərdim və siz həll edilməli olan gündəlik tapşırıqlarla bütün həyat dövrü ərzində yerləşdirilən və saxlanılan bir klasteriniz var. Kubernetes-də ClickHouse klasteri.
Və işi asanlaşdırmağa kömək edəcək bir həll tapmağa çalışdıq. Bu Altinity-dən Kubernetes üçün ClickHouse-operatorudur.
Operator əsas vəzifəsi digər proqramları idarə etmək olan proqramdır, yəni menecerdir.
Və davranış nümunələrini ehtiva edir. Siz bunu mövzu sahəsi haqqında kodlaşdırılmış bilik adlandıra bilərsiniz.
Və onun əsas vəzifəsi DevOps-un həyatını asanlaşdırmaq və mikro idarəetməni azaltmaqdır ki, o (DevOps) artıq yüksək səviyyədə düşünsün, yəni o (DevOps) mikromanaj etməsin, belə ki, bütün proqramları əl ilə konfiqurasiya etməsin. təfərrüatlar.
Və sadəcə operator mikro tapşırıqlarla mübarizə aparan və DevOps-a kömək edən robot köməkçisidir.
Operator niyə lazımdır? O, iki sahədə üstündür:
- ClickHouse mütəxəssisinin kifayət qədər təcrübəsi olmadıqda, lakin artıq ClickHouse-u idarə etmək lazım olduqda, operator əməliyyatı asanlaşdırır və kifayət qədər mürəkkəb konfiqurasiyaya malik ClickHouse klasterini idarə etməyə imkan verir, eyni zamanda hamısının içəridə necə işlədiyi barədə çox təfərrüatlara girmir. . Siz sadəcə ona yüksək səviyyəli tapşırıqlar verirsiniz və bu da işləyir.
- Və özünü ən yaxşı göstərdiyi ikinci vəzifə, çox sayda tipik tapşırıqları avtomatlaşdırmaq lazım olduqda. Mikrotaskları sistem idarəçilərindən silir.
Bu, ya səyahətə yeni başlayanlar, ya da çoxlu avtomatlaşdırmaya ehtiyacı olanlar tərəfindən ən çox tələb olunur.
Operator əsaslı yanaşmanın digər sistemlərdən fərqi nədir? Helm də var. O, həmçinin ClickHouse-u quraşdırmağa kömək edir, siz hətta bütün ClickHouse klasterini quraşdıracaq dəbilqə qrafiklərini çəkə bilərsiniz. Bəs operatorla eyni, məsələn, Helm arasındakı fərq nədir?
Əsas əsas fərq ondan ibarətdir ki, Helm paketin idarə edilməsi ilə bağlıdır və operator bir addım da irəli gedir. Bu, bütün həyat dövrünün dəstəyidir. Bu, yalnız quraşdırma deyil, bunlara miqyaslaşdırma, parçalanma, yəni həyat dövrü ərzində edilməli olan hər şey (lazım olduqda, aradan qaldırılması da) daxil olan gündəlik vəzifələrdir - bunların hamısı operator tərəfindən həll edilir. Bütün proqram təminatının həyat dövrünü avtomatlaşdırmağa və xidmət etməyə çalışır. Bu onun təqdim olunan digər həllərdən əsas fərqidir.
Bu, giriş hissəsi idi, davam edək.
Operatorumuzu necə qururuq? ClickHouse klasterini vahid resurs kimi idarə etmək üçün məsələyə yanaşmağa çalışırıq.
Burada şəklin sol tərəfində giriş məlumatımız var. Bu, klassik olaraq kubectl vasitəsilə Kubernetes-ə ötürülən klaster spesifikasiyasına malik YAML-dir. Orada operatorumuz götürür, sehrini edir. Və nəticədə belə bir sxem alırıq. Bu, Kubernetes-də ClickHouse-un tətbiqidir.
Və sonra yavaş-yavaş operatorun necə işlədiyinə, hansı tipik vəzifələrin həll oluna biləcəyinə baxacağıq. Biz yalnız tipik tapşırıqları nəzərdən keçirəcəyik, çünki vaxtımız məhduddur. Operatorun qərar verə biləcəyi hər şey haqqında danışılmayacaq.
Təcrübədən başlayaq. Layihəmiz tamamilə açıq mənbədir, ona görə də onun GitHub-da necə işlədiyini görə bilərsiniz. Və mülahizələrdən davam edə bilərsiniz, əgər sadəcə başlamaq istəyirsinizsə, o zaman Sürətli Başlanğıc Bələdçisi ilə başlaya bilərsiniz.
Əgər ətraflı başa düşmək istəyirsinizsə, biz sənədləri daha az və ya çox layiqli formada saxlamağa çalışırıq.
Praktik problemlə başlayaq. Hamımızın başlamaq istədiyimiz ilk iş, ilk nümunəni bir şəkildə yerinə yetirməkdir. ClickHouse-u operatorun köməyi ilə necə işlədiyini bilmədən necə işə salmaq olar? Biz manifest yazırıq, çünki k8s ilə bütün ünsiyyət manifestlər vasitəsilə ünsiyyətdir.
Budur, belə bir mürəkkəb manifest. Qırmızı rənglə vurğuladığımız şeyə diqqət yetirməli olduğumuz şeydir. Operatordan demo adlı klaster yaratmağı xahiş edirik.
Hələlik bunlar əsas nümunələrdir. Yaddaş hələ təsvir olunmayıb, lakin biz bir az sonra anbara qayıdacağıq. Hələlik biz klasterin inkişafını dinamikada müşahidə edəcəyik.
Biz bu manifest yaratmışıq. Biz onu operatorumuza veririk. İşlədi, sehr etdi.
Konsola baxırıq. Üç komponent maraq doğurur - bunlar Pod, iki Service-a, StatefulSet.
Operator işlədi və biz onun tam olaraq nə yaratdığını görə bilərik.
O, belə bir şey yaradır. Hər bir replika üçün StatefulSet, Pod, ConfigMap, bütün klaster üçün ConfigMap var. Mütləq klasterə giriş nöqtələri kimi xidmətlər.
Xidmətlər mərkəzi Load Balancer Xidmətidir və bu, hər bir replika, hər bir parça üçün mümkündür.
Budur, bizim baza klasterimiz buna bənzəyir. O, tək düyündəndir.
Gəlin daha da irəli gedək, mürəkkəbləşdirəcəyik. Siz klasteri parçalamalısınız.
Bizim vəzifələrimiz artır, dinamika başlayır. Bir parça əlavə etmək istəyirik. Biz inkişafı izləyirik. Biz spesifikasiyamızı dəyişirik. İki qəlpə istədiyimizi bildiririk.
Bu, sistemin böyüməsi ilə dinamik şəkildə inkişaf etdirdiyimiz eyni fayldır. Saxlama yoxdur, saxlama daha sonra müzakirə olunacaq, bu ayrı bir məsələdir.
YAML operatorunu qidalandırırıq və nə baş verdiyini görürük.
Operator düşündü və aşağıdakı varlıqlar etdi. Artıq iki Pod, üç Xidmət və birdən-birə 2 StatefulSet-imiz var. Niyə 2 StatefulSets?
Diaqramda belə idi - bu, bizim bir podumuz olan ilk vəziyyətimizdir.
Bu belə oldu. İndiyə qədər hər şey sadədir, təkrarlanıb.
Və niyə StatefulSet iki oldu? Burada Podların Kubernetes-də necə idarə olunduğu sualını müzakirə etməli və müzakirə etməliyik.
StatefulSet adlı belə bir obyekt var ki, o, şablondan Podlar dəsti hazırlamağa imkan verir. Burada əsas amil Şablondur. Və bir şablona uyğun olaraq bir StatefulSet-də bir çox Pod işlədə bilərsiniz. Və burada əsas ifadə "bir şablon çox Pod" dir.
Və bütün klasteri bir StatefulSet-ə yığmaq üçün böyük bir sınaq var idi. İşləyəcək, heç bir problemi yoxdur. Ancaq bir xəbərdarlıq var. Əgər biz heterojen klaster yığmaq istəyiriksə, yəni ClickHouse-un bir neçə versiyasından, onda suallarımız başlayır. Bəli, StatefulSet bir yayma yeniləmə edə bilər, lakin orada yeni bir versiya çıxara bilərsiniz, izah edin ki, eyni anda bir çox qovşaq sınamalısınız.
Ancaq tapşırığı ekstrapolyasiya etsək və tamamilə heterojen bir klaster yaratmaq istədiyimizi və yuvarlanan yeniləmədən istifadə edərək köhnə versiyadan yenisinə keçmək istəmədiyimizi, sadəcə olaraq həm müxtəlif versiyalar baxımından heterojen bir çoxluq yaratmaq istədiyimizi söyləsək. ClickHouse və müxtəlif saxlama baxımından. Biz istəyirik, məsələn, ayrı-ayrı disklərdə, yavaş disklərdə bəzi replikalar etmək, ümumiyyətlə, tamamilə heterojen klaster qurmaq. Və StatefulSet bir şablondan standart bir həll hazırladığına görə bunu etmək üçün heç bir yol yoxdur.
Bir az düşündükdən sonra belə qərara gəldik. Hər bir replikamız öz StatefulSet-də var. Bu həllin bəzi çatışmazlıqları var, lakin praktikada hamısı operatoru tamamilə əhatə edir. Və çoxlu faydaları var. Biz tamamilə istədiyimiz kimi, məsələn, tamamilə heterojen bir çoxluq qura bilərik. Buna görə də, bir replika ilə iki parçanın olduğu bir klasterdə 2 StatefulSets və 2 Pod-a sahib olacağıq, çünki heterojen klaster yaratmaq qabiliyyəti üçün yuxarıda göstərilən səbəblərə görə bu yanaşmanı seçmişik.
Qayıdaq praktik tapşırıqlara. Klasterimizdə istifadəçiləri konfiqurasiya etməliyik, yəni. Kubernetes-də ClickHouse-un bəzi konfiqurasiyasını etməlisiniz. Operator bunun üçün bütün imkanları təmin edir.
İstədiyimizi birbaşa YAML-də yaza bilərik. Bütün konfiqurasiya seçimləri birbaşa bu YAML-dən ClickHouse konfiqurasiyalarına uyğunlaşdırılır və sonra bütün klasterdə yerləşdirilir.
Siz də belə yaza bilərsiniz. Bu misal üçün. Parol şifrələnə bilər. Tamamilə bütün ClickHouse konfiqurasiya seçimləri dəstəklənir. Budur sadəcə bir nümunə.
Klaster konfiqurasiyası ConfigMap kimi paylanır. Praktikada ConfigMap yeniləməsi dərhal baş vermir, buna görə də böyük bir klaster varsa, konfiqurasiyanın itələnməsi prosesi bir qədər vaxt aparır. Amma bütün bunlardan istifadə etmək çox rahatdır.
Tapşırığı çətinləşdiririk. Klaster inkişaf edir. Biz məlumatları təkrarlamaq istəyirik. Yəni, artıq iki parçamız var, hər biri bir replika, istifadəçilər konfiqurasiya olunub. Biz böyüyürük və təkrarlamaq istəyirik.
Replikasiya üçün bizə nə lazımdır?
Bizə ZooKeeper lazımdır. ClickHouse-da təkrarlama ZooKeeper istifadə edərək qurulur. ZooKeeper lazımdır ki, müxtəlif ClickHouse replikaları hansı məlumat bloklarının hansı ClickHouse-da olması barədə konsensusa malik olsun.
ZooKeeper hər kəs tərəfindən istifadə edilə bilər. Əgər müəssisədə xarici ZooKeeper varsa, ondan istifadə etmək olar. Əgər belə deyilsə, onda siz bizim depomuzdan quraşdıra bilərsiniz. Hər şeyi asanlaşdıran bir quraşdırıcı var.
Və bütün sistemin qarşılıqlı əlaqə sxemi belə çıxır. Platforma olaraq Kubernetesimiz var. O, ClickHouse bəyanatını yerinə yetirir. ZooKeeper burada təsvir etdim. Və operator həm ClickHouse, həm də ZooKeeper ilə qarşılıqlı əlaqədə olur. Yəni qarşılıqlı təsir əldə edilir.
Bütün bunlar ClickHouse-un məlumatları k8-lərə uğurla təkrarlaması üçün lazımdır.
İndi tapşırığın özünə baxaq, replikasiya üçün manifest necə görünəcək.
Manifestimizə iki bölmə əlavə edirik. Birincisi, Kubernetes daxilində və ya xarici ola bilən ZooKeeper-ı haradan əldə etmək olar. Bu sadəcə təsvirdir. Və biz replikaları sifariş edirik. Bunlar. iki replika istəyirik. Ümumilikdə çıxışda 4 pod olmalıdır. Saxlama haqqında xatırlayırıq, bir az daha geri qayıdacaq. Saxlama ayrı bir mahnıdır.
Bu belə idi.
Bu belə olur. Replikalar əlavə olunur. 4-cü uyğun gəlmədi, inanırıq ki, çox ola bilər. Və ZooKeeper yan tərəfə əlavə olunur. Nümunələr getdikcə mürəkkəbləşir.
Və növbəti tapşırığı əlavə etməyin vaxtı gəldi. Davamlı Saxlama əlavə edəcəyik.
Davamlı Saxlama üçün bizim müxtəlif seçimlərimiz var.
Əgər biz bir bulud provayderində işləyiriksə, məsələn, Amazon, Google-dan istifadə ediriksə, onda bulud yaddaşından istifadə etmək üçün böyük bir cazibə var. Çox rahatdır, yaxşıdır.
Və ikinci variant var. Bu, hər bir qovşaqda yerli disklərimiz olduqda yerli saxlama üçündür. Bu variantı həyata keçirmək daha çətindir, lakin eyni zamanda daha məhsuldardır.
Bulud saxlama ilə bağlı nəyə sahib olduğumuzu görək.
Əla cəhətləri var. Konfiqurasiya etmək çox asandır. Biz sadəcə olaraq bulud provayderindən sifariş edirik ki, zəhmət olmasa bizə filan tutumu, filan sinfi saxlasın. Dərslər provayderlər tərəfindən müstəqil şəkildə rənglənir.
Və bir çatışmazlıq var. Bəziləri üçün bu, tənqid olunmayan çatışmazlıqdır. Əlbəttə ki, bəzi performans örtükləri olacaq. İstifadəsi çox rahatdır, etibarlıdır, lakin performansda bəzi potensial çatışmazlıqlar var.
Və o vaxtdan ClickHouse performansa diqqət yetirir, hətta mümkün olan hər şeyi sıxışdırdığını söyləyə bilərsiniz, buna görə bir çox müştəri maksimum performansı sıxmağa çalışır.
Bundan maksimum yararlanmaq üçün bizə yerli yaddaş lazımdır.
Kubernetes Kubernetes-də yerli yaddaşdan istifadə üçün üç abstraksiya təqdim edir. Bu:
- EmptyDir
- HostPath.
- Yerli
Nə qədər fərqli olduqlarını, necə oxşar olduqlarını düşünün.
Birincisi, hər üç yanaşmada yaddaşımız var - bunlar eyni fiziki k8s qovşağında yerləşən yerli disklərdir. Ancaq onların bəzi fərqləri var.
Ən sadədən başlayaq, yəni emptyDir. Praktikada nədir? Məhz biz konteynerləşdirmə sistemindən (ən çox Docker) spesifikasiyamızdan bizə yerli diskdəki qovluğa girişi təmin etməyi xahiş edirik.
Praktikada docker öz yollarında haradasa müvəqqəti qovluq yaradır, onu uzun hash adlandırır. Və ona daxil olmaq üçün interfeys təqdim edir.
Performans baxımından necə çıxış edəcək? Bu, yerli diskin sürətində işləyəcək, yəni. bu, vidanıza tam girişdir.
Ancaq bu işin mənfi cəhətləri var. Bu vəziyyətdə israrlı olmaq olduqca şübhəlidir. Dokerin konteynerlərlə ilk hərəkətində Persistent itirilir. Kubernetes bu Pod-u nədənsə başqa diskə köçürmək istəsə, məlumat itəcək.
Bu yanaşma testlər üçün yaxşıdır, çünki o, artıq normal sürəti göstərir, lakin bu seçim ciddi bir şey üçün uyğun deyil.
Buna görə də ikinci bir yanaşma var. Bu hostPath. Əvvəlki slayd ilə bu slayda baxsanız, yalnız bir fərq görə bilərsiniz. Qovluqumuz dokeri birbaşa Kubernetes qovşağına buraxdı. Burada bir az daha sürətlidir. Biz məlumatlarımızı saxlamaq istədiyimiz yolu birbaşa yerli fayl sisteminə yazırıq.
Bu metodun üstünlükləri var. Bu, artıq əsl Persistent və klassikdir. Diskimizdə məlumatlar hansısa ünvana yazılacaq.
Mənfi cəhətləri də var. Bu idarəetmənin mürəkkəbliyidir. Kubernetlərimiz Pod-u başqa fiziki qovşağa köçürmək istəyə bilər. Bu, DevOps-un işə girdiyi yerdir. O, bütün sistemə düzgün izah etməlidir ki, siz bu podları yalnız bu yollar boyunca nəyinsə quraşdırıldığı qovşaqlara köçürə bilərsiniz və eyni vaxtda birdən çox qovşaq olmamalıdır. Kifayət qədər çətindir.
Xüsusilə bu məqsədlər üçün operatorumuzda bütün bu mürəkkəbliyi gizlətmək üçün şablonlar hazırlamışıq. Və sadəcə deyə bilərsiniz: "Mən hər fiziki qovşaqda və filan yol boyunca bir ClickHouse nümunəsinə sahib olmaq istəyirəm."
Ancaq bu ehtiyac təkcə bizim üçün deyil, ona görə də Kubernetesdən olan cənablar da insanların fiziki disklərə çıxış əldə etmək istədiklərini başa düşürlər, buna görə də üçüncü səviyyəni təmin edirlər.
Yerli adlanır. Əvvəlki slayddan praktiki olaraq heç bir fərq yoxdur. Yalnız əvvəllər əllərimizlə həyata keçirmək lazım idi ki, biz bu podları düyündən düyünə köçürə bilmərik, çünki onlar yerli fiziki diskə filan yol boyunca bağlanmalıdır və indi bütün bu biliklər Kubernetesin özündə cəmlənmişdir. Və konfiqurasiya etmək daha asan olur.
Qayıdaq praktiki vəzifəmizə. YAML şablonuna qayıdaq. Burada əsl anbarımız var. Biz buna qayıdırıq. K8s-də olduğu kimi klassik VolumeClaim şablonunu təyin etdik. Və nə cür saxlama istədiyimizi təsvir edirik.
Bundan sonra k8s yaddaş tələb edəcək. StatefulSet-də bizə ayırın. Və sonda ClickHouse-un ixtiyarında olacaq.
Bizim belə bir sxemimiz var idi. Davamlı Yaddaşımız qırmızı idi, bu, bunun edilməsi lazım olduğunu göstərirdi.
Və yaşıl olur. İndi ClickHouse on k8s klaster sxemi tam şəkildə tamamlandı. Bizdə qəlpələr, replikalar, ZooKeeper var, bu və ya digər şəkildə həyata keçirilən real Persistent var. Sxem artıq tam fəaliyyətdədir.
Biz yaşamağa davam edirik. Klasterimiz böyüyür. Və Aleksey ClickHouse-un yeni versiyasını sınayır və buraxır.
Praktiki tapşırıq yaranır - ClickHouse-un yeni versiyasını klasterimizdə sınaqdan keçirmək. Əlbətdə ki, hamısını yaymaq istəmirəm, bir replikada uzaq küncdə bir yerə yeni bir versiya qoymaq istəyirəm və ya bəlkə bir yeni versiya deyil, bir anda iki, çünki onlar tez-tez çıxırlar.
Bu barədə nə deyə bilərik?
Burada bizim belə bir fürsətimiz var. Bunlar pod şablonlarıdır. Siz rəngləyə bilərsiniz, operatorumuz tamamilə heterojen bir klaster qurmağa imkan verir. Bunlar. konfiqurasiya edin, dəstədəki bütün replikalardan başlayaraq, hər bir şəxsi replika ilə bitən, ClickHouse-un hansı versiyasını, hansı versiyanın saxlanmasını istəyirik. Biz lazım olan konfiqurasiyada klasteri tam şəkildə konfiqurasiya edə bilərik.
Gəlin içəri bir az daha dərinə gedək. Bundan əvvəl biz ClickHouse-operatorunun ClickHouse-un xüsusiyyətləri ilə bağlı necə işlədiyi barədə danışmışdıq.
İndi hər hansı bir operatorun ümumiyyətlə necə işlədiyi, eləcə də K8-lərlə necə qarşılıqlı əlaqəsi haqqında bir neçə söz demək istərdim.
Başlamaq üçün K8-lərlə qarşılıqlı əlaqəni nəzərdən keçirin. kubectl tətbiq etdikdə nə baş verir? API vasitəsilə obyektlərimiz etcd-də görünür.
Məsələn, əsas Kubernetes obyektləri: siyahı vasitəsilə pod, StatefulSet, xidmət və s.
Bununla belə, hələ fiziki heç nə baş vermir. Bu obyektlər klasterdə maddiləşdirilməlidir.
Nəzarətçinin daxil olduğu yer budur. Nəzarətçi bu təsvirləri reallaşdıra bilən xüsusi k8s komponentidir. Fiziki olaraq necə və nə edəcəyini bilir. O, konteynerləri necə işlətməyi, serverin işləməsi üçün orada nəyi konfiqurasiya etmək lazım olduğunu bilir.
Və o, bizim obyektlərimizi K8-lərdə maddiləşdirir.
Amma biz təkcə podlarla, StatefulSets ilə deyil, bütövlükdə onunla işləmək üçün ClickHouseInstallation, yəni ClickHouse tipli obyekt yaratmaq istəyirik. Hələlik belə bir ehtimal yoxdur.
Ancaq K8-in başqa bir gözəl cəhəti var. İstəyirik ki, haradasa bizim klasterimiz podlardan və StatefulSet-dən yığılacaq belə mürəkkəb bir quruma sahib olaq.
Və bunun üçün nə edilməlidir? Əvvəlcə Xüsusi Resurs Tərifi səhnəyə daxil olur. Bu nədir? Bu, K8-lər üçün təsvirdir ki, sizdə əlavə etmək istədiyimiz başqa bir məlumat növü olacaq, içəridə mürəkkəb olacaq xüsusi resurs StatefulSet. Bu məlumat strukturunun təsviridir.
Biz də kubectl application vasitəsilə ora göndəririk. Kubernetes bunu məmnuniyyətlə qəbul etdi.
İndi anbarımızda etcd-dəki obyekt ClickHouseInstallation adlı xüsusi resurs yazmaq imkanına malikdir.
Amma hələlik başqa heç nə olmayacaq. Yəni indi parçanın, replikaların təsviri ilə nəzərdən keçirdiyimiz YAML faylı yaratsaq və “kubectl tətbiq olunur” desək, Kubernetes onu qəbul edib etcd-ə qoyub deyəcək: “Əla, amma bilmirəm bununla nə etməli. ClickHouseInstallation-a necə qulluq edəcəyimi bilmirəm."
Müvafiq olaraq, Kubernetes-in yeni məlumat növünə xidmət göstərməsinə kömək edəcək birinə ehtiyacımız var. Solda səhm məlumat növləri ilə işləyən səhmdar Kubernetes nəzarətçimiz var. Sağda isə xüsusi məlumat növləri ilə işləyə bilən xüsusi nəzarətçimiz olmalıdır.
Və başqa bir şəkildə operator adlanır. Mən onu xüsusi olaraq buradan Kubernetes üçün çıxardım, çünki o, K8-lərdən kənarda da icra oluna bilər. Çox vaxt, əlbəttə ki, bütün ifadələr Kubernetes-də yerinə yetirilir, lakin heç bir şey onun kənarda dayanmasına mane olmur, buna görə də burada xüsusi olaraq çıxarılır.
Artıq, öz növbəsində, operator kimi tanınan xüsusi nəzarətçi API vasitəsilə Kubernetes ilə qarşılıqlı əlaqə qurur. O, artıq API ilə necə qarşılıqlı əlaqə quracağını bilir. Və o, artıq bizim xüsusi resursdan hazırlamaq istədiyimiz mürəkkəb sxemi necə reallaşdıracağını bilir. Operatorun etdiyi tam olaraq budur.
Operator necə işləyir? Onun bunu necə etdiyini görmək üçün sağ tərəfə nəzər salaq. Operatorun bütün bunları necə reallaşdırdığını və K8-lərlə sonrakı qarşılıqlı əlaqənin necə baş verdiyini öyrənəcəyik.
Operator proqramdır. O, hadisə yönümlüdür. Operator Kubernetes API istifadə edərək hadisələrə abunə olur. Kubernetes API-də tədbirlərə abunə ola biləcəyiniz giriş nöqtələri var. K8-lərdə bir şey dəyişirsə, Kubernetes hadisələri hamıya göndərir, yəni. bu API nöqtəsinə abunə olan bildirişlər alacaq.
Operator hadisələrə abunə olur və bir növ reaksiya verməlidir. Onun vəzifəsi ortaya çıxan hadisələrə cavab verməkdir.
Hadisələr bəzi yeniləmələr tərəfindən yaradılır. YAML faylımız ClickHouseInstallation təsviri ilə gəlir. kubectl application vasitəsilə etcd-ə getdi. Orada bir hadisə işlədi, nəticədə bu hadisə ClickHouse-operatoruna gəldi. Operator bu təsviri aldı. Və o, bir şey etməlidir. ClickHouseInstallation obyektinə yeniləmə gəlibsə, o zaman klasteri yeniləməlisiniz. Operatorun vəzifəsi isə klasteri yeniləməkdir.
O nə edir? Əvvəlcə bu yeniləmə ilə nə edəcəyimizə dair fəaliyyət planı tərtib etməliyik. Yeniləmələr çox kiçik ola bilər, yəni. YAML icrasında kiçik, lakin klasterdə çox böyük dəyişikliklərə səbəb ola bilər. Ona görə də operator plan yaradır, sonra ona əməl edir.
O, bu plana uyğun olaraq, podları, xidmətləri, yəni. əsas vəzifəsi olanı yerinə yetirmək. Bu, Kubernetes-də ClickHouse klasterini qurmaq kimidir.
İndi belə bir maraqlı məsələyə toxunaq. Bu, Kubernetes və operator arasında məsuliyyət bölgüsüdür, yəni. Kubernetes nə edir, operator nə edir və bir-biri ilə necə qarşılıqlı əlaqədə olur.
Kubernetes sistem şeylərinə cavabdehdir, yəni. sistem əhatə dairəsi kimi şərh edilə bilən obyektlərin əsas dəsti üçün. Kubernetes podları necə işə salmağı, konteynerləri necə yenidən işə salmağı, həcmləri quraşdırmağı, ConfigMap ilə necə işləməyi bilir, i.e. sistem adlandırıla bilən hər şey.
Operatorlar mövzu sahələrində fəaliyyət göstərirlər. Hər bir operator öz mövzu sahəsi üçün hazırlanmışdır. ClickHouse üçün hazırladıq.
Operator isə replikanın əlavə edilməsi, sxemin qurulması, monitorinqin qurulması kimi mövzu sahəsi baxımından dəqiq qarşılıqlı fəaliyyət göstərir. Belə bir ayrılıq var.
Əlavə replika hərəkəti etdikdə narahatlıqların bu ayrılmasının necə baş verdiyinə dair praktiki nümunəyə baxaq.
Tapşırıq operatora gəlir - replika əlavə etmək. Operator nə edir? Operator hesablayacaq ki, yeni StatefulSet yaratmaq lazımdır, orada belə və belə şablonları, həcm iddiasını təsvir etmək lazımdır.
O, hamısını hazırlayıb K8-lərə ötürür. Deyir ki, ona ConfigMap, StatefulSet, Volume lazımdır. Kubernetes işləyir. O, işlədiyi əsas bölmələri maddiləşdirir.
Və sonra ClickHouse-operator yenidən işə düşür. Artıq onun üzərində nəsə edə biləcəyiniz fiziki bir pod var. Və ClickHouse-operator yenidən mövzu sahəsi baxımından işləyir. Bunlar. Xüsusilə, ClickHouse, replikanı klasterə daxil etmək üçün, ilk növbədə, bu klasterdə mövcud olan məlumat sxemini konfiqurasiya etməlisiniz. İkincisi, bu qeyd monitorinqə daxil edilməlidir ki, onu aydın izləmək mümkün olsun. Operator artıq onu qurur.
Və yalnız bundan sonra ClickHouse özü işə düşür, yəni. başqa bir yüksək səviyyəli qurum. O, artıq verilənlər bazasıdır. Onun öz nümunəsi var, klasterə qoşulmağa hazır olan növbəti konfiqurasiya edilmiş replika.
Bir replika əlavə edərkən icra zənciri və məsuliyyətin ayrılması kifayət qədər uzun olduğu ortaya çıxdı.
Biz əməli işlərimizi davam etdiririk. Əgər klaster artıq mövcuddursa, onda siz konfiqurasiyanı köçürə bilərsiniz.
Biz bunu elə etdik ki, ClickHouse-un anladığı mövcud xml-ə keçmək mümkün olsun.
ClickHouse-u dəqiq tənzimləyə bilərsiniz. Sadəcə zonalaşdırılmış yerləşdirmə hostPath, yerli yaddaşı izah edərkən danışdığım şeydir. Zonalı yerləşdirməni necə düzgün etmək olar.
Növbəti praktiki vəzifə monitorinqdir.
Əgər klasterimiz dəyişirsə, onda biz vaxtaşırı monitorinqi konfiqurasiya etməliyik.
Gəlin diaqrama nəzər salaq. Artıq burada yaşıl oxları nəzərdən keçirdik. İndi qırmızı oxlara baxaq. Biz klasterimizi belə izləmək istəyirik. ClickHouse klasterindən ölçülər Prometeyə, sonra isə Grafanaya necə daxil olur.
Monitorinqdə problem nədir? Niyə bu bir növ nailiyyət kimi təqdim olunur? Çətinlik dinamikadadır. Bir klasterimiz olduqda və o, statik olduqda, siz monitorinqi bir dəfə qura bilərsiniz və artıq narahat olmayasınız.
Amma bizdə çoxlu klaster varsa və ya nəsə daim dəyişirsə, deməli proses dinamikdir. Və monitorinqi daim yenidən konfiqurasiya etmək resurs və vaxt itkisidir; hətta sadəcə tənbəl. Bunun avtomatlaşdırılması lazımdır. Çətinlik prosesin dinamikasındadır. Və operator bunu çox yaxşı avtomatlaşdırır.
Klasterimiz necə inkişaf etdi? Əvvəlcə o, belə idi.
Sonra o, belə idi.
Axırda o belə oldu.
Və monitorinq avtomatik olaraq operator tərəfindən həyata keçirilir. Tək giriş nöqtəsi.
Və biz sadəcə Grafana tablosundakı çıxışa baxırıq, klasterimizin həyatının içərisində necə qaynayır.
Yeri gəlmişkən, Grafana idarə paneli də operatorumuzla mənbə kodunda paylanır. Qoşub istifadə edə bilərsiniz. Bu ekran görüntüsü mənə DevOps tərəfindən verildi.
Bundan sonra hara getmək istərdik? Bu:
- Test avtomatlaşdırmasını inkişaf etdirin. Əsas vəzifə yeni versiyaların avtomatlaşdırılmış sınaqdan keçirilməsidir.
- Biz həqiqətən də ZooKeeper ilə inteqrasiyanı avtomatlaşdırmaq istəyirik. Və ZooKeeper-operator ilə inteqrasiya etməyi planlaşdırır. Bunlar. ZooKeeper üçün operator yazılmışdır və məntiqlidir ki, iki operator daha rahat həll yolu yaratmaq üçün inteqrasiya etməyə başlayır.
- Biz daha mürəkkəb həyat yoxlamaları etmək istəyirik.
- Yaşıl rənglə vurğuladım ki, yolda Şablonlar mirasımız var - EDİLDİ, yəni operatorun növbəti buraxılışı ilə artıq şablon mirasımız olacaq. Bu, parçalardan mürəkkəb konfiqurasiyalar yaratmağa imkan verən güclü bir vasitədir.
- Və biz mürəkkəb tapşırıqları avtomatlaşdırmaq istəyirik. Əsas odur ki, yenidən paylaşma.
Gəlin bəzi ara nəticələr verək.
Nəticədə nə əldə edirik? Və buna dəyərmi, yoxsa yox? Verilənlər bazasını Kubernetes-ə sürükləməyə və ümumiyyətlə operatoru, xüsusən də Alitnity operatorunu tətbiq etməyə çalışmalıyam.
Çıxışda alırıq:
- Konfiqurasiyanı, yerləşdirməni və texniki xidməti əhəmiyyətli dərəcədə sadələşdirin və avtomatlaşdırın.
- Dərhal quraşdırılmış monitorinq.
- Və mürəkkəb vəziyyətlər üçün istifadəyə hazır kodlaşdırılmış şablonlar. Artıq bir replika əlavə etmək üçün növün hərəkətini əl ilə etmək lazım deyil. Bu operator tərəfindən edilir.
Yalnız son sual qalır. Artıq Kubernetesdə verilənlər bazamız var, virtualizasiya. Xüsusilə ClickHouse performans üçün optimallaşdırıldığı üçün belə bir həllin performansı haqqında nə demək olar?
Cavab budur ki, hər şey yaxşıdır! Mən ətraflı təsvir etməyəcəyəm, bu ayrıca bir hesabatın mövzusudur.
Amma TSBS kimi bir layihə var. Onun əsas vəzifəsi nədir? Bu verilənlər bazası performans testidir. Bu isti ilə isti, yumşaq ilə yumşaq müqayisə etmək cəhdidir.
O necə işləyir? Bir verilənlər toplusu yaradılır. Sonra eyni test dəstindəki bu verilənlər dəsti müxtəlif verilənlər bazalarında işlədilir. Və hər bir verilənlər bazası bir problemi bacardığı şəkildə həll edir. Və sonra nəticələri müqayisə edə bilərsiniz.
O, artıq çoxlu verilənlər bazasını dəstəkləyir. Mən üç əsası müəyyən etdim. Bu:
- vaxt miqyasıb.
- InfluxDB.
- klik evi.
Başqa bir oxşar həll ilə də müqayisə aparıldı. RedShift ilə müqayisə. Müqayisə Amazonda aparılıb. ClickHouse da bu məsələdə hamını qabaqlayır.
Dediklərimdən hansı nəticələr çıxarmaq olar?
- Kubernetes-də DB mümkündür. Yəqin ki, sən hər şeyi edə bilərsən, amma ümumiyyətlə, bacarırsan kimi görünür. Kubernetes-də ClickHouse operatorumuzun köməyi ilə mütləq mümkündür.
- Operator prosesləri avtomatlaşdırmağa kömək edir və həyatı həqiqətən asanlaşdırır.
- Performans normaldır.
- Və bizə elə gəlir ki, ondan istifadə etmək olar və lazımdır.
Açıq mənbə - bizə qoşulun!
Dediyim kimi, operator tamamilə açıq mənbə məhsuludur, ona görə də maksimum sayda insan istifadə etsə, çox yaxşı olardı. İndi qoşul! Hamınızı gözləyirik!
Hamınıza təşəkkür edirəm!
Suallar
Hesabat üçün təşəkkür edirik! Mənim adım Antondur. Mən SEMrush-danam. Mən fikirləşirəm ki, ağacların kəsilməsinin nə işi var? Monitorinq haqqında eşidirik, lakin bütün klaster haqqında danışsaq, giriş haqqında heç bir şey yoxdur. Məsələn, bizdə hardware üzərində çoxluq var. Biz isə mərkəzləşdirilmiş girişdən istifadə edirik, onu standart vasitələrlə ümumi yığında yığırıq. Və oradan bizim üçün maraqlı olan məlumatları əldə edirik.
Yaxşı sual, yəni görüləcək işlər siyahısına daxil olmaq. Operatorumuz bunu hələ avtomatlaşdırmayıb. Hələ inkişaf edir, layihə hələ çox gəncdir. Biz girişə ehtiyac olduğunu başa düşürük. Bu da çox mühüm mövzudur. Və yəqin ki, monitorinqdən az əhəmiyyət kəsb etmir. Lakin həyata keçirilməsi üçün siyahıda ilk növbədə monitorinq idi. Giriş olacaq. Təbii ki, biz klasterin həyatının bütün aspektlərini avtomatlaşdırmağa çalışırıq. Ona görə də cavab budur ki, hazırda operator, təəssüf ki, bunu necə edəcəyini bilmir, amma bu, planlarda var, biz bunu edəcəyik. Qoşulmaq istəyirsinizsə, müraciət edin, zəhmət olmasa.
Salam! Hesabat üçün təşəkkür edirik! Persistent Volumes ilə bağlı standart sualım var. Bu operatorla konfiqurasiya yaratdığımız zaman operator hansı qovşaqda hansısa disk və ya qovluqumuzun olduğunu necə müəyyən edir? Əvvəlcə ona izah etməliyik ki, zəhmət olmasa, ClickHouse-u diski olan bu qovşaqlara yerləşdirin?
Anladığım qədəri ilə bu sual yerli yaddaşın, xüsusən də onun hostPath hissəsinin davamıdır. Bu, bütün sistemə izah etmək kimi bir şeydir ki, podun məhz filan qovşaqda işə salınması lazımdır, onun üzərində fiziki bağlı diskimiz var, o, filan yola quraşdırılmışdır. Bu, çox səthi toxunduğum bütöv bir bölmədir, çünki orada cavab kifayət qədər böyükdür.
Qısacası belə görünür. Təbii ki, biz bu həcmlərin təminatını həyata keçirməliyik. Hazırda yerli yaddaşda heç bir dinamik təminat yoxdur, ona görə də DevOps diskləri özləri kəsməlidir, işdə bu həcmlər. Və onlar Kubernetes təminatını izah etməlidirlər ki, siz filan qovşaqlarda yerləşən filan sinifin Davamlı həcmlərinə sahib olacaqsınız. Sonra Kubernetes-ə izah etmək lazımdır ki, bu və ya digər yerli saxlama sinifini tələb edən podları yalnız bu və ya digər qovşaqlara etiketlərə uyğun olaraq planlaşdırmaq lazımdır. Bu məqsədlər üçün operator bir növ etiket və hər bir host instansiyası təyin etmək imkanına malikdir. Və belə çıxır ki, podlar Kubernetes tərəfindən yalnız tələblərə, etiketlərə cavab verən qovşaqlarda işləmək üçün yönləndiriləcək. Administratorlar etiketlər təyin edir, diskləri əl ilə təmin edirlər. Və sonra tərəzi.
Və yalnız üçüncü yerli seçim onu bir az asanlaşdırmağa kömək edir. Artıq qeyd etdiyim kimi, bu, maksimum performans əldə etməyə kömək edən zəhmətli bir tuning işidir.
Bununla bağlı ikinci sualım var. Kubernetes elə qurulmuşdu ki, bizim üçün bir düyünü itirib itirməməyimizin fərqi yoxdur. Bir qırıq olan düyünü itirmişiksə, bu halda nə etməliyik?
Bəli, Kubernetes əvvəlcə qabıqlarımızla münasibətimizin mal-qara kimi olduğunu söylədi, lakin burada hər bir disk ev heyvanı kimi bir şeyə çevrilir. Elə bir problem var ki, biz onları atıb ata bilmərik. Kubernetesin inkişafı isə o istiqamətdə gedir ki, ona tamamilə fəlsəfi, tamamilə atılmış resurs kimi yanaşmaq mümkün deyil.
İndi praktik sual. Diskin olduğu qovşağı itirsəniz nə etməli? Burada problem daha yüksək səviyyədə həll olunur. ClickHouse vəziyyətində, daha yüksək səviyyədə işləyən replikalarımız var, yəni. ClickHouse səviyyəsində.
Təhlil nədir? DevOps məlumatların itirilməməsini təmin etmək üçün məsuliyyət daşıyır. O, replikasiyanı düzgün qurmalı və replikasiyanın işləməsini təmin etməlidir. ClickHouse səviyyəsindəki replikada məlumatlar təkrarlanmalıdır. Bu operatorun həll etdiyi vəzifə deyil. Və Kubernetesin özünün həll etdiyi vəzifə deyil. Bu, ClickHouse səviyyəsindədir.
Dəmir nodunuz düşsə nə etməli? Və belə çıxır ki, ikincisini qoymaq, diski düzgün şəkildə daşımaq, etiketlər tətbiq etmək lazımdır. Bundan sonra, o, Kubernetes-in pod nümunəsini işlədə bilməsi tələblərinə cavab verəcəkdir. Kubernetes onu işə salacaq. Qovşaqlarınızın sayı göstərilənə kifayət deyil. O, mənim göstərdiyim dövrədən keçəcək. Ən yüksək səviyyədə ClickHouse anlayacaq ki, bizdə bir replika daxil edilib, o, hələ də boşdur və biz ona məlumat ötürməyə başlamalıyıq. Bunlar. bu proses hələ də zəif avtomatlaşdırılıb.
Hesabat üçün təşəkkür edirik! Hər cür xoşagəlməz şeylər baş verəndə, operator qəzaya uğrayıb yenidən işə düşdükdə və o anda hadisələr baş verir, siz bunu bir şəkildə emal edirsiniz?
Operator qəzaya uğrasa və yenidən başlasa nə olar, bəli?
Bəli. Və o anda hadisələr gəldi.
Bu halda nə etmək tapşırığı operator və Kubernetes arasında qismən bölünür. Kubernetes baş vermiş hadisəni təkrar etmək qabiliyyətinə malikdir. O, təkrar edir. Operatorun vəzifəsi hadisə jurnalının təkrar oxunduğu zaman bu hadisələrin idempotent olduğuna əmin olmaqdır. Və eyni hadisənin təkrar baş verməsi sistemimizi bizim üçün pozmasın. Və operatorumuz bu işin öhdəsindən gəlir.
Salam! Hesabat üçün təşəkkür edirik! Dmitri Zavialov, şirkət Smedov. Operatora haproxy ilə fərdiləşdirmə seçimləri əlavə etmək planlaşdırılırmı? Bəzi başqa balanslaşdırıcı standartdan başqa maraqlıdır ki, o, ağıllıdır və ClickHouse-un orada real olduğunu başa düşür.
Ingressdən danışırsan?
Bəli, Ingress-i haproksi ilə əvəz edin. Haproxy-də replikaların olduğu klaster topologiyasını təyin edə bilərsiniz.
İndiyə qədər bu barədə düşünməmişik. Əgər ehtiyacınız varsa və bunun nə üçün lazım olduğunu izah edə bilsəniz, o zaman onu həyata keçirmək mümkün olacaq, xüsusən də iştirak etmək istəyirsinizsə. Seçimi nəzərdən keçirməkdən məmnun olarıq. Qısa cavab yox, bizdə hazırda belə bir funksiya yoxdur. Məsləhət üçün təşəkkür edirik, buna nəzər salacağıq. Əgər siz də istifadə halını və bunun praktikada nə üçün lazım olduğunu izah etsəniz, məsələn, GitHub-da problemlər yaratsanız, əla olar.
Artıq var.
Yaxşı. İstənilən təklifə açığıq. Haproxy görüləcək işlər siyahısına salınır. Todo siyahısı böyüyür, hələ kiçilmir. Amma bu yaxşıdır, məhsula tələbat var deməkdir.
Mənbə: www.habr.com