В очакване на Виталий Хабаров взе интервю от Дмитрий Столяров (), техническия директор и съосновател на компанията „Флант“. Виталий попита Дмитрий за дейността на „Флант“, за 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 request везде, где это возможно. Если pull request там не принимают, мы просто форкаем их для себя и продолжаем использовать, пока они не будут приняты с нашими сборками. Затем, когда это доберется до upstream, мы возвращаемся к версии upstream.
Например, имаме Prometheus оператор, с който многократно преминавахме на upstream на нашата версия, вероятно около 5 пъти. Нуждаем се от нова функция, изпратихме pull request и ни е необходимо да я пуснем утре, без да чакаме тя да бъде включена в upstream. Съответно, ние създаваме своя версия с необходимата функция и я инсталираме на всичките си клъстери. След това, например, upstream я взима и предлага: „Хайде да направим нещо по-общо“, ние или друг, който се включи, актуализираме, и со времето отново всичко се обединява.
Всичко, което съществува, се опитваме да развиваме.Много елементи, които все още не съществуват, не са измислени или измислени, но не са реализирани – ние ги правим. И не защото ни харесва самият процес или строенето на велосипеди като индустрия, а просто защото ни е необходим този инструмент. Често ни питат защо сме направили нещо? Отговорът е прост – защото трябваше да продължим напред, да решим някакъв практичен проблем, и ние го решихме с този инструмент.
Пътят винаги е такъв: ние много внимателно търсим и, ако не намерим решение как да направим тролейбус от хляб, правим свой хляб и свой тролейбус.
Инструменти на 'Фланта'
— Знам, че в момента 'Фланта' има addon оператори, shell оператори и инструменти dapp/werf. Как разбирам, това е един и същ инструмент в различни версии. Също така разбирам, че вътре в 'Фланта' има много различни инструменти. Точно така ли е?
Дмитрий: На нашия GitHub има още много неща. От това, което сега мога да спомена, имаме statusmap – панел за Grafana, който е популярен сред всички. Той се споменава почти във всяка втора статия за мониторинг на Kubernetes в Medium. Невъзможно е накратко да се обясни какво е 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-инженеров сталкиваются с проблемами и решают их каждый день, мы просто анализируем этот опыт и пытаемся обобщить. Мы понимаем, что если он останется у нас внутри, то через год или два инструмент станет бесполезен, потому что где-то в сообществе появится готовое решение. Нет смысла накапливать этот опыт внутри — это просто слив сил и времени в dev/null. А так нам совершенно не жалко. Мы с большой удовольствием все публикуем и понимаем, что это нужно развивать, пиарить, раскручивать, чтобы люди пользовались и добавляли свой опыт — тогда все растет и живет. Тогда через два года инструмент не окажется на свалке. Не жалко продолжать вкладывать силы, потому что видно, что твоим инструментом кто-то пользуется, а через два года им пользуются уже все.
Это часть нашей большой стратегии с dapp/werf. Не помню, когда мы начали его делать, кажется, года 3 назад. Изначально он был вообще на shell. Это был супер proof of concept, мы решили какие-то частные задачи — получилось! Но с shell там проблемы, дальше это наращивать невозможно, программировать на shell — то еще занятие. У нас была привычка писать на Ruby, соответственно, на Ruby мы что-то переделали, развивали, развивали, развивали и уперлись в то, что сообщество, толпа, которая не говорит «мы хотим или не хотим», воротит нос от Ruby, как это ни смешно. Поняли, что должны все это добро писать на Go, чтобы просто соответствовать первому пункту в чек-листе: DevOps-тула должна быть статическим бинарником. На Go или не на Go не е толкова важно, но е по-добре статичен бинарен файл, написан на Go.
Изразходвахме усилия, презаписахме dapp на Go и го нарекохме werf. Dapp вече не се поддържа, не се развива, работи в някаква последна версия, но има абсолютно възможен път за ъпгрейд нагоре, и може да се последва.
Защо беше създаден dapp
— Можеш ли накратко да разкажеш, защо беше създаден dapp, какви проблеми решава?
Дмитрий: Първата причина е в сборката. Първоначално имахме сериозни проблеми със сборката, когато Docker не умеше multi-stage, и ние направихме multi-stage със собствените си усилия. След това имахме още куп въпроси с почистването на image. Всички, които правят CI/CD, рано или късно, се сблъскват с проблема, че има много събрани images, които трябва по някакъв начин да се изчистят, а тези, които са нужни, да се оставят.
Втората причина е в деплоя. Да, има Helm, но той решава само част от задачите. Както и да е, написано е, че „Helm — пакетен мениджър за Kubernetes“. Именно, че е „пакетен мениджър“. Има и думите „пакетен мениджър“ — какво обикновено очакваме от пакетен мениджър? Казваме: „Пакетен мениджър — инсталирай пакета!“ и очакваме той да ни каже: „Пакетът е инсталиран“.
Интересно е, че казваме: „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. Само сега в нашата alpha версия 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, net филтри, мостове и много различни стари компоненти, на които имат по 15, 20, 30 години. В целом те работят, всичко е страхотно, но сега имаме множество контейнери, и това изглежда като кула от 15 тухли една върху друга, а ти стоиш на нея на един крак – странно усещане. Тази система исторически е развивала с множество нюанси, като апендикс в организма. В някои ситуации има проблеми с производителността, например.
Има страхотен BPF и възможност за писане на хукове за ядрото – момчетата написаха своите хукове за ядрото. Пакетът пристига в Linux ядрото, те го изваждат веднага на входа, обработват го както трябва, без мостове, без TCP, без IP стек – практически заобикаляйки всичко, написано в Linux ядрото, и веднага го изплюват в контейнера.
Какво се получи? Много добра производителност, страхотни функции – просто класно! Но ние гледаме на това и виждаме, че на всяка машина има програма, която се свързва с 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. Може да се каже, че това е стара версия, но ние все още сме на нея, защото има LTS. Там има systemd, нюансът му е, че не чисти C-групи. Kubernetes стартира подове, създава C-групи, след това подовете се изтриват, и така остава — не си спомням детайли, извинете, — че остават слайсове на systemd. Това води до това, че с времето всяка машина започва да забавя. Това дори не е въпрос на висок товар. Ако се стартират постоянни подове, например, ако има Cron Job, който постоянно генерира подове, то машината с Ubuntu 16.04 след седмица ще започне да забавя. Там ще има постоянно висок товарен среден показател, защото е създадена купчина C-групи. Това е проблем, с който се сблъсква всеки, който просто инсталира Ubuntu 16 и директно внедрява 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 — навсякъде, където е необходимо непрекъснато доставяне, където се изисква обновяване на версии, активни изменения, навсякъде, където е нужно да се изградят отказоустойчивост — само 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 - със сигурност се сблъскваме с всички тези неща. Дори и ако на някой проект отново се сблъскаме с този проблем, вече бързо питаме един друг и знаем как да решим.
Вероятно, отговорът е такъв - разбира се, хостинг историята улеснява част от задачите. Въпросът е, дали сте готови да доверите на тези хостинг компании и дали те ще решат вашите проблеми. Amazon и Google се утвърдиха добре. За всички наши случаи - определено. Нямаме други позитивни опити. Всички останали облаци, с които опитвахме да работим, създават много проблеми - както Ager, така и всичко, което има в Русия, и всевъзможни OpenStack в различни реализации: Headster, Overage - всичко, което искате. Всички те създават проблеми, които не искаме да решаваме.
Следователно, отговорът е - да, но по фактическа стойност, зрели хостинг решения няма много.
Кому е необходим 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 проекти, независимо в какъв бизнес — софтуер за облекчаване на света, и който осъзнава това, трябва да разреши тези нужди. 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.
Нивото на неизследваното, нивото на нерешените проблеми, нивото на вероятността да се сблъскаме с нещо, ще намалява значително. Това е важна история. И операторите - всичко, свързано с кодифицирането на логиката на административните структури, логиката на управлението, за да получим лесна услуга: MySQL лесна услуга, RabbitMQ лесна услуга, Memcache лесна услуга - всичките тези компоненти, които ни трябват, за да работят гарантно
Тази история с развитието на операторите в едно или друго проявление ще бъде важна през следващите няколко години.
Силно вярвам, че простотата на експлоатацията ще нарасне значително - кутията ще става все по-черна, все по-надеждна, с все по-прости контроли.
Някога слушах старо интервю с Исак Азимов от 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 градуса. Не изключвам ситуации, в които нещо радикално ще се промени, ще измислят нещо ново — така става. Хоп! — и сега действаме по различен начин. Важно е да бъдете готови за това и да не се притеснявате. Може да се случи така, че утре всичко, което правя, да се окаже ненужно — нищо, аз цял живот съм учил и съм готов да се уча на нещо друго. Това не е проблем. Не си струва да се страхувате от工作на сигурност, но трябва да бъдете готови да учите постоянно нови неща.
Пожелания и минутка реклама
— Имате ли някакво пожелание?
Дмитрий: Да, имам няколко пожелания.
Първото и материално — абонирайте се за . Уважаеми читатели, влезте в YouTube и се абонирайте за нашия канал. Някъде след около месец ще започнем активна експанзия на видеосервиза ни, ще имаме куп учебно съдържание за Kubernetes, от отворени и различни неща: от практически уроци до лабораторни работи, до дълбоки принципни теоретични неща и как да прилагаме Kubernetes на ниво принципи и патерни.
Второто материално пожелание — посетете и поставете звезди, защото ние се храним с тях. Ако не ни поставите звезди, няма да имаме какво да ядем. Това е като мана в компютърна игра. Ние правим нещо, правим, стараем се, някой казва, че това са ужасни велосипедчета, някой друг, че всичко е неправилно, а ние продължаваме и действаме напълно честно. Ние виждаме проблема, решаваме го и споделяме опит. Затова поставете ни звезда, от вас няма да отслабне, а на нас ще ни нарасне, защото се храним с тях.
Третото, важно и вече не материално пожелание — спрете да вярвате в приказки. Вие сте професионалисти. DevOps е много сериозна и отговорна професия. Спрете да играете на работното място. Нека ви осени и да разберете това. Представете си, че отивате в болница, а там лекарят експериментира с вас. Разбирам, че на някого това може да бъде обидно, но вероятно не става дума за вас, а за някой друг. Кажете на другите също да спрат. Това наистина разваля живота на всички нас — много хора започват да се отнасят към експлоатацията, към администраторите и към DevOps-ите, като към типове, които отново нещо са счупили. Това „счупване“ най-често е заради това, че сме се развлекли, вместо да погледнем с трезво съзнание какво е тук така, а тук така.
Това не означава, че не трябва да експериментираме. Експериментирането е необходимо, ние сами го правим. За да бъда честен, понякога играем и ние – това, разбира се, е много лошо, но нищо човешко не ни е чуждо. Нека обявим 2019 година за година на сериозни, добре обмислени експерименти, а не на игри в продукция. Вероятно така.
— Благодаря ви много!
Дмитрий: Благодаря на теб, Виталий, за времето и интервюто. Скъпи читатели, благодаря ви, ако сте успели да стигнете до този момент. Надявам се, че сме ви донесли поне няколко идеи.
В интервюто Дмитрий засегна въпроса за werf. В момента това е универсален швейцарски нож, който решава почти всички задачи. Но не е било така винаги. На фестивала Дмитрий Столяров ще разкаже подробно за този инструмент. В доклада ще бъде всичко: проблеми и скрити нюанси на Kubernetes, варианти за решения на тези трудности и текуща реализация на werf в детайли. Присъединявайте се на 27 и 28 май, ще създаваме идеални инструменти.
Източник: habr.com
