Kubernetes ma 10 lat! W połowie 2024 roku przypadają 10. urodziny wiodąca na rynku platforma do orkiestracji kontenerów. Ale według eksperta ds. relacji z programistami DataStax Patrick McFadinPlatforma orkiestracji kontenerów znajduje się w fazie „grzecznego nastolatka”, a pewne wyzwania w zakresie efektywności zarządzania wciąż czekają na rozwiązanie.
Wspomina również, jak Kubernetes, znany również jako K8s, przezwyciężył początkowe trudności i wierzy, iż przetrwa jeszcze jakiś czas.
Początki Kubernetesa rozpoczęły się wraz z pojawieniem się kontenerów jako nowego sposobu wirtualizacji aplikacji, ale wraz z funkcjonalność przechowywania i ochrony danych co praktycznie nie istniało. Teraz Kubernetes oferuje dojrzałą platformę kontenerową dla aplikacji chmurowych ze wszystkim, co jest wymagane do przechowywanie danych stanowych.
Obchodzimy pierwszą dekadę Kubernetesa serią wywiadów z inżynierami, którzy pomogli opracować Kubernetesa i stawić czoła wyzwaniom w zakresie przechowywania i ochrony danych – w tym wykorzystaniu operatorów Kubernetesa – patrząc w przyszłość charakteryzującą się sztuczna inteligencja (AI) obciążenia.
Oto Patrick McFadin, wiceprezes ds. relacji z deweloperami w Baza danych NoSQL specjalista DaneStaxopowiada o tym, jak Kubernetes stał się jednym z wielu narzędzi do koordynacji kontenerów, o tym, kiedy zdał sobie sprawę, iż „Kubernetes po prostu wygrał”, o przeszkodach na drodze do wydajnego przechowywania danych oraz o roli StatefulSet i operatorów zapewniających programowalną automatyzację dla przechowywania danych i innych usług.
Jak wyglądał rynek, gdy Kubernetes po raz pierwszy wystartował?
Kiedy Kubernetes pojawił się po raz pierwszy, wokół orkiestracji kontenerów było wielu graczy. Był Docker Swarm i Apache Mesos, który został zaprojektowany do obsługi dużych obciążeń analitycznych. Kubernetes pojawił się z jednym powodem do sławy – pochodził od Google. Kwestia zarządzania dużą infrastrukturą była wyraźnym problemem, który ludzie próbowali rozwiązać, więc rynek był gotowy na dobre rozwiązanie.
Jak zaczęła się Twoja przygoda z pracą nad infrastrukturą danych opartą na Kubernetesie?
Praca nad dużą rozproszoną bazą danych umieściła mnie w samym środku pracy nad wyzwaniami operacyjnymi dla użytkowników. Można zarządzać kilkoma serwerami bez wielu narzędzi, ale to odpada, gdy skalujesz powyżej 10, 100 lub 1000 węzłów. Mesos dobrze pasował do Apache Cassandra i dlatego zacząłem pracować nad tym projektem. Pracowałem również nad Apache Spark, który dobrze pasował do Mesos. W tym czasie Kubernetes stawał się dobrze znany jako menedżer kontenerów dla front-endów, więc w społeczności infrastruktury back-endowej nie miał aż tak dużego wpływu.
Jak zorientowałeś się, iż Kubernetes jest liderem na rynku?
Podczas konferencji zorganizowanej w 2017 r. przez Mesosphere, firmę dostarczającą wersję korporacyjną Mesos, CEO i współzałożyciel Ben Hindman ogłosił wsparcie Mesos dla Kubernetes. To był moment olśnienia. Odwróciłem się do osoby siedzącej obok mnie i powiedziałem: „Kubernetes po prostu wygrał”. Trochę to trwało, ale to był jeden z punktów zwrotnych, które dostrzegłem.
Kiedy przyglądałeś się Kubernetesowi, jakie było Twoje podejście do danych i przechowywania danych?
To był główny problem między Mesos i Kubernetes. Mesos był znacznie lepszy w zarządzaniu zasobami pamięci masowej. Kubernetes początkowo traktował pamięć masową jako coś drugorzędnego, a gdy baza danych opiera się na pamięci masowej wysokiej jakości, było to okropne dopasowanie. Unikanie Kubernetesa w przypadku obciążeń danych było najlepszym podejściem przez długi czas.
Jakie pierwsze problemy związane z danymi i przechowywaniem danych w Kubernetesie wystąpiły u Ciebie?
Dostarczanie i jakość. Kubernetes początkowo traktował pamięć masową jako ulotną, co oznaczało, iż gdy tylko kontener został usunięty, cała pamięć masowa zniknęła. Nie jest to dobre dla baz danych. Istniało kilka sztuczek w utrzymywaniu danych od ponownego uruchomienia do ponownego uruchomienia, ale żadne nie zostały wbudowane w Kubernetes. Wówczas, będąc woluminami kontenerów, wydajność pozostawiała wiele do życzenia. Ogólnie rzecz biorąc, było wiele problemów, które powstrzymywały poważnych użytkowników przed wskoczeniem.
Co musiało się zmienić?
Pierwszą rzeczą do zrobienia była zmiana sposobu obsługi pamięci masowej. Kubernetes wprowadził StatefulSet, który całkowicie zmienił sposób, w jaki pamięć masowa była aprowizowana. Modelował to, co było potrzebne dla serwera stanowego, takiego jak baza danych. Następną dużą zmianą było dodanie operatorów. Ponieważ serwery były dodawane do systemu, który kontrolował provisioning, potrzebny był sposób na tłumaczenie poleceń, takich jak „start” i „stop”. Operatorzy tworzyli warstwę translacyjną między Kubernetes a ustalonymi usługami, które były wprowadzane.
Jak zaczęła się Twoja przygoda z Kubernetes Operators?
Społeczność Data on Kubernetes wykonała mnóstwo pracy, aby ta koncepcja stała się czymś, w co ludzie byli gotowi uwierzyć. Kiedy zaczynaliśmy, otrzymywaliśmy opinie, które mówiły: „Umieścić moje dane w Kubernetes? Jesteście wściekli?”. Ale widzieliśmy też wielu deweloperów mówiących: „Chcę, aby wszystko było w jednym miejscu, więc spraw, aby to działało”. Z czasem ten wysiłek społeczności odniósł sukces. Myślę, iż 2022 był punktem zwrotnym, w którym zobaczyliśmy więcej osób chętnych do uruchamiania swoich danych w Kubernetes niż nie. Było to oparte na wysiłkach na rzecz tworzenia operatorów wysokiej jakości.
Co wydarzyło się w firmie Operators, iż odniosła ona sukces w zakresie gromadzenia i przechowywania danych?
Operatorzy rozwiązywali ogromny problem i byli prości w montażu. Wiele osób składało własnych operatorów – to było tak, jakby co drugi weekend pojawiał się kolejny operator dla projektów. To było świetne, ale oznaczało to wiele rozłamów z porzuconymi projektami, które wykonywały podstawy, ale nie współpracowały. Każdy chciał być tym, który składa operatora, więc skończyło się na wielu, które wykonywały to samo, ale w bardzo nieznacznie odmienny sposób.
Widzieliśmy to w społeczności Apache Cassandra. Myślę, iż w pewnym momencie było około 12 różnych operatorów jednocześnie i wszyscy byli dobrzy w konkretnych rzeczach. Ale nie skorzystaliśmy na współpracy ze sobą i ulepszaniu rzeczy. Trochę czasu zajęło społeczności zebranie się i uzgodnienie, czego chcemy, nad czym chcemy pracować i jak to zrobić razem. Ale kiedy to się zaczęło, myślę, iż zrobiło to ogromną różnicę.
W jaki sposób wspierało to więcej podejść chmurowych? Jakie były konsekwencje?
Myślę, iż pomogło to w ogólnym podejściu do aplikacji chmurowych, ponieważ można było uruchamiać aplikacje i infrastrukturę w tym samym miejscu i spójnie zarządzać wszystkim. Kiedy masz mikrousługi i kontenery, chcesz móc skalować i przenosić rzeczy, kiedy tego potrzebujesz, zamiast być przywiązanym do tego, co masz. Kiedy można to zrobić również dla bazy danych, po prostu wszystko stało się prostsze. A kiedy można było zacząć od testowania, łatwiej było wykazać, iż to działa i można było przejść do produkcji. To cały argument dotyczący grawitacji danych. Widzieliśmy, jak dane są przenoszone do pamięci masowej wokół wirtualizacji i widzieliśmy, jak więcej danych jest przenoszonych do chmury wraz z aplikacjami, więc naturalne jest, iż widziałeś to również w przypadku chmurowych aplikacji i kontenerów.
DataStax zbudował swoją Cassandrę jako usługę, Astra DB, na Kubernetes. Myślę, iż to jest najsilniejsze poparcie, jakie mogę jej dać
Kubernetes ma już 10 lat. Co o tym myślisz dzisiaj?
Myślę, iż wiele osób uważa, iż Kubernetes jest skończony i iż wszystko będzie się dalej rozwijać. Ja tak nie uważam. Myślę, iż jesteśmy w fazie zrzędliwego nastolatka i wciąż jest wiele rzeczy, nad którymi trzeba popracować. Ale to stabilny system, na którym można polegać. DataStax zbudował swoją Cassandrę jako usługę, Astra DB, na Kubernetes. Myślę, iż to chyba najsilniejsze poparcie, jakie mogę mu dać.
Jakie problemy przez cały czas występują w kontekście Kubernetesa w kontekście danych i przechowywania danych?
Dojrzałość projektu będzie w wydajności. przez cały czas potrzeba dużo wysiłku manualnego, aby płynnie uruchomić wdrożenie Kubernetes. Skalowanie w górę jest łatwe, ale skalowanie w dół jest trudne, do tego stopnia, iż rzadko się to robi. GenAI [generative artificial intelligence] bez wątpienia pojawi się tutaj jako pomysł AIOps [artificial intelligence for IT operations] zyskuje na znaczeniu. Wyjaśnienie, czego chcesz z punktu widzenia aplikacji i zobaczenie, jak powstaje infrastruktura, będzie wydawać się magią, ale tak naprawdę to tylko postęp.
