Pod koniec maja odbyło się spotkanie online na ten temat . Rozmawialiśmy o kontenerach, Kubernetesie i zasadzie orkiestracji, kryteriach wyboru infrastruktury i wielu innych kwestiach. Uczestnicy dzielili się przypadkami z własnej praktyki.
Uczestnicy:
- Jewgienij Potapow, dyrektor generalny ITSumma. Ponad połowa klientów firmy już się przeprowadza lub chce przejść na Kubernetes.
- Dmitry Stolyarov, dyrektor techniczny „Flant”. Ma ponad 10-letnie doświadczenie w pracy z systemami kontenerowymi.
- Denis Remchukov (alias Eric Oldmann), dyrektor operacyjny argotech.io, były RAO UES. Obiecał porozmawiać o sprawach w „krwawym” przedsiębiorstwie.
- Andrey Fedorovsky, dyrektor ds. technicznych „News360.com”Po zakupie firmy przez innego gracza odpowiada za szereg projektów i infrastruktury z zakresu ML i AI.
- Ivan Kruglov, inżynier systemowy, były Booking.com.Ta sama osoba, która własnymi rękami zrobiła wiele 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.
- Case: Firma latami buduje plan rozwoju infrastruktury. W jaki sposób podejmowana jest decyzja o budowie (lub migracji obecnej) infrastruktury do kontenerów i Kubera, czy nie?
- Problemy w świecie chmurowym, czego brakuje, wyobraźmy sobie, co będzie jutro.
Wywiązała się ciekawa dyskusja, opinie uczestników były na tyle odmienne i wywołały tyle komentarzy, że chcę się nimi z Wami podzielić. Jeść , a poniżej streszczenie dyskusji.
Czy Kubernetes to już standard czy świetny marketing?
„Doszliśmy do tego (Kubernetes – przyp. red.), kiedy jeszcze nikt o tym nie wiedział. Przyszliśmy do niego nawet wtedy, gdy go nie było. Chcieliśmy tego wcześniej” – Dmitrij Stolarow
Zdjęcie z Reddit.com
5-10 lat temu istniała ogromna liczba narzędzi i nie było jednego standardu. Co sześć miesięcy pojawiał się nowy produkt, a nawet więcej niż jeden. Najpierw Włóczęga, potem Salt, Szef Kuchni, Puppet… „i odbudowujesz swoją infrastrukturę co sześć miesięcy. Masz pięciu administratorów, którzy są ciągle zajęci przepisywaniem konfiguracji” – wspomina Andrey Fedorovsky. Uważa, że Docker i Kubernetes „wyparły” resztę. Docker stał się standardem w ciągu ostatnich pięciu lat, Kubernetes w ciągu ostatnich dwóch lat. I to jest dobre dla branży..
Dmitry Stolyarov i jego zespół uwielbiają Kubera. Chcieli takiego narzędzia, zanim się pojawiło, i doszli do wniosku, gdy nikt o nim nie wiedział. Obecnie ze względu na wygodę nie przyjmują klienta jeśli rozumieją, że nie będą z nim wdrażać Kubernetesa. Jednocześnie, według Dmitrija, firma ma na swoim koncie „wiele gigantycznych historii sukcesu w zakresie przebudowy straszliwego dziedzictwa”.
Kubernetes to nie tylko orkiestracja kontenerów, to system zarządzania konfiguracją z rozwiniętym API, komponentem sieciowym, równoważeniem L3 i kontrolerami Ingress, dzięki czemu stosunkowo łatwo jest zarządzać zasobami, skalowaniem i abstrakcją z niższych warstw infrastruktury.
Niestety w życiu za wszystko musimy płacić. A ten podatek jest duży, zwłaszcza jeśli mówimy o przejściu na Kubernetes firmy z rozwiniętą infrastrukturą, jak uważa Ivan Kruglov. Mógłby swobodnie pracować zarówno w firmie z tradycyjną infrastrukturą, jak i z Kuberem. Najważniejsze jest zrozumienie charakterystyki firmy i rynku. Ale na przykład dla Jewgienija Potapowa, który uogólniłby Kubernetesa na dowolne narzędzie do orkiestracji kontenerów, takie pytanie nie pojawia się.
Evgeniy dokonał analogii do sytuacji z lat 1990. XX wieku, kiedy pojawiło się programowanie obiektowe jako sposób programowania złożonych aplikacji. W tym czasie debata trwała nadal i pojawiły się nowe narzędzia wspierające OOP. Następnie pojawiły się mikrousługi jako sposób na odejście od koncepcji monolitycznej. To z kolei doprowadziło do pojawienia się kontenerów i narzędzi do zarządzania kontenerami. „Myślę, że wkrótce nadejdzie taki moment, że nie będzie już wątpliwości, czy warto pisać małą aplikację mikroserwisową, domyślnie będzie ona pisana jako mikroserwis” – uważa. Podobnie Docker i Kubernetes ostatecznie staną się 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 jak oddzielić część współpracującą z dyskiem we/wy, warunkowo, od części aplikacyjnej bazy danych. Czy jest możliwe, że w przyszłości bazy danych zmienią się na tyle, że będą dostarczane w pudełku, gdzie jedna część będzie koordynowana poprzez Docker i Kubernetes, a w innej części infrastruktury, poprzez osobne oprogramowanie, będzie zapewniona część magazynowa ? Czy bazy zmienią się jako produkt?
Ten opis jest podobny do zarządzania kolejkami, ale wymagania dotyczące niezawodności i synchronizacji informacji w tradycyjnych bazach danych są znacznie wyższe, uważa Andrey. Współczynnik trafień w pamięci podręcznej w normalnych bazach danych pozostaje na poziomie 99%. Jeśli pracownik ulegnie awarii, uruchamiany jest nowy, a pamięć podręczna „rozgrzewa się” od zera. Dopóki pamięć podręczna nie zostanie rozgrzana, proces roboczy działa powoli, co oznacza, że nie można go załadować obciążeniem użytkownika. Chociaż nie ma obciążenia użytkownika, pamięć podręczna nie nagrzewa się. To błędne koło.
Dmitry zasadniczo się z tym nie zgadza - kwora i podział na części rozwiązują problem. Ale Andrey upiera się, że to rozwiązanie nie jest odpowiednie dla wszystkich. W niektórych sytuacjach kworum jest odpowiednie, ale powoduje dodatkowe obciążenie sieci. Baza danych NoSQL nie jest odpowiednia we wszystkich przypadkach.
Uczestnicy spotkania zostali podzieleni na dwa obozy.
Denis i Andrey argumentują, że wszystko, co jest zapisywane na dysku – bazy danych itd. – jest niemożliwe w obecnym ekosystemie Kubera. W Kubernetesie nie da się zachować integralności i spójności danych produkcyjnych. Jest to podstawowa cecha. Rozwiązanie: infrastruktura hybrydowa.
Nawet nowoczesne bazy danych natywne w chmurze, takie jak MongoDB i Cassandra, lub kolejki komunikatów, takie jak Kafka czy RabbitMQ, wymagają trwałych magazynów danych poza Kubernetesem.
Evgeniy sprzeciwia się: „Bazy w Kuberze to szkoda niemal rosyjska, czyli niemal korporacyjna, co wiąże się z faktem, że w Rosji nie ma adopcji chmury”. Małe i średnie firmy na Zachodzie to Cloud. Bazy danych Amazon RDS są łatwiejsze w użyciu niż samodzielne majsterkowanie przy Kubernetesie. W Rosji korzystają z Kubera „on-premise” i przenoszą do niego bazy, gdy próbują pozbyć się zoo.
Dmitry nie zgodził się także ze stwierdzeniem, że w Kubernetesie nie można przechowywać baz danych: „Baza różni się od bazy. A jeśli wypchniesz gigantyczną relacyjną bazę danych, to pod żadnym pozorem. Jeśli popchniesz coś małego i natywnego w chmurze, co jest mentalnie przygotowane na półefemeryczne życie, wszystko będzie dobrze. Dmitry wspomniał również, że narzędzia do zarządzania bazami danych nie są gotowe ani na Dockera, ani na Kubera, więc pojawiają się duże trudności.
Ivan z kolei jest pewien, że nawet jeśli abstrahujemy od koncepcji stanowego i bezstanowego, ekosystem rozwiązań korporacyjnych w Kubernetesie nie jest jeszcze gotowy. W przypadku Kubera trudno jest zachować wymogi legislacyjne i regulacyjne. Na przykład niemożliwe jest opracowanie rozwiązania zapewniającego tożsamość, w przypadku którego wymagane są ścisłe gwarancje identyfikacji serwera, aż do sprzętu umieszczonego w serwerach. Ten obszar się rozwija, ale nie ma jeszcze rozwiązania.
Uczestnicy nie byli w stanie dojść do porozumienia, dlatego w tej części nie zostaną wyciągnięte żadne wnioski. Podajmy kilka praktycznych przykładów.
Przypadek 1. Cyberbezpieczeństwo „mega-regulatora” z bazami poza Kuberą
W przypadku rozwiniętego systemu cyberbezpieczeństwa zastosowanie kontenerów i orkiestracji pozwala odeprzeć ataki i włamania. Na przykład w jednym megaregulatorze Denis i jego zespół wdrożyli połączenie orkiestratora z przeszkoloną usługą SIEM, która analizuje logi w czasie rzeczywistym i określa proces ataku, włamania lub awarii. W przypadku ataku, próby umieszczenia czegoś lub w przypadku inwazji wirusa ransomware, za pośrednictwem orkiestratora pobiera kontenery z aplikacjami szybciej, niż zostają zainfekowane lub szybciej, niż atakujący je atakuje.
Przypadek 2. Częściowa migracja baz Booking.com do Kubernetes
W Booking.com główną bazą danych jest MySQL z replikacją asynchroniczną - jest master i cała hierarchia slave'ów. Zanim Ivan opuścił firmę, rozpoczęto projekt przeniesienia niewolników, których można było „zastrzelić” z pewnymi obrażeniami.
Oprócz głównej bazy istnieje instalacja Cassandry z samodzielnie napisaną orkiestracją, która powstała jeszcze zanim Kuber wszedł do głównego nurtu. Nie ma z tym problemów, ale jest on trwały na lokalnych dyskach SSD. Zdalna pamięć masowa, nawet w tym samym centrum danych, nie jest wykorzystywana ze względu na problem dużych opóźnień.
Trzecią klasą baz danych jest wyszukiwarka Booking.com, gdzie każdy węzeł usługi jest bazą danych. Próby przeniesienia usługi wyszukiwania do Kubera nie powiodły się, ponieważ każdy węzeł to 60-80 GB pamięci lokalnej, co trudno „podnieść” i „rozgrzać”.
W rezultacie wyszukiwarka nie została przeniesiona do Kubernetesa, a Ivan nie sądzi, aby w najbliższej przyszłości pojawiły się nowe próby. Baza danych MySQL została przeniesiona na pół: tylko Slaves, którzy nie boją się „zastrzelenia”. Cassandra zaaklimatyzowała się idealnie.
Wybór infrastruktury jako zadanie bez rozwiązania ogólnego
Photo by
Załóżmy, że mamy nową firmę lub firmę, w której część infrastruktury jest zbudowana w stary sposób. Buduje plan rozwoju infrastruktury na lata. Jak podejmowana jest decyzja, czy budować infrastrukturę na kontenerach i Kuberze, czy nie?
Z dyskusji wyłączone są firmy walczące o nanosekundy. Zdrowy konserwatyzm opłaca się pod względem niezawodności, ale wciąż 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. Wraz z rozwojem venture capital startupy nie mają większych problemów z pieniędzmi, a głównym zadaniem jest podbój rynku.
Iwan jest tego zdania Kryterium wyboru jest rozwój istniejącej infrastruktury. Jeśli w przeszłości była poważna inwestycja i zadziałała, to nie ma sensu jej powtarzać. Jeśli infrastruktura nie jest rozwinięta i pojawiają się problemy z narzędziami, bezpieczeństwem i monitorowaniem, wówczas warto przyjrzeć się infrastrukturze rozproszonej.
Podatek i tak trzeba będzie zapłacić, a Iwan zapłaci ten, który pozwoli mu w przyszłości płacić mniej. "Bo po prostu dzięki temu, że jeżdżę pociągiem, którym jadą inni, pojadę znacznie dalej, niż gdybym wsiadł do innego pociągu, do którego sam muszę tankować.„mówi Iwan. Gdy firma jest nowa i wymagania dotyczące opóźnień wynoszą dziesiątki milisekund, wówczas Ivan zwróciłby się w stronę „operatorów”, w których dziś „opakowane” są klasyczne bazy danych. Podnoszą łańcuch replikacji, który przełącza się w przypadku przełączenia awaryjnego itp.
Dla małej firmy z kilkoma serwerami Kubera nie ma sensu” – mówi Andrey. Jeśli jednak planuje rozbudowę do setek lub więcej serwerów, potrzebuje automatyzacji i systemu zarządzania zasobami. W 90% przypadków warto. Co więcej, niezależnie od poziomu obciążenia i zasobów. Dla każdego, od start-upów po duże firmy z milionami odbiorców, ma sens stopniowe szukanie produktów do orkiestracji kontenerów. „Tak, to naprawdę przyszłość” – jest pewien Andrey.
Denis przedstawił dwa główne kryteria: skalowalność i stabilność działania. Dobierze narzędzia, które najlepiej sprawdzą się w danym zadaniu. „Może to być noname złożony na kolanach i ma na sobie Nutanix Community Edition. Może to być druga linia w postaci aplikacji na Kuberze z bazą danych na backendzie, która jest replikowana i ma określone parametry RTO i RPO” (cele czasu/punktu odzyskiwania - około).
Evgeniy zidentyfikował możliwy problem z personelem. W tej chwili na rynku nie ma wielu wysoko wykwalifikowanych specjalistów, którzy rozumieją „odwagę”. Rzeczywiście, jeśli wybrana technologia jest stara, trudno zatrudnić kogokolwiek innego niż osoby w średnim wieku, znudzone i zmęczone życiem. Chociaż inni uczestnicy uważają, że jest to kwestia szkolenia personelu.
Jeśli postawimy kwestię wyboru: uruchomić małą firmę w Chmurze Publicznej z bazami danych w Amazon RDS lub „on premise” z bazami danych w Kubernetesie, to pomimo pewnych niedociągnięć, wyborem uczestników stał się Amazon RDS.
A zatem większość słuchaczy spotkania nie pochodzi z „cholernego” przedsiębiorstwa rozwiązania rozproszone są tym, do czego powinniśmy dążyć. Systemy przechowywania danych muszą być rozproszone, niezawodne i powodować opóźnienia mierzone w milisekundach, najwyżej w dziesiątkach„, podsumował Andriej.
Ocena wykorzystania Kubernetesa
Słuchacz Anton Zhbankov zadał apologetom Kubernetes pytanie-pułapkę: w jaki sposób wybraliście i przeprowadziliście studium wykonalności? Dlaczego Kubernetes, dlaczego nie na przykład maszyny wirtualne?
Photo by
Odpowiedzieli Dmitrij i Iwan. W obu przypadkach metodą prób i błędów powstał ciąg decyzji, w wyniku którego obaj uczestnicy dotarli do Kubernetesa. Teraz firmy zaczynają samodzielnie tworzyć oprogramowanie, które ma sens przenieść na Kubera. Nie mówimy o klasycznych systemach innych firm, takich jak 1C. Kubernetes pomaga programistom szybko wprowadzać nowe wersje, zapewniając ciągłe doskonalenie.
Zespół Andreya próbował stworzyć skalowalny klaster oparty na maszynach wirtualnych. Węzły spadały jak domino, co czasami prowadziło do zawalenia się gromady. „Teoretycznie można to dokończyć i wesprzeć rękami, ale jest to nudne. A jeśli na rynku istnieje rozwiązanie, które pozwala na pracę po wyjęciu z pudełka, chętnie się na to zdecydujemy. W rezultacie dokonaliśmy zmiany” – mówi Andrey.
Istnieją standardy takiej analizy i obliczeń, ale nikt nie jest w stanie powiedzieć, jak dokładne są one na rzeczywistym działającym sprzęcie. Do obliczeń ważne jest również zrozumienie każdego narzędzia i ekosystemu, ale nie jest to możliwe.
Co nas czeka
Photo by
W miarę rozwoju technologii pojawia się coraz więcej różnych elementów, a następnie następuje przejście fazowe i pojawia się sprzedawca, który ubił tyle ciasta, że wszystko można połączyć w jednym narzędziu.
Czy myślisz, że nadejdzie czas, gdy będzie dostępne narzędzie takie jak Ubuntu dla świata Linuksa? Być może pojedyncze narzędzie do konteneryzacji i orkiestracji będzie obejmować Kuber. Ułatwi to budowanie chmur lokalnych.
Odpowiedzi udzielił Ivan: „Google buduje teraz Anthos – to jest ich pakietowa oferta, która wdraża chmurę i obejmuje Kuber, Service Mesh, monitorowanie – cały sprzęt potrzebny do mikrousług lokalnych”. Jesteśmy prawie w przyszłości.”
Denis wspomniał także o Nutanixie i VMWare z produktem vRealize Suite, który poradzi sobie z podobnym zadaniem bez konteneryzacji.
Dmitry podzielił się swoją opinią, że zmniejszenie „bólu” i zmniejszenie podatków to dwa obszary, w których możemy spodziewać się poprawy.
Podsumowując dyskusję, zwracamy uwagę na następujące problemy współczesnej infrastruktury:
- Trzej uczestnicy natychmiast zidentyfikowali problem ze stanem.
- Różne problemy związane ze wsparciem bezpieczeństwa, w tym możliwość, że Docker będzie zawierał wiele wersji Pythona, serwerów aplikacji i komponentów.
Nadmierne wydatki, które lepiej omówić na osobnym spotkaniu.
Wyzwanie edukacyjne, ponieważ orkiestracja to złożony ekosystem.
Częstym problemem w branży jest niewłaściwe użycie narzędzi.Reszta wniosków należy do Ciebie. Wciąż istnieje poczucie, że nie jest łatwo, aby kombinacja Docker+Kubernetes stała się „centralną” częścią systemu. Na przykład systemy operacyjne są najpierw instalowane na sprzęcie, czego nie można powiedzieć o kontenerach i orkiestracji. Być może w przyszłości systemy operacyjne i kontenery połączą się z oprogramowaniem do zarządzania chmurą.
Photo byChciałbym skorzystać z okazji, aby przywitać się z moją mamą i przypomnieć, że mamy grupę na Facebooku , kanał z ciekawymi publikacjami z różnych blogów technicznych. I mój kanał , gdzie mówię o zarządzaniu rozwojem w firmach produktowych.
Źródło: www.habr.com