Kubernetes o godzinie 10: Trwała pamięć masowa dojrzewa dzięki pomocy Operatorów


Kubernetes ma 10 lat! W połowie 2024 roku przypada 10. rocznica urodzin wiodąca na rynku platforma do orkiestracji kontenerów.

To dekada, która rozpoczęła się od pojawienia się kontenerów jako nowatorskiego sposobu wirtualizacji aplikacji, ale pamięć masowa i ochrona danych praktycznie nie istniały. Teraz Kubernetes oferuje dojrzałą platformę kontenerową dla aplikacji natywnych w chmurze ze wszystkimi funkcjami wymaganymi do przechowywanie danych stanowych.

Pierwszą dekadę Kubernetes upamiętniamy serią wywiadów z inżynierami, którzy pomogli rozwijać Kubernetes i stawić czoła wyzwaniom związanym z przechowywaniem i ochroną danych – w tym wykorzystaniem operatorów Kubernetes – i nie możemy się doczekać przyszłości charakteryzującej się sztuczna inteligencja (AI) obciążenia.

Tutaj Saad Ali, starszy inżynier oprogramowania w firmie Google, która zaprojektowała Kubernetes, opowiada o wczesnych wyzwaniach związanych z pamięcią masową i ochroną danych, swoim zaangażowaniu w interfejs przechowywania kontenerów (CSI) sterowników, rozwiązując zagadkę przechowywania stanowego w elastycznym i przenośnym środowisku oraz o tym, jak operatorzy Kubernetes stanowili ogromny krok naprzód w przełamywaniu tego problemu.

Jaki był rynek, kiedy po raz pierwszy uruchomiono Kubernetes?

Saad Ali: Kiedy Kubernetes został uruchomiony po raz pierwszy, programiści i dostawcy byli bardzo zainteresowani pojemniki ale nie miałem pojęcia od czego zacząć. Doker pobudziło branżę i ułatwiło rozwój, więc było duże zainteresowanie znalezieniem sposobów wykorzystania go przy wdrożeniach na dużą skalę.

Wielu dostawców pamięci masowych czekało z boku, próbując zdecydować, gdzie zainwestować. Kilku dołączyło wcześniej i napisało oryginał wtyczki głośności w drzewie dla Kubernetes, co było zniechęcającym procesem wymagającym sprawdzenia kodu bezpośrednio w podstawowym repozytorium Kubernetes. Biorąc pod uwagę całą niepewność, większość dostawców pamięci masowych przyjęła podejście wyczekiwania. Gdybyśmy nigdy nie pokonali tego wahania, Kubernetes nie byłby tym, czym jest dzisiaj.

Reklama

Jak zaangażowałeś się w przestrzeń dyskową dla Kubernetes?

Ali: Zaangażowałem się w stronę pamięci masowej Kubernetesa, naprawiając kilka problemów związanych z pamięcią masową. W końcu dostałem zadanie naprawienia Warunki wyścigu który istniał od wersji 1.0 na stosie pamięci. Skończyło się na tym, że naciskałem wielka przebudowa stosu cyklu życia woluminów do Kubernetes 1.3, w tym wyodrębnianie logiki dołączania/odłączania z kubeletu i przenoszenie jej do centralnego kontrolera w celu ograniczenia warunków wyścigu. To, wraz z wieloma dodatkowymi poprawkami wielu programistów wprowadzonymi w wielu kolejnych wydaniach, pomogło poprawić stabilność całego podsystemu woluminów.

Zostałem Kubernetes SIG [Special Interest Group] Współprzewodniczący ds. pamięci masowej, a jednym z głównych obszarów moich zainteresowań w kolejnych latach było znalezienie sposobu na zwiększenie rozszerzalności pamięci masowej Kubernetes. Pomogłem uruchomić i rozwinąć interfejs przechowywania kontenerów.

Kiedy zdałeś sobie sprawę, że Kubernetes zajmuje wiodącą pozycję na rynku?

Ali: Pamiętam, że ogólnie słyszałem o Kubernetesie Pokemon Go działał na platformie Kubernetes. To był niesamowity moment i świadomość, że Kubernetes nabiera tempa.

CSI zapewniło dostawcom pamięci masowej wystarczająco wygodne inwestowanie w tworzenie wtyczek i doprowadziło do pozytywnego cyklu – większa liczba dostawców tworzących dla Kubernetes sprawiła, że ​​Kubernetes stał się bardziej użyteczny, zwiększyło wykorzystanie Kubernetes i doprowadziło do tego, że więcej dostawców rozwijało się dla niego

Saad Ali z Google

