Pod koniec maja mityng online na temat . Rozmawialiśmy o kontenerach, Kubernetes i orkiestracji ogólnie, o kryteriach wyboru infrastruktury i wielu innych kwestiach. Uczestnicy podzielili się przypadkami ze swojej praktyki.
Uczestnicy:
- Eugeniusz Potapow, CEO „ITSumma”. Ponad połowa jego klientów już przeszła lub planuje przejść na Kubernetes.
- Dmitrij Stoljarow, CTO „Flant”. Posiada ponad 10-letnie doświadczenie w systemach kontenerowych.
- Denis Remczukow (aka Eric Oldmann), COO argotech.io, ex-RAO EES. Obiecał podzielić się przypadkami z „krwawego” przedsiębiorstwa.
- Andriej Fiodorowski, CTO „News360.com”Po zakupie firmy przez innego gracza odpowiada za szereg projektów ML i AI oraz za infrastrukturę.
- Iwan Krugłow, inżynier systemowy, ex–Booking.com.To ten człowiek, który własnoręcznie wiele zdziałał z Kubernetes.
Tematy:
- Spostrzeżenia uczestników na temat kontenerów i orkiestracji (Docker, Kubernetes i inne); co próbowali w praktyce lub analizowali.
- Przykład: W firmie opracowują plan rozwoju infrastruktury na lata. Jak podejmowana jest decyzja, czy budować (lub przenosić aktualną) infrastrukturę na kontenerach i Kubernetes, czy nie?
- Problemy w świecie cloud-native, czego brakuje, zastanówmy się wspólnie, co przyniesie jutro.
Zawiązała się interesująca dyskusja, opinie uczestników okazały się tak różne i wywołały tyle komentarzy, że warto się nimi z wami podzielić. Mamy , a poniżej – podsumowanie dyskusji.
Kubernetes to już standard czy znakomity marketing?
„Do niego (Kubernetes. — Red.) dotarliśmy w czasach, gdy nikt jeszcze o nim nie wiedział. Dotarliśmy do niego, gdy go jeszcze nie było. Chcieliśmy go jeszcze wcześniej” — Dmitrij Stoljarow
Zdjęcie z Reddit.com
5-10 lat temu istniało mnóstwo narzędzi, i nie było jednego standardu. Co pół roku pojawiał się nowy produkt, a czasami nawet więcej. Najpierw Vagrant, potem Salt, Chef, Puppet,… „i co pół roku musisz na nowo budować swoją infrastrukturę. Masz pięciu administratorów, którzy cały czas zajmują się przepisywaniem konfiguracji” — wspomina Andriej Fiodorowski. Uważa, że Docker i Kubernetes „zdominowały” resztę. Docker stał się standardem w ciągu ostatnich pięciu lat, Kubernetes — w ciągu ostatnich dwóch. I to dobrze dla branży..
Dmitrij Stolarow i jego zespół uwielbiają Kubernetesa. Chcieli tego narzędzia, jeszcze zanim się pojawiło, i dotarli do niego, kiedy nikt o nim nie wiedział. Obecnie, z powodów wygody, nie przyjmują klientów, jeśli zdają sobie sprawę, że nie wdrożą u nich Kubernetesa. Przy tym, według słów Dmitrija, firma ma "wiele ogromnych success story związanych z przekształcaniem okropnego legacy".
Kubernetes to nie tylko orkiestracja kontenerów, to system zarządzania konfiguracją z rozwiniętym API, komponentem pracy z siecią, balansowaniem L3 i kontrolerami Ingress, który pozwala stosunkowo łatwo zarządzać zasobami, skalować i abstrahować od dolnych warstw infrastruktury.
Niestety, w naszym życiu za wszystko trzeba płacić. A ten podatek jest duży, zwłaszcza gdy mówimy o przejściu na Kubernetesa w firmie z rozwiniętą infrastrukturą, jak uważa Iwan Krugłow. Mógłby pracować zarówno w firmie z tradycyjną infrastrukturą, jak i z Kubernetesem. Głównie chodzi o zrozumienie specyfiki firmy i rynku. Ale, na przykład, dla Jewgienija Potapowa, który sprowadziłby Kubernetesa do każdego narzędzia orkiestracji kontenerów, takie pytanie nie istnieje.
Jewgienij porównał to do sytuacji z lat 90., kiedy pojawiło się programowanie obiektowe jako sposób programowania skomplikowanych aplikacji. Wówczas debaty nie ustawały, a nowe narzędzia wspierające OOP wciąż się pojawiały. Następnie pojawiły się mikroserwisy jako sposób odejścia od monolitycznej koncepcji. To z kolei doprowadziło do powstania kontenerów i narzędzi do ich zarządzania. "Myślę, że szybko dojdziemy do momentu, w którym pytanie, czy pisać mikroserwisowo małą aplikację, będzie pisane domyślnie jako mikroserwis," uważa on. Podobnie, Docker i Kubernetes z czasem staną się standardowym rozwiązaniem, bez potrzeby wyboru.
Problem baz w stateless
Photo by
W dzisiejszych czasach można znaleźć wiele przepisów na uruchamianie baz danych w Kubernetsie. Nawet jak oddzielić część działającą z dyskiem I/O od, powiedzmy, aplikacji — części bazy. Czy w przyszłości bazy danych mogą się zmienić na tyle, że będą dostarczane w pudełku, gdzie jedna część będzie orkiestrując przez Dockera i Kubernetesa, a w drugiej części infrastruktury, przez osobne oprogramowanie, będzie dostarczana część storage? Czy bazy zmienią się jako produkt?
To opis przypomina zarządzanie kolejkami, ale wymagania dotyczące niezawodności i synchronizacji informacji w tradycyjnych bazach danych są znacznie wyższe, uważa Andriej. Cache hit ratio w normalnych bazach utrzymuje się na poziomie 99%. Jeśli worker zawiedzie, uruchamia się nowy, a cache "rozgrzewa się" od zera. Dopóki cache nie jest rozgrzany, worker działa wolno, co oznacza, że nie można na niego wprowadzać obciążenia. Dopóki nie ma obciążenia użytkownika, cache się nie rozgrzewa. To błędne koło.
Dmitrij zdecydowanie się nie zgadza — kworum i shardowanie rozwiązują problem. Ale Andriej twierdzi, że rozwiązanie nie pasuje do wszystkich. W niektórych sytuacjach kworum może być odpowiednie, ale generuje dodatkowe obciążenie sieci. Baza NoSQL nie nadaje się w każdej sytuacji.
Uczestnicy meetup podzielili się na dwa obozy.
Denis i Andriej twierdzą, że wszystko, co zapisuje na dysk — bazy i inne — w obecnym ekosystemie Kubera jest niemożliwe do zrealizowania. Nie można zagwarantować integralności i spójności danych produkcyjnych w Kubernetesa. To fundamentalna cecha. Rozwiązanie: infrastruktura hybrydowa.
Nawet nowoczesne bazy cloud native, takie jak MongoDB i Cassandra, czy kolejki wiadomości, jak Kafka lub RabbitMQ, wymagają stałych magazynów danych poza Kubernetesa.
Jewgienij protestuje: „Bazy w Kubercie to trauma okołorosyjska lub okołenterprise'owa, związana z tym, że w Rosji nie ma adopcji chmur”. Małe lub średnie firmy na Zachodzie korzystają z chmury. Łatwiej jest korzystać z baz Amazon RDS niż samodzielnie męczyć się z Kubernetesa. W Rosji używają Kubernetesa „on-premise” i przenoszą do niego bazy, kiedy próbują pozbyć się złożonej infrastruktury.
Dmitrij również nie zgodził się z twierdzeniem, że żadnych baz nie można trzymać w Kubernetesa: „Baza bazie nie równa. I jeśli włożyć gigantyczną bazę relacyjną — to w żadnym wypadku. Jeśli włożyć coś niewielkiego i cloud native, co moralnie jest gotowe na półefemeryczne życie, wszystko będzie dobrze.” Dmitrij wspomniał także, że narzędzia do zarządzania bazami nie są gotowe ani na Dockera, ani na Kubernetesa, dlatego pojawiają się ogromne trudności.
Iwan jest przekonany, że nawet abstrahując od pojęć stateful i stateless, ekosystem rozwiązań enterprise w Kubernetes nie jest jeszcze gotowy. Z Kubernetes trudno jest spełnić wymagania organów legislacyjnych i regulacyjnych. Na przykład, niemożliwe jest stworzenie rozwiązania do zarządzania tożsamością, które wymaga ścisłych gwarancji identyfikacji serwera, aż do sprzętu, które jest zamontowane w serwerach. Ta dziedzina się rozwija, ale jak dotąd nie ma rozwiązania.
Uczestnikom nie udało się dojść do porozumienia, dlatego w tej części wniosków nie zostanie przedstawione podsumowanie. Lepiej podamy kilka praktycznych przykładów.
Przykład 1. Cyberbezpieczeństwo „mегарегulatora” z bazami danych poza Kubernetes
W przypadku rozwiniętej systemu cyberbezpieczeństwa, zastosowanie kontenerów i orkiestracji pozwala na obronę przed atakami i włamaniami. Na przykład, w jednym z mегарегulatorów Denis i jego zespół zrealizowali połączenie orkiestratora z wytrenowanym serwisem SIEM, który analizuje logi w czasie rzeczywistym i określa przebieg ataku, włamania lub awarii. W przypadku ataku, próby umieszczenia złośliwego oprogramowania lub przy włamaniu wirusa-żądacza, uruchamia on poprzez orkiestrator kontenery z aplikacjami szybciej, niż zostaną one zainfekowane, lub szybciej, niż zaatakuje je złośliwy użytkownik.
Przykład 2. Częściowa migracja baz danych Booking.com do Kubernetes
W Booking.com główną bazą danych jest MySQL z asynchroniczną replikacją — istnieje master i cała hierarchia slave'ów. W momencie odejścia Iwana z firmy uruchomiono projekt migracji slave'ów, które można "wystrzelić" z określoną stratą.
Oprócz głównej bazy danych istnieje instalacja Cassandry z własnoręcznie pisaną orkiestracją, która była pisana jeszcze przed tym, jak Kubernetes stał się popularny. W tym zakresie nie ma problemów, ale korzysta ona z persistent storage na lokalnych SSD. Zdalne składowiska, nawet w ramach jednego centrum danych, nie są używane z powodu problemów z wysoką latencją.
Trzeci rodzaj baz danych to usługa wyszukiwania Booking.com, gdzie każdy węzeł serwisu jest bazą danych. Próby przeniesienia usługi wyszukiwania do Kubernetes nie powiodły się, ponieważ każdy węzeł to 60–80 GB lokalnego storage, które jest trudno "podnieść" i "rozgrzać".
W rezultacie silnik wyszukiwania nie został przeniesiony do Kubernetes, a Iwan nie sądzi, że w najbliższym czasie będą nowe próby. Baza MySQL została przeniesiona częściowo: tylko slave'y, które można "wystrzelić" bez większych obaw. Cassandra "zadomowiła się" doskonale.
Wybór infrastruktury jako zadanie bez ogólnego rozwiązania
Photo by
Załóżmy, że mamy nową firmę lub firmę, w której część infrastruktury została zbudowana w stary sposób. Budują w niej plan rozwoju infrastruktury na lata. Jak podejmuje się decyzję o budowie infrastruktury opartej na kontenerach i Kubernetesie?
Firmy, które rywalizują o nanosekundy, są wyłączone z dyskusji. Zdrowy konserwatyzm zwraca się z powodów związanych z niezawodnością, ale mimo to są firmy, które powinny rozważyć nowe podejścia.
Iwan: „Zdecydowanie rozpocząłbym teraz działalność w chmurze, po prostu dlatego, że to szybsze”, chociaż niekoniecznie tańsze. Wraz z rozwojem venture capital startupy nie mają dużych problemów z pieniędzmi, a głównym celem jest zdobycie rynku.
Iwan jest zdania, że rozwój bieżącej infrastruktury jest kryterium wyboru. Jeżeli w przeszłości dokonano poważnych inwestycji, a to działa, to nie ma sensu wprowadzać zmian. Jeśli jednak infrastruktura jest niedorozwinięta, a są problemy z narzędziami, bezpieczeństwem i monitorowaniem, to jest sens rozważyć rozproszoną infrastrukturę.
Podatek trzeba będzie zapłacić w każdym przypadku, a Iwan płaciłby ten, który pozwolił mu w przyszłości płacić mniej. „Ponieważ po prostu dzięki temu, że jadę pociągiem, którym kierują inni, przejadę o wiele dalej, niż gdybym wsiadł do innego pociągu, w który sam muszę wkładać paliwo.” — mówi Iwan. Gdy firma jest nowa, a wymagania dotyczące latencji to dziesiątki milisekund, Iwan patrzyłby w stronę „operatorów”, w których obecnie „opakowuje się” klasyczne bazy danych. Podnoszą łańcuch replikacji, który sam się przełącza w przypadku awarii i tym podobne...
Dla małej firmy z kilkoma serwerami w Kuberze nie ma sensu — twierdzi Andrzej. Ale jeśli planuje urosnąć do setek serwerów i więcej, potrzebna jest automatyzacja i system zarządzania zasobami. W 90% przypadków wydatki się zwracają. Niezależnie od poziomu obciążenia i zasobów, wszystkim, począwszy od startupów, a kończąc na dużych firmach z milionową publicznością, ma sens stopniowe zwracanie uwagi na produkty do orkiestracji kontenerów. „Tak, to naprawdę przyszłość” — jest pewien Andrzej.
Denis wskazał dwa główne kryteria — skalowalność i niezawodność działania. Wybierze te narzędzia, które najlepiej pasują do tego zadania. "Może to być zbudowany na kolanie no-name z Nutanix Community Edition. Może to być druga linia w postaci aplikacji na Kuber z bazą danych na zapleczu, która jest replikowana i ma ustawione parametry RTO i RPO" (cele czasu \/ punktu odzyskiwania — przykłady).
Eugeniusz wskazał na możliwy problem z kadrą. Obecnie na rynku nie ma zbyt wielu wysoko wykwalifikowanych specjalistów, którzy odnajdują się "w wnętrzach". Rzeczywiście, jeśli wybrana technologia jest stara, to trudno jest zatrudnić kogoś innego niż starsze znudzone i zmęczone życiem osoby. Choć inni uczestnicy uważają, że to kwestia kształcenia kadr.
Jeśli postawić pytanie wyboru: uruchomić małą firmę w Public Cloud z bazami w Amazon RDS czy "on-premise" z bazami w Kubernetes, to mimo pewnych wad, uczestnicy wybrali Amazon RDS.
Ponieważ większość słuchaczy meetupów nie pochodzi z "krwawego" enterprise'u, to rozproszone rozwiązania to to, do czego należy dążyć. Systemy przechowywania danych powinny być rozproszone, niezawodne i mieć opóźnienia mierzone w jednostkach milisekund, maksymalnie dziesiątkach, podsumował Andriej.
Ocena wykorzystania Kubernetes
Słuchacz Anton Żbankow zadał pułapkowe pytanie obrońcom Kubernetes: jak wybierano i przeprowadzano ekonomikę techniczną? Dlaczego Kubernetes, dlaczego nie wirtualne maszyny, na przykład?
Photo by
Odpowiedzieli na niego Dmitrij i Iwan. W obu przypadkach metodą prób i błędów powstała sekwencja rozwiązań, w wyniku której obaj uczestnicy przeszli do Kubernetes. Teraz firma zaczyna samodzielnie rozwijać oprogramowanie, które ma sens przenieść do Kube. Mowa nie o klasycznych systemach zewnętrznych, typu 1C. Kubernetes pomaga, gdy deweloperzy muszą szybko wydawać wersje w ramach nieprzerwanego Continuous Improvement.
Zespół Andrieja próbował stworzyć skalowalny klaster na bazie maszyn wirtualnych. Węzły padały jak domino, co czasami prowadziło do awarii klastra. "Teoretycznie można to dokończyć i utrzymać ręcznie, ale jest to męczące. A jeśli na rynku jest rozwiązanie, które pozwala działać bez problemu, to chętnie do niego idziemy. I w rezultacie przeszliśmy do tego." — relacjonuje Andriej.
Standardy dla takiej analizy i obliczeń istnieją, ale nikt nie powie, jak bardzo są one prawdziwe w rzeczywistym sprzęcie w eksploatacji. Do obliczeń ważne jest również zrozumienie każdego narzędzia i ekosystemu, ale to niemożliwe.
Co nas czeka
Photo by
Kiedy technologie się rozwijają, pojawia się coraz więcej rozrzuconych kawałków, a potem następuje fazowy przejrz, pojawia się dostawca, który zainwestował wystarczająco dużo „kasy”, aby wszystko połączyć w jednym narzędziu.
Czy nie wydaje się wam, że nadejdzie moment, kiedy pojawi się narzędzie, jakie stało się Ubuntu dla świata Linuxa? Możliwe, że jedno narzędzie do konteneryzacji i orkiestracji obejmie też Kubernetesa. Z nim stanie się łatwo budować chmury on-premise.
Odpowiedź podał Iwan: „Google aktualnie buduje Anthos – to ich pakietowe rozwiązanie, które rozwija chmurę i obejmuje Kuber, Service Mesh, monitoring – wszelkie powiązania potrzebne do mikrousług w on-premise. Jesteśmy prawie w przyszłości.”
Denis również wspomniał o Nutanix i VMWare z produktem vRealize Suite, które mogą sobie radzić z takim zadaniem bez konteneryzacji.
Dmitrij podzielił się opinią, że zmniejszenie „bólu” i redukcja obciążeń to dwa obszary, w których należy oczekiwać poprawy.
Podsumowując dyskusję, wyróżniamy następujące problemy współczesnej infrastruktury.
- Aż trzech uczestników wskazało na problem ze stateful.
- Różnego rodzaju problemy z wsparciem bezpieczeństwa, w tym prawdopodobieństwo, że w Dockerze znajdą się różne wersje Pythona, serwerów aplikacyjnych i komponentów.
Nadmierne zużycie, o którym lepiej porozmawiać na osobnym meet-upie.
Problem z nauczaniem, ponieważ orkiestracja to skomplikowany ekosystem.
Ogólny problem branży – używanie narzędzi niezgodnie z ich przeznaczeniem.Pozostałe wnioski pozostawiam Wam. Na razie można odnieść wrażenie, że połączenie Docker+Kubernetes ma trudności w staniu się „centralną” częścią systemu. Na przykład systemy operacyjne są instalowane na sprzęcie jako pierwsze, czego nie można powiedzieć o kontenerach i orkiestracji. Może w przyszłości systemy operacyjne i kontenery złączą się z oprogramowaniem do zarządzania chmurą.
Photo byKorzystając z okazji, chcę pozdrowić mamę i przypomnieć, że mamy grupę na Facebooku , kanał z interesującymi publikacjami z różnych blogów technologicznych. I mój kanał , gdzie opowiadam o zarządzaniu rozwojem w firmach produktowych.
Źródło: habr.com
