W przededniu Witalij Chabarow przeprowadził wywiad z Dmitrijem Stoljarowem (), dyrektorem technicznym i współzałożycielem firmy „Flant”. Witalij zapytał Dmitrija o to, czym zajmuje się „Flant”, o Kubernetes, rozwój ekosystemu, wsparcie. Omówili, po co potrzebny jest Kubernetes i czy w ogóle jest potrzebny. A także o mikroserwisach, Amazon AWS, podejściu „Mam szczęście” w DevOps, przyszłości samego Kubernetes, dlaczego, kiedy i jak podbije świat, perspektywy DevOps i czym powinni przygotować się inżynierowie w jasnej i bliskiej przyszłości z uproszczeniami i sieciami neuronowymi.
w formie podcastu można posłuchać na DevOps Deflope – rosyjskojęzycznym podcaście o DevOps, a poniżej znajdziesz wersję tekstową.
Tutaj i dalej pytania zadaje inżynier z Express42.
O „Flant”
– Dima, cześć. Jesteś dyrektorem technicznym „” i także jego założycielem. Opowiedz proszę, czym zajmuje się firma i co ty w niej robisz?
Dmitrij: Na zewnątrz wydaje się, że jesteśmy takimi chłopakami, którzy chodzą i wszystkim stawiają Kubernetes i coś z nim robią. Ale to nie prawda. Zaczynaliśmy jako firma zajmująca się Linuxem, ale już od bardzo dawna nasza główna działalność to serwisowanie projektów produkcyjnych i highload pod klucz. Zwykle budujemy całą infrastrukturę od zera i potem długo, długo za nią odpowiadamy. Dlatego główną pracą, którą wykonuje „Flant”, za co dostaje pieniądze – to przyjęcie odpowiedzialności i realizacja produkcji pod klucz.
Ja, jako dyrektor techniczny i jeden z założycieli firmy, przez całą dobę zajmuję się tym, jak zwiększyć dostępność produkcji, uprościć jej eksploatację, ułatwić życie adminom, a życie programistów uczynić przyjemniejszym.
O Kubernetes
– Ostatnio od „Flanta” widzę wiele wykładów i o Kubernetes. Jak do niego doszliście?
Dmitrij: Już o tym mówiłem wiele razy, ale nie żałuję, że to powtórzę. Uważam, że warto powtarzać ten temat, ponieważ pojawia się zamieszanie pomiędzy przyczyną a skutkiem.
Potrzebowaliśmy narzędzia. Zmagaliśmy się z wieloma problemami, walczyliśmy z nimi na różne sposoby i czuliśmy potrzebę posiadania narzędzia. Przez wiele różnych opcji, budując własne rozwiązania, zdobywaliśmy doświadczenie. Z czasem doszliśmy do etapu, kiedy zaczęliśmy używać Dockera niemal od razu, gdy się pojawił — około 2013 roku. W momencie jego pojawienia się mieliśmy już sporo doświadczenia z kontenerami, zdążyliśmy napisać coś na kształt „Docker” — nasze własne sztuczki na Pythonie. Dzięki pojawieniu się Dockera mogliśmy porzucić kłopotliwe rozwiązania i korzystać z niezawodnego, wspieranego przez społeczność narzędzia.
Historia z Kubernetes jest podobna. W momencie, gdy zaczął zyskiwać na popularności — dla nas to wersja 1.2 — mieliśmy już masę sztuczek zarówno na Shellu, jak i Chefie, które próbowaliśmy jakoś zorganizować w Dockera. Poważnie rozważaliśmy Rancher i różne inne rozwiązania, ale pojawił się Kubernetes, który zrealizował wszystko dokładnie tak, jak byśmy to zrobili, a może nawet lepiej. Nie ma się do czego przyczepić.
Tak, tu jest jakiś niedoróbka, tam jakaś niedoróbka — mnóstwo niedoróbek, a 1.2 to w ogóle masakra, ale... Kubernetes przypomina budynki w budowie — patrzysz na projekt i rozumiesz, że to będzie świetne. Jeśli budynek ma już fundament i dwa piętra, to zdajesz sobie sprawę, że lepiej jeszcze się nie wprowadzać, a z oprogramowaniem takich problemów nie ma — można już używać.
Nie mieliśmy momentu, w którym byśmy się zastanawiali, czy używać Kubernetes, czy nie. Czekaliśmy na niego długo przed jego pojawieniem się i sami próbowaliśmy stworzyć analogi.
O Kubernetesie
— Bierzecie bezpośredni udział w rozwoju samego Kubernetes?
Dmitrij: Pośrednio. Raczej bierzemy udział w rozwoju ekosystemu. Wysyłamy pewną liczbę zgłoszeń pull: do Prometheus, różnych operatorów, do Helm — do ekosystemu. Niestety, nie jestem w stanie śledzić wszystkiego, co robimy i mogę się mylić, ale od nas nie ma żadnego zgłoszenia do rdzenia.
— Przy tym rozwijacie wiele własnych narzędzi wokół Kubernetes?
Dmitrij: Strategia jest taka: działamy i zgłaszamy do wszystkiego, co już istnieje. Jeśli tam zgłoszenia pull nie są przyjmowane, po prostu forkamy je dla siebie i funkcjonujemy, dopóki nie zostaną przyjęte z naszymi wersjami. Potem, gdy to trafi do upstream, wracamy z powrotem na wersję upstream.
Na przykład mamy operatora Prometheus, z którym przełączaliśmy się tam i z powrotem do upstreamu naszej kompilacji już ze pięć razy, prawdopodobnie. Potrzebujemy jakiejś funkcji, wysłaliśmy pull request, musimy ją jutro wypuścić, a nie chcemy czekać, aż zostanie wydana w upstreamie. W związku z tym składamy dla siebie, wprowadzamy naszą kompilację z naszą funkcją, która jest nam potrzebna, na wszystkie nasze klastry. Później to, na przykład, w upstreamie nam zamykają ze słowami: „Ludzie, zróbmy to dla bardziej ogólnego przypadku”, my lub ktoś inny to dokańcza, i z czasem znowu wraca.
Wszystko, co istnieje, staramy się rozwijać. Wiele elementów, które jeszcze nie istnieją, jeszcze nie zostały wymyślone lub zostały wymyślone, ale nie zostały zrealizowane — my je robimy. I nie dlatego, że lubimy sam proces lub budowanie rowerów jako branżę, a po prostu dlatego, że potrzebujemy tego narzędzia. Często zadają pytanie, dlaczego zrobiliśmy tę lub inną rzecz? Odpowiedź jest prosta — tak, ponieważ musieliśmy iść naprzód, rozwiązać jakiś praktyczny problem, i rozwiązaliśmy go tym narzędziem.
Droga zawsze jest taka: bardzo dokładnie szukamy i, jeśli nie znajdujemy żadnego rozwiązania, jak z bochenka chleba zrobić trolejbus, to robimy nasz bochenek i nasz trolejbus.
Narzędzia „Flanta”
— Wiem, że teraz „Flanta” ma addon-operatorów, operatorów shell, narzędzia dapp/werf. Jak rozumiem, to jedno i to samo narzędzie w różnych wcieleniach. Rozumiem też, że wewnątrz „Flanta” jest jeszcze wiele różnych narzędzi. Czy to prawda?
Dmitrij: Mamy na GitHubie jeszcze wiele różnych rzeczy. Z tego, co teraz pamiętam, mamy statusmap — panel dla Grafany, który wszystkim się podoba. Wspomniane jest prawie w każdym drugim artykule o monitorowaniu Kubernetes na Medium. Niemożliwe jest skrótowo opowiedzieć, czym jest statusmap — potrzebny jest oddzielny artykuł, ale to bardzo przydatna rzecz do monitorowania statusu w czasie, ponieważ w Kubernetes często musimy pokazywać status w czasie. Mamy też LogHouse — to rzecz oparta na ClickHouse oraz czarnej magii do zbierania logów w Kubernetes.
Wiele narzędzi! A będzie ich jeszcze więcej, ponieważ niektóre wewnętrzne rozwiązania będą wydane w tym roku. Z bardzo dużych, na bazie operatora addon, jest wiele dodatków do Kubernetes, np. jak poprawnie zainstalować sert manager – narzędzie do zarządzania certyfikatami, jak poprawnie zainstalować Prometheusa z całą masą dodatkowych komponentów – to około dwudziestu różnych binarek, które eksportują dane i coś zbierają, a Prometheus oferuje świetną grafikę i alerty. To po prostu cała masa dodatków do Kubernetes, które instaluje się w klastrze, a on przekształca się z prostego w zaawansowany, w pełni automatyczny, w którym wiele pytań jest już rozwiązanych. Tak, dużo robimy.
Rozwój ekosystemu
— Uważam, że to bardzo duży wkład w rozwój tego narzędzia i jego metod wykorzystania. Czy możesz mniej więcej oszacować, kto jeszcze mógłby wnieść podobny wkład w rozwój ekosystemu?
Dmitrij: W Rosji z tych firm, które działają na naszym rynku – nikt nawet blisko. Oczywiście, to głośne stwierdzenie, ponieważ są duzi gracze, tacy jak Mail i Yandex – oni też coś robią z Kubernetes, ale nawet oni nie zbliżyli się do wkładu firm na całym świecie, które robią znacznie więcej niż my. Trudno porównywać 'Flant' z zespołem 80 osób i Red Hat, w którym na samego Kubernetes pracuje chyba 300 inżynierów. Ciężko porównywać. Mamy w dziale RnD 6 osób, łącznie ze mną, którzy rozwijają wszystkie nasze narzędzia. 6 osób przeciwko 300 inżynierom Red Hat – jakoś trudno porównać.
— Niemniej jednak, nawet gdy ci 6 ludzi mogą zrobić coś naprawdę użytecznego i przenośnego, gdy stają przed praktycznym zadaniem i przekazują rozwiązanie społeczności – to interesujący przypadek. Rozumiem, że w dużych firmach technologicznych, gdzie jest własny rozwój i zespół wsparcia dla Kubernetes, mogą być rozwijane podobne narzędzia. Daje im to przykład, że można stworzyć i oddać to społeczności, dając impuls całemu społeczności, która używa Kubernetes.
Dmitrij: To chyba cecha integratora, jego wyróżnik. Mamy wiele projektów i widzimy wiele różnych sytuacji. Dla nas głównym sposobem na tworzenie wartości dodanej jest analiza tych przypadków, znalezienie wspólnego mianownika i maksymalne obniżenie ich kosztów dla nas. Aktywnie się tym zajmujemy. Trudno mi mówić o Rosji i świecie, ale mamy około 40 inżynierów DevOps w firmie, którzy zajmują się Kubernetesem. Nie sądzę, żeby w Rosji było wiele firm z porównywalną liczbą specjalistów znających Kubernetes, jeśli w ogóle takie są.
Rozumiem wszystko na temat nazwy stanowiska inżyniera DevOps, wszyscy wszystko rozumieją i przywykliśmy nazywać inżynierów DevOps inżynierami DevOps, nie będziemy tego dyskutować. Ci wszyscy 40 wspaniałych inżynierów DevOps codziennie napotykają problemy i je rozwiązują, my po prostu analizujemy to doświadczenie i staramy się je uogólnić. Rozumiemy, że jeśli to doświadczenie pozostanie tylko u nas, to za rok lub dwa narzędzie stanie się bezużyteczne, ponieważ gdzieś w społeczności pojawi się gotowa alternatywa. Nie ma sensu gromadzić tego doświadczenia wewnętrznie — to po prostu marnowanie sił i czasu w dev/null. Zatem nie żałujemy publikacji. Z przyjemnością to wszystko publikujemy i rozumiemy, że trzeba to publikować, rozwijać, promować, aby ludzie korzystali i dodawali swoje doświadczenia — wtedy wszystko rośnie i żyje. Wtedy po dwóch latach narzędzie nie trafia na śmietnik. Nie żałujemy dalszego wkładu, ponieważ widać, że ktoś korzysta z twojego narzędzia, a po dwóch latach korzystają z niego już wszyscy.
To część naszej dużej strategii z dapp/werf. Nie pamiętam, kiedy to zaczęliśmy robić, wydaje mi się, że 3 lata temu. Początkowo było to w ogóle na shellu. To był super dowód koncepcji, rozwiązaliśmy kilka naszych prywatnych problemów — udało się! Ale są problemy z shellem, dalej trudno to rozwijać, programowanie w shellu to niezła sztuka. Mieliśmy zwyczaj pisać w Ruby, odpowiednio, w Ruby przerobiliśmy coś, rozwijaliśmy to, aż natknęliśmy się na społeczność, która nie mówi: 'chcemy lub nie chcemy', odwraca nos od Ruby, co nie jest śmieszne. Zrozumieliśmy, że musimy to wszystko pisać w Go, żeby po prostu spełnić pierwszy punkt na liście kontrolnej: Narzędzie DevOps powinno być statycznym binarnym plikiem. Na Go lub nie na Go to nie jest tak istotne, ale lepiej mieć statyczny binarny plik napisany w Go.
Zainwestowaliśmy siły, przepisaliśmy dapp na Go i nazwaliśmy go werf. Dapp nie jest już wspierany, nie rozwija się, działa na jakiejś przestarzałej wersji, ale istnieje absolutna ścieżka modernizacji, którą można podjąć.
Dlaczego stworzono dapp
— Czy możesz w skrócie opowiedzieć, dlaczego stworzono dapp, jakie problemy on rozwiązuje?
Dmitrij: Pierwszy powód to budowanie. Na początku mieliśmy poważne problemy z budowaniem, kiedy Docker nie obsługiwał multi-stage, więc zrobiliśmy multi-stage sami. Potem mieliśmy wiele kwestii związanych z oczyszczaniem obrazów. Wszyscy, którzy zajmują się CI/CD, prędzej czy później stają w obliczu problemu, że jest wiele zbudowanych obrazów, które trzeba jakoś wyczyścić i pozostawić te, które są potrzebne.
Drugi powód to deployment. Tak, jest Helm, ale on rozwiązuje tylko część problemów. Jak to śmiesznie brzmi, napisano, że „Helm to menedżer pakietów dla Kubernetes”. Właśnie, że „the”. Jeszcze są słowa „Menedżer Pakietów” — jakie zazwyczaj mamy oczekiwania wobec Menedżera Pakietów? Mówimy: „Menedżer Pakietów — zainstaluj pakiet!” i oczekujemy, że powie nam: „Pakiet zainstalowany”.
Ciekawe, że mówimy: „Helm, zainstaluj pakiet”, a gdy on odpowiada, że zainstalował, okazuje się, że dopiero rozpoczął instalację — wskazał Kubernetes: „Uruchom ten element!”, a czy został uruchomiony, działa czy nie, Helm w ogóle nie rozwiązuje tego pytania.
Okazuje się, że Helm to po prostu tekstowy preprocesor, który ładuje dane do Kubernetes.
Ale w ramach każdego deploymentu chcemy wiedzieć — czy aplikacja została wdrożona na produkcję, czy nie? Wdrożona na produkcję oznacza, że aplikacja tam dotarła, nowa wersja została wdrożona, i przynajmniej nie pada oraz poprawnie odpowiada. Helm w ogóle nie rozwiązuje tego zadania. Aby to rozwiązać, trzeba włożyć wiele wysiłku, bo należy wydać polecenie Kubernetes do wdrożenia i śledzić, co tam się dzieje — czy rzeczywiście się wdrożyło, czy też nie. A jest wiele zadań związanych z deploymentem, oczyszczaniem i budowaniem.
Plany
W tym roku przechodzimy do lokalnego rozwoju. Chcemy osiągnąć to, co wcześniej było w Vagrant – wpisaliśmy 'vagrant up' i uruchomiły się wirtualne maszyny. Dążymy do tego, by przy projekcie w Git można było napisać 'werf up', a on uruchamiał lokalną kopię tego projektu, wdrożoną w lokalnym mini-Kub, z podłączonymi wszystkimi katalogami wygodnymi do rozwoju. W zależności od języka programowania, to jest realizowane w różny sposób, niemniej jednak chcemy, aby lokalny rozwój był wygodny przy zamontowanych plikach.
Następnym krokiem dla nas jest znacząco inwestować w wygodę dla programistów. Aby jednym narzędziem szybko lokalnie uruchomić projekt, rozwijać go, przesłać do Gita, a on z pewnością trafi na stage lub do testów, w zależności od pipeline'ów, a potem tym samym narzędziem trafi na produkcję. To jedność, unifikacja, reprodukowalność infrastruktury od lokalnego środowiska do produkcji jest dla nas bardzo ważnym aspektem. Ale tego nie ma jeszcze w werf – planujemy to zrobić.
Jednak droga do dapp/werf była zawsze taka sama, jak z Kubernetes na początku. Napotykaliśmy problemy, rozwiązywaliśmy je okrężnymi drogami – wymyślaliśmy dla siebie jakieś rozwiązania w shellu, na czymkolwiek. Potem staraliśmy się te okrężne drogi jakoś uprościć, uogólnić i skonsolidować w binariach, którymi po prostu się dzielimy.
Jest jeszcze inny punkt widzenia na tę całą historię, z analogiami.
Kubernetes to rama samochodu z silnikiem. Nie ma drzwi, szyb, radia, choinki – nie ma nic. Tylko rama i silnik. I jest Helm – to kierownica. Fajnie – kierownica jest, ale potrzebne są jeszcze wspornik kierownicy, przekładnia kierownicza, skrzynia biegów i koła, a bez nich ani rusz.
W przypadku werf – to jeszcze jeden komponent do Kubernetes. Tylko teraz mamy w wersji alfa werf, na przykład, Helm kompiluje się całkowicie wewnątrz werf, ponieważ znudziło nam się robienie tego samodzielnie. Wielu powodów, dla których tak zrobiliśmy, dokładnie opiszę, dlaczego skompilowaliśmy helm razem z tillerem wewnątrz werf. .
Obecnie werf to bardziej zintegrowany komponent. Otrzymujemy gotową kierownicę, oś kierowniczą - nie znam się na samochodach, ale to duży blok, który rozwiązuje już dość szeroki zakres problemów. Nie musimy przeszukiwać katalogu, dobierać jedną część do drugiej, myśleć, jak je ze sobą połączyć. Dostajemy gotowy kombajn, który od razu rozwiązuje dużą paczkę zadań. Ale wewnątrz jest zbudowany z tych samych komponentów open source, również wykorzystujemy Dockera do budowy, Helma do części funkcjonalności, a także kilka innych bibliotek. To zintegrowane narzędzie, aby szybko i wygodnie uzyskać świetne CI/CD z pudełka.
Czy trudno jest utrzymać Kubernetes?
— Opowiadasz o doświadczeniach, jakie mieliście z Kubernetes, to dla was rama, silnik, i można na nim wiele różnych rzeczy zamontować: obudowę, kierownicę, przymontować pedały, fotele. Pojawia się pytanie - jak trudne jest dla was utrzymanie Kubernetes? Macie bogate doświadczenie, ile czasu i zasobów poświęcacie na utrzymanie Kubernetes w oderwaniu od wszystkiego innego?
Dmitrij: To bardzo trudne pytanie i aby odpowiedzieć, trzeba zrozumieć, co to znaczy utrzymywać i czego chcemy od Kubernetes. Może to wyjaśnisz?
— Z tego, co wiem i jak widzę, wiele zespołów chce spróbować Kubernetes. Wszyscy się w to angażują, instalują na kolanie. Mam wrażenie, że ludzie nie zawsze rozumieją złożoność tego systemu.
Dmitrij: Zgadza się.
— Jak trudne jest wzięcie i postawienie Kubernetes z niczego, aby było gotowe do produkcji?
Dmitrij: Jak myślisz, jak trudno jest przeszczepić serce? Rozumiem, to kompromitujące pytanie. Operować skalpelem i nie popełnić błędu - to nie jest aż tak trudne. Jeśli ktoś ci mówi, gdzie odciąć, a gdzie zaszyć, to sama procedura nie jest skomplikowana. Trudno jednak zagwarantować, że za każdym razem wszystko się uda.
Zainstalowanie Kubernetes i uruchomienie go jest proste: cyk! — zainstalowane, istnieje mnóstwo sposobów instalacji. Ale co się stanie, gdy pojawią się problemy?
Zawsze pojawiają się pytania - czego jeszcze nie uwzględniliśmy? Co jeszcze nie zrobiliśmy? Jakie parametry jądra Linuxa określiliśmy błędnie? Boże, a w ogóle je określiliśmy?! Jakie komponenty Kubernetes zainstalowaliśmy, a jakich nie? Pojawia się tysiące pytań, a żeby na nie odpowiedzieć, trzeba 15-20 lat zaawansowanej pracy w tej branży.
Mam świeży przykład na ten temat, który może wyjaśnić kwestię 'Czy trudno jest obsługiwać Kubernetes?'. Jakiś czas temu poważnie rozważaliśmy możliwość wdrożenia Cilium jako sieci w Kubernetes.
Wyjaśnię, czym jest Cilium. W Kubernetes istnieje wiele różnych realizacji systemu sieciowego, a jedna z nich jest naprawdę świetna — to Cilium. Jaki jest jej sens? W jądrze jakiś czas temu pojawiła się możliwość pisania haków do jądra, które w jakiś sposób ingerują w system sieciowy i różne inne podsystemy, umożliwiając ominięcie dużych fragmentów w jądrze.
W jądrze Linuxa historycznie są ip rout, nadfiltry, mostki i wiele różnych starych komponentów, które mają po 15, 20, 30 lat. Ogólnie rzecz biorąc, działają, wszystko jest w porządku, ale teraz jest mnóstwo kontenerów, a to wygląda jak wieża z 15 cegieł jedna na drugiej, a ty stoisz na niej na jednej nodze — dziwne uczucie. Ten system rozwijał się historycznie z wieloma niuansami, jak wyrostek w organizmie. W niektórych sytuacjach występują problemy z wydajnością, na przykład.
Jest wspaniały BPF i możliwość pisania haków do jądra — chłopaki napisali swoje haki do jądra. Pakiet dociera do jądra Linuxa, oni go bezpośrednio przy wejściu wyciągają, przetwarzają według potrzeb bez mostków, bez TCP, bez stosu IP — krótko mówiąc, omijają wszystko, co zostało napisane w jądrze Linuxa, a potem od razu wypuszczają do kontenera.
Co z tego wyszło? Bardzo dobra wydajność, świetne funkcje — po prostu rewelacja! Ale patrzymy na to i widzimy, że na każdej maszynie działa program, który łączy się z API Kubernetes i na podstawie danych, które otrzymuje z tego API, generuje kod C i kompiluje binaria, które ładuje do jądra, aby te haki działały w przestrzeni jądra.
Co się stanie, jeśli coś pójdzie nie tak? Nie wiemy. Aby to zrozumieć, trzeba przeczytać cały ten kod, pojąć całą logikę, a to jest naprawdę skomplikowane. Ale z drugiej strony są te mostki, filtry net, ip rout — nie czytałem ich źródeł, a 40 inżynierów w naszej firmie również. Może zdarzają się pojedyncze osoby, które rozumieją niektóre fragmenty.
I jaka jest różnica? Wygląda na to, że istnieje ip route, jądro Linux, a jest nowe narzędzie — jaka różnica, nie rozumiemy ani jednego, ani drugiego. Ale boimy się używać nowego — dlaczego? Ponieważ jeśli narzędzie ma 30 lat, to przez 30 lat znaleziono wszystkie błędy, na wszystkie pułapki natknięto się i nie trzeba wiedzieć o wszystkim — działa jak czarna skrzynka i zawsze działa. Wszyscy wiedzą, jaką diagnostyczną śrubokręt w jakie miejsce włożyć, jaki tcpdump w jakim momencie uruchomić. Wszyscy dobrze znają narzędzia diagnostyczne i rozumieją, jak ten zestaw komponentów działa w jądrze Linux — nie jak jest skonstruowany, ale jak go używać.
A świetne Cilium nie ma 30 lat, nie jest jeszcze wypróbowane. Z Kubernetes jest ta sama problematyka, kopia. To znaczy, że Cilium instalujesz bez problemu, że Kubernetes też instalujesz bez problemu, ale gdy coś nie pójdzie w produkcji, czy jesteś w stanie szybko zrozumieć, co poszło nie tak w krytycznej sytuacji?
Kiedy mówimy, czy trudno jest utrzymać Kubernetes — nie, bardzo prosto, i tak, niesamowicie ciężko. Kubernetes doskonale działa samodzielnie, ale z milionem szczegółów.
O podejściu „Pojdzie mi jak po maśle”
— A czy są firmy, gdzie te szczegóły prawie na pewno się pojawią? Załóżmy, że Yandex nagle przeprowadzi wszystkie serwisy na Kubernetes, będzie tam ogromne obciążenie.
Dmitrij: Nie, to nie jest rozmowa o obciążeniu, a o najprostszych rzeczach. Na przykład, mamy Kubernetes, wdrożyliśmy tam aplikację. Jak zrozumieć, że działa? Nie ma gotowego narzędzia, żeby zrozumieć, że aplikacja nie się zawiesza, po prostu nie ma. Nie ma gotowego systemu, który wysyła alerty — trzeba skonfigurować te alerty i każdy wykres. A my właśnie aktualizujemy Kubernetes.
Jest Ubuntu 16.04. Można powiedzieć, że to stara wersja, ale wciąż na niej jesteśmy, ponieważ tam jest LTS. Jest tam systemd, którego szczegół polega na tym, że nie oczyszcza C-grup. Kubernetes uruchamia pody, tworzy C-grupy, a potem je usuwa i jakoś tak wychodzi – nie pamiętam szczegółów, przepraszam – że pozostają fragmenty systemd. To prowadzi do tego, że z czasem każda maszyna zaczyna mocno się zacinać. To nawet nie jest kwestia dużego obciążenia. Jeśli uruchamiane są stałe pody, na przykład, jeśli jest Cron Job, który nieustannie generuje pody, to maszyna z Ubuntu 16.04 po tygodniu zacznie się zaciąć. Będzie tam stale wysoki średni load ze względu na to, że stworzono masę C-grup. To problem, z którym spotyka się każdy, kto po prostu zainstaluje Ubuntu 16 i uruchomi Kubernetes.
Załóżmy, że jakoś zaktualizuje systemd lub coś innego, ale w jądrze Linux do wersji 4.16 jest jeszcze śmieszniej – przy usuwaniu C-grup w jądrze pojawiają się usterki i faktycznie nie są usuwane. Dlatego po miesiącu pracy na tej maszynie będzie niemożliwe zerknięcie na statystyki pamięci według podów. Wyciągamy plik, kręcimy w progu, a jeden plik kręci się 15 sekund, ponieważ jądro bardzo długo oblicza wewnętrznie milion C-grup, które niby są usunięte, ale nie – one się pojawiają.
Takich drobiazgów wciąż jest mnóstwo tam i tu. To nie jest problem, z którym mogą się czasami zmagać gigantyczne firmy przy dużych obciążeniach – nie, to jest kwestia codziennych spraw. Ludzie mogą tak żyć przez miesiące – zainstalowali Kubernetes, wdrożyli aplikację – niby działa. Wiele osób tak ma. O tym, że kiedyś ta aplikacja z jakiegoś powodu się zawali, nawet się nie dowiedzą, alert nie przyjdzie, ale dla nich to norma. Kiedyś żyli na wirtualkach bez monitoringu, teraz przeszli do Kubernetes również bez monitoringu – jaka różnica?
Pytanie polega na tym, że kiedy chodzimy po lodzie, nigdy nie wiemy, jaka jest jego grubość, jeśli nie zmierzyliśmy tego wcześniej. Wielu chodzi i się nie przejmuje, bo wcześniej już chodzili.
Z mojego punktu widzenia, szczegół i trudność w eksploatacji jakiegokolwiek systemu polega na tym, aby zapewnić, że grubości lodu na pewno wystarczy, aby rozwiązać nasze zadania. O to chodzi.
W IT, uważam, jest zbyt wiele podejść "Może mi się uda". Wiele osób instaluje oprogramowanie, korzysta z bibliotek programistycznych w nadziei, że im się poszczęści. Generalnie, wielu się udaje. Prawdopodobnie dlatego to działa.
- Z mojej pesymistycznej oceny wygląda to tak: gdy ryzyka są duże, a aplikacja musi działać, potrzebne jest wsparcie od "Flanta", być może od Red Hat, lub wymagana jest własna wewnętrzna drużyna, specjalnie dedykowana Kubernetesowi, która jest gotowa się nim zajmować.
Dmitrij: Obiektywnie mówiąc, to prawda. Zajmowanie się Kubernetesem na własną rękę w małej grupie to pewna ilość ryzyk.
Czy potrzebujemy kontenerów?
- Możesz opowiedzieć, jak bardzo Kubernetes jest popularny w Rosji?
Dmitrij: Nie mam tych danych i nie jestem pewien, czy ktokolwiek je ma. Mówimy: "Kubernetes, Kubernetes", a jest jeszcze inny punkt widzenia na tę sprawę. Nie wiem, jak powszechne są kontenery, ale znam liczbę z raportów w internecie, że 70% kontenerów orkiestruje Kubernetes. To był wiarygodny źródło na dość dużej próbce na całym świecie.
Kolejne pytanie - czy potrzebujemy kontenerów? Mam osobiste odczucie i ogólną pozycję firmy "Flant", że Kubernetes to standard de facto.
Nic poza Kubernetesem nie będzie.
To absolutny przełom w zarządzaniu infrastrukturą. Po prostu absolutny - koniec z Ansible, Chef, maszynami wirtualnymi, Terraform. Nie mówię już o starych, chałupniczych metodach. Kubernetes to absolutny zmieniacz, a teraz tylko tak będzie.
Jasne jest, że niektórzy potrzebują kilku lat, a niektórzy kilkunastu, aby to zrozumieć. Nie mam wątpliwości, że nie będzie nic poza Kubernetesem i tym nowym spojrzeniem: już nie ranimy systemu operacyjnego, a wykorzystujemy infrastructure as code, tylko nie z kodem, a z yml - deklaratywnie opisaną infrastrukturę. Mam wrażenie, że tak będzie zawsze.
- Czyli te firmy, które jeszcze nie przeszły na Kubernetes, na pewno przejdą na niego lub pozostaną w zapomnieniu. Dobrze cię zrozumiałem?
Dmitrij: To również nie jest do końca prawda. Na przykład, jeśli mamy zadanie uruchomienia serwera DNS, można go uruchomić na FreeBSD 4.10 i może on działać doskonale przez 20 lat. Po prostu działa i tyle. Być może przez te 20 lat trzeba będzie coś zaktualizować raz. Jeśli mówimy o oprogramowaniu w formacie, które uruchomiliśmy i naprawdę działa od wielu lat bez żadnych aktualizacji, bez wprowadzania zmian, to oczywiście tam nie będzie Kubernetes. Nie jest tam potrzebny.
Wszystko, co dotyczy CI/CD — wszędzie, gdzie potrzebne jest Continuous Delivery, gdzie wymagana jest aktualizacja wersji, wprowadzanie aktywnych zmian, wszędzie, gdzie trzeba zbudować odporność na awarie — tylko Kubernetes.
O mikroserwisach
— Tutaj pojawia się u mnie mały dysonans. Aby pracować z Kubernetes, potrzebne jest wsparcie zewnętrzne lub wewnętrzne — to pierwszy punkt. Drugi — gdy dopiero zaczynamy rozwój, jesteśmy małym startupem, nie mamy jeszcze nic, rozwój pod Kubernetes lub w ogóle pod architekturę mikroserwisową może być trudny i nie zawsze opłacalny ekonomicznie. Interesuje mnie twoje zdanie — czy startupy od zera od razu powinny zaczynać pisać pod Kubernetes, czy może jednak można najpierw napisać monolit, a dopiero potem przejść do Kubernetes?
Dmitrij: Fajne pytanie. Mam prezentację o mikroserwisach. Wiele razy spotykałem się z sytuacją, w której ludzie próbują wbijać gwoździe mikroskopem. Sam w sobie model jest właściwy, my projektujemy nasze wewnętrzne oprogramowanie właśnie w ten sposób. Ale kiedy to robisz, musisz dokładnie wiedzieć, co robisz. Najbardziej w mikroserwisach nienawidzę słowa „mikro”. Historycznie tak się to ułożyło i z jakiegoś powodu ludzie myślą, że mikro to bardzo małe, mniejsze niż milimetr, jak mikrometr. To nieprawda.
Na przykład, jest monolit, nad którym pracuje 300 osób, i wszyscy, którzy brali udział w jego rozwoju, wiedzą, że są tam problemy, i należy go podzielić na mniejsze kawałki — powiedzmy na 10, z których każdy pisze 30 osób w minimalnej wersji. To ważne, potrzebne i fantastyczne. Ale gdy przychodzi do nas startup, w którym 3 bardzo utalentowanych chłopaków napisało na kolanie 60 mikroserwisów, za każdym razem szukam korwalolu.
Wydaje mi się, że o tym mówiło się już tysiące razy – otrzymaliśmy rozproszony monolit w jednej lub drugiej formie. To ekonomicznie nieuzasadnione, bardzo trudne w ogóle we wszystkim. Po prostu widziałem to tyle razy, że naprawdę mnie to boli, dlatego wciąż o tym mówię.
Wracając do początkowego pytania, istnieje konflikt między tym, że z jednej strony Kubernetes jest straszny w użyciu, ponieważ nie wiadomo, co może się zepsuć lub nie działać, a z drugiej strony jasne jest, że wszystko idzie w tym kierunku i nic poza Kubernetesem nie będzie. Odpowiedź to - ważyć korzyści, które przynoszą, oraz zadania, które możesz rozwiązać.. To z jednej strony wagi. Z drugiej strony - ryzyka związane z przestojem lub spadkiem czasu reakcji, poziomu dostępności - ze spadkiem wskaźników wydajności.
Tu jest tak – albo musimy się szybko poruszać, a Kubernetes pozwala wykonywać wiele rzeczy znacznie szybciej i lepiej, albo używamy niezawodnych rozwiązań sprawdzonych w czasie, ale idziemy znacznie wolniej. Ten wybór powinna podejmować każda firma. Można to porównać do ścieżki w dżungli - gdy idziesz pierwszy raz, możesz spotkać węża, tygrysa lub szalonego borsuka, a gdy przeszedłeś 10 razy - utorowałeś szlak, usunąłeś gałęzie i idzie się łatwiej. Z każdym razem ścieżka staje się szersza. Potem to już asfaltowana droga, a później piękny bulwar.
Kubernetes nie stoi w miejscu. Znowu pytanie: z jednej strony Kubernetes to 4-5 binarek, z drugiej - to cały ekosystem. To system operacyjny, który mamy na maszynach. Co to jest? Ubuntu czy Curios? To jądro Linuxa, mnóstwo dodatkowych komponentów. Wszystkie te rzeczy tutaj wyrzuciły jednego jadowitego węża z drogi, tam postawiono płot. Kubernetes rozwija się bardzo szybko i dynamicznie, a ryzyko oraz obszar nieznanego zmniejsza się z każdym miesiącem, a tym samym te wagi równoważą się.
Odpowiadając na pytanie, co zrobić z startupem, powiedziałbym - przyjdźcie do „Flanta”, zapłaćcie 150 tysięcy rubli i otrzymajcie pod klucz usługę DevOps easy service. Jeśli jesteście małym startupem z kilkoma programistami - to działa. Zamiast zatrudniać własnego DevOps, który będzie musiał nauczyć się rozwiązywać wasze problemy i płacić mu w tym czasie wynagrodzenie, otrzymacie rozwiązanie wszystkich pytań pod klucz. Tak, są pewne minusy. Jako outsourcer nie możemy być tak zaangażowani i szybko reagować na wprowadzanie zmian. Ale mamy mnóstwo wiedzy i gotowych praktyk. Gwarantujemy, że w każdej sytuacji szybko zrozumiemy i podniesiemy z martwych każdy Kubernetes.
Kategorycznie polecam outsourcing startupom oraz ugruntowanym firmom do momentu, gdy możecie przeznaczyć na eksploatację zespół złożony z 10 osób, ponieważ w przeciwnym razie nie ma sensu. Outsourcing ma zdecydowanie sens.
O Amazonie i Google'u
— Czy można rozważać hosting od Amazon lub Google jako outsourcing?
Dmitrij: Tak, oczywiście, to rozwiązuje pewną liczbę problemów. Ale znów są niuanse. Nadal trzeba wiedzieć, jak to wykorzystać. Na przykład, w pracy z Amazon AWS jest tysiące drobiazgów: Load Balancer trzeba podgrzewać lub wcześniej złożyć wniosek, że "chłopaki, przyjdzie nam ruch, podgrzejcie nam Load Balancer!" Te niuanse trzeba znać.
Kiedy zwracacie się do ludzi, którzy się na tym specjalizują, otrzymujecie niemal wszystkie typowe rzeczy zamknięte. Mamy teraz 40 inżynierów, do końca roku będzie ich prawdopodobnie 60 - na pewno z wszystkim tymi sprawami mieliśmy do czynienia. Nawet jeśli w jakimś projekcie znowu napotkamy ten problem, szybko się pytamy i wiemy, jak go rozwiązać.
Prawdopodobnie odpowiedź jest taka - oczywiście, hosted-history ułatwia pewną część. Pytanie, czy jesteście gotowi zaufać tym hosterom, i czy rozwiążą wasze problemy. Amazon i Google dobrze się sprawdziły. Dla wszystkich naszych przypadków - zdecydowanie. Nie mamy innych pozytywnych doświadczeń. Wszystkie inne chmury, z którymi próbowaliśmy pracować, stwarzały bardzo wiele problemów - i Ager, i wszystko, co jest w Rosji, i wszelkie OpenStack w różnych realizacjach: Headster, Overage - cokolwiek chcecie. Wszystkie one stwarzają problemy, których nie chcemy rozwiązywać.
Dlatego odpowiedź brzmi - tak, ale w rzeczywistości dojrzałych rozwiązań hosted jest bardzo mało.
Kto potrzebuje Kubernetes?
— A jednak, kto potrzebuje Kubernetes? Kto powinien już przejść na Kubernetes, kto jest typowym klientem "Flanta", który przychodzi właśnie po Kubernetes?
Dmitrij: Ciekawe pytanie, ponieważ teraz na fali Kubernetes przychodzi do nas wielu: "Chłopaki, wiemy, że zajmujecie się Kubernetes, zróbcie to dla nas!". Odpowiadamy: "Panie, nie zajmujemy się Kubernetes, zajmujemy się produkcją i wszystkim, co się z tym wiąże". Ponieważ nie da się stworzyć produkcji bez całego CI/CD i całej tej historii — w obecnych czasach to po prostu niemożliwe. Wszyscy odeszli od podziału, gdzie mamy rozwój jako rozwój, a potem eksploatację jako eksploatację.
Nasi klienci oczekują różnie, ale wszyscy oczekują pewnego dobrego cudu, że mają te czy inne problemy, a teraz — hop! — Kubernetes je rozwiąże. Ludzie wierzą w cuda. Rozumem zdają sobie sprawę, że cudu nie będzie, ale duszą mają nadzieję — a może ten Kubernetes teraz wszystko rozwiąże, tyle o nim mówią! Może on teraz — psik! — i srebrna kula, psik! — i mamy 100% uptime, wszyscy deweloperzy mogą wydawać co popadnie na produkcję, a to nie pada. Generalnie, cud!
Kiedy tacy ludzie do nas przychodzą, mówimy: "Przepraszam, ale cuda się nie zdarzają". Aby być zdrowym, trzeba dobrze się odżywiać i uprawiać sport. Aby mieć niezawodną produkcję, trzeba ją stworzyć niezawodnie. Aby mieć wygodne CI/CD, trzeba je tak zrealizować. To dużo pracy, którą trzeba wykonać.
Odpowiadając na pytanie, komu potrzebny jest Kubernetes — Kubernetes nie jest potrzebny nikomu.
Niektórzy ludzie mają błędne poczucie, że potrzebują Kubernetes. Ludzie potrzebują, mają głęboką potrzebę przestać myśleć, zajmować się, interesować się w ogóle wszystkimi problemami infrastruktury i problemami uruchamiania ich aplikacji. Chcą, aby aplikacje po prostu działały i po prostu się wdrażały. Dla nich Kubernetes to nadzieja, że przestaną słyszeć historię, że "leżymy tam", lub "nie możemy się wdrożyć", lub coś innego.
Zwykle przychodzi do nas dyrektor techniczny. Pyta się o dwie rzeczy: z jednej strony, dajcie nam funkcje, z drugiej strony — stabilność. Proponujemy wziąć to na siebie i się tym zająć. Srebrna kula, a dokładniej mówiąc, posrebrzana, polega na tym, że przestaniesz myśleć o tych problemach i tracić czas. Będziesz miał specjalnych ludzi, którzy zajmą się tym pytaniem.
Sformułowanie, że potrzebujemy Kubernetes, jest błędne.
Kubernetes jest bardzo potrzebny administratorom, ponieważ to bardzo interesująca zabawka, z którą można bawić się i grzebać. Bądźmy szczerzy - wszyscy lubimy zabawki. Wszyscy gdzieś są dziećmi, a gdy widzimy nową zabawkę, chcemy się nią pobawić. U niektórych to od zawsze się wyczerpało, na przykład w administracji, bo już się nagrali i tak bardzo się znudzili, że po prostu nie mają ochoty. Ale jednak nikt całkowicie nie stracił tej pasji. Na przykład, nawet jeśli zabawki w obszarze administracji systemowej i DevOps już mi się znudziły, to wciąż lubię zabawki i ciągle kupuję jakieś nowe. Ludzie w końcu i tak chcą mieć jakieś zabawki.
Nie należy bawić się w produkcji. Czego kategorycznie bym nie zalecał robić i co obserwuję teraz masowo: "A, nowa zabawka!" - pobiegliśmy ją kupić, kupiliśmy i: "Zabierzmy ją teraz do szkoły, pokażmy wszystkim znajomym". Nie róbcie tak. Przepraszam, moje dzieci dorastają, cały czas widzę coś w dzieciach, dostrzegam to w sobie, a potem jeszcze uogólniam na innych.
Ostateczna odpowiedź: nie potrzebujesz Kubernetes. Musisz rozwiązać swoje problemy.
Można osiągnąć to, że:
- produkcja nie pada;
- nawet jeśli próbuje upaść, wiemy o tym wcześniej i możemy coś podłożyć;
- możemy zmieniać go z taką prędkością, jakiej wymagają nasze działania biznesowe, i robić to wygodnie, nie sprawia nam to problemu.
Realne potrzeby to: niezawodność i dynamika/elastyczność procesu wdrażania. Do wszystkich, którzy aktualnie realizują jakiekolwiek projekty IT, niezależnie od branży - soft to ułatwienie świata, i którzy to rozumieją, muszą rozwiązać te potrzeby. Kubernetes, przy właściwym podejściu, z odpowiednim zrozumieniem i wystarczającym doświadczeniem, pozwala te potrzeby spełniać.
Oserverless
Jeśli spojrzeć nieco dalej w przyszłość, próbując rozwiązać problem braku bólu głowy z infrastrukturą, szybkością wdrażania i szybkością zmiany aplikacji, pojawiają się nowe rozwiązania, takie jak serverless. Czy dostrzegasz jakiś potencjał w tym kierunku i, mówiąc tak, zagrożenie dla Kubernetes i podobnych rozwiązań?
Dmitrij: Muszę znów wspomnieć, że nie jestem prorokiem, który patrzy w przyszłość i mówi — tak będzie! Chociaż sam przed chwilą robiłem to samo. Patrzę pod nogi i widzę tam mnóstwo problemów, na przykład, jak działają tranzystory w komputerze. Śmieszne, co? Z jakimiś błędami w CPU się spotykamy.
Zrobienie serverless wystarczająco niezawodnym, tanim, efektywnym i wygodnym, rozwiązując wszystkie problemy ekosystemowe, jest możliwe. Zgadzam się z Elonem Maskiem, że potrzebna jest druga planeta, aby zapewnić odporność dla ludzkości. Chociaż nie wiem, co dokładnie mówi, rozumiem, że nie jestem gotów lecieć na Marsa, a to nie wydarzy się jutro.
Z serverless jest jasne, że to ideologicznie słuszna rzecz, tak jak odporność dla ludzkości — lepiej mieć dwie planety niż jedną. Ale jak to zrobić teraz? Wysłać jedną ekspedycję — to nie problem, jeśli skoncentrujemy na tym wysiłki. Wysłać kilka ekspedycji i zasiedlić tam kilka tysięcy ludzi, myślę, że też jest realistyczne. Ale stworzenie pełnej odporności, żeby połowa ludzkości tam mieszkała, wydaje mi się w tej chwili niemożliwe, nie do rozważenia.
Z serverless jest dokładnie tak samo: to świetna rzecz, ale daleko od problemów roku 2019. Bliżej roku 2030 — dożyjmy do tego. Nie wątpię, że dożyjemy, na pewno dożyjemy (powtarzaj przed snem), ale teraz musimy rozwiązać inne problemy. To jak wierzyć w bajkowego jednorożca. Tak, kilka procent przypadków jest rozwiązanych, i to świetnie, ale subiektywnie serverless to jak tęcza… Dla mnie ten temat jest zbyt odległy i zbyt niejasny. Nie jestem gotów o tym mówić. W 2019 roku z serverless nie stworzy się żadnej aplikacji.
Jak będzie rozwijał się Kubernetes
— Podczas gdy zmierzamy ku temu potencjalnie wspaniałemu dalekiemu przyszłości, jak uważasz, jak będzie rozwijał się Kubernetes i ekosystem wokół niego?
Dmitrij: Długo o tym myślałem i mam jasną odpowiedź. Po pierwsze, statefull – stateless jest jednak łatwiejszy do zrealizowania. Kubernetes od początku bardziej w to inwestował, od tego wszystko się zaczęło. Stateless działa praktycznie idealnie w Kubernetes, nie ma się do czego przyczepić. W przypadku statefull jest jeszcze mnóstwo problemów, a właściwie niuansów. U nas już wszystko tam wspaniale działa, ale to tylko my. Aby to działało u wszystkich, potrzeba jeszcze przynajmniej kilku lat. To nie jest miara obliczeniowa, a moje odczucie z głowy.
Krótko mówiąc, statefull musi – i będzie – intensywnie się rozwijał, ponieważ wszystkie nasze aplikacje przechowują stan, nie ma aplikacji stateless. To iluzja, zawsze potrzebna jest jakaś baza danych i coś jeszcze. Statefull – to uproszczenie wszystkiego, co można, naprawa wszystkich błędów, poprawa wszystkich problemów, z którymi obecnie się zmagamy – nazwijmy to adopcją.
Poziom niewiedzy, poziom nierozwiązanych problemów, poziom prawdopodobieństwa zetknięcia się z czymś będzie znacznie spadał. To ważna sprawa. I operatorzy – wszystko, co związane z kodifikacją logiki administracyjnej, logiki zarządzania, aby uzyskać łatwą usługę: MySQL łatwa usługa, RabbitMQ łatwa usługa, Memcache łatwa usługa – te wszystkie komponenty, których potrzebujemy, aby wszystko działało z pudełka w sposób gwarantowany. To właśnie rozwiązuje te problemy, z którymi mamy bazę danych, ale nie chcemy jej administracji, lub chcemy Kubernetes, ale nie chcemy go administracji.
Ta historia z rozwojem operatorów w jakiejkolwiek formie będzie ważna w ciągu najbliższych kilku lat.
Myślę, że znacznie wzrośnie prostota eksploatacji – skrzynka będzie stawała się coraz bardziej czarna, coraz bardziej niezawodna, z coraz prostszymi pokrętłami.
Kiedyś słuchałem starego wywiadu z Isaaciem Asimovem z lat 80. na YouTube w programie Saturday Night Live – taki odpowiednik Urganta, tylko interesujący. Pytali go o przyszłość komputerów. Powiedział, że przyszłość leży w prostocie, tak jak to było z odbiornikiem radiowym. Odbiornik radiowy na początku był skomplikowany. Aby złapać falę, trzeba było przez 15 minut kręcić pokrętłami, obracać różnymi elementami i ogólnie wiedzieć, jak wszystko działa, rozumieć fizykę przekazu fal radiowych. W rezultacie w radiu została tylko jedna gałka.
Jakie radio mamy w 2019 roku? W samochodzie odbiornik radiowy znajduje wszelkie fale, nazwy stacji. Fizyka procesu nie zmieniła się przez 100 lat, zmieniła się prostota użycia. Obecnie, a już w 1980 roku, w czasie wywiadu z Asimovem, wszyscy korzystali z radia i nikt nie zastanawiał się, jak to działa. Ono zawsze działało — to fakt.
Asimov mówił wtedy, że z komputerami będzie podobnie — prostota użycia wzrośnie. Jeśli w 1980 roku trzeba było zdobyć specjalne wykształcenie, by naciskać przyciski na komputerze, to w przyszłości tak nie będzie.
Mam wrażenie, że z Kubernetes i infrastrukturą również bardzo wzrośnie prostota użycia. To jest, moim zdaniem, oczywiste — leży na powierzchni.
Co zrobić z inżynierami?
— A co się stanie z inżynierami, administratorami systemów, którzy wspierają Kubernetes?
Dmitrij: A co się stało z księgowymi po pojawieniu się 1C? Mniej więcej to samo. Wcześniej liczyli na papierze — teraz w programie. Wydajność pracy wzrosła wielokrotnie, a praca nie zniknęła. Jeśli wcześniej do wkręcania żarówki potrzebnych było 10 inżynierów, teraz wystarczy jeden.
Liczba oprogramowania i zadań wydaje mi się teraz rośnie szybciej, niż pojawiają się nowi DevOps i zwiększa się efektywność. Obecnie na rynku jest wyraźny deficyt, który potrwa długo. Później wszystko wejdzie w pewną normę, w której efektywność pracy wzrośnie, będzie coraz więcej rozwiązań serverless, a do Kubernetes dołączy neuronowa sieć, która sama dobierze wszystkie zasoby, tak jak potrzeba — człowieku, odejdź i nie przeszkadzaj.
Ale decyzje i tak będą musiały być podejmowane przez kogoś. Jasne, że poziom kwalifikacji i specjalizacja tej osoby będą wyższe. Obecnie w dziale księgowości potrzebnych jest już tylko 10 pracowników, którzy prowadzą księgi, aby ręka się nie męczyła. To po prostu nie jest potrzebne. Wiele dokumentów jest automatycznie skanowanych, rozpoznawanych przez system obiegu dokumentów. Wystarczy jeden mądry główny księgowy, mający znacznie większe umiejętności i dobre zrozumienie.
W każdej branży tak to wygląda. Z samochodami jest podobnie: kiedyś przy pojeździe był mechanik i trzech kierowców. Dziś prowadzenie samochodu to najprostszy proces, w którym wszyscy bierzemy udział na co dzień. Nikt nie myśli, że samochód to coś skomplikowanego.
DevOps czy inżynieria systemowa nigdzie się nie wybiera — wysoka jakość i efektywność pracy będą rosnąć.
— Słyszałem też ciekawą myśl, że tak naprawdę pracy będzie więcej.
Dmitrij: Oczywiście, na sto procent! Ponieważ liczba oprogramowania, które piszemy, ciągle rośnie. Liczba problemów, które rozwiązujemy za pomocą oprogramowania, także rośnie. Liczba pracy wzrasta. Obecnie rynek DevOps jest bardzo przegrzany. Widać to po oczekiwaniach płacowych. Z praktycznego punktu widzenia, nie wnikając w szczegóły, powinny być juniors, którzy chcą X, mid-level, którzy chcą 1,5X, i seniorzy, którzy chcą 2X. A teraz, patrząc na moskiewski rynek płac dla DevOps, junior chce od X do 3X, a senior chce od X do 3X.
Nikt nie wie, ile to kosztuje. Poziom wynagrodzenia mierzy się twoją pewnością — to kompletny chaos, szczerze mówiąc, strasznie przegrzany rynek.
Oczywiście, ta sytuacja zmieni się bardzo szybko — powinno nastąpić pewne nasycenie. Z tworzeniem oprogramowania tak nie jest — mimo że wszyscy potrzebują programistów, a dobrych programistów potrzeba jeszcze bardziej, rynek rozumie, ile kto jest wart — branża ustabilizowała się. W DevOps obecnie nie jest tak.
— Z tego, co słyszałem, wyciągnąłem wniosek, że obecny administrator systemów nie ma powodów do dużych zmartwień, ale czas szlifować umiejętności i przygotować się na to, że jutro pracy będzie więcej, ale będzie ona bardziej wykwalifikowana.
Dmitrij: Na pewno. Generalnie żyjemy w 2019 roku i zasada życia jest taka: lifetime learning — uczymy się przez całe życie. Myślę, że teraz wszyscy to wiedzą i czują, ale mało wiedzieć — trzeba działać. Każdego dnia musimy się zmieniać. Jeśli tego nie robimy, prędzej czy później wyrzucą nas na pobocze zawodowe.
Bądź gotowy na nagłe zwroty o 180 stopni. Nie wykluczam sytuacji, w których coś drastycznie się zmieni, wymyślą coś nowego — tak bywa. Hop! — i teraz działamy inaczej. Ważne, aby być na to gotowym i się nie przejmować. Może się zdarzyć, że jutro wszystko, co robię, stanie się niepotrzebne — nic, przez całe życie uczyłem się i jestem gotów uczyć się czegoś nowego. To nie jest problem. Nie ma sensu bać się o bezpieczeństwo pracy, ale trzeba być gotowym na to, by ciągle uczyć się czegoś nowego.
Życzenia i chwilka reklamy
— Czy masz jakieś życzenie?
Dmitrij: Tak, mam kilka życzeń.
Pierwsze i mercenarskie — zapisz się na . Szanowni czytelnicy, wejdźcie na YouTube i zasubskrybujcie nasz kanał. Za około miesiąc rozpoczniemy aktywną ekspansję na platformę wideo, gdzie będzie mnóstwo materiałów edukacyjnych na temat Kubernetes, zarówno otwartych, jak i różnorodnych: od praktycznych zagadnień, po laboratoria, a nawet głębokie teoretyczne zasady dotyczące zastosowania Kubernetes na poziomie zasad i wzorców.
Drugie mercenarskie życzenie — zajrzyj na i wystaw nam gwiazdki, ponieważ to nas karmi. Jeśli nie wystawicie nam gwiazdek, nie będziemy mieli co jeść. To jak manna w grze komputerowej. Robimy coś, robimy, staramy się, ktoś mówi, że to straszne rowery, ktoś, że wszystko jest całkowicie źle, a my nadal działamy, całkowicie uczciwie. Widzimy problem, rozwiązujemy go i dzielimy się doświadczeniem. Dlatego wystawcie nam gwiazdkę, nic wam to nie da, a nam przybędzie, ponieważ to nas karmi.
Trzecie, ważne i już nie mercenarskie życzenie — przestańcie wierzyć w bajki. Jesteście profesjonalistami. DevOps to bardzo poważny i odpowiedzialny zawód. Przestańcie bawić się w pracy. Niech coś was uderzy, i zrozumiecie to. Wyobraźcie sobie, że przyjdziecie do szpitala, a tam lekarz eksperymentuje na was. Rozumiem, że niektórym to może być przykro, ale najprawdopodobniej to nie o was chodzi, lecz o kogoś innego. Powiedzcie innym, aby też przestali. To naprawdę psuje życie nam wszystkim — wielu zaczyna traktować operacje, administratorów oraz DevOps jako gości, którzy znów coś zepsuli. To „zepsuli” najczęściej wynika z tego, że zaczęliśmy się bawić, a nie spokojnym umysłem spojrzeliśmy, że tu tak, a tu tak.
To nie znaczy, że nie warto eksperymentować. Eksperymentować trzeba, sami to robimy. Szczerze mówiąc, czasami też się bawimy — to, oczywiście, jest bardzo źle, ale nic ludzkiego nam nie jest obce. Ogłośmy rok 2019 rokiem poważnych, przemyślanych eksperymentów, a nie zabaw na produkcji. Prawdopodobnie tak.
— Dziękuję bardzo!
Dmitrij: Dziękuję ci, Witalij, za czas i wywiad. Drodzy czytelnicy, serdecznie dziękuję, jeśli dotarliście do tego momentu. Mam nadzieję, że przynieśliśmy wam chociaż kilka myśli.
W wywiadzie Dmitrij poruszył temat werf. To teraz uniwersalny scyzoryk, który rozwiązuje prawie wszystkie zadania. Ale tak nie było zawsze. Na festiwalu Dmitrij Stolyarov szczegółowo opowie o tym narzędziu. W wystąpieniu będą omówione wszystkie: problemy i ukryte niuanse Kubernetes, możliwe rozwiązania tych trudności oraz obecna realizacja werf w szczegółach. Dołączcie 27 i 28 maja, będziemy tworzyć idealne narzędzia.
Źródło: habr.com
