Pod koniec ubiegłego roku odbyła się kolejna transmisja na żywo rosyjskiej społeczności PostgreSQL , podczas którego jego współzałożyciel Nikołaj Samokhwałow rozmawiał z dyrektorem technicznym firmy Flant Dmitrijem Stolyarowem na temat tego systemu DBMS w kontekście Kubernetesa.
Publikujemy zapis głównej części tej dyskusji, a o godz Opublikowano cały film:
Bazy danych i Kubernetes
NS: Nie będziemy dzisiaj rozmawiać o PRÓŻNI i PUNKTACH KONTROLNYCH. Chcemy porozmawiać o Kubernetesie. Wiem, że masz wieloletnie doświadczenie. Oglądałem Twoje filmy, a nawet niektóre z nich jeszcze raz... Przejdźmy od razu do rzeczy: po co w ogóle Postgres lub MySQL w K8?
DS: Nie ma i nie może być jednoznacznej odpowiedzi na to pytanie. Ale ogólnie rzecz biorąc, jest to prostota i wygoda... potencjał. Każdy chce usług zarządzanych.
NS: Jak , tylko w domu?
DS: Tak: jak RDS, po prostu wszędzie.
NS: „Wszędzie” to dobry punkt. W dużych firmach wszystko jest zlokalizowane w różnych miejscach. Dlaczego więc, jeśli jest to duża firma, nie skorzystać z gotowego rozwiązania? Na przykład Nutanix ma własne rozwiązania, inne firmy (VMware...) mają ten sam „RDS, tylko w domu”.
DS: Ale mówimy o osobnej implementacji, która będzie działać tylko pod pewnymi warunkami. A jeśli mówimy o Kubernetesie, to istnieje ogromna różnorodność infrastruktury (która może znajdować się w K8). Zasadniczo jest to standard dla interfejsów API do chmury...
NS: To także jest bezpłatne!
DS: To nie jest takie ważne. Swoboda jest istotna dla niezbyt dużego segmentu rynku. Ważne jest coś innego... Pewnie pamiętacie raport „"?
NS: Tak.
DS: Zdałem sobie sprawę, że zostało to przyjęte bardzo niejednoznacznie. Niektórzy myśleli, że mówię: „Chłopaki, przenieśmy wszystkie bazy danych do Kubernetesa!”, inni uznali, że to wszystko są okropne rowery. Chciałem jednak powiedzieć coś zupełnie innego: „Popatrzcie, co się dzieje, jakie są problemy i jak można je rozwiązać. Czy powinniśmy teraz korzystać z baz danych Kubernetes? Produkcja? Cóż, tylko jeśli lubisz... robić pewne rzeczy. Ale jak na dewelopera mogę powiedzieć, że polecam. Dla programisty bardzo ważna jest dynamika tworzenia/usuwania środowisk.
NS: Przez dewelopera masz na myśli wszystkie środowiska, które nie są prod? Inscenizacja, kontrola jakości…
DS: Jeśli mówimy o stojakach perf, to prawdopodobnie nie, ponieważ wymagania są tam specyficzne. Jeśli mówimy o szczególnych przypadkach, gdy do przemieszczania potrzebna jest bardzo duża baza danych, to prawdopodobnie nie... Jeśli jest to statyczne i długotrwałe środowisko, to jaka jest korzyść z posiadania bazy danych zlokalizowanej w K8?
NS: Nic. Ale gdzie widzimy środowiska statyczne? Środowisko statyczne jutro stanie się przestarzałe.
DS: Inscenizacja może być statyczna. Mamy klientów...
NS: Tak, ja też mam jednego. To duży problem, jeśli masz bazę danych o pojemności 10 TB i przestrzeń dyskową o pojemności 200 GB...
DS: Mam bardzo fajną sprawę! Na etapie stagingu znajduje się baza produktów, w której wprowadzane są zmiany. Jest też przycisk: „wdróż do produkcji”. Te zmiany – delty – są dodawane (wygląda na to, że są po prostu synchronizowane poprzez API) w środowisku produkcyjnym. To bardzo egzotyczna opcja.
NS: Widziałem startupy w Dolinie, które siedzą w RDS lub nawet w Heroku – to historie sprzed 2-3 lat – i pobierają zrzut na swój laptop. Bo baza danych to nadal tylko 80 GB, a na laptopie jest miejsce. Następnie kupują dla każdego dodatkowe dyski, aby mieć 3 bazy danych do przeprowadzania różnych opracowań. Tak też się dzieje. Widziałem też, że nie boją się kopiować prodów na inscenizację – bardzo dużo zależy od firmy. Ale widziałem też, że bardzo się boją i często brakuje im czasu i rąk. Zanim jednak przejdziemy do tego tematu, chcę usłyszeć o Kubernetesie. Czy dobrze rozumiem, że nikt jeszcze nie jest w prod?
DS: Mamy małe bazy danych w prod. Mówimy o wolumenach kilkudziesięciu gigabajtów i usługach niekrytycznych, dla których byliśmy zbyt leniwi, aby tworzyć repliki (a nie ma takiej potrzeby). I pod warunkiem, że w Kubernetesie jest normalna pamięć masowa. Baza ta pracowała na maszynie wirtualnej - warunkowo w VMware, na górze systemu Storage. Umieściliśmy to i teraz możemy przenieść go z maszyny na maszynę.
NS: Bazy danych tej wielkości, do 100 GB, można wdrożyć w ciągu kilku minut na dobrych dyskach i dobrej sieci, prawda? Prędkość 1 GB na sekundę nie jest już egzotyczna.
DS: Tak, w przypadku pracy liniowej nie stanowi to problemu.
NS: OK, musimy tylko pomyśleć o prod. A jeśli rozważamy Kubernetes dla środowisk innych niż produkcyjne, co powinniśmy zrobić? Widzę to w Zalando , w Crunchy , jest jeszcze kilka innych opcji. I jest – to jest nasz dobry przyjaciel Alvaro z Hiszpanii: to, co robią, jest w zasadzie nie tylko i cała dystrybucja (), do którego oprócz samego Postgresa postanowiono także wrzucić kopię zapasową, proxy Envoy...
DS: Posłaniec czego? W szczególności równoważenie ruchu Postgres?
NS: Tak. Oznacza to, że postrzegają to tak: jeśli weźmiesz dystrybucję i jądro Linuksa, wówczas jądrem będzie zwykły PostgreSQL i chcą stworzyć dystrybucję, która będzie przyjazna dla chmury i będzie działać na Kubernetesie. Składają komponenty (kopie zapasowe itp.) i debugują je, aby działały dobrze.
DS: Bardzo fajny! Zasadniczo jest to oprogramowanie do tworzenia własnego zarządzanego Postgres.
NS: Dystrybucje Linuksa mają wieczne problemy: jak stworzyć sterowniki, aby obsługiwał cały sprzęt. I mają pomysł, że będą pracować w Kubernetesie. Wiem, że u operatora Zalando widzieliśmy ostatnio połączenie z AWS i nie jest to już zbyt dobre. Nie powinno być powiązania z konkretną infrastrukturą – po co więc?
DS: Nie wiem dokładnie, w jakiej sytuacji znalazło się Zalando, ale w Kubernetesie przechowywanie danych jest teraz tak zorganizowane, że nie da się wykonać kopii zapasowej dysku zwykłą metodą. Od niedawna w standardzie - w najnowszej wersji — umożliwiliśmy tworzenie migawek, ale gdzie jest to zaimplementowane? Szczerze mówiąc, wszystko jest jeszcze takie surowe... Próbujemy CSI na AWS, GCE, Azure, vSphere, ale gdy tylko zaczniesz go używać, widać, że nie jest jeszcze gotowy.
NS: Dlatego czasami musimy polegać na infrastrukturze. Myślę, że to wciąż wczesny etap – bóle wzrostowe. Pytanie: Jakiej rady udzieliłbyś nowicjuszom, którzy chcą wypróbować PgSQL w K8? Jaki operator może?
DS: Problem w tym, że Postgres stanowi dla nas 3%. Mamy też bardzo dużą listę różnych programów w Kubernetesie, nawet nie będę wszystkiego wymieniać. Na przykład Elasticsearch. Operatorów jest wielu: niektórzy aktywnie się rozwijają, inni nie. Ustaliliśmy dla siebie wymagania dotyczące tego, co powinien posiadać operator, abyśmy mogli go traktować poważnie. W operatorze specjalnie dla Kubernetesa - nie w „operatorze, który zrobi coś na warunkach Amazona”... Tak naprawdę dość powszechnie (= prawie wszyscy klienci) używamy jednego operatora - (wkrótce opublikujemy artykuł na jego temat).
NS: I nie dla MySQL? Wiem, że Percona… skoro pracują teraz nad MySQL, MongoDB i Postgres, będą musieli stworzyć jakieś uniwersalne rozwiązanie: dla wszystkich baz danych, dla wszystkich dostawców usług w chmurze.
DS: Nie mieliśmy czasu przyjrzeć się operatorom MySQL. Nie jest to obecnie naszym głównym celem. MySQL działa dobrze w trybie autonomicznym. Po co używać operatora, jeśli możesz po prostu uruchomić bazę danych... Możesz uruchomić kontener Dockera za pomocą Postrges lub możesz go uruchomić w prosty sposób.
NS: Było też pytanie na ten temat. Brak operatora?
DS: Tak, u 100% z nas PostgreSQL działa bez operatora. Do tej pory. Aktywnie korzystamy z operatora dla Prometheusa i Redisa. Mamy w planach znalezienie operatora dla Elasticsearch – to ten, który najbardziej „pali”, bo chcemy go zainstalować w Kubernetesie w 100% przypadków. Tak jak chcemy mieć pewność, że MongoDB będzie zawsze instalowane także w Kubernetesie. Tutaj pojawiają się pewne życzenia - pojawia się poczucie, że w takich przypadkach można coś zrobić. I nawet nie spojrzeliśmy na Postgres. Oczywiście wiemy, że istnieją różne opcje, ale tak naprawdę mamy samodzielne.
DB do testów w Kubernetesie
NS: Przejdźmy do tematu testów. Jak wdrożyć zmiany w bazie danych - z perspektywy DevOps. Są mikroserwisy, dużo baz danych, cały czas coś się gdzieś zmienia. Jak zapewnić normalny CI/CD, aby wszystko było w porządku z punktu widzenia DBMS. Jakie jest Twoje podejście?
DS: Nie może być jednej odpowiedzi. Istnieje kilka opcji. Pierwszym z nich jest rozmiar bazy, którą chcemy rozłożyć. Sam wspomniałeś, że firmy mają różne podejście do posiadania kopii bazy danych produktów na platformie deweloperskiej i na scenie.
NS: A w warunkach RODO myślę, że są coraz ostrożniejsi... Mogę powiedzieć, że w Europie już zaczęli nakładać kary.
DS: Ale często można napisać oprogramowanie, które pobiera zrzut z produkcji i zaciemnia go. Pobierane są dane produkcyjne (migawka, zrzut, kopia binarna...), ale są one anonimizowane. Zamiast tego mogą istnieć skrypty generujące: mogą to być urządzenia lub po prostu skrypt generujący dużą bazę danych. Problem polega na tym: ile czasu zajmuje utworzenie obrazu podstawowego? Ile czasu zajmuje wdrożenie go w pożądanym środowisku?
Doszliśmy do schematu: jeśli klient ma stały zestaw danych (minimalna wersja bazy danych), to domyślnie z nich korzystamy. Jeśli mówimy o środowiskach recenzyjnych, to tworząc oddział wdrożyliśmy instancję aplikacji - wdrażamy tam małą bazę danych. Ale skończyło się dobrze , kiedy raz dziennie (w nocy) pobieramy zrzut z produkcji i budujemy kontener Docker z PostgreSQL i MySQL na podstawie załadowanych danych. Jeśli chcesz rozszerzyć bazę danych 50 razy z tego obrazu, można to zrobić w prosty i szybki sposób.
NS: Przez proste kopiowanie?
DS: Dane są przechowywane bezpośrednio w obrazie Dockera. Te. Mamy gotowy obraz, aczkolwiek 100 GB. Dzięki warstwom w Dockerze możemy szybko wdrożyć ten obraz tyle razy, ile potrzebujemy. Metoda głupia, ale skuteczna.
NS: Zatem podczas testowania zmienia się to bezpośrednio w Dockerze, prawda? Kopiuj przy zapisie w Dockerze - wyrzuć to i idź jeszcze raz, wszystko jest w porządku. Klasa! A czy już go w pełni wykorzystujesz?
DS: Przez długi czas.
NS: Robimy bardzo podobne rzeczy. Tylko, że my nie korzystamy z metody kopiowania przy zapisie Dockera, tylko z jakiejś innej.
DS: To nie jest ogólne. A Docker działa wszędzie.
NS: Teoretycznie tak. Ale mamy tam również moduły, możesz tworzyć różne moduły i pracować z różnymi systemami plików. Co za chwila tutaj. Od strony Postgres patrzymy na to wszystko inaczej. Teraz spojrzałem od strony Dockera i zobaczyłem, że u Ciebie wszystko działa. Ale jeśli baza danych jest ogromna, na przykład 1 TB, to wszystko zajmuje dużo czasu: operacje w nocy i umieszczanie wszystkiego w Dockerze... A jeśli 5 TB jest upchane w Dockerze... A może wszystko jest w porządku?
DS: Jaka jest różnica: są to plamy, tylko bity i bajty.
NS: Różnica jest następująca: czy robisz to poprzez zrzut i przywracanie?
DS: Wcale nie konieczne. Metody generowania tego obrazu mogą być różne.
NS: Dla niektórych klientów zrobiliśmy to tak, że zamiast regularnie generować obraz bazowy, stale go aktualizujemy. Zasadniczo jest to replika, ale otrzymuje dane nie bezpośrednio od wzorca, ale poprzez archiwum. Archiwum binarne, do którego codziennie pobierane są pliki WAL i tworzone są kopie zapasowe... Te pliki WAL docierają następnie do obrazu podstawowego z niewielkim opóźnieniem (dosłownie 1-2 sekundy). Klonujemy z niego w dowolny sposób - teraz domyślnie mamy ZFS.
DS: Ale w ZFS jesteś ograniczony do jednego węzła.
NS: Tak. Ale ZFS ma także magię : dzięki niemu możesz wysłać migawkę, a nawet (tak naprawdę jeszcze tego nie testowałem, ale...) możesz wysłać deltę między dwoma PGDATA. W rzeczywistości mamy inne narzędzie, którego tak naprawdę nie rozważaliśmy do takich zadań. PostgreSQL ma , który działa jak „inteligentny” rsync, pomijając wiele z tego, czego nie musisz oglądać, ponieważ nic się tam nie zmieniło. Możemy dokonać szybkiej synchronizacji pomiędzy obydwoma serwerami i przewinąć do tyłu w ten sam sposób.
Zatem od strony bardziej DBA staramy się stworzyć narzędzie, które pozwoli nam zrobić to samo, co powiedziałeś: mamy jedną bazę danych, ale chcemy przetestować coś 50 razy, prawie jednocześnie.
DS: 50 razy oznacza, że musisz zamówić 50 instancji Spota.
NS: Nie, wszystko robimy na jednej maszynie.
DS: Ale jak rozszerzysz 50 razy, jeśli ta jedna baza danych ma, powiedzmy, terabajt. Najprawdopodobniej potrzebuje warunkowo 256 GB RAM?
NS: Tak, czasami potrzebujesz dużo pamięci - to normalne. Ale to przykład z życia. Maszyna produkcyjna ma 96 rdzeni i 600 GB. Jednocześnie na bazę danych wykorzystywane są 32 rdzenie (obecnie czasami nawet 16 rdzeni) i 100-120 GB pamięci.
DS: I zmieści się tam 50 egzemplarzy?
NS: Czyli jest tylko jedna kopia, wtedy działa kopiowanie przy zapisie (ZFS)... Powiem ci bardziej szczegółowo.
Na przykład mamy bazę danych o pojemności 10 TB. Zrobili do niego dysk, ZFS też skompresował jego rozmiar o 30-40 procent. Ponieważ nie robimy testów obciążeniowych, dokładny czas reakcji nie jest dla nas ważny: niech będzie nawet 2 razy wolniejszy - nie ma w tym nic złego.
Dajemy możliwość programistom, QA, DBA itp. wykonaj testy w 1-2 wątkach. Na przykład mogą przeprowadzić jakąś migrację. Nie wymaga 10 rdzeni na raz - potrzebuje 1 backendu Postgres, 1 rdzeń. Migracja się rozpocznie – być może będzie nadal uruchamiany, wówczas używany będzie drugi rdzeń. Mamy przydzielonych 16-32 rdzeni, więc jednocześnie może pracować 10 osób, bez problemu.
Bo fizycznie PGDATA to samo, okazuje się, że tak naprawdę oszukujemy Postgres. Sztuczka polega na tym, że na przykład jednocześnie uruchamianych jest 10 Postgresów. Jaki jest zazwyczaj problem? Włożyli powiedzmy 25%. Odpowiednio jest to 200 GB. Nie będziesz mógł uruchomić więcej niż trzech z nich, ponieważ skończy się pamięć.
Ale w pewnym momencie zdaliśmy sobie sprawę, że nie jest to konieczne: ustawiliśmy wspólne bufory na 2 GB. PostgreSQL ma i w rzeczywistości tylko on ma na to wpływ . Ustawiliśmy go na 0,5 TB. I nie ma nawet znaczenia, że tak naprawdę nie istnieją: tworzy plany tak, jakby istniały.
W związku z tym, gdy będziemy testować jakąś migrację, będziemy mogli zebrać wszystkie plany - zobaczymy, jak to będzie wyglądać na produkcji. Sekundy tam będą inne (wolniejsze), ale dane, które faktycznie odczytamy, i same plany (jakie tam są JOINy itp.) okazują się dokładnie takie same jak na produkcji. Można także uruchomić wiele takich kontroli równolegle na jednym komputerze.
DS: Nie sądzisz, że jest tu kilka problemów? Pierwsze to rozwiązanie, które działa tylko na PostgreSQL. To podejście jest bardzo prywatne, nie jest ogólne. Po drugie, Kubernetes (i wszystko, do czego zmierzają teraz technologie chmurowe) obejmuje wiele węzłów, a te węzły są efemeryczne. W twoim przypadku jest to stanowy, trwały węzeł. Te rzeczy budzą we mnie konflikt.
NS: Po pierwsze, zgadzam się, że jest to historia wyłącznie Postgres. Myślę, że jeśli będziemy mieli jakieś bezpośrednie I/O i pulę buforów dla prawie całej pamięci, to podejście to nie zadziała – plany będą inne. Ale na razie współpracujemy tylko z Postgres, nie myślimy o innych.
O Kubernetesie. Sam nam wszędzie mówisz, że mamy trwałą bazę danych. Jeśli instancja się nie powiedzie, najważniejsze jest zapisanie dysku. Tutaj też mamy całą platformę w Kubernetesie, a komponent z Postgresem jest osobny (choć kiedyś tam będzie). Zatem wszystko wygląda tak: instancja upadła, ale zapisaliśmy jej PV i po prostu podłączyliśmy ją do innej (nowej) instancji, jak gdyby nic się nie stało.
DS: Z mojego punktu widzenia tworzymy pody w Kubernetesie. K8s - gumka: węzły zamawia się według potrzeb. Zadanie polega na tym, aby po prostu stworzyć kapsułę i powiedzieć, że potrzebuje X zasobów, a następnie K8s sam to rozwiąże. Jednak obsługa pamięci masowej w Kubernetes jest nadal niestabilna: w (to wydanie zostało wydane недели temu) te funkcje stają się tylko wersją beta.
Minie sześć miesięcy do roku - sytuacja stanie się mniej więcej stabilna, a przynajmniej zostanie zadeklarowana jako taka. Wtedy możliwość tworzenia migawek i zmiany rozmiaru całkowicie rozwiązuje Twój problem. Bo masz bazę. Tak, może nie jest to bardzo szybkie, ale prędkość zależy od tego, co jest „pod maską”, ponieważ niektóre implementacje mogą kopiować i kopiować przy zapisie na poziomie podsystemu dysku.
NS: Konieczne jest również, aby wszystkie silniki (Amazon, Google...) rozpoczęły obsługę tej wersji - to również zajmuje trochę czasu.
DS: Jeszcze ich nie używamy. Używamy naszych.
Rozwój lokalny dla Kubernetes
NS: Czy spotkałeś się z takim życzeniem, gdy musisz zainstalować wszystkie pody na jednej maszynie i wykonać taki mały test. Aby szybko uzyskać proof of concept, sprawdź, czy aplikacja działa w Kubernetesie, bez poświęcania na nią kilku maszyn. Jest Minikube, prawda?
DS: Wydaje mi się, że w tym przypadku – wdrożonym w jednym węźle – chodzi wyłącznie o rozwój lokalny. Lub niektóre przejawy takiego wzoru. Jeść , jest , . Zmierzamy w stronę korzystania z Kubernetes IN Docker. Teraz zaczęliśmy z nim pracować w celach testowych.
NS: Kiedyś myślałem, że była to próba zawinięcia wszystkich podów w jeden obraz Dockera. Okazało się jednak, że tu chodzi o coś zupełnie innego. W każdym razie istnieją osobne kontenery, osobne kapsuły - tylko w Dockerze.
DS: Tak. Powstała dość zabawna imitacja, ale znaczenie jest takie... Mamy narzędzie do wdrażania - . Chcemy, aby był to tryb warunkowy werf up: „Połącz mnie z lokalnym Kubernetesem.” A następnie uruchom tam warunek werf follow. Następnie programista będzie mógł edytować IDE, a w systemie zostanie uruchomiony proces, który zobaczy zmiany i przebuduje obrazy, ponownie wdrażając je na lokalnych K8. W ten sposób chcemy spróbować rozwiązać problem rozwoju lokalnego.
Migawki i klonowanie baz danych w rzeczywistości K8
NS: Jeśli wrócimy do kopiowania przy zapisie. Zauważyłem, że chmury też mają migawki. Działają inaczej. Na przykład w GCP: masz wieloterabajtową instancję na wschodnim wybrzeżu Stanów Zjednoczonych. Okresowo robisz migawki. Z migawki pobierasz kopię dysku na zachodnim wybrzeżu - za kilka minut wszystko jest gotowe, działa bardzo szybko, wystarczy zapełnić pamięć podręczną. Ale te klony (migawki) mają na celu „zapewnienie” nowego woluminu. Jest to fajne, gdy trzeba utworzyć wiele instancji.
Ale do testów wydaje mi się, że migawki, o których mówisz w Dockerze, a ja mówię w ZFS, btrfs, a nawet LVM... - pozwalają nie tworzyć tak naprawdę nowych danych na jednej maszynie. W chmurze nadal za nie zapłacisz za każdym razem i będziesz czekać nie sekundy, a minuty (a w przypadku ewentualnie zegarek).
Zamiast tego możesz uzyskać te dane w ciągu sekundy lub dwóch, uruchomić test i wyrzucić go. Te migawki rozwiązują różne problemy. W pierwszym przypadku - w celu zwiększenia skali i zdobycia nowych replik, a w drugim - do testów.
DS: Nie zgadzam się. Zadaniem chmury jest zapewnienie prawidłowego działania klonowania woluminów. Nie przyglądałem się ich implementacji, ale wiem jak to robimy na sprzęcie. Mamy Ceph, który pozwala na dowolną objętość fizyczną () mowić klonować i uzyskaj drugi wolumin o tej samej charakterystyce w dziesiątki milisekund, „ami” itp. Musisz zrozumieć, że w środku znajduje się trudna metoda kopiowania i zapisu. Dlaczego chmura nie miałaby zrobić tego samego? Jestem pewien, że próbują to zrobić w ten czy inny sposób.
NS: Ale nadal zajmie im to sekundy, dziesiątki sekund, aby podnieść instancję, przenieść tam Dockera itp.
DS: Dlaczego konieczne jest wywołanie całej instancji? Mamy instancję z 32 rdzeniami, 16... i zmieści się w niej - na przykład cztery. Kiedy zamówimy piątą, instancja zostanie już podniesiona, a następnie zostanie usunięta.
NS: Tak, ciekawe, Kubernetes okazuje się być inną historią. Nasza baza danych nie znajduje się w K8 i mamy jedną instancję. Jednak klonowanie wieloterabajtowej bazy danych zajmuje nie więcej niż dwie sekundy.
DS: To jest świetne. Ale na początku chcę powiedzieć, że nie jest to rozwiązanie ogólne. Tak, jest fajnie, ale nadaje się tylko dla Postgres i tylko na jednym węźle.
NS: Nadaje się nie tylko do Postgresa: te plany, jak opisałem, sprawdzą się tylko w nim. Ale jeśli nie zawracamy sobie głowy planami i potrzebujemy tylko wszystkich danych do testów funkcjonalnych, to jest to odpowiednie dla każdego systemu DBMS.
DS: Wiele lat temu zrobiliśmy coś podobnego w przypadku migawek LVM. To jest klasyk. Podejście to było bardzo aktywnie stosowane. Węzły stanowe są po prostu uciążliwe. Bo nie należy ich porzucać, należy zawsze o nich pamiętać...
NS: Czy widzisz tu jakąś możliwość hybrydy? Powiedzmy, że stateful to jakiś rodzaj kapsuły, działa dla kilku osób (wielu testerów). Mamy jeden wolumin, ale dzięki systemowi plików klony są lokalne. Jeśli kapsuła upadnie, ale dysk pozostanie, kapsuła się podniesie, zliczy informacje o wszystkich klonach, podniesie wszystko jeszcze raz i powie: „Oto twoje klony działające na tych portach, kontynuuj z nimi pracę”.
DS: Z technicznego punktu widzenia oznacza to, że w Kubernetesie jest to jeden pod, w którym uruchamiamy wiele Postgres.
NS: Tak. Ma swoje ograniczenia: powiedzmy, że nie pracuje z nim więcej niż 10 osób jednocześnie. Jeśli potrzebujesz 20, uruchomimy drugi taki zasobnik. W pełni go sklonujemy, po otrzymaniu drugiego pełnego tomu będzie miał te same 10 „cienkich” klonów. Nie widzisz tej szansy?
DS: Musimy tutaj dodać kwestie bezpieczeństwa. Tego typu organizacja implikuje, że ten pod ma wysokie uprawnienia (możliwości), bo może wykonywać niestandardowe operacje na systemie plików... Ale powtarzam: wierzę, że w średnioterminowej perspektywie naprawią pamięć masową w Kubernetesie, a w chmury naprawią całą historię tomami - wszystko „po prostu zadziała”. Będzie zmiana rozmiaru, klonowanie... Jest wolumin - mówimy: „Utwórz na jego podstawie nowy” i po półtorej sekundy dostajemy to, czego potrzebujemy.
NS: Nie wierzę w półtorej sekundy na wiele terabajtów. Na Ceph robisz to sam, ale mówisz o chmurach. Przejdź do chmury, zrób klona wieloterabajtowego woluminu EBS na EC2 i zobacz jaka będzie wydajność. To nie zajmie kilku sekund. Bardzo mnie ciekawi, kiedy osiągną ten poziom. Rozumiem, co mówisz, ale pozwolę sobie inaczej.
DS: Ok, ale powiedziałem, że w perspektywie średnioterminowej, a nie krótkoterminowej. Przez kilka lat.
O operatorze dla PostgreSQL od Zalando
W środku tego spotkania przyłączył się także Alexey Klyukin, były programista z Zalando, który opowiedział o historii operatora PostgreSQL:
Świetnie, że ten temat jest poruszany w ogóle: zarówno Postgres, jak i Kubernetes. Kiedy w 2017 roku zaczęliśmy się tym zajmować w Zalando, był to temat, którym wszyscy chcieli się zająć, ale nikt tego nie zrobił. Każdy miał już Kubernetesa, ale kiedy zapytali, co zrobić z bazami danych, nawet ludzie byli zachwyceni , który głosił K8, powiedział coś takiego:
„Przejdź do usług zarządzanych i korzystaj z nich, nie uruchamiaj bazy danych w Kubernetesie. W przeciwnym razie Twoje K8 zdecydują się na przykład na aktualizację, wyłączą wszystkie węzły, a Twoje dane polecą daleko, daleko.”
Postanowiliśmy zrobić operatora, który wbrew tej radzie uruchomi bazę danych Postgres w Kubernetesie. I mieliśmy dobry powód - . Jest to automatyczne przełączanie awaryjne dla PostgreSQL, wykonane poprawnie, tj. używając etcd, consul lub ZooKeeper jako magazynu informacji o klastrze. Takie repozytorium, które da każdemu, kto zapyta np., kim jest obecny lider, tę samą informację – pomimo tego, że wszystko mamy rozesłane – tak, żeby nie było rozdwojonego mózgu. Poza tym mieliśmy dla niego.
Generalnie potrzeba w firmie automatycznego przełączania awaryjnego pojawiła się po migracji z wewnętrznego sprzętowego centrum danych do chmury. Chmura została oparta o autorskie rozwiązanie PaaS (Platform-as-a-Service). Jest to oprogramowanie typu Open Source, ale jego uruchomienie i uruchomienie wymagało dużo pracy. To się nazywało .
Początkowo nie było Kubernetesa. Dokładniej, kiedy wdrożono nasze własne rozwiązanie, K8 już istniały, ale były tak prymitywne, że nie nadawały się do produkcji. Moim zdaniem był to rok 2015 lub 2016. Do 2017 roku Kubernetes stał się mniej więcej dojrzały – zaistniała potrzeba migracji tam.
I mieliśmy już kontener Docker. Istniał PaaS, który korzystał z Dockera. Dlaczego nie wypróbować K8? Dlaczego nie napisać własnego operatora? Murat Kabilov, który przyszedł do nas z Avito, rozpoczął to jako projekt z własnej inicjatywy – „do zabawy” – i projekt „wystartował”.
Ale ogólnie chciałem porozmawiać o AWS. Dlaczego istniał historyczny kod związany z AWS…
Kiedy uruchamiasz coś w Kubernetesie, musisz zrozumieć, że K8s to praca w toku. Stale się rozwija, udoskonala, a nawet od czasu do czasu załamuje się. Musisz uważnie śledzić wszystkie zmiany w Kubernetesie, musisz być gotowy, aby się w to zagłębić, jeśli coś się wydarzy i dowiedzieć się, jak to działa w szczegółach - być może bardziej, niż byś tego chciał. Dotyczy to w zasadzie każdej platformy, na której uruchamiasz swoje bazy danych...
Tak więc, kiedy wykonaliśmy tę instrukcję, Postgres działał na woluminie zewnętrznym (w tym przypadku EBS, ponieważ pracowaliśmy nad AWS). Baza danych rosła, w pewnym momencie konieczna była zmiana jej rozmiaru: na przykład początkowy rozmiar EBS wynosił 100 TB, baza danych urosła do tego, teraz chcemy, aby EBS miał 200 TB. Jak? Załóżmy, że możesz wykonać zrzut/przywrócenie nowej instancji, ale zajmie to dużo czasu i będzie wymagać przestojów.
Dlatego chciałem zmienić rozmiar, który powiększy partycję EBS, a następnie nakaże systemowi plików użycie nowego miejsca. I zrobiliśmy to, ale Kubernetes nie miał wówczas żadnego API do operacji zmiany rozmiaru. Ponieważ pracowaliśmy na AWS, napisaliśmy kod dla jego API.
Nikt nie zabrania Ci robić tego samego na innych platformach. W stwierdzeniu nie ma żadnej wskazówki, że można go uruchomić tylko na AWS i nie będzie działać na wszystkim innym. Generalnie jest to projekt Open Source: jeśli ktoś chce przyspieszyć pojawienie się wykorzystania nowego API, to serdecznie zapraszamy. Jeść , pull requesty – zespół Zalando stara się dość szybko na nie odpowiadać i promować operatora. Z tego co wiem projekt podczas Google Summer of Code i kilku innych podobnych inicjatywach. Zalando bardzo aktywnie nad tym pracuje.
Bonus PS!
Jeśli interesuje Cię tematyka PostgreSQL i Kubernetes, to proszę również zwrócić uwagę, że w zeszłym tygodniu odbył się kolejny wtorek Postgres, podczas którego rozmawiałem z Nikołajem Alexander Kukushkin z Zalando. Dostępne jest wideo z niego .
PPS
Przeczytaj także na naszym blogu:
- «";
- «";
- «";
- «".
Źródło: www.habr.com