Хабрахабр

Kubernetes захватит мир. Когда и как?

В преддверии DevOpsConfВиталий Хабаров взял интервью у Дмитрия Столярова (distol), технического директора и соучредителя компании «Флант». Виталий расспросил Дмитрия про то, чем занимается «Флант», про Kubernetes, развитие экосистемы, поддержку. Обсудили, зачем нужен Kubernetes и нужен ли вообще. А еще про микросервисы, Amazon AWS, подход «Мне повезет» в DevOps, будущее самого Kubernetes, почему, когда и как он захватит мир, перспективы DevOps и к чему готовиться инженерам в светлом и близком будущем с упрощением и нейросетями.

Оригинал интервью в виде подкаста послушайте на DevOps Дефлопе — русскоязычном подкасте о DevOps, а ниже — текстовая версия.

Здесь и далее вопросы задает Виталий Хабаров инженер из Express42.

Про «Флант»

— Дима, привет. Ты — технический директор «Флант» и также его основатель. Расскажи, пожалуйста, чем занимается компания и ты в ней?

Но это не так. Дмитрий СтоляровДмитрий: Снаружи кажется, будто мы такие ребята, которые ходят, всем ставят Kubernetes и что-то с ним делают. Обычно мы строим всю инфраструктуру с нуля и потом долго-долго за нее отвечаем. Мы начинали, как компания, которая занимается Linux, но уже очень давно основная наша деятельность — обслуживание продакшн и highload-проектов под ключ. Поэтому, основная работа, которую выполняет «Флант», за что и получает деньги — это взятие ответственности и реализация продакшн под ключ.

Я, как технический директор и один из учредителей компании, круглые сутки занимаюсь тем, что придумываю, как бы повысить доступность продакшн, упростить его эксплуатацию, облегчить жизнь админов, а жизнь разработчиков сделать приятнее.

Про Kubernetes

— Последнее время от «Фланта» вижу много докладов и статей про Kubernetes. Как вы пришли к нему?

Считаю, что правильно повторять эту тему, потому что возникает путаница между причиной и следствием. Дмитрий: Я уже рассказывал об этом много раз, но мне совершенно не жалко повторить.

Мы сталкивались с кучей проблем, боролись, преодолевали их разными костылями и испытывали потребность в инструменте. Нам очень нужен был инструмент. Постепенно дошли до того, что начали использовать Docker почти сразу как он появился — примерно в 2013 году. Перебирали много разных вариантов, строили свои велосипеды, накапливали опыт. С появлением Docker появилась возможность костылики выкинуть и использовать надежное и поддерживаемое сообществом решение. В момент его появления у нас уже было много опыта с контейнерами, мы уже написали аналог «Docker» — какие-то свои костыли на Python.

К моменту, когда он начал набирать обороты, — для нас это версия 1. С Kubernetes история аналогична. Мы серьезно смотрели в сторону Rancher и разных других решений, но тут появился Kubernetes, в котором все реализовано ровно так, как сделали бы мы или даже лучше. 2, — у нас уже была куча костылей и на Shell, и на Chef, которые мы как-то пытались оркестровать Docker. Придраться не к чему.

2 вообще жуть, но.... Да, тут есть какая-то недоделка, там какая-то недоделка — много недоделок, а 1. Если у здания сейчас есть фундамент и два этажа, то понимаешь, что лучше пока не заселяться, а с софтом таких проблем нет — пользоваться уже можно. Kubernetes как строящееся здание — смотришь на проект и понимаешь, что это будет круто.

Мы его ждали задолго до того, как он появился, и пытались сами городить аналоги. У нас не было момента, что мы думали использовать Kubernetes или нет.

Около Kubernetes

— Вы участвуете непосредственно в разработке самого Kubernetes?

Скорее участвуем в развитии экосистемы. Дмитрий: Посредственно. К сожалению, я не в состоянии следить за всем, что мы делаем и могу ошибаться, но от нас нет ни одного пула в ядро. Мы отправляем какое-то количество pull requests: в Prometheus, во всякие операторы, в Helm — в экосистему.

— При этом вы разрабатываете и много своих инструментов вокруг Kubernetes?

Если там pull requests не принимаются, мы просто форкаем их себе и живем, пока они не приняты с нашими билдами. Дмитрий: Стратегия такая: мы идем и пулл-реквестим во все, что уже есть. Потом, когда это долетает до upstream, мы возвращаемся обратно на upstream’овую версию.

