Pod koniec maja zorganizowano spotkanie online na ten temat . Rozmawialiśmy o kontenerach, Kubernetesie i orkiestracji ogólnie, o kryteriach wyboru infrastruktury i wiele więcej. Uczestnicy dzielili się przykładami ze swojej praktyki.
Uczestnicy:
- Jewgienij Potapow, dyrektor generalny „ITSumma”. Ponad połowa klientów już przeszła na platformę Kubernetes lub chce to zrobić.
- Dmitrij Stolarow, dyrektor techniczny „Flant”. Posiada ponad 10-letnie doświadczenie w pracy z systemami kontenerowymi.
- Denis Remchukov (znany również jako Eric Oldmann), dyrektor operacyjny argotech.io, były członek RAO UES. Obiecał opowiedzieć o przypadkach w „krwawym” przedsięwzięciu.
- Andrey Fedorovsky, dyrektor techniczny News360.comPo przejęciu firmy przez innego gracza odpowiada za szereg projektów z zakresu uczenia maszynowego i sztucznej inteligencji, a także za infrastrukturę.
- Ivan Kruglov, inżynier systemów, były pracownik Booking.com.Ta sama osoba, która własnymi rękami wiele zrobiła z Kubernetesem.
Tematy:
- Spostrzeżenia uczestników na temat kontenerów i orkiestracji (Docker, Kubernetes itp.); co zostało wypróbowane w praktyce lub przeanalizowane.
- Przypadek: Firma opracowuje plan rozwoju infrastruktury na kolejne lata. W jaki sposób podejmowana jest decyzja o tym, czy budować (lub migrować obecną) infrastrukturę do kontenerów i Kubera, czy nie?
- Problemy w świecie chmury natywnej, czego brakuje, wyobraźmy sobie, co stanie się jutro.
Wywiązała się ciekawa dyskusja, opinie uczestników były tak różne i wywołały tak wiele komentarzy, że chciałbym się nimi z Wami podzielić. Jeść , a poniżej znajduje się podsumowanie dyskusji.
Czy Kubernetes to standard czy po prostu świetny marketing?
„Przyszliśmy do niego (Kubernetesa — red.), gdy nikt jeszcze o nim nie wiedział. Przyszliśmy do niego, nawet gdy go nie było. Chcieliśmy tego przed tym” — Dmitrij Stolarow
Zdjęcie z Reddit.com
Około 5–10 lat temu istniała ogromna liczba narzędzi i nie było jednego standardu. Co pół roku pojawiał się nowy produkt, a nawet więcej niż jeden. Najpierw Vagrant, potem Salt, Chef, Puppet,… „i odbudowujesz swoją infrastrukturę co pół roku. „Masz pięciu administratorów, którzy są nieustannie zajęci przepisywaniem konfiguracji”, wspomina Andrey Fedorovsky. Uważa, że Docker i Kubernetes „zmiażdżyły” resztę. W ciągu ostatnich pięciu lat Docker stał się standardem, a w ciągu ostatnich dwóch lat Kubernetes. A to jest dobre dla branży..
Dmitrij Stolarow i jego zespół kochają Kubera. Chcieli mieć takie narzędzie jeszcze zanim powstało i wpadli na pomysł, gdy nikt jeszcze o nim nie wiedział. W tej chwili, ze względów praktycznych, nie przyjmują klientów, jeśli wiedzą, że nie wdrożą dla nich Kubernetesa. Jednocześnie, według Dmitrija, firma ma „wiele gigantycznych sukcesów w odnawianiu okropnej spuścizny”.
Kubernetes to nie tylko system orkiestracji kontenerów, to także system zarządzania konfiguracją z zaawansowanym interfejsem API, komponentem sieciowym, równoważeniem L3 i kontrolerami Ingress. Pozwala on na stosunkowo łatwe zarządzanie zasobami, skalowanie i abstrakcję z niższych warstw infrastruktury.
Niestety w naszym życiu za wszystko musimy płacić. A podatek ten jest duży, zwłaszcza jeśli mówimy o przejściu na Kubernetes firmy z rozwiniętą infrastrukturą, jak uważa Ivan Kruglov. Z łatwością mógłby pracować w firmie z tradycyjną infrastrukturą lub w firmie Kuber. Najważniejsze jest zrozumienie specyfiki firmy i rynku. Ale na przykład dla Jewgienija Potapowa, który uogólniałby Kubernetesa na dowolne narzędzie do koordynacji kontenerów, takie pytanie w ogóle nie powstaje.
Jewgienij przytoczył analogię do sytuacji z lat 1990., gdy programowanie obiektowe pojawiło się jako sposób programowania złożonych aplikacji. W tym czasie trwały debaty i pojawiały się nowe narzędzia wspierające programowanie obiektowe. Następnie pojawiły się mikrousługi, które stanowiły sposób odejścia od koncepcji monolitycznej. To z kolei doprowadziło do powstania kontenerów i narzędzi do ich zarządzania. „Myślę, że niedługo nadejdzie czas, w którym nikt nie będzie miał wątpliwości, czy warto pisać małą aplikację jako mikrousługę; domyślnie będzie ona pisana jako mikrousługa” – uważa. Podobnie Docker i Kubernetes staną się z czasem standardowym rozwiązaniem, bez konieczności dokonywania wyboru.
Problem baz danych w systemach bezstanowych
Photo by
Obecnie istnieje wiele przepisów na uruchamianie baz danych w Kubernetesie. Nawet w jaki sposób oddzielić część, która obsługuje dyskowe operacje wejścia/wyjścia, od np. części aplikacyjnej bazy danych. Czy możliwe jest, że w przyszłości bazy danych zmienią się na tyle, że będą dostarczane w pudełku, gdzie jedna część będzie zarządzana za pomocą Dockera i Kubernetesa, a część odpowiadająca za przechowywanie danych będzie w innej części infrastruktury, za pośrednictwem oddzielnego oprogramowania? Czy bazy danych zmienią się jako produkt?
Opis ten jest podobny do zarządzania kolejkami, jednak wymagania dotyczące niezawodności i synchronizacji informacji w tradycyjnych bazach danych są znacznie wyższe – uważa Andriej. Współczynnik trafień w pamięci podręcznej w normalnych bazach danych utrzymuje się na poziomie 99%. Jeśli jeden z pracowników ulegnie awarii, uruchamiany jest nowy, a pamięć podręczna jest „rozgrzewana” od nowa. Dopóki pamięć podręczna nie zostanie rozgrzana, proces roboczy działa wolno, co oznacza, że nie można do niego przesyłać obciążeń użytkowników. Dopóki nie ma żadnego obciążenia ze strony użytkowników, pamięć podręczna nie nagrzewa się. To błędne koło.
Dmitrij zasadniczo się z tym nie zgadza — kworum i partycjonowanie rozwiązują problem. Jednak Andriej twierdzi, że takie rozwiązanie nie sprawdzi się u każdego. W niektórych sytuacjach kworum będzie działać, ale spowoduje to dodatkowe obciążenie sieci. Baza danych NoSQL nie sprawdzi się w każdym przypadku.
Uczestnicy spotkania zostali podzieleni na dwa obozy.
Denis i Andrey twierdzą, że wszystko, co jest zapisywane na dysku – bazy danych itd. – jest niemożliwe do zrobienia w obecnym ekosystemie Kubernetes. W Kubernetesie nie da się zachować integralności i spójności danych produkcyjnych. Jest to podstawowa cecha. Rozwiązanie: infrastruktura hybrydowa.
Nawet nowoczesne, natywne bazy danych w chmurze, takie jak MongoDB i Cassandra, czy kolejki komunikatów, takie jak Kafka lub RabbitMQ, wymagają trwałych magazynów danych poza platformą Kubernetes.
Jewgienij protestuje: „Bazy w Kuberze to trauma niemal rosyjska lub niemal korporacyjna, co wiąże się z faktem, że w Rosji nie ma adopcji chmury”. Małe i średnie firmy na Zachodzie korzystają z technologii Cloud. Korzystanie z baz danych Amazon RDS jest łatwiejsze niż samodzielne zabawy z Kubernetesem. W Rosji używają Kubera „lokalnie” i przenoszą do niego bazy danych, gdy chcą pozbyć się zoo.
Dmitrij nie zgodził się również ze stwierdzeniem, że w Kubernetesie nie można przechowywać żadnych baz danych: „Nie ma dwóch takich samych baz danych. A jeśli zamierzasz wcisnąć gigantyczną relacyjną bazę danych, to nie ma mowy. Jeśli wciśniesz coś małego i natywnego dla chmury, co jest mentalnie przygotowane na pół-ulotne życie, wszystko będzie dobrze”. Dmitrij wspomniał również, że narzędzia do zarządzania bazami danych nie są gotowe ani na Dockera, ani na Kubera, stąd duże trudności.
Ivan z kolei jest przekonany, że nawet jeśli abstrahujemy od koncepcji stanu i jego bezstanowości, ekosystem rozwiązań korporacyjnych w Kubernetesie nie jest jeszcze gotowy. Utrzymanie platformy Kubernetes jest trudne ze względu na wymogi prawne i regulacyjne. Przykładowo, nie da się stworzyć rozwiązania do obsługi tożsamości, które wymagałoby ścisłych gwarancji tożsamości serwera, aż po sprzęt włożony do serwerów. Obszar ten się rozwija, ale nie ma jeszcze rozwiązania.
Uczestnikom nie udało się osiągnąć porozumienia, więc w tej części nie będziemy wyciągać żadnych wniosków. Podajmy kilka praktycznych przykładów.
Przypadek 1. Cyberbezpieczeństwo „megaregulatora” mającego bazy poza Kubernetes
W przypadku rozwiniętego systemu cyberbezpieczeństwa wykorzystanie kontenerów i orkiestracji pozwala na odpieranie ataków i włamań. Przykładowo, w jednym z dużych organów regulacyjnych Denis i jego zespół wdrożyli połączenie między koordynatorem a przeszkoloną usługą SIEM, która analizuje logi w czasie rzeczywistym i określa przebieg ataku, włamania lub awarii. W przypadku ataku, próby instalacji czegoś lub ataku wirusa typu ransomware, tworzy kontenery z aplikacjami za pośrednictwem koordynatora szybciej, niż dochodzi do ich zainfekowania lub szybciej, niż atakujący je atakuje.
Przypadek 2. Częściowa migracja baz danych Booking.com do Kubernetes
W Booking.com główną bazą danych jest MySQL z asynchroniczną replikacją - istnieje baza główna (master) i cała hierarchia baz podrzędnych (slave). Kiedy Iwan opuścił firmę, rozpoczęto projekt mający na celu transfer niewolników, których można było „odstrzelić” z pewną dozą obrażeń.
Oprócz głównej bazy znajduje się tam instalacja Cassandra z autorską orkiestracją, która powstała zanim Kuber stał się popularny. Nie ma z tym problemu, ale problem pojawia się na lokalnym dysku SSD. Zdalne przechowywanie danych, nawet w obrębie tego samego centrum danych, nie jest stosowane ze względu na problem dużych opóźnień.
Trzecią klasę baz danych stanowi usługa wyszukiwania Booking.com, w której każdy węzeł usługi jest bazą danych. Próby migracji usługi wyszukiwania do Kubera zakończyły się niepowodzeniem, ponieważ każdy węzeł ma 60–80 GB lokalnej pamięci masowej, którą trudno „podnieść” i „rozgrzać”.
Ostatecznie wyszukiwarka nie została przeniesiona do Kubernetesa i Ivan nie sądzi, aby w najbliższej przyszłości podjęto jakiekolwiek nowe próby w tym zakresie. Baza danych MySQL została przeniesiona w połowie: tylko Slave'y, które nie boją się „odstrzelić”. Kasandra dobrze się zakorzeniła.
Wybór infrastruktury jako problem bez wspólnego rozwiązania
Photo by
Załóżmy, że mamy nową firmę lub firmę, której część infrastruktury została zbudowana w stary sposób. Służy do tworzenia planu rozwoju infrastruktury na przestrzeni lat. W jaki sposób podejmowana jest decyzja o tym, czy budować infrastrukturę na kontenerach i Kuberze, czy nie?
Firmy walczące o nanosekundy są wykluczone z dyskusji. Zdrowy konserwatyzm popłaca ze względu na niezawodność, ale nadal są firmy, które powinny rozważyć nowe podejście.
Ivan: „Zdecydowanie założyłbym teraz firmę w chmurze, po prostu dlatego, że jest to szybsze”, choć niekoniecznie tańsze. Dzięki rozwojowi kapitalizmu wysokiego ryzyka startupy nie mają już większych problemów z pieniędzmi, a ich głównym zadaniem jest podbój rynku.
Iwan jest zdania, że kryterium wyboru jest rozwój obecnej infrastruktury. Jeżeli w przeszłości dokonano poważnych inwestycji i coś się sprawdziło, to nie ma sensu tego powtarzać. Jeśli infrastruktura nie jest rozwinięta i występują problemy z narzędziami, bezpieczeństwem i monitorowaniem, warto zastanowić się nad infrastrukturą rozproszoną.
Podatek i tak będzie musiał zostać zapłacony, a Iwan zapłaci taki, który pozwoli mu w przyszłości płacić mniej. «Ponieważ jeśli po prostu wsiądę do pociągu ciągniętego przez innych, przejadę o wiele dłuższą trasę, niż gdybym wsiadł do innego pociągu i sam musiał zatankować.„- mówi Ivan. Gdy firma jest nowa i wymagania dotyczące opóźnień wynoszą dziesiątki milisekund, Ivan będzie szukał „operatorów”, którzy są obecnie wykorzystywani do „opakowywania” klasycznych baz danych. Tworzą oni łańcuch replikacji, który przełącza się sam w przypadku awarii itp.
Według Andrieja, dla małej firmy posiadającej kilka serwerów Kubera nie ma sensu. Jeśli jednak planuje się rozbudowę do setek lub więcej serwerów, konieczna będzie automatyzacja i system zarządzania zasobami. 90% przypadków jest wartych swojej ceny. Co więcej, bez względu na poziom obciążenia i zasobów. Dla każdego, od start-upów po duże firmy obsługujące miliony klientów, ma sens stopniowe przechodzenie na produkty do orkiestracji kontenerów. „Tak, to naprawdę jest przyszłość” – jest pewien Andriej.
Denis wyróżnił dwa główne kryteria: skalowalność i stabilność działania. Wybierze narzędzia najlepiej dostosowane do danego zadania. „To może być produkt bez nazwy, który został złożony w locie i ma na sobie Nutanix Community Edition. Może to być druga linia w formie aplikacji na Kuber z bazą danych w zapleczu, która jest replikowana i ma zdefiniowane parametry RTO i RPO” (cele punktu/czasu odzyskiwania — około).
Jewgienij zauważył możliwy problem kadrowy. W tej chwili na rynku nie ma zbyt wielu wysoko wykwalifikowanych specjalistów, którzy rozumieją „bebechy”. Rzeczywiście, jeśli wybrana technologia jest stara, trudno jest zatrudnić kogoś innego niż osoby starsze, znudzone i zmęczone. Choć inni uczestnicy uważają, że jest to kwestia szkolenia personelu.
Gdybyśmy mieli zadać sobie pytanie, czy uruchomić małą firmę w chmurze publicznej z bazami danych w Amazon RDS, czy „lokalnie” z bazami danych w Kubernetes, to pomimo pewnych niedociągnięć, wybór uczestników padł na Amazon RDS.
Ponieważ większość słuchaczy spotkania nie pochodzi z „krwawego” przedsiębiorstwa, Powinniśmy dążyć do rozwiązań rozproszonych. Systemy przechowywania danych muszą być rozproszone, niezawodne i generować opóźnienia mierzone w milisekundach, maksymalnie dziesiątkach.— podsumował Andriej.
Ocena wykorzystania Kubernetes
Słuchacz Anton Zhbankov zadał apologetom Kubernetesa pułapkę: w jaki sposób wybrali i przeprowadzili studium wykonalności? Dlaczego na przykład Kubernetes, a nie maszyny wirtualne?
Photo by
Odpowiedzieli Dmitrij i Iwan. W obu przypadkach metodą prób i błędów podejmowano szereg decyzji, które ostatecznie doprowadziły obie strony do rozwiązania Kubernetes. Teraz firmy zaczynają samodzielnie opracowywać oprogramowanie, którego przeniesienie do platformy Kuber jest sensowne. Nie mówimy tu o klasycznych systemach firm trzecich, takich jak 1C. Platforma Kubernetes przydaje się programistom, którzy muszą szybko udostępniać swoje produkty, zapewniając nieprzerwany, ciągły proces udoskonalania.
Zespół Andrieja podjął próbę stworzenia skalowalnego klastra w oparciu o maszyny wirtualne. Węzły padały jak kostki domina, czasami powodując awarię klastra. „Teoretycznie możliwe jest ręczne dokończenie i utrzymanie tego, ale jest to żmudne. A jeśli na rynku jest rozwiązanie, które pozwala nam pracować od razu, to chętnie z niego korzystamy. „I w rezultacie zmieniliśmy to” – mówi Andriej.
Istnieją standardy tego typu analiz i obliczeń, lecz nikt nie potrafi powiedzieć, jak dokładne są one w przypadku rzeczywistego sprzętu używanego w praktyce. Do obliczeń istotne jest również zrozumienie każdego narzędzia i ekosystemu, ale jest to niemożliwe.
Co nas czeka
Photo by
W miarę rozwoju technologii pojawia się coraz więcej elementów, aż w końcu następuje faza przejścia i pojawia się dostawca, który zdołał już wystarczająco zniszczyć „bańkę”, aby połączyć wszystko w jedno narzędzie.
Czy nie sądzisz, że nadejdzie czas, kiedy taki instrument się pojawi? Ubuntu dla pokoju Linux? Być może Kuber będzie jednym z narzędzi do konteneryzacji i koordynacji. Ułatwi budowę lokalnych chmur.
Ivan odpowiedział: „Google obecnie buduje Anthos – jest to ich pakietowa oferta, która wdraża chmurę i obejmuje Kuber, Service Mesh, monitorowanie – cały sprzęt potrzebny do lokalnych mikrousług”. Jesteśmy już niemal w przyszłości.
Denis wspomniał także o firmach Nutanix i VMWare z ich produktem vRealize Suite, który może obsłużyć podobne zadanie bez konteneryzacji.
Dmitrij podzielił się opinią, że zmniejszenie „bólu” i obniżenie podatków to dwa obszary, w których można spodziewać się poprawy.
Podsumowując dyskusję, podkreślimy następujące problemy współczesnej infrastruktury
- Trzech uczestników jednocześnie zauważyło problem ze stanem.
- Różne problemy z bezpieczeństwem, w tym możliwość, że Docker będzie posiadał wiele wersji Pythona, serwerów aplikacji i komponentów.
Przekroczenie budżetu, co lepiej omówić na osobnym spotkaniu.
Problemem jest uczenie się, ponieważ orkiestracja jest złożonym ekosystemem.
Częstym problemem w branży jest niewłaściwe używanie narzędzi.Resztę wniosków musisz wyciągnąć sam. Nadal panuje przekonanie, że pakiet Docker+Kubernetes ma trudności z pełnieniem roli „centralnej” części systemu. Przykładowo systemy operacyjne są w pierwszej kolejności instalowane na sprzęcie, czego nie można powiedzieć o kontenerach i orkiestracji. Być może w przyszłości systemy operacyjne i kontenery zostaną połączone z oprogramowaniem do zarządzania chmurą.
Photo byKorzystając z okazji chciałbym pozdrowić moją mamę. Przypominam, że mamy grupę na Facebooku. , kanał z interesującymi publikacjami z różnych blogów technologicznych. I mój kanał , w którym opowiadam o zarządzaniu rozwojem w firmach produkcyjnych.
Źródło: www.habr.com
