W tym podcaście przyjrzymy się oczekiwanym w Kubernetes 1.31 funkcjom przechowywania danych z Siergiejem Proninem, kierownikiem ds. produktów grupowych w Perconaktóra opracowuje produkty typu open source dla baz danych SQL i NoSQL.
Pronin opowiada o funkcjonalności pamięci masowej oczekiwanej w wydaniu 1.31 z tego tygodnia, ale także tego, co widzi jako pewne luki w zakresie pamięci masowej dla baz danych i ogólniej dla przechowywanie w Kubernetes. Omawia również luki w zakresie zgodności i bezpieczeństwa, które jego zdaniem nadal muszą zostać naprawione w Kubernetes.
Jak podsumowałbyś nadchodzące dodatki do Kubernetesa, które mogą zainteresować osoby zajmujące się przechowywaniem danych?
Siergiej Pronin: Nie sądzę, aby było wiele ulepszeń związanych z przechowywaniem, ponieważ wersja 1.31 była mocno skoncentrowana na poważnym usunięciu starszego kodu. To około 1,5 miliona linii kodu usuniętych z podstawowej bazy kodu, ale ta baza kodu została stworzona głównie dla starszej wersji interfejsy przechowywania kontenerów (CSI) stworzone przez różnych dostawców chmury, a następnie przeniesione do struktury wtyczek. To był główny cel tego wydania.
Istnieją pewne ulepszenia pamięci masowej. Uważam, że największym i najciekawszym dla mnie jest klasa atrybutów woluminów. Umożliwia użytkownikom modyfikowanie istniejących woluminów w locie, np. jeśli chcesz zmienić liczbę IOPS woluminu – wiesz, jak na Amazonie masz woluminy EBS i mają one IOPS. Wcześniej, aby to zrobić w Kubernetes, musiałeś utworzyć nową klasę pamięci masowej, a następnie migrować swoją aplikację do tego nowego woluminu pamięci masowej.
To był dość długi proces. Na razie, przez Kubernetes, możesz po prostu zmienić IOPS dla tego konkretnego woluminu i to wszystko, ale ta funkcja była w wersji alfa, a teraz w 1.31 przechodzi do wersji beta, więc zbliża się do wersji GA lub stabilnej.
To jedna z głównych cech pamięci masowej, która się zmienia. Czy są jakieś inne w 1.31?
Istnieją pewne dodatki do statusu woluminu trwałego. W wersji 1.31 dodano nowy status „status last phase transition time” do trwałe woluminy.
Umożliwia to mierzenie czasu między różnymi stanami trwałego woluminu. Może on być w stanie oczekującym, może być w ruchu, może być w błędzie itd. A teraz, gdy dodano ten ostatni stan czasu przejścia fazy, może być on wykorzystywany przez różnych administratorów klastra do mierzenia różnych celów poziomu usług itd. znacznie łatwiej.
Ponownie, to nie jest ogromna poprawa, ale zdecydowanie jest to coś, na co społeczność czekała od dłuższego czasu. Zwłaszcza administratorzy klastrów, ponieważ trwałe woluminy dojrzewają w środowisku Kubernetes, a czegoś, czego można by się spodziewać od dnia zerowego, nie ma. A teraz to dodano, więc to dobra rzecz.
Czy są jakieś inne dodatki, które można by zgrupować razem z tymi?
Mam kilka, ale nie są one szczególnie poważne i nie znajdują się w stanie Georgia, więc myślę, że nie warto o nich wspominać.
Jakie Twoim zdaniem wyzwania czekają jeszcze osoby, które chcą administrować pamięcią masową w Kubernetesie?
Myślę, że jeden z problemów, które widzę, leży w obszarze automatycznego skalowania i przechowywania. Historycznie rzecz biorąc, Kubernetes został zaprojektowany jako narzędzie do usuwania trudu administratorów, a dla różnych zasobów obliczeniowych, takich jak CPU lub RAM, dość łatwo jest wdrożyć automatyczne skalowanie dla nich.
Jeśli zauważysz, że osiągnąłeś pewien próg, możesz albo dodać więcej węzłów do obrazu, albo wykonać skalowanie pionowe, dodając do kontenera więcej zasobów procesora lub pamięci RAM.
Ale w przypadku pamięci masowej nie jest to tak naprawdę prawdą. Natomiast jeśli spojrzysz na większość dostawców chmury – mam na myśli dostawców chmury publicznej, takich jak Amazon RDS lub Aurora [databases]Na przykład – od samego początku mają automatyczne skalowanie pamięci masowej i dla mnie jest ogromnym zaskoczeniem, że w Kubernetesie nie ma niczego takiego.
Istnieją pewne rozwiązania ad hoc opracowane przez firmy, ale są one albo bardzo ograniczone, albo nie są już utrzymywane. To bardziej jak: „Hej, stworzyłem POC. Teraz, społeczności, rozgryźcie to!”
A dla mnie jako dewelopera różnych [Kubernetes] Operatorzy baz danych, zdecydowanie chcę zapewnić użytkownikom Kubernetes ten sam poziom doświadczenia użytkownika, ponieważ czasami myślą: „OK, jeśli przejdę z tej ładnej Aurory z Amazon do Operators, jakie będą kompromisy?” To jest jeden z nich.
Czy w Kubernetesie dzieją się jakieś zmiany, które zmierzają w tym kierunku, czy też nie ma żadnych zmian?
W Kubernetesie zawsze coś się dzieje w różnych dziedzinach, ale niestety na razie są to tylko dyskusje. Nie widziałem ani jednej linijki kodu stworzonej dla tego.
Poza tym nie jestem w 100% pewien, czy powinno to być napędzane przez społeczność Kubernetes, czy może to być coś w ekosystemie CNCF, np. projekt KedaNa przykład.
Keda to Kubernetes Event-driven Autoscaling. CNCF wyhodował go z inkubatora cloud-native i całkiem skutecznie skaluje obliczenia. Więc pomyślałem, dlaczego nie dodać pamięci masowej? Rozmawialiśmy o tym z nimi jakiś czas temu, ale jeszcze nigdzie się nie ruszyło.
Czy są jeszcze jakieś inne ważne obszary, które Twoim zdaniem wymagają rozwiązania w kontekście Kubernetes w kontekście przechowywania danych?
Myślę, że ogólna standaryzacja sposobu, w jaki różni operatorzy wchodzą w interakcje z pamięcią masową, z pewnością by pomogła. Ale znowu, nie sądzę, że jest to coś, co społeczność Kubernetes powinna rozwiązywać. Powinna to być szersza społeczność, obejmująca różne SIG-i, ponieważ znowu, jeśli spojrzę na to, jak różni operatorzy Kubernetes lub jak różne projekty Kubernetes wchodzą w interakcje z pamięcią masową, niektóre z nich używają zestawów stanowych, większość z nich, niektóre z nich tworzą wdrożenia i montują PVC.
Zatem z technicznego punktu widzenia jest to zupełnie inna sytuacja. Powodem tego jest technologia, na której opiera się ta aplikacja. Może to być na przykład baza danych MySQL lub MongoDB, a w obu przypadkach warto pobawić się z pamięcią masową w nieco inny sposób.
Ale końcowym rezultatem, który powinieneś uzyskać, jest po prostu stabilność. Twoje miejsce do przechowywania powinno być dostępne cały czas, Twoje dane powinny być spójne i powinieneś być w stanie wzbudzić zaufanie użytkowników, że jeśli uruchomisz coś związanego z miejscem do przechowywania w Kubernetes, to po prostu zadziała. To nie jest jakaś magia voodoo.
Będąc w tej dziedzinie od dłuższego czasu, nadal czuję, że nie osiągnęliśmy jeszcze punktu, w którym firmy, przedsiębiorstwa mogłyby śmiało powiedzieć: „Och, tak, uruchamianie baz danych w Kubernetes jest dla nas. Wierzymy, że to droga naprzód”. Nadal jest wiele pytań [like] jak stabilne są rozwiązania, jak solidne są rozwiązania i jakie kompromisy by za sobą pociągnęły?
Czy nadal uważa się, że przechowywanie w Kubernetes jest dość skomplikowane? Czy to masz na myśli?
Tak, cóż, powiedziałbym, że około trzy lub cztery lata temu uruchamianie baz danych w Kubernetes było czymś nowym. Podczas gdy jakieś duże przedsiębiorstwo byłoby na tyle odważne, aby uruchomić bazy danych w K8s [Kubernetes]Teraz widzimy, że cała pamięć masowa w Kubernetesie oraz operatorzy i inne narzędzia w ramach ekosystemu CNCF dojrzewają do obsługi pamięci masowej w Kubernetesie.
Ale to prowadzi do tego, że gdy przedsiębiorstwa zaczynają analizować dane w Kubernetes, chcą zastosować istniejący proces myślowy [about] jak bazy danych powinny wyglądać. Więc dzisiaj uruchamiają coś na maszynach wirtualnych i mają integrację LDAP, różne poziomy szyfrowania, standardy itd. i próbują to rzutować na bazy danych na Kubernetes, których jeszcze nie ma.
Nadal brakuje pewnych funkcji, o których przedsiębiorstwa mogłyby sądzić, że „Och, to powinno być w dniu zero. Dlaczego tego nie ma?” Ale powoli do tego zmierzamy. Powoli nadrabiamy zaległości i uważam, że omówiliśmy aspekty stabilności i wydajności, więc teraz nie widziałbym żadnych problemów dla nikogo z SLA lub z czasem sprawności, jeśli uruchamiają swoje bazy danych w K8s
Jednak jeśli chodzi o bezpieczeństwo i zgodność, istnieją pewne luki, a może nawet pewne trudne funkcje, jak ta, którą opisałem, dotycząca zewnętrznego skalowania. [It’s] nadal nie ma [and] ktoś by się spodziewał, że będzie tam od razu. Więc tak, myślę, że z roku na rok jesteśmy coraz lepsi, ale wciąż jest dużo pracy do wykonania.
Jakie zatem widzisz luki w zakresie zgodności i bezpieczeństwa?
Szyfrowanie danych w stanie spoczynku dla baz danych. Dla niektórych jest dostępne. Dla niektórych, takich jak PostgreSQL, jest to nadal bardziej jak pragnienie. Nie jest dostępne w wersji społecznościowej PostgreSQL. [It’s] tylko w niektórych odmianach przedsiębiorstw, takich jak EnterpriseDB, na przykład, mają to. Rozwidlili to i tak dalej
Podobnie jest z kopiami zapasowymi. Jak na przykład, jak ogólnie podchodzisz do ciągłości biznesowej. Czy szyfrujesz swoje kopie zapasowe, jak są przechowywane itd. Większość operatorów już to rozwiązała, ale na przykład rzeczy takie jak odzyskiwanie po awarii, gdy chcesz uruchomić swoją bazę danych w różnych centrach danych i mieć automatyczne przełączanie awaryjne w ramach swoich SLA; cóż, jeszcze tego nie ma.