Нам нужна какая-то фича, мы послали pull request, нам надо ее завтра выкатить, а ждать, пока ее релизнут в upstream, не хотим. Например, у нас есть Prometheus-оператор, с которым мы туда-сюда переключались на upstream нашей сборки уже раз 5, наверное. Потом это, например, в upstream нам заворачивают со словами: «Ребята, давайте, сделаем для более общего случая», мы, или кто-то другой, это доделываем, и со временем опять обратно сливается. Соответственно, мы собираем себе, катим нашу сборку с нашей фичей, которая нам зачем-то нужна, на все свои кластеры.

Многие элементы, которых еще нет, еще не придумали или придумали, но не успели реализовать — мы делаем. Все, что существует, мы стараемся развивать. Часто задают вопрос, зачем мы сделали ту или иную вещь? И не потому, что нам нравится сам процесс или велосипедостроение как отрасль, а просто потому, что нам нужен этот инструмент. Ответ прост — да потому, что нам надо было идти дальше, решить какую-то практическую проблему, и мы ее решили этой тулой.

Путь всегда такой: мы очень тщательно ищем и, если не находим никакого решения, как из буханки хлеба сделать троллейбус, то делаем свою буханку и свой троллейбус.

Инструменты «Фланта»

— Мне известно, что сейчас у «Фланта» есть addon-операторы, shell-операторы, инструменты dapp/werf. Как я понимаю, это один и тот же инструмент в разных инкарнациях. Также я понимаю, что внутри «Флант» есть еще много различных инструментов. Это так?

Из того, что я сейчас вспомню, у нас есть statusmap — панель для Grafana, которая зашла всем. Дмитрий: У нас на GitHub еще много чего есть. Невозможно кратко рассказать, что такое statusmap — нужна отдельная статья, но это очень полезная вещь для мониторинга статуса во времени, так как в Kubernetes нам часто требуется показывать статус во времени. Она упоминается чуть ли не в каждой второй статье про мониторинг Kubernetes на Медиум. Еще у нас есть LogHouse — это штука на базе ClickHouse и черной магии для сбора логов в Kubernetes.

И будет еще больше, потому что некоторое количество внутренних решений будет релизиться в этом году. Много утилит! Все это просто куча addons к Kubernetes, которые ставятся в кластер, и он превращается из простого в крутой, навороченный, автоматический, в котором многие вопросы уже решены. Из очень больших на базе addon-оператора есть куча addons к Kubernetes аля как правильно поставить sert manager — инструмент для управления сертификатами, как правильно поставить Prometheus с кучей обвески — это штук двадцать разных бинарников, которые экспортируют данные и что-то собирают, к этому Prometheus шикарнейшая графика и алерты. Да, много что делаем.

Развитие экосистемы

— Мне кажется, это очень большой вклад в развитие этого инструмента и его методов использования. Можешь ли ты примерно прикинуть, кто бы еще вносил такой же вклад в развитие экосистемы?

Конечно, это громкое заявление, потому что есть крупные игроки, как Mail с Яндексом — они тоже что-то делают с Kubernetes, но даже они не подобрались ко вкладу компаний в целом по миру, которые делают гораздо больше, чем мы. Дмитрий: В России из тех компаний, которые действуют на нашем рынке — никто и близко. Тяжело сравнивать. Сложно сравнивать «Флант» со штатом в 80 человек и Red Hat, в котором только на один Kubernetes 300 инженеров, если не ошибаюсь. У нас в отделе RnD 6 человек включая меня, которые пилят все наши тулы. 6 человек против 300 инженеров Red Hat — как-то сложно сравнивать.

Понимаю, что в крупных технологических компаниях, где есть своя разработка и команда поддержки Kubernetes, в принципе, могут разрабатываться такие же тулы. — Тем не менее, когда даже эти 6 человек могут сделать что-то действительно полезное и отчуждаемое, когда они сталкиваются с практической задачей и отдают решение в сообщество — интересный кейс. Это для них пример, что можно разработать и отдать в сообщество, дать толчок всему сообществу, которое использует Kubernetes.

У нас же много проектов и мы видим много разных ситуаций. Дмитрий: Наверное, это фишка интегратора, его особенность. Этим мы активно занимаемся. Для нас основной способ создания добавленной стоимости — это проанализировать эти кейсы, найти общее и максимально удешевить их для нас. Я не думаю, что в России много компаний с сопоставимым количеством специалистов, которые разбираются в Kubernetes, если они вообще есть. Мне сложно говорить про Россию и мир, но у нас примерно 40 DevOps-инженеров в компании, которые занимаются Kubernetes.

