Raport poświęcony jest praktycznym zagadnieniom budowy operatora w Kubernetesie, projektowaniu jego architektury oraz podstawowych zasad działania.
W pierwszej części raportu rozważymy:
- czym jest operator w Kubernetesie i do czego jest potrzebny;
- jak dokładnie operator upraszcza zarządzanie złożonymi systemami;
- co operator może, a czego nie może zrobić.
Następnie przejdźmy do omówienia wewnętrznej struktury operatora. Przyjrzyjmy się krok po kroku architekturze i działaniu operatora. Przyjrzyjmy się temu szczegółowo:
- interakcja pomiędzy operatorem a Kubernetesem;
- jakie funkcje przejmuje operator i jakie funkcje deleguje Kubernetesowi.
Przyjrzyjmy się zarządzaniu fragmentami i replikami baz danych w Kubernetesie.
Następnie omówimy kwestie przechowywania danych:
- jak pracować z Persistent Storage z punktu widzenia operatora;
- pułapki związane z korzystaniem z magazynu lokalnego.
W końcowej części raportu rozważymy praktyczne przykłady zastosowań z usługą Amazon lub Google Cloud Service. Raport powstał na przykładzie rozwoju i doświadczeń operacyjnych operatora ClickHouse.
Video:
Nazywam się Władysław Klimenko. Dziś chciałem opowiedzieć o naszych doświadczeniach w opracowaniu i obsłudze operatora, a jest to wyspecjalizowany operator do zarządzania klastrami baz danych. Na przykład do zarządzania klastrem ClickHouse.
Dlaczego mamy okazję porozmawiać o operatorze i ClickHouse?
- Wspieramy i rozwijamy ClickHouse.
- W tej chwili staramy się powoli dokładać swój wkład w rozwój ClickHouse. Jesteśmy drudzy po Yandexie pod względem ilości zmian wprowadzonych w ClickHouse.
- Staramy się wykonywać dodatkowe projekty dla ekosystemu ClickHouse.
Chciałbym opowiedzieć o jednym z takich projektów. Chodzi o ClickHouse-operatora dla Kubernetes.
W swoim raporcie chciałbym poruszyć dwa tematy:
- Pierwszym tematem jest działanie naszego operatora zarządzania bazami danych ClickHouse w Kubernetesie.
- Drugim tematem jest to, jak działa dowolny operator, czyli jak współdziała z Kubernetesem.
Jednakże te dwa pytania będą się krzyżować w całym moim raporcie.
Kto byłby zainteresowany słuchaniem tego, co próbuję powiedzieć?
- Będzie to najbardziej interesujące dla tych, którzy obsługują operatorów.
- Lub dla tych, którzy chcą stworzyć własny, aby zrozumieć, jak to działa wewnętrznie, jak operator współdziała z Kubernetesem i jakie pułapki mogą się pojawić.
Aby najlepiej zrozumieć, co dzisiaj omówimy, warto wiedzieć, jak działa Kubernetes i odbyć podstawowe szkolenie w zakresie chmury.
Co to jest ClickHouse? Jest to kolumnowa baza danych ze specyficznymi funkcjami do przetwarzania zapytań analitycznych online. I jest to całkowicie open source.
I ważne jest, abyśmy wiedzieli tylko dwie rzeczy. Musisz wiedzieć, że jest to baza danych, więc to, co ci powiem, będzie miało zastosowanie do prawie każdej bazy danych. A fakt, że ClickHouse DBMS bardzo dobrze się skaluje, daje niemal liniową skalowalność. Dlatego stan klastra jest dla ClickHouse stanem naturalnym. Najbardziej interesuje nas omówienie sposobu obsługi klastra ClickHouse w Kubernetes.
Dlaczego jest tam potrzebny? Dlaczego nie możemy dalej obsługiwać tego sami? Odpowiedzi są częściowo techniczne, a częściowo organizacyjne.
- W praktyce coraz częściej spotykamy się z sytuacją, że w dużych firmach prawie wszystkie komponenty znajdują się już w Kubernetesie. Bazy danych pozostają na zewnątrz.
- Coraz częściej pojawia się pytanie: „Czy można to umieścić w środku?” Dlatego duże firmy starają się osiągnąć maksymalną unifikację zarządzania, aby móc szybko zarządzać swoimi hurtowniami danych.
- A to szczególnie pomaga, jeśli potrzebujesz maksymalnej możliwości powtórzenia tego samego w nowym miejscu, czyli maksymalnej przenośności.
Jak łatwe lub trudne jest to? Można to oczywiście zrobić ręcznie. Ale to nie jest takie proste, bo mamy dodatkową złożoność zarządzania samym Kubernetesem, ale jednocześnie narzucają się specyfiki ClickHouse. I taka agregacja skutkuje.
A to wszystko razem daje dość duży zestaw technologii, którym zarządzanie staje się dość trudne, bo Kubernetes wnosi do działania własne, codzienne problemy, a ClickHouse swoje własne problemy w codziennym działaniu. Szczególnie jeśli mamy kilka ClickHouse'ów i ciągle musimy coś z nimi robić.
Przy konfiguracji dynamicznej ClickHouse ma dość dużą liczbę problemów, które powodują stałe obciążenie DevOps:
- Kiedy chcemy coś zmienić w ClickHouse, np. dodać replikę lub shard, wówczas musimy zapanować nad konfiguracją.
- Następnie zmień schemat danych, ponieważ ClickHouse ma specyficzną metodę shardingu. Tam musisz rozłożyć diagram danych, rozłożyć konfiguracje.
- Musisz skonfigurować monitoring.
- Zbieranie logów dla nowych fragmentów, dla nowych replik.
- Zadbaj o regenerację.
- I uruchom ponownie.
Są to rutynowe zadania, które naprawdę chciałbym ułatwić w użyciu.
Sam Kubernetes pomaga dobrze w działaniu, ale w podstawowych sprawach systemowych.
Kubernetes dobrze radzi sobie z ułatwianiem i automatyzacją takich rzeczy jak:
- Powrót do zdrowia.
- Uruchom ponownie.
- Zarządzanie systemem pamięci masowej.
To dobrze, to właściwy kierunek, ale on nie ma zielonego pojęcia, jak obsługiwać klaster baz danych.
Chcemy więcej, chcemy, żeby cała baza danych działała w Kubernetesie.
Chciałbym dostać coś w rodzaju dużego, magicznego czerwonego przycisku, po naciśnięciu którego klaster z codziennymi zadaniami do rozwiązania zostanie wdrożony i utrzymywany przez cały cykl życia. Klaster ClickHouse w Kubernetes.
Staraliśmy się stworzyć rozwiązanie, które ułatwiłoby pracę. To jest operator ClickHouse dla Kubernetes od Altinity.
Operator to program, którego głównym zadaniem jest zarządzanie innymi programami, czyli jest menadżerem.
Zawiera także wzorce zachowań. Można to nazwać skodyfikowaną wiedzą z danej dziedziny.
A jego głównym zadaniem jest ułatwienie życia DevOps i ograniczenie mikrozarządzania, aby on (DevOps) myślał już w kategoriach wysokiego szczebla, czyli aby (DevOps) nie zajmował się mikrozarządzaniem, aby nie konfigurował wszystkie szczegóły ręcznie.
I właśnie operatorem jest robotyczny asystent, który zajmuje się mikrozadaniami i pomaga DevOps.
Dlaczego potrzebujesz operatora? Szczególnie dobrze radzi sobie w dwóch obszarach:
- Gdy specjalista zajmujący się ClickHouse nie ma wystarczającego doświadczenia, ale potrzebuje już obsługiwać ClickHouse, operator ułatwia operację i pozwala na obsługę klastra ClickHouse o dość złożonej konfiguracji, bez wchodzenia w szczegóły jak to wszystko działa wewnątrz. Po prostu dajesz mu zadania na wysokim poziomie i to działa.
- Drugim zadaniem, w którym radzi sobie najlepiej, jest sytuacja, gdy konieczna jest automatyzacja dużej liczby typowych zadań. Usuwa mikrozadania administratorom systemu.
Jest to najbardziej potrzebne zarówno tym, którzy dopiero rozpoczynają swoją podróż, jak i tym, którzy muszą dokonać dużej automatyzacji.
Czym podejście oparte na operatorach różni się od innych systemów? Jest Helm. Pomaga także zainstalować ClickHouse; możesz narysować wykresy steru, które nawet zainstalują cały klaster ClickHouse. Jaka jest zatem różnica między operatorem a tym samym, na przykład Helmem?
Główną zasadniczą różnicą jest to, że Helm to zarządzanie pakietami, a Operator idzie o krok dalej. To wsparcie przez cały cykl życia. To nie jest tylko instalacja, to są codzienne zadania, które obejmują skalowanie, sharding, czyli wszystko, co trzeba zrobić w trakcie cyklu życia (jeśli to konieczne, następnie usunięcie) - o tym wszystkim decyduje operator. Próbuje zautomatyzować i utrzymać cały cykl życia oprogramowania. Na tym właśnie polega jego zasadnicza różnica w stosunku do innych prezentowanych rozwiązań.
To była część wprowadzająca, przejdźmy dalej.
Jak budujemy naszego operatora? Próbujemy podejść do problemu tak, aby zarządzać klastrem ClickHouse jako pojedynczym zasobem.
Tutaj mamy dane wejściowe po lewej stronie obrazu. Jest to YAML ze specyfikacją klastra, który w klasyczny sposób przekazywany jest do Kubernetesa poprzez kubectl. Tam nasz operator podnosi go i wykonuje swoją magię. Na wyjściu otrzymujemy następujący schemat. Jest to implementacja ClickHouse w Kubernetesie.
A potem będziemy powoli przyglądać się, jak dokładnie działa operator, jakie typowe zadania można rozwiązać. Rozważymy tylko typowe zadania, ponieważ mamy ograniczony czas. I nie wszystko, o czym może zdecydować operator, zostanie omówione.
Zacznijmy od praktyki. Nasz projekt jest całkowicie open source, więc możesz zobaczyć, jak działa na GitHubie. Możesz też wyjść z założenia, że jeśli chcesz go po prostu uruchomić, możesz zacząć od Przewodnika szybkiego startu.
Jeśli chcesz zrozumieć szczegółowo, to staramy się prowadzić dokumentację w mniej lub bardziej przyzwoitej formie.
Zacznijmy od problemu praktycznego. Pierwszym zadaniem, od którego wszyscy chcemy zacząć, jest jakoś uruchomienie pierwszego przykładu. Jak mogę uruchomić ClickHouse za pomocą operatora, nawet jeśli nie do końca wiem, jak to działa? Piszemy manifest, bo... Cała komunikacja z k8s odbywa się poprzez manifesty.
To taki złożony manifest. To, co podkreśliliśmy na czerwono, jest tym, na czym musimy się skupić. Prosimy operatora o utworzenie klastra o nazwie demo.
To na razie podstawowe przykłady. Przechowywanie nie zostało jeszcze opisane, ale wrócimy do przechowywania nieco później. Na razie będziemy obserwować dynamikę rozwoju klastra.
Stworzyliśmy ten manifest. Podajemy to naszemu operatorowi. Pracował, tworzył magię.
Patrzymy na konsolę. Interesujące są trzy komponenty: Pod, dwie usługi i StatefulSet.
Operator się napracował i możemy zobaczyć, co dokładnie stworzył.
Tworzy coś takiego. Mamy StatefulSet, Pod, ConfigMap dla każdej repliki, ConfigMap dla całego klastra. Usługi są wymagane jako punkty wejścia do klastra.
Usługi to centralna usługa równoważenia obciążenia i można ich również używać dla każdej repliki, dla każdego fragmentu.
Nasz podstawowy klaster wygląda mniej więcej tak. Pochodzi z jednego węzła.
Pójdźmy dalej i skomplikujmy sprawę. Musimy rozbić klaster.
Nasze zadania rosną, zaczyna się dynamika. Chcemy dodać fragment. Śledzimy rozwój. Zmieniamy naszą specyfikację. Wskazujemy, że chcemy dwa shardy.
Jest to ten sam plik, który dynamicznie rozwija się wraz z rozwojem systemu. Przechowywanie nie, przechowywanie będzie omówione dalej, to osobny temat.
Karmimy operatora YAML i zobaczymy, co się stanie.
Operator pomyślał i stworzył następujące byty. Mamy już dwa Pody, trzy usługi i nagle 2 zestawy StatefulSet. Dlaczego 2 zestawy stanowe?
Na schemacie wyglądało to tak - to nasz stan początkowy, gdy mieliśmy jeden zasobnik.
Stało się tak. Póki co wszystko jest proste, zostało zdublowane.
I dlaczego powstały dwa zestawy stanowe? W tym miejscu musimy zrobić dygresję i omówić kwestię zarządzania Podami w Kubernetesie.
Istnieje obiekt o nazwie StatefulSet, który umożliwia utworzenie zestawu Podów na podstawie szablonu. Kluczowym czynnikiem jest tutaj szablon. Możesz także uruchomić wiele Podów, korzystając z jednego szablonu w jednym zestawie StatefulSet. Kluczowym zwrotem jest tutaj „wiele Podów w jednym szablonie”.
Istniała wielka pokusa, aby utworzyć cały klaster i upakować go w jeden StatefulSet. Będzie działać, nie ma z tym problemu. Ale jest jedno zastrzeżenie. Jeżeli chcemy złożyć heterogeniczny klaster, czyli z kilku wersji ClickHouse, wówczas zaczynają pojawiać się pytania. Tak, StatefulSet może przeprowadzić aktualizację ciągłą i tam możesz wdrożyć nową wersję, wyjaśnij, że nie musisz wypróbowywać więcej niż określonej liczby węzłów jednocześnie.
Ale jeśli ekstrapolujemy zadanie i powiemy, że chcemy stworzyć całkowicie heterogeniczny klaster i nie chcemy zmieniać starej wersji na nową za pomocą aktualizacji kroczącej, ale po prostu chcemy stworzyć heterogeniczny klaster zarówno pod względem różnych wersji ClickHouse i pod względem różnej przestrzeni dyskowej. Chcemy np. zrobić jakieś repliki na osobnych dyskach, w ogóle na wolnych, żeby w całości zbudować heterogeniczny klaster. A ze względu na to, że StatefulSet tworzy ustandaryzowane rozwiązanie z jednego szablonu, nie ma takiej możliwości.
Po chwili namysłu zdecydowano, że zrobimy to w ten sposób. Każdą replikę mamy w swoim własnym zestawie StatefulSet. Rozwiązanie to ma pewne wady, ale w praktyce wszystko jest całkowicie hermetyzowane przez operatora. A zalet jest mnóstwo. Możemy zbudować dokładnie taki klaster, jaki chcemy, na przykład absolutnie heterogeniczny. Dlatego w klastrze, w którym mamy dwa shardy z jedną repliką, będziemy mieli 2 StatefulSets i 2 Pody właśnie dlatego, że wybraliśmy to podejście z powodów podanych powyżej, aby móc zbudować heterogeniczny klaster.
Wróćmy do problemów praktycznych. W naszym klastrze musimy skonfigurować użytkowników, tj. musisz przeprowadzić konfigurację ClickHouse w Kubernetes. Operator zapewnia ku temu wszelkie możliwości.
Możemy pisać, co chcemy bezpośrednio w YAML. Wszystkie opcje konfiguracji są mapowane bezpośrednio z tego YAML do konfiguracji ClickHouse, które są następnie dystrybuowane w całym klastrze.
Można to napisać w ten sposób. To jest na przykład. Hasło można zaszyfrować. Obsługiwane są absolutnie wszystkie opcje konfiguracyjne ClickHouse. Oto tylko przykład.
Konfiguracja klastra jest dystrybuowana jako ConfigMap. W praktyce aktualizacja ConfigMap nie następuje natychmiastowo, więc jeśli klaster jest duży, to proces wypychania konfiguracji zajmuje trochę czasu. Ale wszystko to jest bardzo wygodne w użyciu.
Skomplikujmy zadanie. Klaster się rozwija. Chcemy replikować dane. Oznacza to, że mamy już dwa fragmenty, po jednej repliki każdy, a użytkownicy są skonfigurowani. Rośniemy i chcemy replikować.
Czego potrzebujemy do replikacji?
Potrzebujemy ZooKeepera. W ClickHouse replikacja jest budowana przy użyciu ZooKeepera. ZooKeeper jest potrzebny, aby różne repliki ClickHouse osiągnęły konsensus co do tego, które bloki danych znajdują się w którym ClickHouse.
ZooKeeper może być używany przez każdego. Jeśli przedsiębiorstwo posiada zewnętrznego ZooKeepera, wówczas można z niego skorzystać. Jeśli nie, możesz zainstalować go z naszego repozytorium. Dostępny jest instalator, który ułatwia to wszystko.
A schemat interakcji całego systemu wygląda tak. Mamy Kubernetes jako platformę. Wykonuje operator ClickHouse. Wyobraziłem sobie tutaj ZooKeepera. Operator współpracuje zarówno z ClickHouse, jak i ZooKeeperem. Oznacza to, że wyniki interakcji.
A wszystko to jest potrzebne, aby ClickHouse mógł pomyślnie replikować dane w k8s.
Przyjrzyjmy się teraz samemu zadaniu i temu, jak będzie wyglądał manifest replikacji.
Do naszego manifestu dodajemy dwie sekcje. Po pierwsze, skąd można pobrać ZooKeepera, który może znajdować się w Kubernetesie lub na zewnątrz. To tylko opis. I zamawiamy repliki. Te. chcemy dwie repliki. Łącznie na wyjściu powinniśmy mieć 4 strąki. Pamiętamy o przechowywaniu, wrócimy do tego nieco później. Przechowywanie to osobna historia.
To było tak.
Staje się tak. Dodano repliki. Czwarty nie zmieścił się, uważamy, że mogło ich tam być dużo. Z boku dodano ZooKeeper. Schematy stają się coraz bardziej złożone.
I czas dodać kolejne zadanie. Dodamy pamięć trwałą.
W przypadku pamięci trwałej mamy różne opcje.
Jeśli korzystamy z usług dostawcy chmury, na przykład Amazona, Google'a, istnieje duża pokusa, aby skorzystać z przechowywania w chmurze. Jest to bardzo wygodne, jest dobre.
Jest też druga opcja. Dotyczy to magazynu lokalnego, gdy w każdym węźle mamy dyski lokalne. Ta opcja jest znacznie trudniejsza do wdrożenia, ale jednocześnie bardziej produktywna.
Zobaczmy, co mamy dotyczące przechowywania w chmurze.
Są zalety. Jest bardzo łatwy w konfiguracji. Po prostu zamawiamy u dostawcy usług chmurowych, aby udostępnił nam magazyn o takiej a takiej pojemności, takiej a takiej klasy. Zajęcia są planowane przez dostawców niezależnie.
I jest wada. Dla niektórych jest to niekrytyczna wada. Oczywiście będą pewne problemy z wydajnością. Jest bardzo wygodny w użyciu i niezawodny, ale istnieją pewne potencjalne wady w działaniu.
I ponieważ ClickHouse skupia się szczególnie na produktywności, można nawet powiedzieć, że wyciska wszystko, co może, dlatego wielu klientów stara się wycisnąć maksimum produktywności.
Aby jak najlepiej wykorzystać tę możliwość, potrzebujemy lokalnego magazynu.
Kubernetes udostępnia trzy abstrakcje korzystania z magazynu lokalnego w Kubernetes. Ten:
- Pusty katalog
- Ścieżka hosta.
- miejscowy
Przyjrzyjmy się, czym się różnią i jak są podobne.
Po pierwsze, we wszystkich trzech podejściach mamy pamięć masową - są to dyski lokalne, które znajdują się w tym samym fizycznym węźle k8s. Ale mają pewne różnice.
Zacznijmy od najprostszego, czyli pustyDir. Co to jest w praktyce? W naszej specyfikacji prosimy system konteneryzacyjny (najczęściej Docker) o udostępnienie nam folderu na dysku lokalnym.
W praktyce Docker tworzy folder tymczasowy gdzieś wzdłuż własnych ścieżek i nazywa go długim skrótem. I zapewnia interfejs umożliwiający dostęp do niego.
Jak to będzie działać pod względem wydajności? Będzie to działać przy lokalnej szybkości dysku, tj. To pełny dostęp do śruby.
Ale ten przypadek ma swoją wadę. Trwałość jest w tej kwestii dość wątpliwa. Gdy Docker po raz pierwszy porusza się z kontenerami, funkcja Persistent zostaje utracona. Jeśli Kubernetes z jakiegoś powodu będzie chciał przenieść tego Poda na inny dysk, dane zostaną utracone.
To podejście jest dobre do testów, ponieważ pokazuje już normalną prędkość, ale w przypadku czegoś poważnego ta opcja nie jest odpowiednia.
Dlatego istnieje drugie podejście. To jest ścieżka hosta. Jeśli spojrzysz na poprzedni slajd i ten, zobaczysz tylko jedną różnicę. Nasz folder został przeniesiony z Dockera bezpośrednio do węzła Kubernetes. Tutaj jest trochę prościej. Bezpośrednio określamy ścieżkę w lokalnym systemie plików, w którym chcielibyśmy przechowywać nasze dane.
Ta metoda ma zalety. To już prawdziwy Persistent i to klasyczny. Będziemy mieć dane zapisane na dysku pod jakimś adresem.
Są też wady. Na tym polega złożoność zarządzania. Nasz Kubernetes może chcieć przenieść Poda do innego fizycznego węzła. I tu właśnie pojawia się DevOps. Musi poprawnie wyjaśnić całemu systemowi, że te kapsuły można przenosić tylko do tych węzłów, na których masz coś zamontowanego wzdłuż tych ścieżek i nie więcej niż jeden węzeł na raz. To dość trudne.
Specjalnie do tych celów wykonaliśmy szablony w naszym operatorze, aby ukryć całą tę złożoność. Można po prostu powiedzieć: „Chcę mieć jedną instancję ClickHouse dla każdego węzła fizycznego i wzdłuż takiej a takiej ścieżki”.
Ale nie tylko my potrzebujemy tej potrzeby, więc panowie z samego Kubernetesa też rozumieją, że ludzie chcą mieć dostęp do dysków fizycznych, więc zapewniają trzecią warstwę.
To się nazywa lokalność. Praktycznie nie ma różnicy w stosunku do poprzedniego slajdu. Dopiero wcześniej trzeba było ręcznie potwierdzić, że nie możemy przenieść tych podów z węzła na węzeł, bo muszą być jakąś ścieżką dołączone do lokalnego dysku fizycznego, ale teraz cała ta wiedza jest zawarta w samym Kubernetesie. I okazuje się, że jest znacznie łatwiejszy w konfiguracji.
Wróćmy do naszego problemu praktycznego. Wróćmy do szablonu YAML. Tutaj mamy prawdziwy magazyn. Wracamy do tego. Ustawiamy klasyczny szablon VolumeClaim jak w k8s. I opisujemy, jakiego rodzaju przechowywania chcemy.
Następnie k8s poprosi o pamięć. Przydzieli nam to w StatefulSet. I docelowo będzie do dyspozycji ClickHouse.
Mieliśmy taki schemat. Nasz magazyn trwały był czerwony, co zdawało się sugerować, że należy to zrobić.
I robi się zielono. Teraz schemat klastra ClickHouse na k8s jest całkowicie sfinalizowany. Mamy shardy, repliki, ZooKeepera, mamy prawdziwego Persistenta, który jest zaimplementowany w taki czy inny sposób. System jest już w pełni operacyjny.
Żyjemy dalej. Nasz klaster się rozwija. Ale Alexey próbuje i wydaje nową wersję ClickHouse.
Powstaje praktyczne zadanie – przetestować nową wersję ClickHouse na naszym klastrze. I oczywiście nie chcesz tego wszystkiego rozkręcać, chcesz umieścić nową wersję w jednej replice gdzieś w odległym kącie i może nie jedną nową wersję, ale dwie na raz, bo często wychodzą.
Co możemy o tym powiedzieć?
Tutaj mamy właśnie taką możliwość. To są szablony podów. Można napisać, że nasz operator całkowicie pozwala na zbudowanie klastra heterogenicznego. Te. skonfiguruj, zaczynając od wszystkich replik w grupie, a kończąc na każdej osobistej replice, jaką wersję chcemy ClickHouse i jaką wersję chcemy przechowywać. Klaster możemy w pełni skonfigurować z konfiguracją, której potrzebujemy.
Wejdźmy trochę głębiej do środka. Wcześniej rozmawialiśmy o tym, jak działa ClickHouse-operator w odniesieniu do specyfiki ClickHouse.
Teraz chciałbym powiedzieć kilka słów o tym, jak ogólnie działa każdy operator, a także jak współdziała z K8.
Przyjrzyjmy się najpierw interakcji z K8. Co się stanie, gdy zastosujemy kubectl? Nasze obiekty pojawiają się w etcd poprzez API.
Na przykład podstawowe obiekty Kubernetes: pod, StatefulSet, service i tak dalej na liście.
Jednocześnie nic fizycznego się jeszcze nie dzieje. Obiekty te muszą zmaterializować się w klastrze.
W tym celu pojawia się kontroler. Kontroler jest specjalnym komponentem K8s, który może urzeczywistnić te opisy. Wie, jak i co robić fizycznie. Wie jak uruchomić kontenery, co należy tam skonfigurować, aby serwer działał.
I materializuje nasze obiekty w K8.
Ale my chcemy działać nie tylko z podami i StatefulSets, chcemy stworzyć ClickHouseInstallation, czyli obiekt typu ClickHouse, aby móc z nim działać jako jedną całość. Póki co nie ma takiej możliwości.
Ale K8s ma następującą miłą rzecz. Chcemy, abyśmy mieli coś w rodzaju tej złożonej jednostki, w której nasz klaster byłby złożony z podów i StatefulSet.
I co trzeba w tym celu zrobić? Najpierw pojawia się niestandardowa definicja zasobów. Co to jest? To jest opis dla K8, że będziesz mieć jeszcze jeden typ danych, że chcemy dodać do poda niestandardowy zasób, StatefulSet, który będzie w środku skomplikowany. To jest opis struktury danych.
Wysyłamy go tam również poprzez kubectl Apply. Kubernetes chętnie to przyjął.
A teraz w naszym magazynie obiekt w etcd ma możliwość zarejestrowania niestandardowego zasobu o nazwie ClickHouseInstallation.
Ale na razie nic więcej się nie wydarzy. Oznacza to, że jeśli teraz utworzymy plik YAML, który opisywałem shardy i repliki, i powiemy „kubectl Apply”, wówczas Kubernetes go zaakceptuje, umieści w etcd i powie: „Świetnie, ale nie wiem, co robić z tym. Nie wiem, jak utrzymać instalację ClickHouseInstallation.”
W związku z tym potrzebujemy kogoś, kto pomoże Kubernetesowi w obsłudze nowego typu danych. Po lewej stronie mamy natywny kontroler Kubernetes, który współpracuje z natywnymi typami danych. Po prawej stronie powinniśmy mieć niestandardowy kontroler, który może pracować z niestandardowymi typami danych.
W inny sposób nazywa się to operatorem. Specjalnie umieściłem go tutaj jako Kubernetes, ponieważ można go również wykonać poza K8. Najczęściej oczywiście wszyscy operatorzy są wykonywani w Kubernetesie, ale nic nie stoi na przeszkodzie, aby stał on na zewnątrz, dlatego tutaj jest specjalnie przenoszony na zewnątrz.
Z kolei niestandardowy kontroler, zwany także operatorem, wchodzi w interakcję z Kubernetesem za pośrednictwem API. Wie już, jak współdziałać z API. I już wie, jak zmaterializować złożony obwód, który chcemy wykonać z niestandardowego zasobu. Dokładnie to robi operator.
Jak działa operator? Spójrzmy na prawą stronę, żeby zobaczyć, jak on to robi. Przekonajmy się, jak operator materializuje to wszystko i jak zachodzi dalsza interakcja z K8.
Operator jest programem. Jest zorientowana na wydarzenia. Operator subskrybuje zdarzenia za pomocą Kubernetes API. Kubernetes API ma punkty wejścia, w których możesz subskrybować zdarzenia. A jeśli coś się zmieni w K8s, to Kubernetes wysyła zdarzenia do wszystkich, czyli tzw. każdy, kto zapisał się do tego punktu API, otrzyma powiadomienia.
Operator subskrybuje zdarzenia i musi zareagować. Jej zadaniem jest reagowanie na pojawiające się wydarzenia.
Zdarzenia są generowane przez określone aktualizacje. Nadchodzi nasz plik YAML z opisem ClickHouseInstallation. Poszedł do etcd poprzez kubectl Apply. Tam zostało wywołane zdarzenie, w wyniku czego zdarzenie to dotarło do operatora ClickHouse. Operator otrzymał taki opis. I musi coś zrobić. Jeśli nadeszła aktualizacja dla obiektu ClickHouseInstallation, należy zaktualizować klaster. Natomiast zadaniem operatora jest aktualizacja klastra.
Co on robi? Najpierw musimy sporządzić plan działania dotyczący tego, co zrobimy z tą aktualizacją. Aktualizacje mogą być bardzo małe, tj. małe w wykonaniu YAML, ale mogą pociągać za sobą bardzo duże zmiany w klastrze. Dlatego operator tworzy plan, a następnie się go trzyma.
Zgodnie z tym planem zaczyna gotować tę konstrukcję w środku, aby zmaterializować strąki, usługi, czyli tzw. robić to, co jest jego głównym zadaniem. Oto jak zbudować klaster ClickHouse w Kubernetesie.
Poruszmy teraz taką interesującą rzecz. To podział odpowiedzialności pomiędzy Kubernetesem a operatorem, czyli tzw. co robi Kubernetes, co robi operator i jak współdziałają ze sobą.
Kubernetes odpowiada za sprawy systemowe, tj. dla podstawowego zestawu obiektów, który można interpretować jako zasięg systemowy. Kubernetes wie jak uruchamiać pody, jak restartować kontenery, jak montować wolumeny, jak pracować z ConfigMapem, czyli: wszystko, co można nazwać systemem.
Operatorzy działają w domenach. Każdy operator jest stworzony dla własnego obszaru tematycznego. Zrobiliśmy to dla ClickHouse.
A operator wchodzi w interakcję precyzyjnie merytorycznie, np. dodając replikę, robiąc diagram, ustawiając monitoring. W rezultacie następuje podział.
Przyjrzyjmy się praktycznemu przykładowi, jak ten podział odpowiedzialności zachodzi, gdy wykonujemy akcję dodawania repliki.
Operator otrzymuje zadanie - dodać replikę. Co robi operator? Operator obliczy, że należy utworzyć nowy StatefulSet, w którym należy opisać takie a takie szablony, zastrzeżenie woluminu.
On to wszystko przygotował i przekazał K8. Mówi, że potrzebuje ConfigMap, StatefulSet, Volume. Kubernetes działa. Materializuje podstawowe jednostki, za pomocą których operuje.
I wtedy do akcji ponownie wkracza operator ClickHouse. Ma już fizyczny kapsułę, na której może już coś zrobić. A operator ClickHouse znów działa w kategoriach domenowych. Te. W szczególności ClickHouse, aby włączyć replikę do klastra, należy najpierw skonfigurować schemat danych istniejący w tym klastrze. Po drugie, replika ta musi zostać objęta monitoringiem, aby można było ją jednoznacznie prześledzić. Operator już to konfiguruje.
I dopiero potem w grę wchodzi sam ClickHouse, czyli tzw. kolejna jednostka wyższego szczebla. To już jest baza danych. Posiada własną instancję, kolejną skonfigurowaną replikę, która jest gotowa do przyłączenia się do klastra.
Okazuje się, że łańcuch wykonania i podziału odpowiedzialności przy dodawaniu repliki jest dość długi.
Kontynuujemy nasze zadania praktyczne. Jeśli masz już klaster, możesz przeprowadzić migrację konfiguracji.
Zrobiliśmy to tak, abyś mógł wkleić bezpośrednio do istniejącego pliku XML, co ClickHouse rozumie.
Możesz dostroić ClickHouse. Właśnie wdrożenie strefowe było tym, o czym mówiłem, wyjaśniając HostPath, lokalną pamięć masową. Oto jak poprawnie przeprowadzić wdrożenie strefowe.
Kolejnym praktycznym zadaniem jest monitorowanie.
Jeśli nasz klaster ulegnie zmianie, wówczas musimy okresowo konfigurować monitorowanie.
Spójrzmy na diagram. Przyjrzeliśmy się już zielonym strzałkom tutaj. Spójrzmy teraz na czerwone strzałki. W ten sposób chcemy monitorować nasz klaster. Jak metryki z klastra ClickHouse trafiają do Prometheusa, a następnie do Grafany.
Jaka jest trudność w monitorowaniu? Dlaczego jest to przedstawiane jako pewnego rodzaju osiągnięcie? Trudność leży w dynamice. Gdy mamy jeden klaster i jest on statyczny, to możemy raz skonfigurować monitoring i nie zawracać sobie tym głowy.
Jeśli jednak mamy dużo klastrów, albo coś ciągle się zmienia, to proces jest dynamiczny. A ciągłe rekonfigurowanie monitorowania to strata zasobów i czasu, tj. nawet po prostu lenistwo. Należy to zautomatyzować. Trudność polega na dynamice procesu. Operator bardzo dobrze to automatyzuje.
Jak rozwijał się nasz klaster? Na początku taki był.
Potem był taki.
W końcu stał się taki.
Monitorowanie odbywa się automatycznie przez operatora. Pojedynczy punkt wejścia.
I już przy wyjściu zaglądamy na deskę rozdzielczą Grafany, żeby zobaczyć, jak kipi w środku życie naszego klastra.
Nawiasem mówiąc, dashboard Grafana jest również dystrybuowany u naszego operatora bezpośrednio w kodzie źródłowym. Można się łączyć i używać. Nasz DevOps dał mi ten zrzut ekranu.
Gdzie chcielibyśmy pojechać dalej? Ten:
- Rozwijaj automatyzację testów. Głównym zadaniem jest automatyczne testowanie nowych wersji.
- Bardzo chcemy też zautomatyzować integrację z ZooKeeperem. W planach jest także integracja z operatorem ZooKeeper. Te. Dla ZooKeepera napisano operatora i logiczne jest, że obaj operatorzy zaczną się integrować, aby zbudować wygodniejsze rozwiązanie.
- Chcemy wykonać bardziej złożone parametry życiowe.
- Zaznaczyłem na zielono, że zbliżamy się do dziedziczenia Szablonów - DONE, czyli wraz z kolejną wersją operatora będziemy już mieli dziedziczenie szablonów. Jest to potężne narzędzie, które pozwala budować złożone konfiguracje z elementów.
- A my chcemy automatyzacji złożonych zadań. Najważniejszym z nich jest ponowne sharding.
Weźmy kilka wyników pośrednich.
Co w efekcie otrzymamy? I czy warto to robić czy nie? Czy w ogóle trzeba próbować przeciągnąć bazę danych do Kubernetesa i używać operatora w ogóle, a w szczególności operatora Alitnity?
Na wyjściu otrzymujemy:
- Znaczące uproszczenie i automatyzacja konfiguracji, wdrażania i konserwacji.
- Natychmiast wbudowany monitoring.
- Oraz gotowe do użycia, skodyfikowane szablony dla złożonych sytuacji. Czynności takiej jak dodanie repliki nie trzeba wykonywać ręcznie. Robi to operator.
Pozostało już tylko ostatnie pytanie. Mamy już bazę danych w Kubernetesie, wirtualizacja. A co z wydajnością takiego rozwiązania, zwłaszcza, że ClickHouse jest zoptymalizowany pod kątem wydajności?
Odpowiedź brzmi: wszystko w porządku! Nie będę się wdawał w szczegóły, to temat na oddzielny reportaż.
Ale jest taki projekt jak TSBS. Jakie jest jego główne zadanie? To jest test wydajności bazy danych. To próba porównania ciepła z ciepłem, miękkości z miękkością.
Jak on pracuje? Generowany jest jeden zestaw danych. Następnie ten zestaw danych jest uruchamiany w różnych bazach danych przy użyciu tego samego zestawu testów. Każda baza danych rozwiązuje jeden problem w sposób, w jaki wie. A potem będziesz mógł porównać wyniki.
Obsługuje już dużą liczbę baz danych. Zidentyfikowałem trzy główne. Ten:
- Skala czasuDB.
- NapływDB.
- KliknijDom.
Dokonano także porównania z innym podobnym rozwiązaniem. Porównanie z RedShift. Porównanie zostało dokonane na Amazonie. ClickHouse również w tej kwestii wyprzedza wszystkich.
Jakie wnioski można wyciągnąć z tego co powiedziałem?
- DB w Kubernetesie jest możliwy. Prawdopodobnie wszystko jest możliwe, ale ogólnie wygląda na to, że jest to możliwe. ClickHouse na Kubernetesie jest zdecydowanie możliwy z pomocą naszego operatora.
- Operator pomaga zautomatyzować procesy i naprawdę ułatwia życie.
- Wydajność jest normalna.
- I wydaje nam się, że można i należy to wykorzystać.
Otwarte oprogramowanie – dołącz do nas!
Jak już mówiłem, operator jest produktem całkowicie open source, więc byłoby bardzo dobrze, gdyby korzystała z niego jak największa liczba osób. Dołącz do nas! Czekamy na Was wszystkich!
Dziękuję wszystkim!
pytania
Dziękujemy za raport! Nazywam się Anton. Jestem z SEMrush. Zastanawiam się, co się dzieje z logowaniem. Słyszymy o monitorowaniu, ale nie ma nic o logowaniu, jeśli mówimy o całym klastrze. Na przykład utworzyliśmy klaster dotyczący sprzętu. Używamy scentralizowanego rejestrowania, zbierając je we wspólną stertę przy użyciu standardowych środków. Stamtąd otrzymujemy interesujące nas dane.
Dobre pytanie, czyli logowanie się na listę rzeczy do zrobienia. Nasz operator jeszcze tego nie automatyzuje. Wciąż się rozwija, projekt jest jeszcze dość młody. Rozumiemy potrzebę logowania. To także bardzo ważny temat. I jest to prawdopodobnie nie mniej ważne niż monitorowanie. Jednak na pierwszym miejscu na liście do wdrożenia znalazł się monitoring. Będzie logowanie. Naturalnie staramy się automatyzować wszystkie aspekty życia klastra. Dlatego odpowiedź jest taka, że na chwilę obecną operator niestety nie wie jak to zrobić, ale jest w planach, że to zrobimy. Jeśli chcesz dołączyć, wyślij prośbę.
Cześć! Dziękujemy za raport! Mam standardowe pytanie związane z woluminami trwałymi. Kiedy tworzymy konfigurację za pomocą tego operatora, w jaki sposób operator określa, w którym węźle mamy podłączony konkretny dysk lub folder? Musimy mu najpierw wyjaśnić, że proszę umieścić nasz ClickHouse na tych węzłach, które mają dysk?
O ile rozumiem, to pytanie jest kontynuacją pamięci lokalnej, zwłaszcza jej części hostPath. To jakby tłumaczyć całemu systemowi, że pod trzeba uruchomić na takim a takim węźle, do którego mamy fizycznie podłączony dysk, który jest zamontowany taką a taką ścieżką. To cała sekcja, którą poruszyłem bardzo powierzchownie, ponieważ odpowiedź tam jest dość obszerna.
W skrócie wygląda to tak. Oczywiście musimy zapewnić te woluminy. W tej chwili nie ma dynamicznego udostępniania w lokalnej pamięci masowej, więc DevOps musi samodzielnie wyciąć dyski, te woluminy. Muszą też wyjaśnić obsługę Kubernetesa, że będziesz mieć trwałe woluminy takiej a takiej klasy, które będą zlokalizowane w takich a takich węzłach. Następnie będziesz musiał wyjaśnić Kubernetesowi, że pody, które wymagają takiej a takiej lokalnej klasy pamięci masowej, muszą być kierowane tylko do takich a takich węzłów za pomocą etykiet. W tym celu operator ma możliwość przypisania pewnego rodzaju etykiety, po jednej dla każdej instancji hosta. I okazuje się, że pody będą kierowane przez Kubernetesa tak, aby działały tylko na węzłach, które spełniają wymagania, czyli etykiety, mówiąc najprościej. Administratorzy ręcznie przypisują etykiety i udostępniają dyski. A potem to się skaluje.
I jest to trzecia opcja, lokalna, która pomaga to trochę ułatwić. Jak już podkreślałem, jest to żmudna praca nad tuningiem, która ostatecznie pomaga uzyskać maksymalne osiągi.
Mam drugie pytanie z tym związane. Kubernetes został zaprojektowany w taki sposób, że nie ma dla nas znaczenia, czy stracimy węzeł, czy nie. Co powinniśmy zrobić w tym przypadku, jeśli zgubiliśmy węzeł, w którym wisi nasz shard?
Tak, Kubernetes początkowo był nastawiony na to, że nasza relacja z naszymi strąkami jest jak bydło, ale tutaj każdy dysk staje się dla nas czymś w rodzaju zwierzaka. Jest taki problem, że nie możemy ich po prostu wyrzucić. A rozwój Kubernetesa zmierza w tym kierunku, że nie da się go całkowicie filozoficznie potraktować, jakby był całkowicie wyrzuconym zasobem.
A teraz pytanie praktyczne. Co zrobić jeśli zgubiłeś węzeł, na którym znajdował się dysk? Tutaj problem jest rozwiązywany na wyższym poziomie. W przypadku ClickHouse mamy repliki, które działają na wyższym poziomie, tj. na poziomie ClickHouse.
Jaka jest wynikająca z tego dyspozycja? DevOps jest odpowiedzialny za to, aby dane nie zostały utracone. Musi poprawnie skonfigurować replikację i upewnić się, że replikacja działa. Replika na poziomie ClickHouse musi posiadać zduplikowane dane. To nie jest zadanie, które rozwiązuje operator. I nie jest to problem, który sam Kubernetes rozwiązuje. To jest na poziomie ClickHouse.
Co zrobić, jeśli odpadnie Ci żelazny węzeł? I okazuje się, że trzeba będzie zainstalować drugi, odpowiednio przygotować na nim płytę i nakleić etykiety. A potem spełni wymagania, aby Kubernetes mógł uruchomić na nim instancję pod. Kubernetes go uruchomi. Twoja liczba podów nie jest wystarczająca, aby spełnić określoną liczbę. Przejdzie przez cykl, który pokazałem. A na najwyższym poziomie ClickHouse zrozumie, że wprowadziliśmy replikę, jest ona nadal pusta i trzeba zacząć przesyłać do niej dane. Te. Proces ten nie jest jeszcze dobrze zautomatyzowany.
Dziękujemy za raport! Kiedy zdarzają się różne nieprzyjemne rzeczy, operator ulega awarii i uruchamia się ponownie, i w tym momencie pojawiają się zdarzenia. Czy jakoś sobie z tym radzisz?
Co się stanie, jeśli operator ulegnie awarii i uruchomi się ponownie, prawda?
Tak. I w tym momencie nastąpiły wydarzenia.
Zadanie, co zrobić w tym przypadku, jest częściowo podzielone pomiędzy operatora i Kubernetesa. Kubernetes ma możliwość odtworzenia zdarzenia, które miało miejsce. On odtwarza. Zadaniem operatora jest dopilnowanie, aby podczas odtwarzania na nim dziennika zdarzeń zdarzenia te były idempotentne. I żeby powtarzające się wystąpienie tego samego zdarzenia nie zepsuło naszego systemu. A nasz operator radzi sobie z tym zadaniem.
Cześć! Dziękujemy za raport! Dmitrij Zavyalov, firma Smedova. Czy w planach jest dodanie do operatora możliwości konfiguracji za pomocą haproxy? Byłbym zainteresowany jakimś innym balanserem oprócz standardowego, żeby był mądry i rozumiał, że ClickHouse naprawdę istnieje.
Mówisz o Ingressie?
Tak, zamień Ingress na haproxy. W haproxy możesz określić topologię klastra, w którym znajdują się jego repliki.
Jeszcze o tym nie myśleliśmy. Jeśli tego potrzebujesz i potrafisz wyjaśnić, dlaczego jest to potrzebne, wówczas będzie możliwe jego wdrożenie, szczególnie jeśli chcesz wziąć udział. Chętnie rozważymy taką opcję. Krótka odpowiedź brzmi: nie, obecnie nie mamy takiej funkcjonalności. Dziękujemy za podpowiedź, przyjrzymy się tej sprawie. A jeśli wyjaśnisz również przypadek użycia i dlaczego jest to potrzebne w praktyce, na przykład stworzysz problemy na GitHubie, to będzie świetnie.
Ma już.
Cienki. Jesteśmy otwarci na wszelkie sugestie. A haproxy zostaje dodany do listy rzeczy do zrobienia. Lista rzeczy do zrobienia rośnie, a nie maleje. Ale to dobrze, oznacza to, że produkt jest poszukiwany.
Źródło: www.habr.com