Dla Magazyn Kubernetesa, kiedy po raz pierwszy zaczęliśmy tworzyć CSI, poszedłem na spotkanie w San Francisco, aby o tym porozmawiać, i jeden z członków publiczności zapytał: „Co sprawia, że ​​ten wysiłek różni się od wielu wcześniejszych wysiłków na rzecz standaryzacji pamięci masowej, których próbowała społeczność OpenStack? Co sprawia, że ​​myślisz, że tym razem będzie inaczej?”

Przypominało to, że sukces nie jest gwarantowany, dlatego wspólnie z CSI podjęliśmy aktywne wysiłki, aby ściśle współpracować ze społecznością pamięci masowej i wieloma koordynatorami kontenerów, budować bardzo metodycznie i stale iterować na CSI i nie nazywać go wersją 1.0, dopóki nie będziemy mieli wielu działających sterowników /integracje.

Dzięki temu dostawcy pamięci masowej byli na tyle wygodni, że mogli inwestować w tworzenie wtyczek, i doprowadziło do pozytywnego cyklu – większa liczba dostawców tworzących rozwiązania dla Kubernetes sprawiła, że ​​Kubernetes stał się bardziej użyteczny, zwiększyło wykorzystanie Kubernetes i doprowadziło do tego, że więcej dostawców opracowywało dla niego rozwiązania. To było kiedy lista sterowników CSI przekroczyło liczbę 100 kierowców i zdałem sobie sprawę, że osiągnęliśmy coś wyjątkowego.

Kiedy przyjrzałeś się Kubernetesowi, jak podszedłeś do danych i pamięci masowej?

Ali: Moim zdaniem poza rozszerzalnością platformy Kubernetes (z integracjami takimi jak CSI) magia pamięci masowej Kubernetes polega na tym, że oddziela ona pamięć blokową/plikową od obliczeń – „oddzielenie problemów” – i sprawia, że ​​obciążenia stanowe są równie elastyczne, jak i niestanowe obciążenia. Kiedy obciążenia stanowe nie musiały już być zakotwiczone w węźle, w którym były udostępniane, samonaprawa stała się łatwiejsza bez interwencji człowieka.

Nawet Kubernetes 1.0 zawierał podstawowy system „wtyczek woluminów w drzewie”, który umożliwiał Kubernetesowi automatyczne podłączanie/formatowanie/montowanie dowolnych woluminów blokowych/plików do podów oraz odmontowywanie/odłączanie ich w miarę przemieszczania się podów między węzłami. Miało to kluczowe znaczenie dla zapewnienia elastyczności planowania dla obciążeń stanowych. Nawet jeśli coś pójdzie nie tak z węzłem obliczeniowym, Twoje dane mogą zostać automatycznie udostępnione w innym węźle bez interwencji człowieka.

Jakie problemy pojawiły się po raz pierwszy w związku z danymi i pamięcią masową w Kubernetes?

Ali: Podstos pamięci masowej Kubernetes jest niezwykle skomplikowany. Pierwotnie mieliśmy do czynienia z wieloma warunkami wyścigowymi. Jednym z największych wyzwań związanych ze stosem pamięci masowej jest konieczność radzenia sobie z najgorszym możliwym kompromisem pomiędzy automatycznym odzyskiwaniem a potencjalną utratą i uszkodzeniem danych. Żadne z tych wyników nie jest akceptowalne, dlatego Kubernetes SIG Storage włożył wiele wysiłku w zidentyfikowanie i zapewnienie płynnego odzyskiwania danych z takich przypadków brzegowych.

Magia pamięci masowej Kubernetes polega na tym, że oddziela ona pamięć blokową/plikową od obliczeń i sprawia, że ​​obciążenia stanowe są tak elastyczne, jak obciążenia niestanowe

Saad Ali z Google

Co musiało się zmienić?

Ali: Pierwotnie stos pamięci masowej Kubernetes zakładał, że administrator pamięci masowej wstępnie udostępni pulę woluminów bloków/plików o różnych rozmiarach, z których będą mogli korzystać operatorzy aplikacji. Prowadziło to do nieefektywnego wykorzystania dostępnej pojemności pamięci masowej.

Firma SIG Storage wprowadziła koncepcję dynamicznego udostępniania w Kubernetes 1.6. Stanowiło to przełom w zakresie użyteczności przechowywania bloków/plików na dużą skalę i zakończyło automatyzację cyklu życia woluminów pamięci masowej, ponieważ udostępniało pamięć masową na żądanie w zależności od obciążenia, eliminowało interwencję człowieka i umożliwiało efektywne wykorzystanie pojemności pamięci masowej.

Co wydarzyło się wokół operatorów Kubernetes, co sprawiło, że odnieśli sukces w zakresie danych i pamięci masowej?