Все эти 40 замечательных DevOps-инженеров каждый день сталкиваются с проблемами и решают их, мы просто анализируем этот опыт и пытаемся обобщить. Я понимаю все про название должности DevOps-инженер, все всё понимают и привыкли называть DevOps-инженеров DevOps-инженерами, мы не будем это обсуждать. Нет смысла накапливать этот опыт внутри — это просто слив сил и времени в dev/null. Мы понимаем, что если он останется у нас внутри, то через год или два инструмент бесполезен, потому что где-то в community появится готовая тула. Мы с большим удовольствием все публикуем и понимаем, что это надо публиковать, развивать, пиарить, раскручивать, чтобы люди пользовались и добавляли свой опыт — тогда все растет и живет. А так нам совершенно не жалко. Не жалко продолжать вливать силы, потому что видно, что твоим инструментом кто-то пользуется, а через два года им пользуются уже все. Тогда через два года инструмент не идет на помойку.

Не помню, когда мы начали его делать, кажется, года 3 назад. Это часть нашей большой стратегии с dapp/werf. Это был супер proof of concept, мы решили какие-то наши частные задачи — получилось! Изначально он был вообще на shell. У нас была привычка писать на Ruby, соответственно, на Ruby мы что-то переделали, развивали, развивали, развивали, и уперлись в то, что community, толпа, которая не говорит «мы хотим или не хотим», воротит нос от Ruby, как это не смешно. Но с shell там проблемы, дальше это наращивать невозможно, программировать на shell — то еще занятие. На Go или не на Go не так важно, но лучше статический бинарник, написанный на Go. Поняли, что должны все это добро писать на Go, чтобы просто соответствовать первому пункту в чек-листе: DevOps-тула должна быть статическим бинарником.

Dapp больше не поддерживается, не развивается, работает в какой-то последней версии, но есть абсолютный upgrade-путь наверх, и ему можно последовать. Потратили силы, переписали dapp на Go и назвали его werf.

Зачем создавался dapp

— Можешь вкратце рассказать, зачем создавался dapp, какие проблемы он решает?

Изначально у нас были сильные проблемы со сборкой, когда Docker не умел multi-stage, и мы сделали multi-stage своими силами. Дмитрий: Первая причина в сборке. Все, кто делают CI/CD, скорее раньше, чем позже, сталкиваются с проблемой, что есть куча собранных images, требуется как-то вычищать то, что не нужно, и оставлять то, что нужно. Потом у нас была еще куча вопросов с очисткой image.

Да, есть Helm, но он решает только часть задач. Вторая причина в деплое. Именно, что «the». Как ни смешно, написано, что «Helm — the Package Manager for Kubernetes». Мы говорим: «Package Manager — поставь пакет!» и ожидаем, что он нам скажет: «Пакет поставлен». Еще есть слова «Package Manager» — какое ожидание обычно от Package Manager?

Интересно, что мы говорим: «Helm, поставь пакет», а когда он отвечает, что поставил, то выясняется, что он только начал установку — указал Kubernetes: «Вот эту штуку запусти!», а запустилась она или нет, работает или нет, Helm этот вопрос вообще никак не решает.

Получается, что Helm — просто текстовый препроцессор, который загружает данные в Kubernetes.

Но мы в рамках любого деплоя хотим знать — приложение выкатилось на прод или нет? Выкатилось на прод значит, что приложение туда выехало, развернулась новая версия развернулась, и она там хотя бы не падает и корректно отвечает. Helm эту задачу никак не решает. Чтобы ее решить, надо потратить много сил, потому что необходимо отдать Kubernetes команду выкатывать и следить за тем, что же там происходит — развернулось ли оно, выкатилось ли. А еще есть куча задач, связанных с деплоем, с очисткой, со сборкой.

Планы

Еще в этом году мы пойдем в локальную разработку. Мы хотим прийти к тому, что раньше было в Vagrant — набрали «vagrant up» и у нас развернулись виртуалки. Мы хотим прийти к такому состоянию, что есть проект в Git, мы там пишем «werf up», и он поднимает локальную копию этого проекта, развернутую в локальном мини-Kub, с подключенными всеми директориями, удобными для разработки. В зависимости от языка разработки это выполняется по-разному, но, тем не менее, чтобы можно было удобно вести локальную разработку под монтированными файлами.

Чтобы одним инструментом быстро локально развернуть проект, подевелопить, пушнуть в Git, и он точно также выкатится на stage или на тесты, в зависимости от пайплайнов, и потом тем же самым инструментом поехать на прод. Следующий шаг для нас — сильно вкладываться в удобство для разработчиков. Но этого пока нет в werf — только планируем делать. Это единство, унификация, воспроизводимость инфраструктуры от локального окружения до прода для нас очень важный момент.

