W oczekiwaniu Witalij Chabarow wywiad Dmitrij Stolarow (), dyrektor techniczny i współzałożyciel firmy Flant. Witalij zapytał Dmitrija o to, co robi Flant, o Kubernetes, rozwój ekosystemu, wsparcie. Rozmawialiśmy o tym, dlaczego Kubernetes jest potrzebny i czy w ogóle jest potrzebny. A także o mikroserwisach, Amazon AWS, podejściu „będę miał szczęście” do DevOps, przyszłości samego Kubernetesa, dlaczego, kiedy i jak przejmie władzę nad światem, perspektywach DevOps i na co powinni przygotować się inżynierowie w jasna i niedaleka przyszłość dzięki uproszczeniu i sieciom neuronowym.
posłuchaj jako podcastu na DevOps Deflop - rosyjskojęzyczny podcast o DevOps, a poniżej wersja tekstowa.
Tutaj i poniżej zadaje pytania inżynier z Express42.
O firmie „Flant”
- Cześć Dima. Jesteś dyrektorem technicznym”", a także jego założyciel. Proszę opowiedzieć czym zajmuje się firma i czym się w niej zajmujesz?
Dmitry: Z zewnątrz wygląda na to, że to my instalujemy Kubernetes dla wszystkich i coś z nim robimy. Ale to nieprawda. Zaczynaliśmy jako firma zajmująca się Linuksem, jednak od bardzo długiego czasu naszą główną działalnością jest obsługa projektów produkcyjnych i wysokoobciążeniowych pod klucz. Zwykle całą infrastrukturę budujemy od podstaw i potem jesteśmy za nią odpowiedzialni przez długi, długi czas. Dlatego główną pracą, którą wykonuje „Flant”, za którą otrzymuje pieniądze, jest przejęcie odpowiedzialności i wdrożenie produkcji pod klucz.
Ja, jako dyrektor techniczny i jeden z założycieli firmy, całe dnie i noce spędzam próbując wymyślić, jak zwiększyć dostępność produkcji, uprościć jej obsługę, ułatwić życie administratorom i uprzyjemnić życie programistom .
O Kubernetesie
— Ostatnio widziałem wiele raportów z Flant i o Kubernetesie. Jak do tego doszedłeś?
Dmitry: Mówiłem już o tym wiele razy, ale nie mam nic przeciwko powtórzeniu. Myślę, że słuszne jest powtórzenie tego tematu, ponieważ istnieje pomieszanie przyczyny i skutku.
Naprawdę potrzebowaliśmy narzędzia. Stawialiśmy czoła wielu problemom, zmagaliśmy się, pokonywaliśmy je różnymi kulami i czuliśmy potrzebę posiadania narzędzia. Rozważaliśmy wiele różnych opcji, zbudowaliśmy własne rowery i zdobyliśmy doświadczenie. Stopniowo doszliśmy do momentu, w którym zaczęliśmy używać Dockera niemal od razu po jego pojawieniu się – około 2013 roku. W momencie jego pojawienia się mieliśmy już duże doświadczenie z kontenerami, napisaliśmy już analogię „Dockera” - kilka własnych kul w Pythonie. Wraz z pojawieniem się Dockera stało się możliwe rzucenie kul i skorzystanie z niezawodnego i wspieranego przez społeczność rozwiązania.
W przypadku Kubernetesa historia jest podobna. Zanim zaczęło nabierać rozpędu – dla nas jest to wersja 1.2 – mieliśmy już kilka podpór zarówno w Shell, jak i Chef, co w jakiś sposób próbowaliśmy zaaranżować za pomocą Dockera. Poważnie patrzyliśmy w stronę Ranchera i różnych innych rozwiązań, ale wtedy pojawił się Kubernetes, w którym wszystko jest zaimplementowane dokładnie tak, jak byśmy to zrobili, a nawet lepiej. Nie ma na co narzekać.
Tak, tu jest jakaś niedoskonałość, tam jest jakaś niedoskonałość – jest mnóstwo niedoskonałości, a 1.2 jest ogólnie okropny, ale… Kubernetes jest jak budynek w budowie – patrzysz na projekt i rozumiesz że będzie fajnie. Jeśli budynek ma teraz fundamenty i dwa piętra, to rozumiesz, że lepiej się jeszcze nie wprowadzać, ale z oprogramowaniem nie ma takich problemów - możesz już z niego korzystać.
Nie mieliśmy momentu, w którym zastanawialibyśmy się, czy skorzystać z Kubernetesa, czy nie. Czekaliśmy na to długo przed jego pojawieniem się i sami próbowaliśmy stworzyć analogie.
O Kubernetesie
— Czy jesteś bezpośrednio zaangażowany w rozwój samego Kubernetesa?
Dmitry: Przeciętny. Raczej uczestniczymy w rozwoju ekosystemu. Wysyłamy określoną liczbę pull requestów: do Prometheusa, do różnych operatorów, do Helma – do ekosystemu. Niestety nie jestem w stanie na bieżąco śledzić wszystkiego co robimy i mogę się mylić, ale od nas do rdzenia nie ma ani jednej puli.
— Czy jednocześnie rozwijasz wiele swoich narzędzi w oparciu o Kubernetes?
Dmitry: Strategia jest następująca: pobieramy żądania do wszystkiego, co już istnieje. Jeśli żądania ściągnięcia nie są tam akceptowane, po prostu sami je rozwidlamy i żyjemy, dopóki nie zostaną zaakceptowane w naszych kompilacjach. Następnie, gdy dotrze do wersji upstream, wracamy do wersji upstream.
Na przykład mamy operator Prometheus, za pomocą którego przełączaliśmy się tam i z powrotem do poprzedzającego naszego zestawu już prawdopodobnie 5 razy. Potrzebujemy jakiejś funkcji, wysłaliśmy prośbę o ściągnięcie, musimy ją wdrożyć jutro, ale nie chcemy czekać, aż zostanie udostępniona wcześniej. W związku z tym gromadzimy się dla siebie, wdrażamy nasz zespół z naszą funkcją, której z jakiegoś powodu potrzebujemy, do wszystkich naszych klastrów. Potem np. oddają nam to na upstream ze słowami: „Chłopaki, zróbmy to dla sprawy bardziej ogólnej”, my lub ktoś inny to kończymy i z czasem wszystko znów się łączy.
Staramy się rozwijać wszystko, co istnieje. Wiele elementów, które jeszcze nie istnieją, nie zostały jeszcze wynalezione, lub zostały wynalezione, ale nie miały czasu na wdrożenie - robimy to. I nie dlatego, że podoba nam się proces lub budowa rowerów jako branża, ale po prostu dlatego, że potrzebujemy tego narzędzia. Często zadawane jest pytanie: dlaczego zrobiliśmy to czy tamto? Odpowiedź jest prosta – tak, bo trzeba było pójść dalej, rozwiązać jakiś praktyczny problem i rozwiązaliśmy go za pomocą tej tuli.
Droga zawsze wygląda tak: szukamy bardzo dokładnie i jeśli nie znajdziemy rozwiązania, jak zrobić trolejbus z bochenka chleba, to robimy własny bochenek i własny trolejbus.
Narzędzia Flanty
— Wiem, że Flant ma teraz operatory dodatków, operatory powłoki i narzędzia dapp/werf. Jak rozumiem, jest to ten sam instrument w różnych wcieleniach. Rozumiem również, że w ramach Flaunt dostępnych jest znacznie więcej różnych narzędzi. To prawda?
Dmitry: Mamy dużo więcej na GitHubie. Z tego co pamiętam, mamy statusmapę – panel dla Grafany, z którym spotkał się każdy. Wspomina się o tym niemal co drugi artykuł o monitorowaniu Kubernetesa na Medium. Nie da się w skrócie wyjaśnić czym jest statusmapa - potrzebuje osobnego artykułu, ale jest bardzo przydatną rzeczą do monitorowania statusu w czasie, gdyż w Kubernetesie często potrzebujemy pokazywać status w czasie. Mamy też LogHouse - jest to rzecz oparta na ClickHouse i czarnej magii do zbierania logów w Kubernetesie.
Mnóstwo narzędzi! A będzie ich jeszcze więcej, bo w tym roku ukaże się szereg rozwiązań wewnętrznych. Z tych bardzo dużych, bazujących na operatorze dodatków, jest cała masa dodatków dla Kubernetesa, czyli jak poprawnie zainstalować sert managera - narzędzie do zarządzania certyfikatami, jak poprawnie zainstalować Prometheusa z mnóstwem dodatków - jest tego około dwudziestu różnych pliki binarne, które eksportują dane i coś zbierają, do tego Prometheus ma najbardziej niesamowitą grafikę i alerty. Wszystko to to tylko garść dodatków do Kubernetesa, które instaluje się w klastrze i z prostego staje się fajne, wyrafinowane, automatyczne, w którym wiele problemów zostało już rozwiązanych. Tak, robimy dużo.
Rozwój ekosystemu
„Wydaje mi się, że jest to bardzo duży wkład w rozwój tego instrumentu i sposobów jego użycia.” Czy potrafisz z grubsza oszacować, kto jeszcze miałby taki sam wkład w rozwój ekosystemu?
Dmitry: W Rosji spośród firm działających na naszym rynku nikt nie jest nawet blisko. Oczywiście to głośne stwierdzenie, bo istnieją główni gracze jak Mail i Yandex – oni też coś robią z Kubernetesem, ale nawet oni nie zbliżają się do wkładu firm z całego świata, które robią znacznie więcej od nas. Jeśli się nie mylę, trudno porównywać Flant, który zatrudnia 80 osób, z Red Hatem, który ma 300 inżynierów na samym Kubernetesie. Trudno to porównać. W dziale badawczo-rozwojowym mamy 6 osób, w tym ja, którzy wycinają wszystkie nasze narzędzia. 6 osób kontra 300 inżynierów Red Hata – jakoś trudno to porównywać.
- Jednak gdy nawet tych 6 osób jest w stanie zrobić coś naprawdę pożytecznego i odstraszającego, gdy stają przed praktycznym problemem i dają rozwiązanie społeczności - to ciekawy przypadek. Rozumiem, że w dużych firmach technologicznych, gdzie mają własny zespół rozwoju i wsparcia Kubernetesa, w zasadzie można opracować te same narzędzia. To dla nich przykład tego, co można rozwijać i dać społeczności, dając impuls całej społeczności korzystającej z Kubernetesa.
Dmitry: Jest to prawdopodobnie cecha integratora, jego osobliwość. Mamy wiele projektów i widzimy wiele różnych sytuacji. Dla nas głównym sposobem na stworzenie wartości dodanej jest analiza tych przypadków, znalezienie podobieństw i uczynienie ich jak najtańszymi dla nas. Aktywnie nad tym pracujemy. Trudno mi mówić o Rosji i świecie, ale w firmie mamy około 40 inżynierów DevOps, którzy pracują na Kubernetesie. Nie sądzę, że w Rosji jest wiele firm z porównywalną liczbą specjalistów rozumiejących Kubernetes, jeśli w ogóle w ogóle.
Rozumiem wszystko na temat stanowiska inżyniera DevOps, każdy wszystko rozumie i jest przyzwyczajony do nazywania inżynierów DevOps inżynierami DevOps, nie będziemy tego omawiać. Wszystkich 40 niesamowitych inżynierów DevOps codziennie mierzy się z problemami i je rozwiązuje. My po prostu analizujemy to doświadczenie i staramy się uogólniać. Rozumiemy, że jeśli pozostanie w nas, to za rok lub dwa narzędzie będzie bezużyteczne, bo gdzieś w społeczności pojawi się gotowa Tula. Nie ma sensu kumulować tego doświadczenia wewnętrznie – to po prostu marnowanie energii i czasu na dev/null. I wcale nam tego nie żal. Z wielką przyjemnością wszystko publikujemy i rozumiemy, że trzeba to opublikować, rozwinąć, wypromować, wypromować, żeby ludzie z tego skorzystali i dodali swoje doświadczenie – wtedy wszystko rośnie i żyje. Następnie po dwóch latach instrument nie ląduje na śmietniku. Nie szkoda dalej nabierać sił, bo widać, że ktoś korzysta z Twojego narzędzia, a po dwóch latach wszyscy z niego korzystają.
Jest to część naszej dużej strategii z dapp/werf. Nie pamiętam kiedy zaczęliśmy to robić, wydaje mi się, że jakieś 3 lata temu. Początkowo było to na ogół na skorupie. To był super dowód koncepcji, rozwiązaliśmy niektóre z naszych konkretnych problemów – zadziałało! Ale są problemy z powłoką, nie da się jej dalej rozwijać, programowanie na powłoce to kolejne zadanie. Mieliśmy zwyczaj pisać w Ruby, w związku z tym przerobiliśmy coś w Ruby, rozwijaliśmy, rozwijaliśmy, rozwijaliśmy i napotkaliśmy fakt, że społeczność, tłum, który nie mówi „chcemy tego lub nie chcemy, ” kręci nosem na Ruby, jakie to zabawne? Zdaliśmy sobie sprawę, że powinniśmy napisać to wszystko w Go, aby spełnić pierwszy punkt na liście kontrolnej: Narzędzie DevOps powinno być statycznym plikiem binarnym. Być Go czy nie, nie jest tak ważne, ale statyczny plik binarny napisany w Go jest lepszy.
Wydaliśmy całą energię, przepisaliśmy dapp w Go i nazwaliśmy go werf. Dapp nie jest już obsługiwany, nie jest rozwijany, działa w jakiejś najnowszej wersji, ale istnieje absolutna ścieżka aktualizacji na sam szczyt i można nią podążać.
Dlaczego powstał dapp?
— Czy możesz nam krótko powiedzieć, po co powstał dapp, jakie problemy rozwiązuje?
Dmitry: Pierwszy powód leży w zgromadzeniu. Początkowo mieliśmy poważne problemy z kompilacją, gdy Docker nie miał możliwości wieloetapowości, więc sami stworzyliśmy wieloetapowość. Potem mieliśmy więcej problemów z czyszczeniem obrazu. Każdy, kto zajmuje się CI/CD, prędzej czy później staje przed problemem tego, że zebranych obrazów jest mnóstwo, trzeba w jakiś sposób wyczyścić to, co niepotrzebne, a zostawić to, co potrzebne.
Drugim powodem jest wdrożenie. Tak, istnieje Helm, ale rozwiązuje tylko część problemów. Co zabawne, napisano, że „Helm to menedżer pakietów dla Kubernetes”. Dokładnie to „the”. Są też słowa „Menedżer pakietów” – jakie są typowe oczekiwania wobec menedżera pakietów? Mówimy: „Menedżer pakietów - zainstaluj pakiet!” i oczekujemy, że powie nam: „Paczka została dostarczona”.
Ciekawe, że mówimy: „Helm, zainstaluj pakiet”, a kiedy odpowiada, że go zainstalował, okazuje się, że właśnie rozpoczął instalację - wskazał Kubernetesa: „Uruchom to!” i czy się uruchomił, czy nie niezależnie od tego, czy to działa, czy nie, Helm w ogóle nie rozwiązuje tego problemu.
Okazuje się, że Helm to po prostu preprocesor tekstu, który ładuje dane do Kubernetesa.
Ale w ramach każdego wdrożenia chcemy wiedzieć, czy aplikacja została wypuszczona do produkcji, czy nie? Wdrożenie na prod oznacza, że aplikacja została tam przeniesiona, nowa wersja została wdrożona, przynajmniej tam nie zawiesza się i reaguje poprawnie. Helm w żaden sposób nie rozwiązuje tego problemu. Aby go rozwiązać, trzeba włożyć dużo wysiłku, ponieważ trzeba wydać Kubernetesowi polecenie wdrożenia i monitorowania tego, co się tam dzieje - niezależnie od tego, czy zostało wdrożone, czy wdrożone. Istnieje również wiele zadań związanych z wdrażaniem, czyszczeniem i montażem.
Plany
W tym roku rozpoczniemy rozwój lokalny. Chcemy osiągnąć to, co było wcześniej w Vagrant – wpisaliśmy „vagrant up” i wdrożyliśmy maszyny wirtualne. Chcemy dojść do momentu, w którym w Gicie jest projekt, piszemy tam „werf up” i wyświetla się lokalna kopia tego projektu, wdrożona w lokalnym mini-Kubie, z podłączonymi wszystkimi wygodnymi do programowania katalogami . W zależności od języka programowania robi się to inaczej, niemniej jednak tak, aby rozwój lokalny mógł być wygodnie przeprowadzany w zamontowanych plikach.
Następnym krokiem dla nas jest inwestuj w wygodę dla programistów. Aby szybko wdrożyć projekt lokalnie za pomocą jednego narzędzia, opracuj go, wepchnij do Git, a także zostanie on wdrożony do etapu lub testów, w zależności od potoków, a następnie użyj tego samego narzędzia, aby przejść do produkcji. Ta jedność, ujednolicenie, powtarzalność infrastruktury od środowiska lokalnego po sprzedaż jest dla nas bardzo ważnym punktem. Ale to jeszcze nie jest werf – dopiero planujemy to zrobić.
Ale droga do dapp/werf zawsze była taka sama, jak w przypadku Kubernetes na początku. Napotkaliśmy problemy, rozwiązaliśmy je obejściami - wymyśliliśmy dla siebie pewne rozwiązania na powłoce, na czymkolwiek. Następnie próbowali w jakiś sposób wyprostować te obejścia, uogólnić i skonsolidować je w postaci binarnej, w tym przypadku, którą po prostu udostępniamy.
Na całą tę historię można spojrzeć jeszcze inaczej, posługując się analogiami.
Kubernetes to rama samochodu z silnikiem. Nie ma drzwi, szkła, radia, choinki – zupełnie nic. Tylko rama i silnik. I jest Helm - to jest kierownica. Fajnie - jest kierownica, ale potrzebny jest też sworzeń kierowniczy, drążek kierowniczy, skrzynia biegów i koła, a bez nich nie można się obejść.
W przypadku werf jest to kolejny komponent Kubernetesa. Dopiero teraz, na przykład, w wersji alfa werf Helm jest kompilowany wewnątrz werf, ponieważ jesteśmy zmęczeni robieniem tego sami. Powodów jest wiele, opowiem szczegółowo dlaczego skompletowaliśmy cały ster wraz z rumplem wewnątrz werf .
Teraz werf jest bardziej zintegrowanym komponentem. Dostajemy gotową kierownicę, sworzeń kierownicy - nie jestem zbyt dobry w samochodach, ale jest to duży klocek, który już rozwiązuje dość szeroki zakres problemów. Nie musimy sami przeglądać katalogu, wybierać jedną część za drugą, zastanawiać się, jak je skręcić. Otrzymujemy gotowy kombajn, który rozwiązuje dużą liczbę problemów na raz. Ale wewnątrz jest zbudowany z tych samych komponentów open source, nadal używa Dockera do montażu, Helma do niektórych funkcji i istnieje kilka innych bibliotek. Jest to zintegrowane narzędzie umożliwiające szybkie i wygodne uruchamianie CI/CD od razu po wyjęciu z pudełka.
Czy Kubernetes jest trudny w utrzymaniu?
— Mówisz o tym, jak zacząłeś korzystać z Kubernetesa, to dla ciebie rama, silnik, na którym można powiesić mnóstwo różnych rzeczy: karoserię, kierownicę, przykręcane pedały, siedzenia. Powstaje pytanie – jak trudne jest dla Ciebie wsparcie Kubernetesa? Masz duże doświadczenie, ile czasu i zasobów przeznaczasz na wspieranie Kubernetesa w oderwaniu od wszystkiego innego?
Dmitry: To bardzo trudne pytanie i aby odpowiedzieć, musimy zrozumieć, czym jest wsparcie i czego oczekujemy od Kubernetesa. Może ujawnisz?
— Z tego, co wiem i widzę, obecnie wiele zespołów chce wypróbować Kubernetes. Każdy się do tego zaprzęga, kładzie na kolanach. Mam wrażenie, że ludzie nie zawsze rozumieją złożoność tego systemu.
Dmitry: To tak.
— Jak trudno jest pobrać i zainstalować Kubernetesa od zera, tak aby był gotowy do produkcji?
Dmitry: Jak myślisz, jak trudno jest przeszczepić serce? Rozumiem, że to pytanie kompromitujące. Używanie skalpela i nie popełnianie błędów nie jest takie trudne. Jeśli powiedzą ci, gdzie wyciąć i gdzie uszyć, sama procedura nie jest skomplikowana. Trudno zagwarantować za każdym razem, że wszystko się ułoży.
Instalacja Kubernetesa i uruchomienie go jest łatwe: kurczę! — zainstalowany, istnieje wiele metod instalacji. Ale co się stanie, gdy pojawią się problemy?
Zawsze pojawiają się pytania – czego jeszcze nie wzięliśmy pod uwagę? Czego jeszcze nie zrobiliśmy? Które parametry jądra Linuksa zostały określone niepoprawnie? Panie, czy w ogóle o nich wspominaliśmy?! Które komponenty Kubernetes dostarczyliśmy, a które nie? Pojawiają się tysiące pytań, a żeby na nie odpowiedzieć, trzeba spędzić 15-20 lat w tej branży.
Mam niedawny przykład na ten temat, który może ujawnić znaczenie problemu „Czy Kubernetes jest trudny w utrzymaniu?” Jakiś czas temu poważnie zastanawialiśmy się, czy nie spróbować wdrożyć Cilium jako sieci w Kubernetesie.
Pozwólcie, że wyjaśnię, czym jest Cilium. Kubernetes ma wiele różnych implementacji podsystemu sieciowego, a jedna z nich jest bardzo fajna – Cilium. Jakie jest jego znaczenie? W jądrze jakiś czas temu stało się możliwe pisanie haków dla jądra, które w ten czy inny sposób atakują podsystem sieciowy i różne inne podsystemy i pozwalają ominąć duże fragmenty jądra.
Jądro Linuksa historycznie posiada routing IP, filtr nadmiarowy, mosty i wiele różnych starych komponentów, które mają 15, 20, 30 lat. Ogólnie działają, wszystko jest super, ale teraz ułożyli kontenery w stosy i wygląda to jak wieża z 15 cegieł jedna na drugiej, a ty stoisz na jednej nodze - dziwne uczucie. System ten rozwijał się historycznie z wieloma niuansami, takimi jak wyrostek robaczkowy w ciele. W niektórych sytuacjach występują na przykład problemy z wydajnością.
Jest wspaniały BPF i możliwość pisania hooków dla jądra - chłopaki napisali własne hooki dla jądra. Pakiet wchodzi do jądra Linuksa, pobierają go bezpośrednio na wejściu, sami przetwarzają tak, jak powinien, bez mostów, bez TCP, bez stosu IP - krótko mówiąc, omijając wszystko, co jest zapisane w jądrze Linuksa, a następnie wypluwają go do pojemnika.
Co się stało? Bardzo fajna wydajność, fajne funkcje - po prostu super! Ale patrzymy na to i widzimy, że na każdej maszynie znajduje się program, który łączy się z API Kubernetes i na podstawie danych otrzymanych z tego API generuje kod C i kompiluje pliki binarne, które ładuje do jądra, tak aby te hooki działały w przestrzeni jądra.
Co się stanie, jeśli coś pójdzie nie tak? Nie wiemy. Aby to zrozumieć, musisz przeczytać cały ten kod, zrozumieć całą logikę i niesamowite, jakie to trudne. Ale z drugiej strony są te mosty, filtry sieciowe, routing ip – nie czytałem ich kodu źródłowego, podobnie jak 40 inżynierów, którzy pracują w naszej firmie. Może tylko nieliczni rozumieją niektóre części.
A jaka jest różnica? Okazuje się, że istnieje ip rout, jądro Linuksa i nowe narzędzie - co za różnica, nie rozumiemy ani jednego, ani drugiego. Ale boimy się użyć czegoś nowego - dlaczego? Bo jeśli narzędzie ma 30 lat, to w ciągu 30 lat wykryto wszystkie błędy, nadeptano wszystkie błędy i nie trzeba o wszystkim wiedzieć – działa jak czarna skrzynka i działa zawsze. Każdy wie jaki śrubokręt diagnostyczny w które miejsce wpiąć, jaki tcpdump w jakim momencie uruchomić. Każdy dobrze zna narzędzia diagnostyczne i rozumie, jak ten zestaw komponentów działa w jądrze Linuksa - nie jak to działa, ale jak go używać.
A niesamowicie fajna Cilium nie ma 30 lat, jeszcze się nie zestarzała. Kubernetes ma ten sam problem, kopia. Że Cilium jest zainstalowane idealnie, że Kubernetes jest zainstalowany idealnie, ale gdy coś pójdzie nie tak na produkcji, czy w krytycznej sytuacji jesteś w stanie szybko zrozumieć, co poszło nie tak?
Kiedy mówimy, czy utrzymanie Kubernetesa jest trudne – nie, jest to bardzo łatwe i tak, jest niesamowicie trudne. Kubernetes działa świetnie sam, ale z miliardem niuansów.
O podejściu „będę miał szczęście”.
— Czy są firmy, w których występowanie tych niuansów jest niemal pewne? Załóżmy, że Yandex nagle przeniesie wszystkie usługi do Kubernetesa, będzie tam ogromne obciążenie.
Dmitry: Nie, to nie jest rozmowa o obciążeniu, ale o najprostszych rzeczach. Przykładowo mamy Kubernetesa, tam wdrożyliśmy aplikację. Skąd wiesz, że to działa? Po prostu nie ma gotowego narzędzia, które pozwoliłoby zrozumieć, czy aplikacja się nie zawiesza. Nie ma gotowego systemu wysyłającego alerty, trzeba skonfigurować te alerty i każdy harmonogram. Aktualizujemy Kubernetes.
Mam Ubuntu 16.04. Można powiedzieć, że jest to stara wersja, ale nadal na niej pracujemy, bo jest to LTS. Istnieje systemd, którego niuans polega na tym, że nie czyści grup C. Kubernetes uruchamia pody, tworzy grupy C, następnie usuwa pody i jakoś okazuje się – nie pamiętam szczegółów, przepraszam – że pozostają plasterki systemowe. Prowadzi to do tego, że z czasem każdy samochód zaczyna mocno zwalniać. To nawet nie jest pytanie o duże obciążenie. Jeśli na przykład uruchomione zostaną stałe pody, jeśli istnieje zadanie Cron, które stale generuje pody, to maszyna z Ubuntu 16.04 zacznie zwalniać po tygodniu. Średnie obciążenie będzie stale wysokie, co wynika z faktu, że utworzono kilka grup C. To problem, przed którym stanie każda osoba, która po prostu zainstaluje Ubuntu 16 i Kubernetes na wierzchu.
Powiedzmy, że w jakiś sposób aktualizuje systemd lub coś innego, ale w jądrze Linuksa do wersji 4.16 jest jeszcze zabawniej - kiedy usuwasz grupy C, wyciekają one do jądra i tak naprawdę nie są usuwane. Dlatego po miesiącu pracy na tej maszynie nie będzie już możliwości sprawdzenia statystyk pamięci palenisk. Wyciągamy plik, wrzucamy go do programu, a jeden plik przewija się przez 15 sekund, ponieważ jądro bardzo długo liczy w sobie milion grup C, które wydają się usunięte, ale nie - przeciekają .
Tu i ówdzie wciąż jest mnóstwo takich drobiazgów. Nie jest to problem, z którym gigantyczne firmy mogą czasami się zmierzyć pod bardzo dużymi obciążeniami – nie, to kwestia codziennych spraw. Ludzie mogą tak żyć miesiącami – zainstalowali Kubernetesa, wdrożyli aplikację – wygląda na to, że działa. Dla wielu osób jest to normalne. Nawet nie będą wiedzieć, że ta aplikacja z jakiegoś powodu ulegnie awarii, nie otrzymają powiadomienia, ale dla nich to norma. Wcześniej żyliśmy na maszynach wirtualnych bez monitoringu, teraz przenieśliśmy się na Kubernetes, także bez monitoringu – jaka jest różnica?
Pytanie jest takie, że chodząc po lodzie, nigdy nie poznamy jego grubości, jeśli nie zmierzymy jej wcześniej. Wiele osób chodzi i nie martwi się, ponieważ chodziło już wcześniej.
Z mojego punktu widzenia niuanse i złożoność obsługi dowolnego systemu polegają na tym, aby grubość lodu była dokładnie wystarczająca do rozwiązania naszych problemów. O tym właśnie mówimy.
Wydaje mi się, że w IT istnieje zbyt wiele podejść typu „będę szczęśliwy”. Wiele osób instaluje oprogramowanie i korzysta z bibliotek oprogramowania w nadziei, że im się poszczęści. Ogólnie rzecz biorąc, wiele osób ma szczęście. Pewnie dlatego to działa.
— Z mojej pesymistycznej oceny wygląda to tak: gdy ryzyko jest duże, a aplikacja musi działać, to potrzebne jest wsparcie ze strony Flaunta, być może Red Hata, lub potrzebny jest własny, wewnętrzny zespół dedykowany specjalnie do Kubernetesa, który jest gotowy żeby to zdjąć.
Dmitry: Obiektywnie tak jest. Samodzielne zapoznawanie się z historią Kubernetes dla małego zespołu wiąże się z wieloma zagrożeniami.
Czy potrzebujemy kontenerów?
— Czy możesz nam powiedzieć, jak powszechny jest Kubernetes w Rosji?
Dmitry: Nie mam tych danych i nie jestem pewien, czy ktokolwiek inny je ma. Mówimy: „Kubernetes, Kubernetes”, ale jest inny sposób spojrzenia na to zagadnienie. Nie wiem też, jak powszechne są kontenery, ale znam dane z raportów w Internecie, że 70% kontenerów jest orkiestrowanych przez Kubernetes. Było to wiarygodne źródło dla dość dużej próby na całym świecie.
Następnie kolejne pytanie - czy potrzebujemy kontenerów? Moje osobiste odczucie i ogólne stanowisko firmy Flant jest takie, że Kubernetes jest de facto standardem.
Nie będzie nic poza Kubernetesem.
To absolutna rewolucja w dziedzinie zarządzania infrastrukturą. Po prostu absolut - to wszystko, koniec z Ansible, Chefem, maszynami wirtualnymi, Terraformem. Nie mówię o starych metodach kołchozów. Kubernetes to absolutna zmiana, a teraz będzie tylko tak.
Oczywiste jest, że niektórym zajmuje to kilka lat, a innym kilka dekad, zanim sobie to uświadomią. Nie mam wątpliwości, że nie pozostanie nic innego, jak tylko Kubernetes i ten nowy wygląd: nie szkodzimy już systemowi operacyjnemu, ale korzystamy infrastruktura jako kod, tylko nie kodem, ale yml - deklaratywnie opisaną infrastrukturą. Mam wrażenie, że tak będzie zawsze.
— Czyli te firmy, które jeszcze nie przeszły na Kubernetesa, na pewno przejdą na niego lub pozostaną w zapomnieniu. Dobrze Cię zrozumiałem?
Dmitry: To również nie jest do końca prawdą. Przykładowo, jeśli mamy za zadanie uruchomić serwer DNS, to da się go uruchomić na FreeBSD 4.10 i może działać idealnie przez 20 lat. Po prostu pracować i tyle. Być może za 20 lat trzeba będzie coś choć raz zaktualizować. Jeśli mówimy o oprogramowaniu w formacie, który uruchomiliśmy i faktycznie działa on przez wiele lat bez aktualizacji, bez dokonywania zmian, to oczywiście Kubernetesa nie będzie. Nie jest tam potrzebny.
Wszystko co związane z CI/CD - wszędzie tam, gdzie potrzebne jest Continuous Delivery, gdzie trzeba aktualizować wersje, wprowadzać aktywne zmiany, wszędzie tam, gdzie trzeba budować odporność na awarie - tylko Kubernetes.
O mikroserwisach
- Tutaj mam lekki dysonans. Do pracy z Kubernetesem potrzebne jest wsparcie zewnętrzne lub wewnętrzne – to jest punkt pierwszy. Po drugie, kiedy dopiero zaczynamy rozwój, jesteśmy małym startupem, jeszcze nic nie mamy, rozwój pod Kubernetesa czy ogólnie architekturę mikroserwisową może być złożony i nie zawsze uzasadniony ekonomicznie. Ciekawi mnie Twoja opinia – czy startupy muszą od razu zacząć pisać dla Kubernetesa od zera, czy mogą jeszcze napisać monolit, a potem dopiero przychodzić na Kubernetes?
Dmitry: Fajne pytanie. Mówię o mikroserwisach Wielokrotnie spotkałem ludzi próbujących wbijać gwoździe pod mikroskopem. Samo podejście jest prawidłowe, sami projektujemy w ten sposób nasze wewnętrzne oprogramowanie. Ale kiedy to robisz, musisz jasno zrozumieć, co robisz. Słowo, którego najbardziej nienawidzę w odniesieniu do mikrousług, to „mikro”. Historycznie rzecz biorąc, to słowo powstało właśnie tam i z jakiegoś powodu ludzie myślą, że mikro jest bardzo małe, mniejsze niż milimetr, jak mikrometr. To jest źle.
Na przykład istnieje monolit napisany przez 300 osób i każdy, kto brał udział w opracowaniu, rozumie, że są w nim problemy i należy go podzielić na mikrocząsteczki - około 10 sztuk, z których każda jest napisana przez 30 osób w wersji minimalnej. To ważne, potrzebne i fajne. Ale kiedy przychodzi do nas startup, w którym 3 bardzo fajnych i utalentowanych chłopaków napisało na kolanach 60 mikroserwisów, za każdym razem szukam Corvalolu.
Wydaje mi się, że było to już poruszane tysiące razy – otrzymaliśmy w takiej czy innej formie rozproszony monolit. Nie jest to uzasadnione ekonomicznie, w ogóle jest to bardzo trudne we wszystkim. Widziałem to tyle razy, że naprawdę mnie to boli, więc nadal o tym mówię.
Z pytaniem początkowym istnieje konflikt pomiędzy tym, że z jednej strony Kubernetes jest straszny w użyciu, bo nie wiadomo, co może się tam zepsuć, a co nie działać, z drugiej strony jest jasne, że wszystko tam idzie i nic poza Kubernetesem nie będzie istnieć. Odpowiedź - zważ ilość korzyści, jakie z tego wynikną, ilość zadań, które możesz rozwiązać. To jest po jednej stronie skali. Z drugiej strony istnieją ryzyka związane z przestojami lub skróceniem czasu reakcji, poziomu dostępności – wraz ze spadkiem wskaźników wydajności.
I oto jest – albo poruszamy się szybko, a Kubernetes pozwala nam robić wiele rzeczy znacznie szybciej i lepiej, albo korzystamy z niezawodnych, sprawdzonych w czasie rozwiązań, ale poruszamy się znacznie wolniej. To wybór, którego musi dokonać każda firma. Można o niej myśleć jak o ścieżce w dżungli – kiedy idziesz po raz pierwszy, możesz spotkać węża, tygrysa lub szalonego borsuka, a kiedy przeszedłeś 10 razy, przeszedłeś tę ścieżkę, usunięto gałęzie i chodzić łatwiej. Za każdym razem ścieżka staje się szersza. Dalej jest już droga asfaltowa, a później piękny bulwar.
Kubernetes nie stoi w miejscu. Pytanie jeszcze raz: Kubernetes to z jednej strony 4-5 plików binarnych, z drugiej to cały ekosystem. To jest system operacyjny, który mamy na naszych komputerach. Co to jest? Ubuntu czy Curios? To jest jądro Linuksa, kilka dodatkowych komponentów. To wszystko tutaj, jednego jadowitego węża wyrzucono z drogi, postawiono tam płot. Kubernetes rozwija się bardzo szybko i dynamicznie, a wolumen ryzyk, wolumen nieznanego z każdym miesiącem maleje, a co za tym idzie, te skale się równoważą.
Odpowiadając na pytanie, co powinien zrobić startup, powiedziałbym - przyjdź do Flaunt, zapłać 150 tysięcy rubli i uzyskaj łatwą usługę DevOps pod klucz. Jeśli jesteś małym startupem z kilkoma programistami, to działa. Zamiast zatrudniać własnego DevOpsa, który będzie musiał nauczyć się rozwiązywać Twoje problemy i płacić pensję w tym czasie, otrzymasz rozwiązanie wszystkich problemów pod klucz. Tak, są pewne wady. Jako outsourcer nie możemy być aż tak zaangażowani i szybko reagować na zmiany. Mamy jednak dużą wiedzę i gotowe praktyki. Gwarantujemy, że w każdej sytuacji na pewno szybko rozwiążemy problem i wskrzesimy Kubernetesa z martwych.
Zdecydowanie polecam outsourcing start-upom i dojrzałym firmom do takiej wielkości, w której do operacji można dedykować 10-osobowy zespół, bo inaczej nie ma to sensu. Zdecydowanie warto zlecić to podmiotom zewnętrznym.
O Amazonie i Google
— Czy hosta z rozwiązania Amazon lub Google można uznać za outsourcing?
Dmitry: Tak, oczywiście, to rozwiązuje wiele problemów. Ale znowu są niuanse. Nadal musisz zrozumieć, jak z niego korzystać. Na przykład w pracy Amazon AWS jest tysiąc małych rzeczy: trzeba rozgrzać Load Balancer lub wcześniej napisać prośbę, że „chłopaki, przyjmiemy ruch, rozgrzejcie dla nas Load Balancer!” Musisz znać te niuanse.
Kiedy zwrócisz się do ludzi, którzy się w tym specjalizują, prawie wszystkie typowe sprawy zostaną zamknięte. Obecnie mamy 40 inżynierów, do końca roku będzie ich prawdopodobnie 60 – z tym wszystkim na pewno się zetknęliśmy. Nawet jeśli ponownie napotkamy ten problem w jakimś projekcie, szybko zadajemy sobie nawzajem pytania i wiemy, jak go rozwiązać.
Prawdopodobnie odpowiedź brzmi – oczywiście hostowana historia ułatwia pewne części. Pytanie brzmi, czy jesteś gotowy zaufać tym hosterom i czy rozwiążą Twoje problemy. Amazon i Google radzą sobie dobrze. We wszystkich naszych przypadkach - dokładnie. Nie mamy już żadnych pozytywnych doświadczeń. Wszystkie inne chmury, z którymi próbowaliśmy pracować, stwarzają wiele problemów - Ager i wszystko, co jest w Rosji, oraz wszelkiego rodzaju OpenStack w różnych implementacjach: Headster, Overage - co tylko chcesz. Wszystkie tworzą problemy, których nie chcesz rozwiązać.
Dlatego odpowiedź brzmi: tak, ale w rzeczywistości nie ma zbyt wielu dojrzałych rozwiązań hostowanych.
Kto potrzebuje Kubernetesa?
— A jednak komu potrzebny Kubernetes? Kto powinien już przejść na Kubernetes, kto jest typowym klientem Flaunt, który przychodzi specjalnie dla Kubernetes?
Dmitry: To ciekawe pytanie, ponieważ właśnie teraz, po Kubernetesie, przychodzi do nas wiele osób: „Chłopaki, wiemy, że robicie Kubernetes, zróbcie to dla nas!” Odpowiadamy im: „Panowie, nie robimy Kubernetesa, tylko prod i wszystko co z tym związane.” Ponieważ obecnie po prostu niemożliwe jest stworzenie produktu bez wykonania wszystkich CI/CD i całej tej historii. Wszyscy odeszli od podziału, w którym mamy rozwój za rozwojem, a następnie wyzysk za wyzyskiem.
Nasi klienci oczekują różnych rzeczy, ale każdy czeka na jakiś dobry cud, że mają pewne problemy, a teraz – hop! — Kubernetes je rozwiąże. Ludzie wierzą w cuda. W myślach rozumieją, że cudu nie będzie, ale w duszach mają nadzieję – a co jeśli ten Kubernetes teraz wszystko za nas rozwiąże, tyle o tym mówią! Nagle on teraz - kichnij! - i złoty środek, kichnij! — i mamy 100% czasu sprawności, wszyscy programiści mogą wypuścić wszystko, co trafi do produkcji 50 razy i nie ulegnie to awarii. Ogólnie rzecz biorąc, cud!
Kiedy takie osoby zgłaszają się do nas, mówimy: „Przykro nam, ale cudu nie ma”. Aby być zdrowym, trzeba dobrze się odżywiać i ćwiczyć. Aby produkt był niezawodny, musi być solidnie wykonany. Aby mieć wygodny CI/CD, musisz zrobić to w ten sposób. To dużo pracy, którą trzeba wykonać.
Odpowiadając na pytanie komu potrzebny Kubernetes – Kubernetes nie jest nikomu potrzebny.
Niektórzy ludzie błędnie myślą, że potrzebują Kubernetesa. Ludzie potrzebują, mają głęboką potrzebę, aby przestać myśleć, studiować i interesować się wszystkimi problemami infrastruktury i problemami związanymi z uruchamianiem aplikacji. Chcą, aby aplikacje po prostu działały i można je było po prostu wdrażać. Kubernetes jest dla nich nadzieją, że przestaną słyszeć historię o tym, że „leżeliśmy tam”, „nie możemy wystartować” czy jeszcze coś innego.
Zwykle przychodzi do nas dyrektor techniczny. Proszą go o dwie rzeczy: z jednej strony o nadanie nam cech, z drugiej o stabilność. Sugerujemy, abyś wziął to na siebie i zrobił to. Srebrna kula, a raczej posrebrzana, polega na tym, że przestaniesz myśleć o tych problemach i marnować czas. Będziesz miał wyjątkowych ludzi, którzy zamkną tę kwestię.
Sformułowanie, że my lub ktokolwiek inny potrzebuje Kubernetes, jest nieprawidłowe.
Adminom naprawdę potrzebny jest Kubernetes, bo to bardzo ciekawa zabawka, przy której można się bawić i majstrować. Nie oszukujmy się – każdy kocha zabawki. Wszyscy jesteśmy gdzieś dziećmi i kiedy widzimy nowe, chcemy się nim bawić. Niektórym to zniechęcało np. w administracji, bo grali już wystarczająco dużo i są już tak zmęczeni, że po prostu nie chce się. Ale to nie jest całkowicie stracone dla nikogo. Przykładowo, jeśli już dawno znudziły mi się zabawki z zakresu administracji systemami i DevOps, to nadal kocham te zabawki, wciąż kupuję nowe. Wszyscy ludzie, w ten czy inny sposób, nadal chcą jakiegoś rodzaju zabawek.
Nie ma potrzeby bawić się produkcją. Czegokolwiek kategorycznie nie polecam robić i co teraz widzę masowo: „Och, nowa zabawka!” — pobiegli, żeby to kupić, kupili i: „Zabierzmy to teraz do szkoły i pokażmy wszystkim znajomym”. Nie rób tego. Przepraszam, moje dzieci dopiero dorastają, ciągle coś widzę w dzieciach, zauważam to w sobie, a potem uogólniam to na innych.
Ostateczna odpowiedź brzmi: nie potrzebujesz Kubernetesa. Musisz rozwiązać swoje problemy.
To, co możesz osiągnąć to:
- prod nie spada;
- nawet jeśli spróbuje upaść, wiemy o tym z góry i możemy coś w to włożyć;
- możemy to zmienić w tempie, jakiego wymaga nasza działalność, i możemy to zrobić wygodnie, nie sprawia nam to żadnych problemów.
Istnieją dwie rzeczywiste potrzeby: niezawodność i dynamika/elastyczność wdrożenia. Każdy, kto obecnie realizuje jakieś projekty informatyczne, niezależnie od rodzaju biznesu - soft do ułatwiania świata i kto to rozumie, musi te potrzeby rozwiązać. Kubernetes przy właściwym podejściu, z właściwym zrozumieniem i wystarczającym doświadczeniem pozwala je rozwiązać.
O bezserwerowym
— Jeśli spojrzymy nieco dalej w przyszłość, to próbując rozwiązać problem braku problemów z infrastrukturą, szybkością wdrażania i szybkością zmian aplikacji, pojawiają się nowe rozwiązania, na przykład bezserwerowe. Czy czujesz potencjał w tym kierunku i, powiedzmy, zagrożenie dla Kubernetesa i podobnych rozwiązań?
Dmitry: W tym miejscu jeszcze raz musimy zaznaczyć, że nie jestem wieszczem, który patrzy przed siebie i mówi – tak będzie! Chociaż właśnie zrobiłem to samo. Patrzę na swoje stopy i widzę tam masę problemów, na przykład działanie tranzystorów w komputerze. To zabawne, prawda? Napotykamy pewne błędy w procesorze.
Spraw, aby rozwiązania bezserwerowe były dość niezawodne, tanie, wydajne i wygodne, rozwiązując wszystkie problemy ekosystemu. Zgadzam się w tym miejscu z Elonem Muskiem, że potrzebna jest druga planeta, aby zapewnić ludzkości odporność na błędy. Chociaż nie wiem, co on mówi, rozumiem, że nie jestem gotowy, aby sam polecieć na Marsa i nie stanie się to jutro.
W przypadku bezserwerowego jasne jest, że jest to rzecz poprawna ideologicznie, podobnie jak tolerancja błędów ludzkości – posiadanie dwóch planet jest lepsze niż jednej. Ale jak to teraz zrobić? Wysłanie jednej wyprawy nie stanowi problemu, jeśli skoncentrujesz na niej swoje wysiłki. Wysłanie kilku ekspedycji i osiedlenie tam kilku tysięcy ludzi też jest, moim zdaniem, realne. Ale uczynienie go całkowicie odpornym na błędy, aby mieszkała tam połowa ludzkości, wydaje mi się teraz niemożliwe, nie brane pod uwagę.
Z bezserwerowym jeden na jednego: sprawa jest fajna, ale daleko jej do problemów 2019 roku. Bliżej roku 2030 – dożyjmy, żeby to zobaczyć. Nie wątpię, że przeżyjemy, na pewno przeżyjemy (powtórz przed pójściem spać), ale teraz musimy rozwiązać inne problemy. To jakby wierzyć w bajkowego kucyka Rainbow. Tak, kilka procent spraw zostało rozwiązanych i to rozwiązanych perfekcyjnie, ale subiektywnie serwerless to tęcza... Dla mnie ten temat jest zbyt odległy i zbyt niezrozumiały. Nie jestem gotowy na rozmowę. W 2019 roku nie można napisać ani jednej aplikacji bezserwerowej.
Jak Kubernetes będzie ewoluował
— W miarę zbliżania się do tej potencjalnie wspaniałej odległej przyszłości, jak według Ciebie rozwinie się Kubernetes i otaczający go ekosystem?
Dmitry: Dużo o tym myślałem i mam jasną odpowiedź. Pierwsza jest stanowa - w końcu bezpaństwowość jest łatwiejsza. Kubernetes początkowo zainwestował w to więcej, od tego wszystko się zaczęło. Stateless działa na Kubernetesie niemal idealnie, po prostu nie ma na co narzekać. Nadal istnieje wiele problemów, a raczej niuansów. Wszystko tam już działa dla nas świetnie, ale to my. Zanim to zadziała dla wszystkich, minie jeszcze co najmniej kilka lat. To nie jest wyliczony wskaźnik, ale moje odczucie z głowy.
Krótko mówiąc, statefull powinien - i będzie - rozwijać się bardzo mocno, ponieważ wszystkie nasze aplikacje przechowują status; nie ma aplikacji bezstanowych. To złudzenie; zawsze potrzebujesz jakiejś bazy danych i czegoś innego. Statefull polega na wyprostowaniu wszystkiego, co się da, naprawieniu wszystkich błędów, naprawieniu wszystkich problemów, z którymi obecnie się borykamy – nazwijmy to adopcją.
Poziom nieznanego, poziom nierozwiązanych problemów, poziom prawdopodobieństwa napotkania czegoś znacznie spadną. To ważna historia. Oraz operatorzy – wszystko, co jest związane z kodowaniem logiki administracyjnej, logiki sterującej, aby uzyskać łatwą obsługę: łatwa obsługa MySQL, łatwa obsługa RabbitMQ, łatwa obsługa Memcache – ogólnie rzecz biorąc, wszystkie te komponenty, z których musimy mieć pewność, że zadziałają pudełko. To po prostu rozwiązuje problem polegający na tym, że chcemy bazy danych, ale nie chcemy nią administrować, lub chcemy Kubernetesa, ale nie chcemy nim administrować.
Ta historia rozwoju operatorów w takiej czy innej formie będzie ważna w ciągu najbliższych kilku lat.
Myślę, że komfort obsługi powinien znacznie wzrosnąć – pudełko będzie coraz bardziej czarne, coraz bardziej niezawodne, z coraz prostszymi pokrętłami.
Słuchałem kiedyś starego wywiadu z Izaakiem Asimowem z lat 80. na YouTubie w Saturday Night Live – program taki jak Urgant, tylko ciekawy. Zapytali go o przyszłość komputerów. Powiedział, że przyszłość kryje się w prostocie, tak jak radio. Odbiornik radiowy był pierwotnie skomplikowaną rzeczą. Aby złapać falę, trzeba było kręcić pokrętła przez 15 minut, przekręcać patyki i ogólnie wiedzieć, jak to wszystko działa, rozumieć fizykę transmisji fal radiowych. W rezultacie w radiu pozostało tylko jedno pokrętło.
Teraz w 2019 jakie radio? W samochodzie odbiornik radiowy wyszukuje wszystkie fale i nazwy stacji. Fizyka procesu nie zmieniła się od 100 lat, ale łatwość użycia tak. Teraz i nie tylko teraz, już w 1980 roku, kiedy był wywiad z Azimovem, wszyscy korzystali z radia i nikt nie zastanawiał się, jak to działa. To zawsze działało – to oczywiste.
Azimow powiedział następnie, że z komputerami będzie tak samo - wzrośnie łatwość obsługi. Podczas gdy w 1980 roku trzeba było uczyć się naciskania przycisków na komputerze, w przyszłości nie będzie to możliwe.
Mam wrażenie, że dzięki Kubernetesowi i infrastrukturze nastąpi także ogromny wzrost łatwości obsługi. To moim zdaniem jest oczywiste – leży na powierzchni.
Co zrobić z inżynierami?
— Co wtedy stanie się z inżynierami i administratorami systemów obsługującymi Kubernetes?
Dmitry: Co stało się z księgowym po pojawieniu się 1C? O tym samym. Wcześniej liczyli na papierze – teraz w programie. Wydajność pracy wzrosła o rzędy wielkości, ale sama praca nie zniknęła. Jeśli wcześniej do wkręcenia żarówki potrzeba było 10 inżynierów, teraz wystarczy jeden.
Wydaje mi się, że ilość oprogramowania i liczba zadań rośnie teraz szybciej niż pojawiają się nowe DevOps, a wydajność rośnie. Na rynku jest teraz specyficzny niedobór i będzie on trwał długo. Później wszystko wróci do jakiejś normalności, w którym wzrośnie wydajność pracy, będzie coraz więcej bezserwerów, do Kubernetesa zostanie podłączony neuron, który będzie dobierał wszystkie zasoby dokładnie tak, jak potrzeba i w ogóle będzie zrób wszystko sam, tak jak powinien - osoba po prostu odejdzie i nie wtrąca się.
Ale ktoś i tak będzie musiał podjąć decyzje. Wyraźnie widać, że poziom kwalifikacji i specjalizacji tej osoby jest wyższy. W dzisiejszych czasach w księgowości nie potrzeba 10 pracowników prowadzących księgi, żeby nie męczyły ich ręce. To po prostu nie jest konieczne. Wiele dokumentów jest automatycznie skanowanych i rozpoznawanych przez elektroniczny system zarządzania dokumentami. Wystarczy jeden mądry główny księgowy, już ze znacznie większymi umiejętnościami, z dobrym zrozumieniem.
Ogólnie rzecz biorąc, tak należy postępować we wszystkich branżach. Podobnie jest z samochodami: wcześniej samochód przyjeżdżał z mechanikiem i trzema kierowcami. W obecnych czasach prowadzenie samochodu to prosty proces, w którym na co dzień uczestniczymy wszyscy. Nikt nie uważa, że samochód to coś skomplikowanego.
DevOps czy inżynieria systemów nie odejdą w niepamięć – wzrośnie praca na wysokim poziomie i wydajność.
— Słyszałem też ciekawy pomysł, że praca faktycznie wzrośnie.
Dmitry: Oczywiście, na sto procent! Ponieważ ilość oprogramowania, które piszemy, stale rośnie. Liczba problemów, które rozwiązujemy za pomocą oprogramowania, stale rośnie. Ilość pracy rośnie. Teraz rynek DevOps jest strasznie przegrzany. Widać to po oczekiwaniach płacowych. W dobrym tego słowa znaczeniu, bez wchodzenia w szczegóły, powinni być juniorzy, którzy chcą X, średni, którzy chcą 1,5X i seniorzy, którzy chcą 2X. A teraz, jeśli spojrzysz na moskiewski rynek wynagrodzeń DevOps, junior chce od X do 3X, a senior chce od X do 3X.
Nikt nie wie, ile to kosztuje. Poziom wynagrodzenia mierzony jest pewnością siebie – kompletny dom wariatów, szczerze mówiąc, strasznie przegrzany rynek.
Oczywiście sytuacja ta już niedługo ulegnie zmianie – powinno nastąpić pewne nasycenie. Nie inaczej jest w przypadku tworzenia oprogramowania – pomimo tego, że każdy potrzebuje programistów i każdy potrzebuje dobrych programistów, rynek rozumie, kto jest co wart – branża się uspokoiła. Obecnie nie jest tak w przypadku DevOps.
— Z tego, co usłyszałem, doszedłem do wniosku, że obecny administrator systemu nie powinien się zbytnio martwić, ale czas podnieść swoje umiejętności i przygotować się na to, że jutro będzie więcej pracy, ale będzie to bardziej wykwalifikowana.
Dmitry: Sto procent. Generalnie żyjemy w 2019 roku i zasada życia jest taka: uczenie się przez całe życie – uczymy się przez całe życie. Wydaje mi się, że teraz wszyscy już to wiedzą i czują, ale nie wystarczy wiedzieć – trzeba to zrobić. Każdego dnia musimy się zmieniać. Jeśli tego nie zrobimy, wcześniej czy później zostaniemy zepchnięci na margines zawodu.
Przygotuj się na ostre zakręty o 180 stopni. Nie wykluczam, że coś się radykalnie zmieni, wymyśli się coś nowego – to się zdarza. Chmiel! - i teraz postępujemy inaczej. Ważne jest, aby być na to przygotowanym i nie martwić się. Może się zdarzyć, że jutro wszystko, co zrobię, okaże się niepotrzebne – nic, całe życie się uczyłem i jestem gotowy nauczyć się czegoś innego. To nie problem. Nie ma co bać się bezpieczeństwa pracy, ale trzeba być przygotowanym na ciągłe uczenie się czegoś nowego.
Życzenia i minuta reklamy
- Czy masz jakieś życzenie?
Dmitry: Tak, mam kilka życzeń.
Pierwszy i kupiecki - zapisz się . Drodzy czytelnicy, wejdź na YouTube i zasubskrybuj nasz kanał. Za około miesiąc rozpoczniemy aktywną ekspansję usługi wideo.Będziemy mieli mnóstwo treści edukacyjnych na temat Kubernetesa, otwartych i różnorodnych: od zagadnień praktycznych, aż po laboratoria, aż do głębokich, fundamentalnych zagadnień teoretycznych i tego, jak wykorzystać Kubernetes w praktyce poziom zasad i wzorców.
Drugie życzenie kupieckie - idź do i umieszczamy gwiazdki, bo się nimi żywimy. Jeśli nie dasz nam gwiazdek, nie będziemy mieli co jeść. To jak mana w grze komputerowej. Robimy coś, robimy, próbujemy, ktoś mówi, że to okropne rowery, ktoś, że wszystko jest całkowicie nie tak, ale my działamy dalej i zachowujemy się absolutnie uczciwie. Widzimy problem, rozwiązujemy go i dzielimy się doświadczeniem. Dlatego daj nam gwiazdę, ona nie odejdzie od Ciebie, ale przyjdzie do nas, bo się nimi żywimy.
Po trzecie, ważne i już nie kupieckie życzenie - przestań wierzyć w bajki. Jesteście profesjonalistami. DevOps to bardzo poważny i odpowiedzialny zawód. Przestań bawić się w miejscu pracy. Niech kliknie dla Ciebie, a zrozumiesz. Wyobraź sobie, że przychodzisz do szpitala, a tam lekarz przeprowadza na Tobie eksperyment. Rozumiem, że może to być dla kogoś obraźliwe, ale najprawdopodobniej nie chodzi tu o ciebie, ale o kogoś innego. Powiedz innym, żeby też przestali. To naprawdę rujnuje życie nam wszystkim – wielu zaczyna traktować operacje, administratorów i DevOps jak kolesi, którym znowu coś zepsuło. Najczęściej było to „łamane” przez to, że szliśmy się bawić, a nie patrzyliśmy z zimną świadomością, że tak jest i tak jest.
Nie oznacza to, że nie należy eksperymentować. Musimy poeksperymentować, robimy to sami. Szczerze mówiąc, sami czasami gramy w gry - to oczywiście jest bardzo złe, ale nic ludzkiego nie jest nam obce. Ogłośmy 2019 rokiem poważnych, przemyślanych eksperymentów, a nie gier na produkcji. Prawdopodobnie tak.
- Dziękuję bardzo!
Dmitry: Dziękuję Witalijowi zarówno za poświęcony czas, jak i za rozmowę. Drodzy czytelnicy, bardzo dziękuję, jeśli nagle dotarliście do tego punktu. Mam nadzieję, że przynieśliśmy Ci przynajmniej kilka myśli.
W wywiadzie Dmitry poruszył kwestię werf. Teraz jest to uniwersalny szwajcarski nóż, który rozwiązuje prawie wszystkie problemy. Ale nie zawsze tak było. NA na festiwalu Dmitry Stolyarov szczegółowo opowie Ci o tym narzędziu. w raporcie będzie wszystko: problemy i ukryte niuanse Kubernetesa, opcje rozwiązania tych trudności i szczegółowa bieżąca implementacja werf. Dołącz do nas 27 i 28 maja, stworzymy idealne narzędzia.
Źródło: www.habr.com