Ali: Jak bloki konstrukcyjne wskoczyło na swoje miejsce – interfejsy StorageClass, PersistentVolumeClaim (PVC) i PersistentVolume (PV), CSI, dynamiczne dostarczanie – w centrum uwagi znalazła się orkiestracja prymitywów stanowych wyższego poziomu.

Kubernetes oferował zestawy StatefulSets jako element składowy obciążeń stanowych. Okazało się jednak, że wiele złożonych aplikacji stanowych wymaga dalszej, starannej orkiestracji danych, aby umożliwić replikację, skalowanie i tak dalej.

W tym miejscu wkroczyli Operatorzy Kubernetes. Zaproponowali łatwy sposób rozszerzenia Kubernetes, aby umożliwić operacje uwzględniające aplikacje, takie jak sharding danych w celu zapewnienia wysokiej dostępności, unikając jednoczesnej niedostępności wszystkich replik i tak dalej.

W jaki sposób wspierało to podejście bardziej natywne w chmurze? Jakie były konsekwencje?

Ali: Stos pamięci masowej Kubernetes wraz z Operatorami Kubernetes umożliwiają naprawdę elastyczne wykorzystanie dostępnych zasobów obliczeniowych. Moim zdaniem to jest sedno tego, co oznacza budowanie w chmurze – posiadanie dużej, elastycznej puli zasobów obliczeniowych, z których można korzystać przy wszystkich obciążeniach, na żądanie, skalowanie w górę i w dół bez interwencji człowieka w celu maksymalizacji dostępność i obniżenie kosztów.

W wieku 10 lat Kubernetes zaczyna przypominać Linuksa do przetwarzania rozproszonego. To potężne i rozszerzalne narzędzie typu open source, które zostało powszechnie przyjęte i stanowi kluczowy element nowoczesnej rozproszonej infrastruktury obliczeniowej

Saad Ali z Google

Kubernetes ma już 10 lat. Jak o tym myślisz dzisiaj?

W wieku 10 lat Kubernetes zaczyna przypominać Linuksa do przetwarzania rozproszonego. Jest to potężne i rozszerzalne narzędzie typu open source, które zostało powszechnie przyjęte i stanowi kluczowy element nowoczesnej rozproszonej infrastruktury obliczeniowej.

Jakie problemy nadal istnieją wokół Kubernetes, jeśli chodzi o dane i pamięć masową?

Ali: Kubernetes znacznie ułatwił tworzenie przenośnych, skalowalnych aplikacji stanowych, które wykorzystują pamięć blokową i plikową. Jednak pamięć masowa nadal stanowi wyzwanie dla wielu programistów, którzy nie chcą się martwić sposobem działania różnych baz danych, różnicami między replikacją asynchroniczną i synchroniczną, kompromisem między różnymi profilami nadmiarowości pamięci masowej i tak dalej.

Być może nie jest to problem Kubernetesa do rozwiązania, ale jako branża musimy ułatwić tworzenie aplikacji stanowych wszystkim programistom o różnej skali, redundancji i wymaganiach dotyczących wydajności, przy jednoczesnym zachowaniu przenośności niezależnej od dostawcy.

Jakieś inne anegdoty lub informacje, którymi chcesz się podzielić?

Ali: Projekty open source, takie jak Kubernetes, są możliwe dzięki wielu niesamowitym współpracownikom z całego świata. Wymagają ciągłej konserwacji i udoskonalania. Zachęcam wszystkich zainteresowanych do przyłączenia się do nas. Jeśli interesuje Cię przechowywanie danych, dołącz Pamięć Kubernetes SIG. Jeśli interesują Cię dane, dołącz do Dane na Kubernetesie wspólnota. Zaangażuj się i pomóż nam wprowadzać ulepszenia nowej generacji.



Source link

Advertisment

Więcej

Advertisment

Podobne

Advertisment

Najnowsze

Gwiezdne Wojny: Największym i najdziwniejszym jajkiem wielkanocnym Akolity jest Jedi Plo Koon

Nowa seria Gwiezdnych Wojen od Lucasfilm Akolita ma zasłużył na pochwałę za zwykłe istnienie poza sagą Skywalker – po 47...

Oto, jak przygotować komputer Mac na system macOS Sequoia za pomocą narzędzia CleanMyMac X

Obraz: CleanMyMac X Nowy system MacOS Sequoia firmy Apple oficjalnie pojawi się jesienią, więc Wyczyść MyMaca X udzielił nam świetnych rad, jak najlepiej przygotować...

Tożsamość Mistrza Sithów z „Akolity” jest już całkiem jasna

Akolita utrzymuje w tajemnicy tożsamość tajemniczego Mistrza Sithów, ale – naszym skromnym zdaniem – nie może być to jaśniejsze. Przez...
Advertisment