Мы сталкивались с проблемами, решали их обходными путями — придумывали для себя какие-то решения на shell, на чем угодно. Но путь к dapp/werf всегда был такой же, как с Kubernetes в начале. Потом эти обходные пути старались как-то спрямить, обобщить и консолидировать в бинарники в данном случае, которыми просто делимся.

Есть еще другой взгляд на всю эту историю, с аналогиями.

Нет дверей, стекол, радиоприемника, елочки — вообще ничего нет. Kubernetes — это каркас автомобиля с движком. И есть Helm — это руль. Только рама и движок. Классно — руль есть, но нужны еще рулевой штифт, рулевая рейка, КПП и колеса, а без них никак.

В случае с werf — это еще один компонент к Kubernetes. Только сейчас у нас в альфа-версии werf, например, Helm вкомпиливается вообще внутрь werf, потому что нам надоело это делать самим. Много причин так делать, подробно о том, зачем мы вкомпилили helm целиком вместе с tiller внутрь werf, я расскажу как раз на докладе на РИТ++.

У нас получается готовый руль, рулевой штифт — я не очень хорошо в автомобилях разбираюсь, но это большой блок, который решает уже достаточно большой спектр задач. Сейчас werf — это более интегрированный компонент. Мы получаем готовый комбайн, который решает сразу большую пачку задач. Нам не нужно самим лазить по каталогу, подбирать одну деталь к другой, думать, как их прикрутить друг к другу. Это интегрированный инструмент, чтобы получить быстро и удобно крутой CI/CD из коробки. Но внутри он устроен все из тех же опенсорсных компонентов, все также использует Docker для сборки, Helm для части функционала, и есть еще несколько других библиотек.

Cложно ли поддерживать Kubernetes?

— Ты рассказываешь про опыт, что начали использовать Kubernetes, это для вас рама, движок, и что на него можно много всего разного навесить: корпус, руль, прикрутить педальки, сиденья. Возникает вопрос — насколько сложно вам дается поддержка Kubernetes? У вас богатый опыт, сколько у вас уходит времени и ресурсов именно на поддержку Kubernetes в отрыве от всего остального?

Может быть, ты раскроешь? Дмитрий: Это очень сложный вопрос и чтобы ответить, надо понять, что такое поддержка, и что мы хотим от Kubernetes.

Все в него впрягаются, ставят на коленке. — Насколько мне известно и как я вижу, сейчас много команд хотят попробовать Kubernetes. У меня есть ощущение, что люди не всегда понимают сложность этой системы.

Дмитрий: Все так.

— Насколько сложно взять и поставить Kubernetes с ничего, чтобы это было production ready?

Понимаю, вопрос компрометирующий. Дмитрий: Как думаешь, насколько сложно пересадить сердце? Если тебе говорят где отрезать, а где зашить, то сама по себе процедура несложная. Возить скальпелем и не ошибиться — это не так сложно. Сложно гарантировать из раза в раз, что все получится.

— поставился, есть куча способов инсталляции. Поставить Kubernetes и заставить работать просто: чик! Но что будет, когда возникнут проблемы?

Всегда встают вопросы — что мы еще не учли? Что мы еще не сделали? Какие параметры Linux-ядра указали неправильно? Господи, а мы вообще их указывали?! Какие компоненты Kubernetes мы поставили, а какие нет? Возникают тысячи вопросов, и чтобы ответить на них, нужно 15-20 лет вариться в этой индустрии.

Некоторое время назад мы всерьез рассматривали не попробовать ли нам внедрить Cilium в качестве сети в Kubernetes. У меня есть свежий пример на эту тему, который может раскрыть смысл проблемы «Сложно ли поддерживать Kubernetes?».

В Kubernetes есть много разных реализаций сетевой подсистемы, и одна из них очень крутая — это Cilium. Поясню, что такое Cilium. В ядре некоторое время назад появилась возможность писать хуки для ядра, которые так или иначе вторгаются в сетевую подсистему и в разные другие подсистемы, и позволяют обойти большие куски в ядре. В чем ее смысл?

В целом они работают, все классно, но сейчас понагородили контейнеров, и это выглядит как башенка из 15 кирпичей друг на друге, а ты стоишь на ней на одной ноге — странное ощущение. В Linux-ядре исторически есть ip rout, надфильтр, бриджи и много разных старых компонент, которым по 15, 20 30 лет. В некоторых ситуациях есть проблемы с performance, например. Эта система исторически развивалась со множеством нюансов, как аппендикс в организме.

