Kubernetes ma 10 lat! W połowie 2024 roku przypadają 10. urodziny wiodąca na rynku platforma do orkiestracji kontenerów. Jednak, jak twierdzi Siergiej Pronin, kierownik ds. produktów grupowych w firmie Percona, która opracowuje produkty typu open source dla baz danych SQL i NoSQL, nie zawsze tak było.
Pronin wspomina wczesne lata, kiedy Kubernetes pojawił się na rynku, będąc w zasadzie ograniczonym do orkiestracji aplikacji bezstanowych, z funkcjonalność przechowywania i ochrony danych który praktycznie nie istniał.
On również był zwolennikiem „Kubernetes dla bezstanowości”. Jednak z czasem, wraz z dodaniem funkcjonalności usług stanowych za pośrednictwem Kubernetes Operators i StatefulSet, platforma orkiestracji stała się miejscem docelowym dla deweloperów, którzy chcieli dojrzałej platformy kontenerowej 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 – i patrzymy w przyszłość charakteryzującą się sztuczna inteligencja (AI) obciążenia.
Jak wyglądał rynek, gdy Kubernetes po raz pierwszy wystartował?
Siergiej Pronin: Ponieważ organizacje coraz częściej przyjmowały architekturę mikrousług, istniała potrzeba wydajnego zarządzania i skalowania dużej liczby kontenerów. Wdrożenia i skalowanie kontenerów były wykonywane manualnie, co było podatne na błędy i czasochłonne, więc istniało zapotrzebowanie na zautomatyzowane narzędzia do orkiestracji.
W 2014 r. Kubernetes wszedł na rynek orkiestracji kontenerów, który tętnił potencjałem, ale brakowało mu wyraźnego lidera. Docker zapoczątkował rewolucję kontenerów, ale zarządzanie kontenerami w skalowaniue pozostała skomplikowaną zagadką. Opcje takie jak Apache Mesos istniały, ale były często nieporęczne i wymagały specjalistycznej wiedzy.
Jak zaczęła się Twoja przygoda z pracą nad infrastrukturą danych opartą na Kubernetesie?
Pronina:Wtedy kierowałem wieloma zespołami inżynierów budującymi różne rozwiązania platform-as-a-service. Deweloperzy zawsze chcą usuwać trud poprzez automatyzację, a uproszczenie orkiestracji było czymś, czego każdy chciał. Kubernetes nie był tak wyrafinowany, jak jest dzisiaj, ale powoli zyskiwał popularność w społeczności.
Ciekawość otwiera wiele drzwi i za jednymi z nich zobaczyłem Kubernetesa. Kiedy spojrzałem na to, co było w to zaangażowane, pomyślałem, iż to projekt, który powinienem śledzić. Nie wiedziałem, jak bardzo będzie to częścią mojej przyszłej kariery.
Jak zorientowałeś się, iż Kubernetes jest liderem na rynku?
Pronina: To nie było dla mnie nagłe uświadomienie. Stało się to powoli. Rozwiązania takie jak Apache Mesos, Docker Swarm, a choćby AWS ECS (Elastic Container Service) były szeroko stosowane. Powodem zwycięstwa Kubernetesa jest społeczność. Jego wtykowa architektura i szybki rozwój napędzały jego adopcję i powoli pochłaniały udziały rynkowe innych rozwiązań.
Kiedy przyglądałeś się Kubernetesowi, w jaki sposób podchodziłeś do danych?
Pronina:Przez długi czas Kubernetes był dla mnie przeznaczony tylko do aplikacji bezstanowych. Mieliśmy choćby dość rygorystyczne standardy jakości na naszych platformach, gdzie nie zezwalaliśmy na aplikacje stanowe w Kubernetes. To było Aplikacja 12 faktorów myślenie w najlepszym wydaniu na temat tego, jak projektować i budować skalowalne i odporne aplikacje chmurowe. Jedną z podstawowych zasad jest traktowanie usług zaplecza, w tym baz danych, jako zasobów dołączonych, w celu promowania projektowania aplikacji bezstanowych.
Jakie pierwsze problemy związane z danymi i przechowywaniem danych w Kubernetesie wystąpiły u Ciebie?
Pronina: Największym problemem była niedojrzałość. Dostarczanie trwałych woluminów było jak święta wiedza, znana tylko nielicznym, nie w pełni zautomatyzowana i dostępna poprzez pewne podstawowe hakowanie. Integracja z dostawcami pamięci masowej nie istniała, co oznaczało, iż doświadczenie użytkownika było dość toporne.
Następnie w 2019 r. AWS EKS (Elastic Kubernetes Service) oficjalnie zaczął obsługiwać AWS EBS (Elastic Block Storage). To może być kamień milowy, który zaczął zmieniać postrzeganie.
Co musiało się zmienić?
Pronina:Wydanie Stateful Sets and Operators nastąpiło trzy lata po pierwszym wydaniu, więc przygotowanie Kubernetesa zajęło trochę czasu. Po ich wydaniu przez cały czas trzeba było przezwyciężyć niechęć do ich wdrożenia. Potrzeba było wielu testów, aby pokonać tę przeszkodę, zanim byliśmy gotowi zmienić nasze zasady.
Jak zaczęła się Twoja przygoda z operatorami Kubernetes?
Pronina:Dołączyłem do Percona 3,5 roku temu, aby poprowadzić zespół zarządzania produktem odpowiedzialny za operatorów i wdrożenia aplikacji w chmurze. Wtedy było to zupełnie nowe pole, z dużą dozą niepewności i stosunkowo małą społecznością. Wierzyłem w „Kubernetes dla bezstanowych”, więc zrozumienie tej idei było nie lada wyzwaniem. Zespół kierowniczy Percona dostrzegł okazję i wyczuł trend rynkowy na długo przed tym, zanim stał się on głównym nurtem.
Co wydarzyło się wokół operatorów, iż odnieśli sukces w zakresie danych i przechowywania danych?
Pronina:To kombinacja zdarzeń.
W erze mikrousług użytkownicy próbowali uruchamiać bazy danych w kontenerach Docker, poza Kubernetes. Jest to złożone zadanie, zwłaszcza jeżeli wdrożeń jest klastrowanie, które może być potrzebne w przypadku baz danych.
Kubernetes stawał się de facto standardem do uruchamiania mikrousług i budowania platform. Opisywano go jako „platformę do budowania platform” i myślę, iż ta definicja jest teraz trafna.
Kubernetes obiecał rozwiązać niektóre problemy ze złożonością, ale zarządzanie bazami danych jest trudne. Poznanie wszystkich prymitywów Kubernetes i zrozumienie koncepcji jest dla odważnych. Operatorzy abstrahowali całą tę złożoność i znacznie obniżyli barierę wejścia.
Co więcej, Operatorzy rozwiązali problem operacji drugiego dnia. To właśnie stąd bierze się większość złożoności bazy danych – zadania takie jak bieżąca konserwacja, uaktualnienia, tworzenie kopii zapasowych i przywracanie, bezpieczeństwo itd. Kubernetes może pomóc w zwiększeniu szybkości wdrażania infrastruktury, ale nie może przejąć zapytania do bazy danych za Ciebie.
W jaki sposób wspierało to więcej podejść chmurowych? Jakie były konsekwencje?
Pronina:Operatorzy – zwłaszcza w przypadku baz danych – dodatkowo wzmocnili Kubernetesa i ekosystem CNCF i ułatwiło wdrażanie rozwiązań open source.
Uzależnienie od dostawcy było problemem w chmurze publicznej, podczas gdy Kubernetes zapewniał sposób uruchamiania aplikacji w dowolnym miejscu przy użyciu jednolitego interfejsu API. Kubernetes wykazał, iż może doskonale działać w przypadku aplikacji bezstanowych i z operatorami, więc bazy danych również miały szansę działać w ten sam sposób.
Kubernetes ma już 10 lat. Co o tym myślisz dzisiaj?
Pronina: W ciągu ostatnich 10 lat Kubernetes stał się standardem branżowym i fundamentalnie zmienił sposób tworzenia i wdrażania aplikacji. Jego wpływ jest niezaprzeczalny. Wspierał innowacje i napędzał rozwój architektury mikrousług.
Podczas gdy wyzwania takie jak złożoność i bezpieczeństwo przez cały czas istnieją, przyszłość Kubernetesa jest świetlana. Rosnąca społeczność i wszystkie innowacje, które mają miejsce, zapewnią, iż pozostanie on podatny na nowe trendy.
Jakie problemy przez cały czas występują w kontekście Kubernetesa w kontekście danych i przechowywania danych?
Pronina: Złożoność przez cały czas jest problemem, choćby gdy operatorzy ułatwiają zarządzanie danymi i zasobami pamięci masowej. Wynika to głównie z braku standaryzacji w różnych interfejsach pamięci masowej kontenerów (CSI) i zawiłości integracji z różnymi dostawcami pamięci masowej.
Zarządzanie danymi i pamięcią masową w wielu chmurach lub środowiskach hybrydowych może być trudne ze względu na różnice w interfejsach API pamięci masowej i konfiguracjach. Istnieją różne próby uproszczenia tego poprzez federację lub płaszczyzny sterowania wieloma klastrami.
Silniki baz danych, takie jak MySQL lub PostgreSQL, zostały zaprojektowane na długo przed mikrousługami. Inżynierowie dostosowali je do działania w Kubernetes, ale czasami wymaga to obejścia hacków, aby działały.
Czy masz jeszcze jakieś anegdoty lub informacje, którymi chciałbyś się podzielić?
Pronina: Operatorzy i bazy danych w Kubernetes gwałtownie przeszli od hacków greenfield, aby wszystko działało, do poziomu klasy korporacyjnej. Teraz chodzi bardziej o „jak” niż „dlaczego” w organizacjach różnych szczebli. Dane w Kubernetes nie są już „tylko dla odważnych”. Są głównym nurtem.
