Напярэдадні Віталь Хабараў узяў інтэрв'ю ў Дзмітрыя Сталярова (), тэхнічнага дырэктара і сузаснавальніка кампаніі «Флант». Віталь распытаў Зміцера пра тое, чым займаецца «Флант», пра Kubernetes, развіццё экасістэмы, падтрымку. Абмеркавалі, навошта патрэбен Kubernetes і ці патрэбен наогул. А яшчэ пра мікрасэрвісы, Amazon AWS, падыход "Мне павязе" ў DevOps, будучыня самога Kubernetes, чаму, калі і як ён захопіць свет, перспектывы DevOps і да чаго рыхтавацца інжынерам у светлай і блізкай будучыні са спрашчэннем і нейрасецямі.
у выглядзе падкасьце паслухайце на DevOps Дэфлопе - рускамоўным падкасьце аб DevOps, а ніжэй - тэкставая версія.
Тут і далей пытанні задае інжынер з Express42.
Пра «Флянт»
- Дзіма, прывітанне. Ты - тэхнічны дырэктар «»і таксама яго заснавальнік. Раскажы, калі ласка, чым займаецца кампанія, і ты ў ёй?
Дзмітрый: Звонку здаецца, быццам мы такія хлопцы, якія ходзяць, усім ставяць Kubernetes і нешта з ім робяць. Але гэта не так. Мы пачыналі, як кампанія, якая займаецца Linux, але ўжо вельмі даўно асноўная наша дзейнасць - абслугоўванне прадакшн і highload-праектаў пад ключ. Звычайна мы будуем усю інфраструктуру з нуля і потым доўга-доўга за яе адказваем. Таму, асноўная праца, якую выконвае «Флант», за што і атрымлівае грошы - гэта ўзяцце адказнасці і рэалізацыя прадакшн пад ключ.
Я, як тэхнічны дырэктар і адзін з заснавальнікаў кампаніі, круглыя суткі займаюся тым, што прыдумляю, як бы павысіць даступнасць прадакшн, спрасціць яго эксплуатацыю, аблегчыць жыццё адмінаў, а жыццё распрацоўшчыкаў зрабіць прыемней.
Пра Kubernetes
- Апошнім часам ад «Фланта» бачу шмат дакладаў і пра Kubernetes. Як вы прыйшлі да яго?
Дзмітрый: Я ўжо расказваў пра гэта шмат разоў, але мне зусім не шкада паўтарыць. Лічу, што правільна паўтараць гэтую тэму, бо ўзнікае блытаніна паміж прычынай і следствам.
Нам вельмі патрэбен быў інструмент. Мы сутыкаліся з кучай праблем, дужаліся, пераадольвалі іх рознымі мыліцамі і выпрабоўвалі запатрабаванне ў прыладзе. Перабіралі шмат розных варыянтаў, будавалі свае веласіпеды, назапашвалі вопыт. Паступова дайшлі да таго, што пачалі выкарыстоўваць Docker амаль адразу як ён з'явіўся - прыкладна ў 2013 годзе. У момант яго з'яўлення ў нас ужо было шмат вопыту з кантэйнерамі, мы ўжо напісалі аналаг "Docker" - нейкія свае мыліцы на Python. Са з'яўленнем Docker з'явілася магчымасць мыліцы выкінуць і выкарыстоўваць надзейнае і падтрымоўванае супольнасцю рашэнне.
З Kubernetes гісторыя аналагічная. Да моманту, калі ён пачаў набіраць абароты, для нас гэта версія 1.2, у нас ужо была куча мыліц і на Shell, і на Chef, якія мы неяк спрабавалі аркестраваць Docker. Мы сур'ёзна глядзелі ў бок Rancher і розных іншых рашэнняў, але тут з'явіўся Kubernetes, у якім усё рэалізавана роўна так, як зрабілі б мы ці нават лепей. Прычапіцца няма да чаго.
Так, тут ёсць нейкая недаробка, там нейкая недаробка - шмат недаробак, а 1.2 наогул жудасць, але .... Kubernetes як будынак - глядзіш на праект і разумееш, што гэта будзе крута. Калі ў будынка зараз ёсць падмурак і два паверхі, то разумееш, што лепш пакуль не засяляцца, а з софтам такіх праблем няма - карыстацца ўжо можна.
У нас не было моманту, што мы думалі выкарыстоўваць Kubernetes ці не. Мы яго чакалі задоўга да таго, як ён з'явіўся, і спрабавалі самі гарадзіць аналагі.
Каля Kubernetes
- Вы ўдзельнічаеце непасрэдна ў распрацоўцы самога Kubernetes?
Дзмітрый: Пасрэдна. Хутчэй удзельнічаем у развіцці экасістэмы. Мы адпраўляем нейкую колькасць pull requests: у Prometheus, ва ўсякія аператары, у Helm – у экасістэму. На жаль, я не ў стане сачыць за ўсім, што мы робім і магу памыляцца, але ад нас няма ніводнага пула ў ядро.
- Пры гэтым вы распрацоўваеце і шмат сваіх інструментаў вакол Kubernetes?
Дзмітрый: Стратэгія такая: мы ідзём і пул-рэквеставаным ва ўсё, што ўжо ёсць. Калі там pull requests не прымаюцца, мы проста форкаем іх сабе і жывем, пакуль яны не прыняты з нашымі білдамі. Потым, калі гэта далятае да upstream, мы вяртаемся зваротна на upstream'авую версію.
Напрыклад, у нас ёсць Prometheus-аператар, з якім мы туды-сюды перамыкаліся на upstream нашай зборкі ўжо разоў 5, мусіць. Нам патрэбна нейкая фіча, мы паслалі pull request, нам трэба яе заўтра выкаціць, а чакаць, пакуль яе рэлізуюць у upstream, не жадаем. Адпаведна, мы збіраем сабе, коцім нашу зборку з нашай фічай, якая нам навошта-то патрэбна, на ўсе свае кластары. Потым гэта, напрыклад, у upstream нам заварочваюць са словамі: «Хлопцы, давайце, зробім для больш агульнага выпадку», мы, ці хтосьці іншы, гэта дарабляем, і з часам ізноў зваротна зліваецца.
Усё, што існуе, мы імкнемся развіваць. Многія элементы, якіх яшчэ няма, яшчэ не прыдумалі ці прыдумалі, але не паспелі рэалізаваць - мы робім. І не таму, што нам падабаецца сам працэс або роварабудаванне як галіна, а проста таму, што нам патрэбен гэты інструмент. Часта задаюць пытанне, навошта мы зрабілі тую ці іншую рэч? Адказ просты - ды таму, што нам трэба было ісці далей, вырашыць нейкую практычную праблему, і мы яе вырашылі гэтым тулам.
Шлях заўсёды такі: мы вельмі старанна шукаем і, калі не знаходзім ніякага рашэння, як з баханкі хлеба зрабіць тралейбус, то які робіцца свой бохан і свой тралейбус.
Інструменты «Фланта»
- Мне вядома, што цяпер у "Фланта" ёсць addon-аператары, shell-аператары, інструменты dapp / werf. Як я разумею, гэта адзін і той жа інструмент у розных інкарнацыях. Таксама я разумею, што ўсярэдзіне "Флант" ёсць яшчэ шмат розных інструментаў. Гэта так?
Дзмітрый: У нас на GitHub яшчэ шмат чаго ёсць. З таго, што я зараз успомню, у нас ёсць statusmap – панэль для Grafana, якая зайшла ўсім. Яна згадваецца ці ледзь не ў кожным другім артыкуле пра маніторынг Kubernetes на Медыум. Немагчыма коратка распавесці, што такое statusmap - патрэбны асобны артыкул, але гэта вельмі карысная рэч для маніторынгу статусу ў часе, бо ў Kubernetes нам часта патрабуецца паказваць статус у часе. Яшчэ ў нас ёсць LogHouse - гэта штука на базе ClickHouse і чорнай магіі для збору логаў у Kubernetes.
Шмат утыліт! І будзе яшчэ больш, таму што некаторая колькасць унутраных рашэнняў будзе рэлізіцца ў гэтым годзе. З вельмі вялікіх на базе addon-аператара ёсць куча addons да Kubernetes аля як правільна паставіць sert manager - інструмент для кіравання сертыфікатамі, як правільна паставіць Prometheus з кучай абважвання - гэта штук дваццаць розных бінарнікаў, якія экспартуюць дадзеныя і нешта збіраюць, да гэтага Prometheus шыкоўная графіка і алерты. Усё гэта проста куча addons да Kubernetes, якія ставяцца ў кластар, і ён ператвараецца з простага ў круты, наварочаны, аўтаматычны, у якім многія пытанні ўжо вырашаны. Так, шмат што які робіцца.
Развіццё экасістэмы
- Мне здаецца, гэта вельмі вялікі ўклад у развіццё гэтага інструмента і яго метадаў выкарыстання. Ці можаш ты прыкладна прыкінуць, хто б яшчэ ўносіў такі ж уклад у развіццё экасістэмы?
Дзмітрый: У Расіі з тых кампаній, якія дзейнічаюць на нашым рынку - ніхто і блізка. Вядома, гэта гучная заява, таму што ёсць буйныя гульцы, як Mail з Яндэксам - яны таксама нешта робяць з Kubernetes, але нават яны не падабраліся да ўкладу кампаній у цэлым па свеце, якія робяць значна больш, чым мы. Складана параўноўваць "Флант" са штатам у 80 чалавек і Red Hat, у якім толькі на адзін Kubernetes 300 інжынераў, калі не памыляюся. Цяжка параўноўваць. У нас у аддзеле RnD 6 чалавек уключаючы мяне, якія пілуюць усе нашы тулы. 6 чалавек супраць 300 інжынераў Red Hat – неяк складана параўноўваць.
- Тым не менш, калі нават гэтыя 6 чалавек могуць зрабіць нешта сапраўды карыснае і адчужаемае, калі яны сутыкаюцца з практычнай задачай і аддаюць рашэнне ў супольнасць - цікавы кейс. Разумею, што ў буйных тэхналагічных кампаніях, дзе ёсць свая распрацоўка і каманда падтрымкі Kubernetes, у прынцыпе, могуць распрацоўвацца такія ж тулы. Гэта для іх прыклад, што можна распрацаваць і аддаць у супольнасць, даць штуршок усёй супольнасці, якую выкарыстоўвае Kubernetes.
Дзмітрый: Напэўна, гэта фішка інтэгратара, яго адметнасць. У нас жа шмат праектаў і мы бачым шмат розных сітуацый. Для нас асноўны спосаб стварэння дабаўленай вартасці - гэта прааналізаваць гэтыя кейсы, знайсці агульнае і максімальна зрабіць таннейшым іх для нас. Гэтым мы актыўна займаемся. Мне складана казаць пра Расею і мір, але ў нас прыкладна 40 DevOps-інжынераў у кампаніі, якія займаюцца Kubernetes. Я не думаю, што ў Расіі шмат кампаній з супастаўнай колькасцю спецыялістаў, якія разбіраюцца ў Kubernetes, калі яны ўвогуле ёсць.
Я разумею ўсё пра назву пасады DevOps-інжынер, усе ўсё разумеюць і прывыклі называць DevOps-інжынераў DevOps-інжынерамі, мы не будзем гэта абмяркоўваць. Усе гэтыя 40 выдатных DevOps-інжынераў кожны дзень сутыкаюцца з праблемамі і вырашаюць іх, мы проста аналізуем гэты досвед і спрабуем абагульніць. Мы разумеем, што калі ён застанецца ў нас усярэдзіне, то праз год ці два прылада бескарысны, таму што дзесьці ў community з'явіцца гатовая тула. Няма сэнсу назапашваць гэты досвед усярэдзіне - гэта проста зліў сіл і чакай у dev/null. А так нам зусім не шкада. Мы з вялікім задавальненнем усё публікуем і разумеем, што гэта трэба публікаваць, развіваць, піярыць, раскручваць, каб людзі карысталіся і дадавалі свой досвед - тады ўсё расце і жыве. Тады праз два гады інструмент не ідзе на памыйніцу. Не шкада працягваць уліваць сілы, таму што бачна, што тваім інструментам нехта карыстаецца, а праз два гады ім карыстаюцца ўжо ўсе.
Гэта частка нашай вялікай стратэгіі з dapp/werf. Не памятаю, калі мы пачалі яго рабіць, здаецца, гады 3 таму. Першапачаткова ён быў увогуле на shell. Гэта быў супер proof of concept, мы вырашылі нейкія нашыя прыватныя задачы — атрымалася! Але з shell там праблемы, далей гэта нарошчваць немагчыма, праграмаваць на shell - то яшчэ занятак. У нас была звычка пісаць на Ruby, адпаведна, на Ruby мы нешта перарабілі, развівалі, развівалі, развівалі, і ўперліся ў тое, што community, натоўп, які не кажа "мы хочам ці не хочам", верне нос ад Ruby, як гэта не смешна. Зразумелі, што павінны ўсё гэта дабро пісаць на Go, каб проста адпавядаць першаму пункту ў чэк-лісце: DevOps-тула павінна быць статычным бінарнікам. На Go ці не на Go не так важна, але лепш статычны бінарнік, напісаны на Go.
Патрацілі сілы, перапісалі dapp на Go і назвалі яго werf. Dapp больш не падтрымліваецца, не развіваецца, працуе ў нейкай апошняй версіі, але ёсць абсалютны upgrade-шлях наверх, і яму можна рушыць услед.
Навошта ствараўся dapp
- Можаш сцісла распавесці, навошта ствараўся dapp, якія праблемы ён вырашае?
Дзмітрый: Першая прычына ў зборцы. Першапачаткова ў нас былі моцныя праблемы са зборкай, калі Docker не ўмеў multi-stage, і мы зрабілі multi-stage саматугам. Потым у нас была яшчэ куча пытанняў з ачысткай image. Усё, хто робяць CI/CD, хутчэй раней, чым пазней, сутыкаюцца з праблемай, што ёсць куча сабраных images, патрабуецца неяк вычышчаць тое, што не трэба, і пакідаць тое, што трэба.
Другая прычына ў дэплоі. Так, есць Helm, але ён вырашае толькі частка задач. Як ні смешна, напісана, што "Helm – the Package Manager for Kubernetes". Менавіта, што "the". Яшчэ ёсць словы "Package Manager" - якое чаканне звычайна ад Package Manager? Мы кажам: «Package Manager – пастаў пакет!» і чакаем, што ён нам скажа: "Пакет пастаўлены".
Цікава, што мы кажам: «Helm, пастаў пакет», а калі ён адказвае, што паставіў, то высвятляецца, што ён толькі пачаў усталёўку — паказаў Kubernetes: «Вось гэтую штуку запусці!», а запусцілася яна ці не, працуе ці не , Helm гэтае пытанне ўвогуле ніяк не вырашае.
Атрымліваецца, што Helm - проста тэкставы прэпрацэсар, які загружае дадзеныя ў Kubernetes.
Але мы ў рамках любога дэплоя хочам ведаць - дадатак выкацілася на прод ці не? Выкацілася на прад значыць, што дадатак туды выехала, разгарнулася новая версія разгарнулася, і яна там хаця б не падае і карэктна адказвае. Helm гэтую задачу ніяк не вырашае. Каб яе вырашыць, трэба выдаткаваць шмат сіл, таму што неабходна аддаць Kubernetes каманду выкочваць і сачыць за тым, што ж там адбываецца - ці разгарнулася яно, ці выкацілася. А яшчэ ёсць куча задач, злучаных з дэплоем, з ачысткай, са зборкай.
Планы
Яшчэ сёлета мы пойдзем у лакальную распрацоўку. Мы жадаем прыйсці да таго, што раней было ў Vagrant набралі vagrant up і ў нас разгарнуліся віртуалкі. Мы жадаем прыйсці да такога стану, што ёсць праект у Git, мы тамака пішам «werf up», і ён паднімае лакальную копію гэтага праекту, разгорнутую ў лакальным міні-Kub, з падлучанымі ўсімі дырэкторыямі, зручнымі для распрацоўкі. У залежнасці ад мовы распрацоўкі гэта выконваецца па-рознаму, але, тым не менш, каб можна было зручна весці лакальную распрацоўку пад мантаванымі файламі.
Наступны крок для нас - моцна ўкладвацца ў зручнасць для распрацоўшчыкаў. Каб адной прыладай хутка лакальна разгарнуць праект, патаннець, пушнуць у Git, і ён сапраўды таксама выкоціцца на stage ці на тэсты, у залежнасці ад пайплайнаў, і потым тым жа самым прыладай паехаць на прод. Гэта адзінства, уніфікацыя, узнаўляльнасць інфраструктуры ад лакальнага асяроддзя да прода для нас вельмі важны момант. Але гэтага пакуль няма ў werf - толькі плануем рабіць.
Але шлях да dapp/werf заўседы быў такі ж, як з Kubernetes у пачатку. Мы сутыкаліся з праблемамі, вырашалі іх абыходнымі шляхамі – прыдумлялі для сябе нейкія рашэнні на shell, на чым заўгодна. Потым гэтыя абыходныя шляхі імкнуліся неяк выраўнаваць, абагульніць і кансалідаваць у бінарнікі ў дадзеным выпадку, якімі проста дзелімся.
Ёсць яшчэ іншы погляд на ўсю гэтую гісторыю, з аналогіямі.
Kubernetes - гэта каркас аўтамабіля з рухавіком. Няма дзвярэй, шкла, радыёпрымача, ялінкі - наогул нічога няма. Толькі рама і рухавічок. І ёсць Helm гэта руль. Класна руль ёсць, але патрэбныя яшчэ рулявы штыфт, рулявая рэйка, КПП і колы, а без іх ніяк.
У выпадку з werf гэта яшчэ адзін кампанент да Kubernetes. Толькі цяпер у нас у альфа-версіі werf, напрыклад, Helm укамплёўваецца наогул унутр werf, таму што нам надакучыла гэта рабіць самім. Шмат прычын так рабіць, падрабязна пра тое, навошта мы ўкампілі helm цалкам разам з tiller ўнутр werf, я раскажу як раз .
Цяпер werf – гэта больш інтэграваны кампанент. У нас атрымліваецца гатовы руль, рулявы штыфт я не вельмі добрае ў аўтамабілях разбіраюся, але гэта вялікі блок, які вырашае ўжо досыць вялікі спектр задач. Нам не трэба самім лазіць па каталогу, падбіраць адну дэталь да іншай, думаць, як іх прыкруціць сябар да сябра. Мы атрымліваем гатовы камбайн, які вырашае адразу вялікі пачак задач. Але ўнутры ён уладкованы ўсё з тых жа апенсорсных кампанентаў, усё таксама выкарыстоўвае Docker для зборкі, Helm для часткі функцыяналу, і ёсць яшчэ некалькі іншых бібліятэк. Гэта інтэграваны інструмент, каб атрымаць хутка і зручна круты CI/CD са скрынкі.
Ці цяжка падтрымліваць Kubernetes?
- Ты распавядаеш пра досвед, што пачалі выкарыстоўваць Kubernetes, гэта для вас рама, рухавічок, і што на яго можна шмат усяго рознага навесіць: корпус, руль, прыкруціць педалькі, сядзенні. Узнікае пытанне - наколькі складана вам даецца падтрымка Kubernetes? У вас багаты досвед, колькі ў вас сыходзіць часу і рэсурсаў менавіта на падтрымку Kubernetes у адрыве ад усяго астатняга?
Дзмітрый: Гэта вельмі складанае пытанне і каб адказаць, трэба зразумець, што такое падтрымка, і што мы хочам ад Kubernetes. Можа быць, ты расчыніш?
- Наколькі мне вядома і як я бачу, цяпер шмат каманд хочуць паспрабаваць Kubernetes. Усе ў яго запрагаюцца, ставяць на каленцы. У мяне ёсць адчуванне, што людзі не заўжды разумеюць складанасць гэтай сістэмы.
Дзмітрый: Усё так.
- Наколькі складана ўзяць і паставіць Kubernetes з нічога, каб гэта было production ready?
Дзмітрый: Як думаеш, наколькі складана перасадзіць сэрца? Разумею, пытанне кампраметуючае. Вазіць скальпелем і не памыліцца - гэта не так складана. Калі табе кажуць дзе адрэзаць, а дзе зашыць, то сама па сабе працэдура нескладаная. Складана гарантаваць з разу ў раз, што ўсё атрымаецца.
Паставіць Kubernetes і прымусіць працаваць проста: чык! - паставіўся, ёсць куча спосабаў усталёўкі. Але што будзе, калі ўзнікнуць праблемы?
Заўсёды паўстаюць пытанні - што мы яшчэ не ўлічылі? Што мы яшчэ не зрабілі? Якія параметры Linux-ядра паказалі няправільна? Госпадзі, а мы ўвогуле іх паказвалі?! Якія кампаненты Kubernetes мы паставілі, а якія не? Узнікаюць тысячы пытанняў, і каб адказаць на іх, трэба 15-20 год варыцца ў гэтай індустрыі.
У мяне ёсць свежы прыклад на гэтую тэму, які можа раскрыць сэнс праблемы "Ці складана падтрымліваць Kubernetes?". Некаторы час таму мы сур'ёзна разглядалі не паспрабаваць ці нам укараніць Cilium у якасці сеткі ў Kubernetes.
Растлумачу, што такое Cilium. У Kubernetes ёсць шмат розных рэалізацый сеткавай падсістэмы, і адна з іх вельмі крутая – гэта Cilium. У чым яе сэнс? У ядры некаторы час назад з'явілася магчымасць пісаць хукі для ядра, якія так ці інакш урываюцца ў сеткавую падсістэму і ў розныя іншыя падсістэмы, і дазваляюць абыйсці вялікія кавалкі ў ядры.
У Linux-ядры гістарычна ёсць ip rout, надфільтр, брыджы і шмат розных старых кампанент, якім па 15, 20 30 гадоў. У цэлым яны працуюць, усё класна, але зараз нагарадзілі кантэйнераў, і гэта выглядае як вежка з 15 цаглін сябар на сябру, а ты стаіш на ёй на адной назе - дзіўнае адчуванне. Гэтая сістэма гістарычна развівалася са мноствам нюансаў, як апендыкс у арганізме. У некаторых сітуацыях ёсць праблемы з performance, напрыклад.
Ёсць выдатны BPF і магчымасць пісаць хукі для ядра - хлопцы напісалі свае хукі для ядра. Пакет прыходзіць у Linux-ядро, яны яго прама на ўваходзе вымаюць, апрацоўваюць самі як трэба без брыджаў, без TCP, без IP-стэка - карацей, у абыход усяго, што напісана ў Linux-ядры, і тут жа выплёўваюць у кантэйнер.
Што атрымалася? Вельмі круты performance, стромкія фічы - проста класна! Але мы глядзім на гэта і бачым, што на кожнай машыне стаіць прога, якая падключаецца да API Kubernetes і па дадзеных, якія атрымлівае з гэтага API, генеруе C-код і кампіліт бінарнікі, якія загружае ў ядро, каб у kernel space гэтыя хукі працавалі .
Што будзе, калі нешта пойдзе не так? Мы не ведаем. Каб гэта зразумець, трэба прачытаць увесь гэты код, зразумець усю логіку, а гэта ачмурэць, як складана. Але, з іншага боку, ёсць гэтыя брыджы, net-фільтры, ip rout – я не чытаў іх зыходнікі, і 40 інжынераў, якія працуюць у нашай кампаніі таксама. Можа, нейкія кавалкі разумеюць адзінкі.
І якая розніца? Атрымліваецца, што ёсць ip rout, ядро Linux, і ёсць новая прылада - якая розніца, мы ні адну, ні іншую не разумеем. Але баімся выкарыстоўваць новае - чаму? Таму што калі інструменту 30 гадоў, то за 30 гадоў усе багі знайшлі, на ўсе граблі наступілі і ведаць пра ўсё не трэба - працуе, як чорная скрыня, і працуе заўсёды. Усё ведаюць, якую дыягнастычную адвёртку ў якое месца ўторкнуць, які tcpdump у які момант запусціць. Усё добра ведаюць дыягнастычныя ўтыліты і разумеюць, як гэты набор кампанентаў працуе ў ядры Linux – не як ён уладкованы, а як ім карыстацца.
А афігенна класнаму Cilium не 30 гадоў, ён яшчэ не вытрыманы. З Kubernetes такая ж праблема, копія. Што Cilium ставіцца выдатна, што Kubernetes ставіцца выдатна, але, калі нешта не так пойдзе ў продзе, ці здольныя вы ў крытычнай сітуацыі хутка зразумець, што пайшло не так?
Калі мы кажам, ці складана падтрымліваць Kubernetes – не, вельмі проста, і так, неверагодна складана. Kubernetes выдатна працуе сам па сабе, але з мільярдам нюансаў.
Пра падыход "Мне павязе"
- А ці ёсць кампаніі, дзе гэтыя нюансы амаль гарантавана з'явяцца? Выкажам здагадку, Яндэкс раптам пагалоўна перавядзе ўсе сэрвісы на Kubernetes, тамака будзе ого-го якая нагрузка.
Дзмітрый: Не, гэта ж размова не пра нагрузку, а пра найпростыя рэчы. Напрыклад, ёсць у нас Kubernetes, мы задэплоілі туды дадатак. Як зразумець, што яна працуе? Гатовага інструмента, каб зразумець, што прыкладанне не падае, проста няма. Гатовай сістэмы, якая шле алерты - не, трэба наладзіць гэтыя алерты і кожны графік. А мы вось абнаўляем Kubernetes.
Ёсць Ubuntu 16.04/16.04. Можна сказаць, што гэта старая версія, але мы да гэтага часу на ёй, таму што там LTS. Тамака ёсць systemd, нюанс якога ў тым, што ён не чысціць C-групы. Kubernetes запускае поды, стварае C-групы, потым поды выдаляе, і неяк так атрымліваецца - я не памятаю дэталяў, прабачце, - што застаюцца слайсы systemd. Гэта прыводзіць да таго, што з часам любая машына пачынае моцна тармазіць. Гэта нават пытаньне не пра highload. Калі запускаюцца сталыя поды, напрыклад, калі ёсць Cron Job, які ўвесь час генеруе поды, то машына з Ubuntu 16/XNUMX праз тыдзень пачне тармазіць. Там будзе ўвесь час высокі load average з-за таго, што створана куча C-груп. Гэта праблема, з якой сутыкаецца любы чалавек, які проста паставіць Ubuntu XNUMX і зверху Kubernetes.
Дапушчальны, ён неяк абновіць systemd ці нешта яшчэ, але ў ядры Linux да 4.16 яшчэ смяшней - пры выдаленні C-груп яны ў ядры падцякаюць і фактычна не выдаляюцца. Таму праз месяц працы на гэтай машыне немагчыма будзе паглядзець статыстыку па памяці па падах. Мы дастаем файлік, катаем у прозе, і адзін файлік катаецца 15 секунд, таму што ядро вельмі доўга лічыць ўнутры сябе па мільёне C-груп, якія быццам бы выдаленыя, але не - яны падцякаюць.
Такіх дробязяў да гэтага часу вельмі шмат і там і тут. Гэта не пытанне, з якім кампаніі-гіганты могуць часам сутыкнуцца пры вельмі вялікіх нагрузках - не, гэта пытанне штодзённых рэчаў. Людзі могуць месяцамі так жыць - паставілі Kubernetes, задэплоілі дадатак - накшталт працуе. Многім так нармальна. Пра тое, што калісьці гэта дадатак чамусьці ўпадзе, яны нават не даведаюцца, алерт не прыйдзе, але для іх гэта норма. Раней жылі на віртуалка без маніторынгу, цяпер пераехалі ў Kubernetes таксама без маніторынгу - якая розніца?
Пытанне ў тым, што калі мы ходзім па лёдзе, ніколі не ведаем яго таўшчыню, калі не вымералі загадзя. Многія ходзяць і не парацца, бо і раней хадзілі.
На мой погляд, нюанс і складанасць эксплуатацыі любой сістэмы ў тым, каб гарантаваць, што таўшчыні лёду сапраўды хопіць, каб вырашыць нашы задачы. Гаворка пра гэта.
У IT, мне здаецца, занадта шмат падыходаў "Мне павязе". Многія ставяць софт, выкарыстоўваюць праграмныя бібліятэкі ў надзеі, што ім пашанцуе. У цэлым, вязе шматлікім. Мусіць таму гэта і працуе.
- З маёй песімістычнай ацэнкі гэта выглядае так: калі рызыкі вялікія, а прыкладанне павінна працаваць, то патрэбна падтрымка ад "Фланта", магчыма, ад Red Hat, альбо патрабуецца свая ўнутраная каманда, выдзеленая менавіта на Kubernetes, якая гатова яго цягнуць.
Дзмітрый: Аб'ектыўна гэта так. Улазіць самастойна ў гісторыю з Kubernetes невялікай камандзе - гэта некаторая колькасць рызык.
Ці патрэбны нам кантэйнеры?
- Можаш распавесці, наколькі Kubernetes наогул распаўсюджаны ў Расіі?
Дзмітрый: У мяне няма гэтых дадзеных, і я не ўпэўнены, што яны ёсць увогуле ў каго-небудзь. Мы кажам: "Kubernetes, Kubernetes", а ёсць жа іншы погляд на гэтае пытанне. Наколькі распаўсюджаныя кантэйнеры, я таксама не ведаю, але ведаю лічбу са справаздач у інтэрнэце, што 70% кантэйнераў аркеструе Kubernetes. Гэта была дакладная крыніца па дастаткова вялікай выбарцы па свеце.
Далей іншае пытанне - ці патрэбныя нам кантэйнеры? У мяне асабістае адчуванне і ў цэлым пазіцыя кампаніі "Флант" такая, што Kubernetes – гэта стандарт дэ-факта.
Нічога акрамя Kubernetes не будзе.
Гэта абсалютны game-changer у вобласці кіравання інфраструктурай. Проста абсалютны усё, больш ніякіх Ansible, Chef, віртуальных машын, Terraform. Я ўжо не гавару пра старыя калгасныя метады. Kubernetes - гэта абсалютны changer, і зараз будзе толькі так.
Зразумела, што камусьці патрэбна пара гадоў, а камусьці пара дзясяткаў, каб гэта ўсвядоміць. У мяне няма сумневаў, што не будзе нічога, акрамя Kubernetes і гэтага новага погляду: больш мы не паранім аперацыёнку, а выкарыстоўваны infrastructure as code, толькі не з кодам, а з yml - дэкларатыўна апісаную інфраструктуру. У мяне адчуванне, што так будзе заўжды.
- Гэта значыць тыя кампаніі, што яшчэ не перайшлі на Kubernetes, абавязкова на яго пяройдуць або застануцца ў забыцці. Я правільна цябе зразумеў?
Дзмітрый: Гэта таксама не зусім дакладна. Напрыклад, калі ў нас стаіць задача запусціць dns-сервер, тое яго можна запусціць на FreeBSD 4.10 і ён можа 20 гадоў выдатна працаваць. Проста працаваць і ўсё. Магчыма, за 20 гадоў спатрэбіцца нешта абнавіць адзін раз. Калі мы гаворым пра софт у фармаце, што мы запусцілі і ён рэальна шмат гадоў працуе без нейкіх абнаўленняў, без унясення зменаў, то, вядома, там не будзе Kubernetes. Ён тамака не патрэбен.
Усё, што тычыцца CI/CD – усюды, дзе патрэбен Continuous Delivery, дзе патрабуецца абнаўляць версіі, весці актыўныя змены, усюды, дзе неабходна выбудаваць адмоваўстойлівасць – толькі Kubernetes.
Пра мікрасэрвісы
- Тут у мяне ўзнікае невялікі дысананс. Каб працаваць з Kubernetes, патрэбна знешняя або ўнутраная падтрымка - гэта першы момант. Другі - калі мы толькі-толькі пачынаем распрацоўку, мы маленькі стартап, у нас яшчэ нічога няма, распрацоўка пад Kubernetes ці наогул пад мікрасэрвісную архітэктуру можа быць складанай, і не заўсёды апраўдана з эканамічна. Мне цікава тваё меркаванне ці трэба стартапам з нуля адразу пачынаць пісаць пад Kubernetes ці можна ўсёткі напісаць маналіт, і потым толькі прыйсці да Kubernetes?
Дзмітрый: Стромкае пытанне. У мяне ёсць даклад пра мікрасэрвісы Я шмат разоў сутыкаўся з тым, што людзі спрабуюць мікраскопам забіваць цвікі. Сам па сабе падыход правільны, мы самі ўнутраны софт праектуем менавіта гэтым шляхам. Але калі гэта робіш, трэба дакладна разумець, што ты робіш. Больш за ўсё ў мікрасэрвісах я ненавіджу слова "мікра". Гістарычна склалася, што там узнікла гэтае слова, і чамусьці людзі думаюць, што мікра — гэта вельмі маленькі, менш за міліметр, як мікраметр. Гэта не так.
Напрыклад, ёсць маналіт, які пішуць 300 чалавек, і ўсе, хто ўдзельнічаў у распрацоўцы, разумеюць, што там ёсць праблемы, і яго трэба было б разбіць на мікра-кавалачкі — штук на 10, кожны з якіх пішуць 30 чалавек у мінімальным варыянце. Гэта важна, патрэбна і класна. Але калі да нас прыходзіць стартап, дзе 3 вельмі крутых і таленавітых пацана напісалі на каленцы 60 мікрасэрвісаў, кожны раз я шукаю карвалол.
Мне здаецца, пра гэта ўжо казалі тысячы разоў - атрымалі размеркаваны маналіт у той ці іншай выяве. Гэта эканамічна не апраўдана, вельмі складана ўвогуле ва ўсім. Проста я гэта столькі разоў бачыў, што мне проста балюча, таму я працягваю пра гэта казаць.
Да пачатковага пытання, што ёсць канфлікт паміж тым, што, з аднаго боку, Kubernetes страшна выкарыстоўваць, таму што незразумела, што там можа зламацца ці не зарабіць, з другога боку, зразумела, што ўсё ідзе туды і нічога, акрамя Kubernetes, не будзе . Адказ - узважваць аб'ём карысці, якая прыходзіць, аб'ём задач, які вы можаце вырашыць. Гэта з аднаго боку шаляў. З іншага боку - рызыкі, якія звязаны з прастоем або са зніжэннем часу водгуку, ўзроўню даступнасці - са зніжэннем паказчыкаў працы.
Тут так - ці нам хутка рухацца, і Kubernetes дазваляе многія рэчы выконваць нашмат хутчэй і лепш, або выкарыстоўваць надзейныя, правераныя часам рашэнні, але рухацца значна павольней. Гэты выбар павінна рабіць кожная кампанія. Можна разглядаць гэта як дарожку ў джунглях - калі ідзеш першы раз, можна сустрэць змяю, тыгра або шалёнага барсука, а калі схадзіў 10 разоў - пратаптаў сцежку, прыбраў галінкі і хадзіць лягчэй. З кожным разам сцяжынка шырэйшая. Пасля гэта ўжо асфальтаваная дарога, а пазней прыгожы бульвар.
Kubernetes не стаіць на месцы. Ізноў пытанне: Kubernetes, з аднаго боку, гэта 4-5 бінарнікаў, з другога - гэта ўся экасістэма. Гэта аперацыёнка, якая ў нас стаіць на машынах. Што гэта? Ubuntu ці Curios? Гэта ядро Linux, куча дадатковых кампанентаў. Усе гэтыя штукі тут адну атрутную змяю выкінулі з дарогі, там агароджу паставілі. Kubernetes вельмі хутка і дынамічна развіваецца, і аб'ём рызык, аб'ём нязведанага з кожным месяцам памяншаецца і, адпаведна, гэтыя шалі перабалансуюцца.
Адказваючы на пытанне, што рабіць стартапу, я б сказаў – прыходзьце да "Фланта", плаціце 150 тысяч рублёў і атрымлівайце пад ключ DevOps easy service. Калі вы невялікі стартап у некалькі распрацоўшчыкаў - гэта працуе. Замест таго, каб наймаць свайго DevOps, якому трэба будзе вучыцца вырашаць вашыя праблемы і плаціць тым часам зарплату, вы атрымаеце рашэнне ўсіх пытанняў пад ключ. Так, ёсць некаторыя мінусы. Мы, як аўтсорсер, не можам быць так уцягнутыя і хутка рэагаваць на занясенне змен. Але затое ў нас шмат экспертызы, гатовыя практыкі. Мы гарантуем, што ў любой сітуацыі мы сапраўды хутка разбяромся і паднімем з таго святла любы Kubernetes.
Я катэгарычна рэкамендую аўтсорсінг стартапам і які склаўся бізнэсу да памеру, калі вы можаце вылучаць на эксплуатацыю каманду з 10 чалавек, таму што інакш няма сэнсу. Гэта катэгарычна мае сэнс аўтсорсіць.
Пра Amazon і Google
- Ці можна разглядаць у якасці аўтсорса хост ад рашэння ад Amazon або Google?
Дзмітрый: Так, вядома, гэта вырашае некаторую колькасць пытанняў. Але зноў нюансы. Усё роўна трэба разумець, як гэта выкарыстоўваць. Напрыклад, ёсць тысяча дробязяў у працы Amazon AWS: Load Balancer трэба выграваць ці загадзя пісаць заяўку, што "хлопцы, нам прыйдзе трафік, прагрэйце нам Load Balancer!" Гэтыя нюансы трэба ведаць.
Калі вы звяртаецеся да людзей, якія на гэтым спецыялізуюцца, вы атрымліваеце амаль усе тыпавыя рэчы зачыненымі. У нас зараз 40 інжынераў, да канца года іх, напэўна, будзе 60 – мы сапраўды з усімі гэтымі рэчамі сутыкаліся. Нават калі на нейкім праекце мы яшчэ раз сутыкаемся з гэтай праблемай, мы ўжо хутка адно ў аднаго пытаемся і ведаем, як вырашыць.
Напэўна, адказ такі - вядома, hosted-гісторыя палягчае нейкую частку. Пытанне ў тым, ці гатовыя вы давяраць гэтым хостэрам, і ці вырашаць яны вашы праблемы. Amazon і Google зарэкамендавалі сябе добра. Для ўсіх нашых кейсаў - сапраўды. Больш мы ніякіх пазітыўных досведаў не маем. Усе астатнія clouds, з якімі мы спрабавалі працаваць, ствараюць вельмі шмат праблем – і Ager, і ўсё, што ёсць у Расіі, і разнастайныя OpenStack у розных рэалізацыях: Headster, Overage – усё, што хочаце. Яны ўсё ствараюць праблемы, якія не жадаецца вырашаць.
Таму, адказ - так, але, па факце, спелых hosted-рашэнняў не вельмі шмат.
Каму патрэбен Kubernetes?
- І ўсё ж каму патрэбен Kubernetes? Хто павінен ужо пераходзіць на Kubernetes, хто тыповы кліент "Фланта", які прыходзіць менавіта за Kubernetes?
Дзмітрый: Пытанне цікавае, таму што зараз якраз на хвалі Kubernetes да нас многія прыходзяць: «Хлопцы, мы ведаем, што вы робіце Kubernetes, зрабіце нам!». Мы ім адказваем: "Спадары, мы не робім Kubernetes, мы робім прод і ўсё, што з ім звязана". Таму што зрабіць прод, не зрабіўшы ўвесь CI/CD і ўсю гэтую гісторыю, у наш час проста немагчыма. Усе адышлі ад падзелу, што ў нас распрацоўка распрацоўкай, а потым эксплуатацыя эксплуатацыяй.
Нашы кліенты чакаюць рознае, але ўсе чакаюць некаторага добрага цуду, што ў іх ёсць тыя ці іншыя праблемы, а цяпер - хоп! - Kubernetes іх вырашыць. Людзі вераць у цуды. Розумам разумеюць, што цуду не будзе, але душой спадзяюцца - а раптам гэты Kubernetes зараз нам усё вырашыць, пра яго столькі кажуць! Раптам ён зараз - чых! - і срэбная куля, чых! - І ў нас 100% uptime, усе распрацоўшчыкі могуць па 50 разоў рэлізаваць абы-што, і яно не падае. Увогуле, цуд!
Калі такія людзі да нас прыходзяць, мы кажам: «Прабачце, але цуду не бывае». Каб быць здаровым, трэба добра харчавацца і займацца спортам. Каб мець надзейны прад, яго трэба зрабіць надзейна. Каб мець зручны CI/CD, яго трэба зрабіць такім. Гэта шмат працы, якую трэба рабіць.
Адказваючы на пытанне, каму патрэбен Kubernetes - Kubernetes не патрэбен нікому.
У некаторых людзей ёсць памылковае адчуванне, што ім патрэбен Kubernetes. Людзям трэба, у іх проста глыбокае запатрабаванне перастаць думаць, займацца, цікавіцца наогул усімі праблемамі інфраструктуры і праблемамі запуску іх прыкладанняў. Яны жадаюць, каб прыкладанні проста працавалі і проста дэпляваліся. Для іх Kubernetes - гэта надзея, што яны перастануць чуць гісторыю, што "мы там валяліся", ці "не можам выкаціцца", ці нешта яшчэ.
Да нас звычайна прыходзіць тэхнічны дырэктар. З яго пытаюцца дзве рэчы: з аднаго боку, давай нам фічы, з другога боку - стабільнасць. Мы прапануем узяць гэта на сябе і зрабіць. Сярэбраная куля, дакладней, пасярэбраная, у тым, што ты перастанеш думаць пра гэтыя праблемы і марнаваць час. У цябе будуць спецыяльныя людзі, якія закрыюць гэтае пытанне.
Фармулёўка, што нам ці камусьці патрэбен Kubernetes - няправільная.
Kubernetes вельмі патрэбен адмінам, таму што гэта ж вельмі цікавая цацка, з якой можна пагуляць, пакалупацца. Давайце будзем сумленныя - усё любяць цацкі. Усе мы дзесьці дзеці, і калі мы бачым новую - хочам у яе пагуляць. У кагосьці гэта адбіта, напрыклад, у адмінстве, бо ўжо найграліся і ўжо надакучыла да таго, што проста не хочацца. Але ж гэта не адбіта ні ў кога цалкам. Напрыклад, калі мне цацкі ў вобласці сістэмнага адміністравання і DevOps ужо даўно надакучылі, то цацкі вось я ўсё роўна кахаю, нейкія новыя ўсё роўна купляю. Усе людзі так ці інакш усё роўна жадаюць нейкія цацкі.
Не трэба гуляць з прадакшн. Што б я катэгарычна не рэкамендаваў рабіць і што бачу зараз масава: "А, новая цацка!" - пабеглі яе купляць, купілі і: "Давайце яе зараз возьмем у школу, пакажам усім сябрам". Не рабіце так. Прашу прабачэння, у мяне проста дзеці растуць, я ўвесь час бачу нешта ў дзецях, заўважаю гэта ў сабе, і потым яшчэ абагульняю на астатніх.
Канчатковы адказ: не патрэбен вам Kubernetes. Вам трэба вырашыць вашыя праблемы.
Дабіцца можна таго, што:
- прод не падае;
- нават калі ён спрабуе ўпасці, мы аб гэтым ведаем загадзя, і можам нешта падкласці;
- мы можам яго мяняць з той хуткасцю, з якой нам патрабуецца па бізнесе, і рабіць гэта зручна, нам гэта не выклікае праблем.
Рэальных запатрабаванняў дзве: надзейнасць і дынамічнасць/гнуткасць выкату. Усім, хто зараз робіць нейкія IT-праекты, усё роўна, у якім-бізнэсе – soft for easing the world, і хто гэта разумее, трэба вырашыць гэтыя патрэбы. Kubernetes з правільным падыходам, з правільным разуменнем і з дастатковым досведам дазваляе іх вырашаць.
Пра serverless
— Калі зірнуць крыху далей у будучыню, то спрабуючы вырашыць праблему адсутнасці галаўнога болю з інфраструктурай, з хуткасцю выкаткі і хуткасцю змены прыкладання, з'яўляюцца новыя рашэнні, напрыклад, serverless. Ці адчуваеш ты нейкі патэнцыял у гэтым напрамку і, скажам так, небяспека для Kubernetes і падобных рашэнняў?
Дзмітрый: Тут трэба зноў зрабіць рэмарку, што я не празорлівец, які глядзіць наперад і кажа - будзе вось так! Хаця я толькі што рабіў тое ж самае. Я гляджу пад ногі і бачу там кучу праблем, напрыклад, як у камп'ютары працуюць транзістары. Да смешнага, так? Мы з нейкімі багамі ў CPU сутыкаемся.
Зрабіць serverless дастаткова надзейна, танна, эфектыўна і зручна, вырашыўшы ўсе экасістэмныя пытанні. Тут я згодны з Ілонам Маском, што патрэбна другая планета, каб зрабіць адмоваўстойлівасць для чалавецтва. Хаця я не ведаю, што ён кажа, але разумею, што не гатовы ляцець сам на Марс і гэта не заўтра будзе.
З serverless выразна зразумела, што гэта ідэалагічна правільная рэч, як адмоваўстойлівасць для чалавецтва – дзве планеты мець лепш, чым адну. Але як гэта зрабіць зараз? Адну экспедыцыю паслаць - не праблема, калі сканцэнтраваць на гэтым намаганні. Адправіць некалькі экспедыцый і засяліць тамака некалькі тысяч чалавек, думаю, таксама рэалістычна. А вось прама адмоваўстойлівасць цалкам зрабіць, каб палова чалавецтва там жыла, мне здаецца зараз немагчымым, не разгляданым.
З serverless адзін у адзін: штука класная, але яна далёкая ад праблем 2019 гады. Бліжэй да 2030 - давайце дажывем да яго. Я не сумняваюся, што дажывем, мы абавязкова дажывем (паўтарайце перад сном), але зараз трэба вырашаць іншыя праблемы. Гэта як верыць у казачнага поні Вясёлку. Так, пара адсоткаў кейсаў вырашаюцца, і вырашаюцца выдатна, але суб'ектыўна serverless - гэта вясёлка… Для мяне гэтая тэма занадта далёкая і занадта незразумелая. Я не гатовы казаць. У 2019 годзе з serverless ніводнае прыкладанне не напішаш.
Як будзе развівацца Kubernetes
- Пакуль мы ідзем да гэтай патэнцыйна выдатнай далёкай будучыні, як ты лічыш, як будзе развівацца Kubernetes і экасістэма вакол яго?
Дзмітрый: Я шмат пра гэта думаў і ў мяне ёсць дакладны адказ. Першае statefull усёткі stateless зрабіць лягчэй. Kubernetes першапачаткова ў гэта больш укладваў, з яго ўсё пачыналася. Stateless працуе практычна ідэальна ў Kubernetes, проста няма да чаго прычапіцца. Па statefull яшчэ куча праблем, дакладней, нюансаў. У нас ужо ўсё там выдатна працуе, але гэта мы. На тое, каб гэта працавала ва ўсіх, трэба яшчэ пару гадоў як мінімум. Гэта не разлічаны паказчык, а маё адчуванне з галавы.
Карацей, statefull вельмі моцна павінен - і будзе - развівацца, таму што ўсе прыкладанні ў нас захоўваюць статут, не бывае stateless-прыкладанняў. Гэта ілюзія, заўсёды патрэбная якая-небудзь БД і нешта яшчэ. Statefull - гэта спраўленне за ўсё, чаго можна, выпраўленне ўсіх багаў, паляпшэнне ўсіх праблем, з якімі цяпер сутыкаюцца - назавем гэта adoption.
Узровень нязведанага, узровень нявырашаных праблем, узровень верагоднасці з нечым сутыкнуцца, будзе моцна падаць. Гэта важная гісторыя. І аператары – усё, што звязана з кадыфікаваннем логікі адміністравання, логікі кіравання, каб атрымаць Easy Service: MySQL Easy Service, RabbitMQ Easy Service, Memcache Easy Service, – наогул усе гэтыя кампаненты, якія нам патрэбныя, каб атрымаць працуючым са скрынкі гарантавана. Гэта як раз вырашае тыя болі, што мы жадаем базу дадзеных, але не жадаем яе адміністраваць, ці жадаем Kubernetes, але не жадаем яго адміністраваць.
Гэтая гісторыя з развіццём аператараў у той ці іншай праяве будзе важная ў бліжэйшыя пару гадоў.
Я думаю моцна павінна ўзрасці прастата эксплуатацыі скрыню будзе станавіцца ўсё больш і больш чорным, усё больш і больш надзейным, з усё больш і прасцейшымі круцілкамі.
Я неяк слухаў старое інтэрв'ю Айзека Азімава 80-х гадоў на YouTube у шоў Saturday Night Live – перадача тыпу Урганта, толькі цікавая. Яго там пыталі пра будучыню кампутараў. Ён сказаў, што будучыня ў прастаце, як гэта было з радыёпрымачом. Радыёпрымач першапачаткова быў складанай штукай. Каб злавіць хвалю, трэба было 15 хвілін круціць круцілкі, круціць ражкі і наогул ведаць як усё ўладкавана, разумець фізіку перадачы радыёхваль. У выніку ў радыё засталася адна круцілка.
Цяпер у 2019 годзе якое радыё? У машыне радыёпрымач знаходзіць усе хвалі, назву станцый. Фізіка працэсу не змянілася за 100 гадоў, змянілася прастата выкарыстання. Цяпер, ды і не толькі зараз, ужо ў 1980 году, калі было інтэрв'ю з Азімавым, усё карысталіся радыё і ніхто не задумляўся аб тым, як яно ўладкована. Яно заўсёды працавала - гэта дадзенасць.
Азімаў тады казаў, што з кампутарамі будзе аналагічна - прастата выкарыстання ўзрасце. Калі ў 1980 годзе трэба атрымаць адмысловую адукацыю, каб націскаць кнопкі на кампутары, то ў будучыні гэта будзе не так.
У мяне адчуванне, што з Kubernetes і з інфраструктурай таксама будзе вельмі моцна ўзрастаць прастата выкарыстання. Гэта, па-мойму, відавочна - ляжыць на паверхні.
Што рабіць з інжынерамі?
- А што тады стане з інжынерамі, сістэмнымі адміністратарамі, якія падтрымліваюць Kubernetes?
Дзмітрый: А што стала з бухгалтарам пасля з'яўлення 1С? Прыкладна тое ж самае. Да гэтага лічылі на паперцы - зараз у праграме. Прадукцыйнасць працы ўзрасла на парадкі, а праца ад гэтага сама не знікла. Калі раней для ўкручвання лямпачкі трэба было 10 інжынераў, то зараз будзе дастаткова аднаго.
Колькасць софту і колькасць задач, мне здаецца, зараз расце з хуткасцю большай, чым з'яўляюцца новыя DevOps'ы і павялічваецца ККД. Цяпер на рынку канкрэтны дэфіцыт і ён працягнецца доўга. Пазней усё ўвойдзе ў некаторую норму, пры якой ККД працы ўзрасце, будзе ўсё больш serverless, да Kubernetes прыкруцяць нейронку, якая будзе падбіраць усе рэсурсы прама як трэба, і наогул усё робіць сама, як трэба - чалавек адыдзі і не замінай.
Але рашэньні ўсё роўна трэба будзе камусьці прымаць. Зразумела, што ўзровень кваліфікацыі і спецыялізаванасць гэтага чалавека вышэйшы. Цяпер у аддзеле бухгалтэрыі вам не патрэбны 10 супрацоўнікаў, якія вядуць бухгалтарскія кнігі, каб у іх рука не стамлялася. Гэта проста не патрэбна. Многія дакументы аўтаматычна скануюцца, распазнаюцца сістэмай электроннага дакументазвароту. Досыць аднаго разумнага галоўнага бухгалтара, ужо са значна вялікімі скіламі, з добрым разуменнем.
У цэлым такі шлях ва ўсіх галінах. З аўтамабілямі таксама: раней да аўтамабіля прыкладаўся аўтамеханік і тры вадзіцелі. Цяпер кіраванне аўтамабіля - гэта найпросты працэс, у якім мы ўсе ўдзельнічаем кожны дзень. Ніхто не задумваецца, што аўтамабіль - гэта нешта складанае.
DevOps або сістэмная інжынерыя нікуды не дзенуцца – высокаўзроўневай і эфектыўнасць працы будуць узрастаць.
— Я яшчэ чуў цікавую ідэю, што насамрэч і праца павялічыцца.
Дзмітрый: Вядома, сто працэнтаў! Таму што колькасць софту, якое мы пішам, увесь час расце. Колькасць пытанняў, якія мы вырашаем софтам, увесь час расце. Колькасць працы расце. Цяпер рынак DevOps жудасна перагрэты. Гэта бачна па зарплатных чаканнях. Па-добраму, не ўдаючыся ў дэталі, павінны быць джуніёры, якія жадаюць Х, мідлы, якія жадаюць 1,5Х, і сеньёры, якія жадаюць 2Х. А цяпер, калі глядзець маскоўскі рынак заробкаў DevOps'аў, джуніёр хоча ад Х да 3Х і сеньёр хоча ад Х да 3Х.
Ніхто не ведае, колькі каштуе. Узровень зарплаты вымяраецца тваёй упэўненасцю - поўны дурдом, калі сапраўды, жудасна перагрэты рынак.
Вядома, гэтая сітуацыя зменіцца вельмі хутка - павінна наступіць некаторае насычэнне. З распрацоўкай софту ж не так - нягледзячы на тое, што распрацоўшчыкі ўсім патрэбныя, і ўсім патрэбныя добрыя распрацоўшчыкі, рынак разумее, хто колькі каштуе - галіна ўстаканіцца. З DevOps зараз не так.
- З таго, што я пачуў, я зрабіў выснову, што моцна турбавацца бягучаму сістэмнаму адміністратару не варта, але пара пампаваць скілы і рыхтавацца да таго, што заўтра працы будзе больш, але яна будзе больш высокакваліфікаванай.
Дзмітрый: Стопрацэнтна. У цэлым мы жывем у 2019 годзе і правіла жыцця такое: lifetime learning - мы вучымся ўсё жыццё. Мне здаецца, зараз гэта ўжо ўсё ведаюць і адчуваюць, але мала ведаць - трэба рабіць. Кожны дзень мы павінны мяняцца. Калі мы гэтага не робім, то раней ці пазней нас высадзяць на абочыне прафесіі.
Будзьце гатовыя да рэзкіх разваротаў на 180 градусаў. Я не выключаю сітуацыі, калі нешта кардынальна зменіцца, прыдумаюць нешта новае - такое бывае. Хоп! - і мы цяпер дзейнічаем па-іншаму. Важна быць гатовым да гэтага і не парыцца. Можа так здарыцца, што заўтра ўсё, што я раблю, акажацца непатрэбным - нічога, я ўсё жыццё вучыўся і гатовы вучыцца нечаму іншаму. Гэта не праблема. Баяцца job security не варта, але трэба быць гатовым да таго, каб увесь час вучыцца чамусьці новаму.
Пажаданні і хвілінка рэкламы
- Ці будзе ў цябе нейкае пажаданне?
Дзмітрый: Так, у мяне некалькі пажаданняў.
Першае і меркантыльнае - падпішыцеся на . Паважаныя чытачы, зайдзіце на YouTube і падпішыцеся на наш канал. Дзесьці праз месяц мы пачнем актыўную экспансію на відэасэрвіс у нас будзе куча навучальнага кантэнту пра Kubernetes, адчыненага і рознага: ад практычных рэчаў, аж да лабараторак, да глыбокіх прынцыповых тэарэтычных рэчаў і як ужываць Kubernetes на ўзроўні прынцыпаў і патэрнаў.
Другое меркантыльнае пажаданне - зайдзіце на і пастаўце зорачкі, таму што мы імі харчуемся. Калі вы нам зорачкі не паставіце, нам есці будзе няма чаго. Гэта як мана ў кампутарнай гульні. Мы нешта робім, робім, стараемся, нехта кажа, што гэта жудасныя ровары, нехта, што ўсё ўвогуле няправільна, а мы працягваем і дзейнічаем абсалютна сумленна. Мы бачым праблему, яе вырашаем і дзелімся досведам. Таму пастаўце нам зорачку, ад вас не зменшае, а нам прыбудзе, бо мы імі харчуемся.
Трэцяе, важнае, і ўжо не меркантыльнае пажаданне перастаньце верыць у казкі. Вы - прафесіяналы. DevOps - гэта вельмі сур'ёзная і адказная прафесія. Перастаньце гуляць на працоўным месцы. Няхай вас пстрыкне, і вы зразумееце гэта. Уявіце, што вы прыйдзеце ў шпіталь, а там доктар на вас эксперыментуе. Разумею, што камусьці гэта можа быць крыўдна, але хутчэй за ўсё гэта ж не пра вас, а пра кагосьці іншага. Скажыце іншым, каб яны таксама перасталі. Гэта рэальна псуе жыццё ўсім нам - многія пачынаюць ставіцца да эксплуатацыі, да адмінаў і да DevOps'ам, як да чувакоў, якія зноў нешта паламалі. Гэта "паламалі" часцей за ўсё з-за таго, што мы пайшлі гуляць, а не халоднай свядомасцю паглядзелі, што тут так, а тут так.
Гэта не азначае, што не трэба эксперыментаваць. Эксперыментаваць трэба, мы самі так робім. Калі быць сумленным, мы самі яшчэ і гуляемся часам - гэта, вядома, вельмі дрэнна, але нішто чалавечае нам не чужа. Давайце 2019 аб'явім годам сур'ёзных прадуманых эксперыментаў, а не гульняў на продзе. Мусіць, так.
- Вялікі дзякуй!
Дзмітрый: Табе дзякуй, Віталь, і за час, і за інтэрв'ю. Дарагія чытачы, вам вялікі дзякуй, калі вы раптам дайшлі да гэтага моманту. Спадзяюся, што хаця б пару думак мы вам прынеслі.
У інтэрв'ю Дзмітрый закрануў пытанне werf. Цяпер гэта ўніверсальны швейцарскі нож, які вырашае амаль усе задачы. Але так было не заўжды. На на фестывалі Дзмітрый Сталяроў раскажа пра гэты інструмент падрабязна. У дакладзе будзе ўсё: праблемы і ўтоеныя нюансы Kubernetes, варыянты рашэнняў гэтых цяжкасцяў і бягучая рэалізацыя werf у падрабязнасцях. Далучайцеся 27 і 28 траўня, будзем ствараць ідэальныя прылады.
Крыніца: habr.com