Пакет приходит в Linux-ядро, они его прямо на входе вынимают, обрабатывают сами как надо без бриджей, без TCP, без IP-стека — короче, в обход всего, что написано в Linux-ядре, и тут же выплевывают в контейнер. Есть замечательный BPF и возможность писать хуки для ядра — ребята написали свои хуки для ядра.

Очень крутой performance, крутые фичи — просто классно! Что получилось? Но мы смотрим на это и видим, что на каждой машине стоит прога, которая подключается к API Kubernetes и по данным, которые получает из этого API, генерирует C-код и компилит бинарники, которые загружает в ядро, чтобы в kernel space эти хуки работали.

Мы не знаем. Что будет, если что-то пойдет не так? Но, с другой стороны, есть эти бриджи, net-фильтры, ip rout — я не читал их исходники, и 40 инженеров, которые работают в нашей компании тоже. Чтобы это понять, надо прочитать весь этот код, понять всю логику, а это обалдеть, как сложно. Может быть, какие-то куски понимают единицы.

Получается, что есть ip rout, ядро Linux, и есть новый инструмент — какая разница, мы ни одну, ни другую не понимаем. И какая разница? Потому что если инструменту 30 лет, то за 30 лет все баги нашли, на все грабли наступили и знать про все не нужно — работает, как чёрный ящик, и работает всегда. Но боимся использовать новое — почему? Все хорошо знают диагностические утилиты и понимают, как этот набор компонентов работает в ядре Linux — не как он устроен, а как им пользоваться. Все знают, какую диагностическую отвертку в какое место воткнуть, какой tcpdump в какой момент запустить.

С Kubernetes такая же проблема, копия. А офигенно классному Cilium не 30 лет, он еще не выдержан. Что Cilium ставится прекрасно, что Kubernetes ставится прекрасно, но, когда что-то не так пойдет в проде, способны ли вы в критической ситуации быстро понять, что пошло не так?

Kubernetes прекрасно работает сам по себе, но с миллиардом нюансов. Когда мы говорим, сложно ли поддерживать Kubernetes — нет, очень просто, и да, невероятно сложно.

Про подход «Мне повезет»

— А есть ли компании, где эти нюансы почти гарантированно появятся? Предположим, Яндекс вдруг поголовно переведет все сервисы на Kubernetes, там будет ого-го какая нагрузка.

Например, есть у нас Kubernetes, мы задеплоили туда приложение. Дмитрий: Нет, это же разговор не про нагрузку, а о простейших вещах. Готового инструмента, чтобы понять, что приложение не падает, просто нет. Как понять, что оно работает? А мы вот обновляем Kubernetes. Готовой системы, которая шлет алерты — нет, надо настроить эти алерты и каждый график.

04. Есть Ubuntu 16. Там есть systemd, нюанс которого в том, что он не чистит C-группы. Можно сказать, что это старая версия, но мы до сих пор на ней, потому что там LTS. Это приводит к тому, что со временем любая машина начинает сильно тормозить. Kubernetes запускает поды, создает C-группы, потом поды удаляет, и как-то так получается — я не помню деталей, простите, — что остаются слайсы systemd. Если запускаются постоянные поды, например, если есть Cron Job, который постоянно генерирует поды, то машина с Ubuntu 16. Это даже вопрос не про highload. Там будет постоянно высокий load average из-за того, что создана куча C-групп. 04 через неделю начнет тормозить. Это проблема, с которой сталкивается любой человек, который просто поставит Ubuntu 16 и сверху Kubernetes.

16 еще смешнее — при удалении C-групп они в ядре подтекают и фактически не удаляются. Допустим, он как-то обновит systemd или что-то еще, но в ядре Linux до 4. Мы достаем файлик, катаем в проге, и один файлик катается 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 лет прекрасно работать. Если мы говорим про софт в формате, что мы запустили и он реально много лет работает без каких-то обновлений, без внесения изменений, то, конечно, там не будет Kubernetes. Возможно, за 20 лет понадобится что-то обновить один раз. Он там не нужен.

Все, что касается CI/CD — везде, где нужен Continuous Delivery, где требуется обновлять версии, вести активные изменения, везде, где необходимо выстроить отказоустойчивость — только Kubernetes.

Про микросервисы

— Тут у меня возникает небольшой диссонанс. Чтобы работать с Kubernetes, нужна внешняя или внутренняя поддержка — это первый момент. Второй — когда мы только-только начинаем разработку, мы маленький стартап, у нас еще ничего нет, разработка под Kubernetes или вообще под микросервисную архитектуру может быть сложной, и не всегда оправдана с экономически. Мне интересно твое мнение — нужно ли стартапам с нуля сразу начинать писать под Kubernetes или можно все-таки написать монолит, и потом только прийти к Kubernetes?

У меня есть доклад про микросервисы «Микросервисы: размер имеет значение». Дмитрий: Крутой вопрос. Сам по себе подход правильный, мы сами внутренний софт проектируем именно этим путем. Я много раз сталкивался с тем, что люди пытаются микроскопом забивать гвозди. Больше всего в микросервисах я ненавижу слово «микро». Но когда это делаешь, нужно четко понимать, что ты делаешь. Это не так. Исторически сложилось, что там возникло это слово, и почему-то люди думают, что микро — это очень маленький, меньше миллиметра, как микрометр.

Это важно, нужно и классно. Например, есть монолит, который пишут 300 человек, и все, кто участвовал в разработке, понимают, что там есть проблемы, и его надо бы разбить на микро-кусочки — штук на 10, каждый из которых пишут 30 человек в минимальном варианте. Но когда к нам приходит стартап, где 3 очень крутых и талантливых пацана написали на коленке 60 микросервисов, каждый раз я ищу корвалол.

Это экономически не оправдано, очень сложно вообще во всем. Мне кажется, про это уже говорили тысячи раз — получили распределенный монолит в той или иной ипостаси. Просто я это столько раз видел, что мне прямо больно, поэтому я продолжаю об этом говорить.

Ответ — взвешивать объем пользы, которая приходит, объем задач, который вы можете решить. К начальному вопросу, что есть конфликт между тем, что, с одной стороны, Kubernetes страшно использовать, потому что непонятно, что там может сломаться или не заработать, с другой стороны, понятно, что все идет туда и ничего, кроме Kubernetes, не будет. С другой стороны — риски, которые связаны с простоем или со снижением времени отклика, уровня доступности — со снижением показателей работы. Это с одной стороны весов.

Этот выбор должна делать каждая компания. Тут так — или нам быстро двигаться, и Kubernetes позволяет многие вещи выполнять намного быстрее и лучше, или использовать надежные, проверенные временем решения, но двигаться гораздо медленнее. С каждым разом тропинка шире. Можно рассматривать это как дорожку в джунглях — когда идешь первый раз, можно встретить змею, тигра или бешеного барсука, а когда сходил 10 раз — протоптал тропу, убрал ветки и ходить полегче. Потом это уже асфальтированная дорога, а позже красивый бульвар.

Опять вопрос: Kubernetes, с одной стороны, это 4-5 бинарников, с другой — это вся экосистема. Kubernetes не стоит на месте. Что это? Это операционка, которая у нас стоит на машинах. Это ядро Linux, куча дополнительных компонентов. Ubuntu или Curios? 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 четко понятно, что это идеологически правильная вещь, как отказоустойчивость для человечества — две планеты иметь лучше, чем одну. Отправить несколько экспедиций и заселить там несколько тысяч человек, думаю, тоже реалистично. Одну экспедицию послать — не проблема, если сконцентрировать на этом усилия. А вот прямо отказоустойчивость целиком сделать, чтобы половина человечества там жила, мне кажется сейчас невозможным, не рассматриваемым.

Ближе к 2030 — давайте доживем до него. С serverless один в один: штука классная, но она далека от проблем 2019 года. Это как верить в сказочного пони Радугу. Я не сомневаюсь, что доживем, мы обязательно доживем (повторяйте перед сном), но сейчас надо решать другие проблемы. Я не готов говорить. Да, пара процентов кейсов решаются, и решаются отлично, но субъективно serverless — это радуга… Для меня эта тема слишком далека и слишком непонятна. В 2019 году с serverless ни одно приложение не напишешь.

Как будет развиваться Kubernetes

— Пока мы идем к этому потенциально прекрасному далекому будущему, как ты считаешь, как будет развиваться Kubernetes и экосистема вокруг него?

Первое — statefull — все-таки stateless сделать легче. Дмитрий: Я много об этом думал и у меня есть четкий ответ. Stateless работает практически идеально в Kubernetes, просто не к чему придраться. Kubernetes изначально в это больше вкладывал, с него все начиналось. У нас уже все там прекрасно работает, но это мы. По statefull еще куча проблем, вернее, нюансов. Это не рассчитанный показатель, а мое ощущение из головы. На то, чтобы это работало у всех, нужно еще пару лет как минимум.

Это иллюзия, всегда нужна какая-нибудь БД и что-то еще. Короче, statefull очень сильно должен — и будет — развиваться, потому что все приложения у нас хранят статус, не бывает stateless-приложений. Statefull — это спрямление всего, чего можно, исправление всех багов, улучшение всех проблем, с которыми сейчас сталкиваются — назовем это adoption.

Это важная история. Уровень неизведанного, уровень нерешенных проблем, уровень вероятности с чем-то столкнуться, будет сильно падать. Это как раз решает те боли, что мы хотим базу данных, но не хотим ее администрировать, или хотим Kubernetes, но не хотим его администрировать. И операторы — все, что связано с кодифицированием логики администрирования, логики управления, чтобы получить easy service: MySQL easy service, RabbitMQ easy service, Memcache easy service, — вообще все эти компоненты, которые нам нужны, чтобы получить работающим из коробки гарантированно.

Эта история с развитием операторов в том или ином проявлении будет важна в ближайшие пару лет.

Я думаю сильно должна возрасти простота эксплуатации — ящик будет становиться все более и более черным, все более и более надёжным, со все более и более простыми крутилками.

Я как-то слушал старое интервью Айзека Азимова 80-х годов на YouTube в шоу Saturday Night Live — передача типа Урганта, только интересная. Его там спрашивали про будущее компьютеров. Он сказал, что будущее в простоте, как это было с радиоприемником. Радиоприемник изначально был сложной штукой. Чтобы поймать волну, нужно было 15 минут крутить крутилки, вертеть вертелки и вообще знать как все устроено, понимать физику передачи радиоволн. В итоге в радио осталась одна крутилка.

В машине радиоприемник находит все волны, название станций. Сейчас в 2019 году какое радио? Сейчас, да и не только сейчас, уже в 1980 году, когда было интервью с Азимовым, все пользовались радио и никто не задумывался о том, как оно устроено. Физика процесса не изменилась за 100 лет, изменилась простота использования. Оно всегда работало — это данность.

Если в 1980 году нужно получить специальное образование, чтобы нажимать кнопки на компьютере, то в будущем это будет не так. Азимов тогда говорил, что с компьютерами будет аналогично — простота использования возрастет.

Это, по-моему, очевидно — лежит на поверхности. У меня ощущение, что с Kubernetes и с инфраструктурой тоже будет очень сильно возрастать простота использования.

Что делать с инженерами?

— А что тогда станет с инженерами, системными администраторами, которые поддерживают Kubernetes?

Примерно то же самое. Дмитрий: А что стало с бухгалтером после появления 1С? Производительность труда возросла на порядки, а труд от этого сам не пропал. До этого считали на бумажке — теперь в программе. Если раньше для вкручивания лампочки нужно было 10 инженеров, то теперь будет достаточно одного.

Сейчас на рынке конкретный дефицит и он продлится долго. Количество софта и количество задач, мне кажется, сейчас растет со скоростью большей, чем появляются новые DevOps’ы и увеличивается КПД. Позднее все войдет в некоторую норму, при которой КПД работы возрастет, будет все больше serverless, к Kubernetes прикрутят нейронку, которая будет подбирать все ресурсы прямо как надо, и вообще все делает сама, как надо — человек отойди и не мешай.

Понятно, что уровень квалификации и специализированность этого человека выше. Но решения все равно надо будет кому-то принимать. Это просто не нужно. Сейчас в отделе бухгалтерии вам не нужны 10 сотрудников, которые ведут бухгалтерские книги, чтобы у них рука не уставала. Достаточно одного умного главного бухгалтера, уже с гораздо большими скиллами, с хорошим пониманием. Многие документы автоматически сканируются, распознаются системой электронного документооборота.

С автомобилями так же: раньше к автомобилю прилагался автомеханик и три водителя. В целом такой путь во всех отраслях. Никто не задумывается, что автомобиль — это что-то сложное. Сейчас вождение автомобиля — это простейший процесс, в котором мы все участвуем каждый день.

DevOps или системная инженерия никуда не денутся — высокоуровневость и эффективность работы будут возрастать.

— Я еще слышал интересную идею, что на самом деле и работа увеличится.

Потому что количество софта, которое мы пишем, постоянно растет. Дмитрий: Конечно, сто процентов! Количество работы растёт. Количество вопросов, которые мы решаем софтом, постоянно растет. Это видно по зарплатным ожиданиям. Сейчас рынок DevOps жутко перегрет. А сейчас, если смотреть московский рынок зарплат DevOps’ов, джуниор хочет от Х до 3Х и сеньор хочет от Х до 3Х. По-хорошему, не вдаваясь в детали, должны быть джуниоры, которые хотят Х, миддлы, которые хотят 1,5Х, и сеньоры, которые хотят 2Х.

Уровень зарплаты измеряется твоей уверенностью — полный дурдом, если честно, жутко перегретый рынок. Никто не знает, сколько стоит.

Конечно, эта ситуация изменится очень скоро — должно наступить некоторое насыщение. С разработкой софта же не так — несмотря на то, что разработчики всем нужны, и всем нужны хорошие разработчики, рынок понимает, кто сколько стоит — отрасль устаканилась. С DevOps сейчас не так.

— Из того, что я услышал, я сделал вывод, что сильно беспокоиться текущему системному администратору не стоит, но пора качать скиллы и готовиться к тому, что завтра работы будет больше, но она будет более высококвалифицированной.

В целом мы живем в 2019 году и правило жизни такое: lifetime learning — мы учимся всю жизнь. Дмитрий: Стопроцентно. Каждый день мы должны меняться. Мне кажется, сейчас это уже все знают и чувствуют, но мало знать — надо делать. Если мы этого не делаем, то раньше или позже нас высадят на обочине профессии.

Я не исключаю ситуации, когда что-то кардинально изменится, придумают что-то новое — такое бывает. Будьте готовы к резким разворотам на 180 градусов. — и мы теперь действуем по-другому. Хоп! Может так случиться, что завтра все, что я делаю, окажется ненужным — ничего, я всю жизнь учился и готов учиться чему-то другому. Важно быть готовым к этому и не париться. Бояться job security не стоит, но нужно быть готовым к тому, чтобы постоянно учиться чему-то новому. Это не проблема.

Пожелания и минутка рекламы

— Будет ли у тебя какое-то пожелание?

Дмитрий: Да, у меня несколько пожеланий.

Уважаемые читатели, зайдите на YouTube и подпишитесь на наш канал. Первое и меркантильное — подпишитесь на YouTube. Где-то через месяц мы начнем активную экспансию на видеосервис у нас будет куча учебного контента про Kubernetes, открытого и разного: от практических вещей, вплоть до лабораторок, до глубоких принципиальных теоретических вещей и как применять Kubernetes на уровне принципов и паттернов.

Если вы нам звездочки не поставите, нам кушать будет нечего. Второе меркантильное пожелание — зайдите на GitHub и поставьте звёздочки, потому что мы ими питаемся. Мы что-то делаем, делаем, стараемся, кто-то говорит, что это жуткие велосипеды, кто-то, что все вообще неправильно, а мы продолжаем и действуем абсолютно честно. Это как мана в компьютерной игре. Поэтому поставьте нам звездочку, от вас не убудет, а нам прибудет, потому что мы ими питаемся. Мы видим проблему, ее решаем и делимся опытом.

Вы — профессионалы. Третье, важное, и уже не меркантильное пожелание — перестаньте верить в сказки. Перестаньте играть на рабочем месте. DevOps — это очень серьезная и ответственная профессия. Представьте, что вы придёте в больницу, а там доктор на вас экспериментирует. Пусть вас щелкнет, и вы поймете это. Скажите другим, чтобы они тоже перестали. Понимаю, что кому-то это может быть обидно, но, скорее всего, это же не про вас, а про кого-то другого. Это «поломали» чаще всего из-за того, что мы пошли играться, а не холодным сознанием посмотрели, что тут так, а тут так. Это реально портит жизнь всем нам — многие начинают относиться к эксплуатации, к админам и к DevOps’ам, как к чувакам, которые опять что-то поломали.

Экспериментировать надо, мы сами так делаем. Это не означает, что не надо экспериментировать. Давайте 2019 год объявим годом серьезных продуманных экспериментов, а не игр на проде. Если быть честным, мы сами еще и играемся иногда — это, конечно, очень плохо, но ничто человеческое нам не чуждо. Наверное, так.

— Большое спасибо!

Дорогие читатели, вам большое спасибо, если вы вдруг дошли до этого момента. Дмитрий: Тебе спасибо, Виталий, и за время, и за интервью. Надеюсь, что хотя бы пару мыслей мы вам принесли.

Сейчас это универсальный швейцарский нож, который решает почти все задачи. В интервью Дмитрий коснулся вопроса werf. На DevOpsConf  на фестивале РИТ++ Дмитрий Столяров расскажет об этом инструменте подробно. Но так было не всегда. Присоединяйтесь 27 и 28 мая, будем создавать идеальные инструменты. В докладе «werf — наш инструмент для CI/CD в Kubernetes» будет все: проблемы и скрытые нюансы Kubernetes, варианты решений этих трудностей и текущая реализация werf в подробностях.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть