Kubernetes захватит мир. Когда и как?
В преддверии DevOpsConfВиталий Хабаров взял интервью у Дмитрия Столярова (distol), технического директора и соучредителя компании «Флант». Виталий расспросил Дмитрия про то, чем занимается «Флант», про Kubernetes, развитие экосистемы, поддержку. Обсудили, зачем нужен Kubernetes и нужен ли вообще. А еще про микросервисы, Amazon AWS, подход «Мне повезет» в DevOps, будущее самого Kubernetes, почему, когда и как он захватит мир, перспективы DevOps и к чему готовиться инженерам в светлом и близком будущем с упрощением и нейросетями.
Оригинал интервью в виде подкаста послушайте на DevOps Дефлопе — русскоязычном подкасте о DevOps, а ниже — текстовая версия.
Здесь и далее вопросы задает Виталий Хабаров инженер из Express42.
Про «Флант»
— Дима, привет. Ты — технический директор «Флант» и также его основатель. Расскажи, пожалуйста, чем занимается компания и ты в ней?
Дмитрий: Снаружи кажется, будто мы такие ребята, которые ходят, всем ставят Kubernetes и что-то с ним делают. Но это не так. Мы начинали, как компания, которая занимается Linux, но уже очень давно основная наша деятельность — обслуживание продакшн и highload-проектов под ключ. Обычно мы строим всю инфраструктуру с нуля и потом долго-долго за нее отвечаем. Поэтому, основная работа, которую выполняет «Флант», за что и получает деньги — это взятие ответственности и реализация продакшн под ключ.
Я, как технический директор и один из учредителей компании, круглые сутки занимаюсь тем, что придумываю, как бы повысить доступность продакшн, упростить его эксплуатацию, облегчить жизнь админов, а жизнь разработчиков сделать приятнее.
Про Kubernetes
— Последнее время от «Фланта» вижу много докладов и статей про Kubernetes. Как вы пришли к нему?
Дмитрий: Я уже рассказывал об этом много раз, но мне совершенно не жалко повторить. Считаю, что правильно повторять эту тему, потому что возникает путаница между причиной и следствием.
Нам очень нужен был инструмент. Мы сталкивались с кучей проблем, боролись, преодолевали их разными костылями и испытывали потребность в инструменте. Перебирали много разных вариантов, строили свои велосипеды, накапливали опыт. Постепенно дошли до того, что начали использовать Docker почти сразу как он появился — примерно в 2013 году. В момент его появления у нас уже было много опыта с контейнерами, мы уже написали аналог «Docker» — какие-то свои костыли на Python. С появлением Docker появилась возможность костылики выкинуть и использовать надежное и поддерживаемое сообществом решение.
С Kubernetes история аналогична. К моменту, когда он начал набирать обороты, — для нас это версия 1.2, — у нас уже была куча костылей и на Shell, и на Chef, которые мы как-то пытались оркестровать Docker. Мы серьезно смотрели в сторону Rancher и разных других решений, но тут появился Kubernetes, в котором все реализовано ровно так, как сделали бы мы или даже лучше. Придраться не к чему.
Да, тут есть какая-то недоделка, там какая-то недоделка — много недоделок, а 1.2 вообще жуть, но…Kubernetes как строящееся здание — смотришь на проект и понимаешь, что это будет круто. Если у здания сейчас есть фундамент и два этажа, то понимаешь, что лучше пока не заселяться, а с софтом таких проблем нет — пользоваться уже можно.
У нас не было момента, что мы думали использовать Kubernetes или нет. Мы его ждали задолго до того, как он появился, и пытались сами городить аналоги.
Около Kubernetes
— Вы участвуете непосредственно в разработке самого Kubernetes?
Дмитрий: Посредственно. Скорее участвуем в развитии экосистемы. Мы отправляем какое-то количество pull requests: в Prometheus, во всякие операторы, в Helm — в экосистему. К сожалению, я не в состоянии следить за всем, что мы делаем и могу ошибаться, но от нас нет ни одного пула в ядро.
— При этом вы разрабатываете и много своих инструментов вокруг Kubernetes?
Дмитрий: Стратегия такая: мы идем и пулл-реквестим во все, что уже есть. Если там pull requests не принимаются, мы просто форкаем их себе и живем, пока они не приняты с нашими билдами. Потом, когда это долетает до upstream, мы возвращаемся обратно на upstream«овую версию.
Например, у нас есть Prometheus-оператор, с которым мы туда-сюда переключались на upstream нашей сборки уже раз 5, наверное. Нам нужна какая-то фича, мы послали pull request, нам надо ее завтра выкатить, а ждать, пока ее релизнут в upstream, не хотим. Соответственно, мы собираем себе, катим нашу сборку с нашей фичей, которая нам зачем-то нужна, на все свои кластеры. Потом это, например, в upstream нам заворачивают со словами: «Ребята, давайте, сделаем для более общего случая», мы, или кто-то другой, это доделываем, и со временем опять обратно сливается.
Все, что существует, мы стараемся развивать. Многие элементы, которых еще нет, еще не придумали или придумали, но не успели реализовать — мы делаем. И не потому, что нам нравится сам процесс или велосипедостроение как отрасль, а просто потому, что нам нужен этот инструмент. Часто задают вопрос, зачем мы сделали ту или иную вещь? Ответ прост — да потому, что нам надо было идти дальше, решить какую-то практическую проблему, и мы ее решили этой тулой.
Путь всегда такой: мы очень тщательно ищем и, если не находим никакого решения, как из буханки хлеба сделать троллейбус, то делаем свою буханку и свой троллейбус.
Инструменты «Фланта»
— Мне известно, что сейчас у «Фланта» есть addon-операторы, shell-операторы, инструменты dapp/werf. Как я понимаю, это один и тот же инструмент в разных инкарнациях. Также я понимаю, что внутри «Флант» есть еще много различных инструментов. Это так?
Дмитрий: У нас на GitHub еще много чего есть. Из того, что я сейчас вспомню, у нас есть statusmap — панель для Grafana, которая зашла всем. Она упоминается чуть ли не в каждой второй статье про мониторинг Kubernetes на Медиум. Невозможно кратко рассказать, что такое statusmap — нужна отдельная статья, но это очень полезная вещь для мониторинга статуса во времени, так как в Kubernetes нам часто требуется показывать статус во времени. Еще у нас есть LogHouse — это штука на базе ClickHouse и черной магии для сбора логов в Kubernetes.
Много утилит! И будет еще больше, потому что некоторое количество внутренних решений будет релизиться в этом году. Из очень больших на базе addon-оператора есть куча addons к Kubernetes аля как правильно поставить sert manager — инструмент для управления сертификатами, как правильно поставить Prometheus с кучей обвески — это штук двадцать разных бинарников, которые экспортируют данные и что-то собирают, к этому Prometheus шикарнейшая графика и алерты. Все это просто куча addons к Kubernetes, которые ставятся в кластер, и он превращается из простого в крутой, навороченный, автоматический, в котором многие вопросы уже решены. Да, много что делаем.
Развитие экосистемы
— Мне кажется, это очень большой вклад в развитие этого инструмента и его методов использования. Можешь ли ты примерно прикинуть, кто бы еще вносил такой же вклад в развитие экосистемы?
Дмитрий: В России из тех компаний, которые действуют на нашем рынке — никто и близко. Конечно, это громкое заявление, потому что есть крупные игроки, как Mail с Яндексом — они тоже что-то делают с Kubernetes, но даже они не подобрались ко вкладу компаний в целом по миру, которые делают гораздо больше, чем мы. Сложно сравнивать «Флант» со штатом в 80 человек и Red Hat, в котором только на один Kubernetes 300 инженеров, если не ошибаюсь. Тяжело сравнивать. У нас в отделе RnD 6 человек включая меня, которые пилят все наши тулы. 6 человек против 300 инженеров Red Hat — как-то сложно сравнивать.
— Тем не менее, когда даже эти 6 человек могут сделать что-то действительно полезное и отчуждаемое, когда они сталкиваются с практической задачей и отдают решение в сообщество — интересный кейс. Понимаю, что в крупных технологических компаниях, где есть своя разработка и команда поддержки Kubernetes, в принципе, могут разрабатываться такие же тулы. Это для них пример, что можно разработать и отдать в сообщество, дать толчок всему сообществу, которое использует Kubernetes.
Дмитрий: Наверное, это фишка интегратора, его особенность. У нас же много проектов и мы видим много разных ситуаций. Для нас основной способ создания добавленной стоимости — это проанализировать эти кейсы, найти общее и максимально удешевить их для нас. Этим мы активно занимаемся. Мне сложно говорить про Россию и мир, но у нас примерно 40 DevOps-инженеров в компании, которые занимаются Kubernetes. Я не думаю, что в России много компаний с сопоставимым количеством специалистов, которые разбираются в Kubernetes, если они вообще есть.
Я понимаю все про название должности DevOps-инженер, все всё понимают и привыкли называть DevOps-инженеров DevOps-инженерами, мы не будем это обсуждать. Все эти 40 замечательных DevOps-инженеров каждый день сталкиваются с проблемами и решают их, мы просто анализируем этот опыт и пытаемся обобщить. Мы понимаем, что если он останется у нас внутри, то через год или два инструмент бесполезен, потому что где-то в community появится готовая тула. Нет смысла накапливать этот опыт внутри — это просто слив сил и времени в dev/null. А так нам совершенно не жалко. Мы с большим удовольствием все публикуем и понимаем, что это надо публиковать, развивать, пиарить, раскручивать, чтобы люди пользовались и добавляли свой опыт — тогда все растет и живет. Тогда через два года инструмент не идет на помойку. Не жалко продолжать вливать силы, потому что видно, что твоим инструментом кто-то пользуется, а через два года им пользуются уже все.
Это часть нашей большой стратегии с dapp/werf. Не помню, когда мы начали его делать, кажется, года 3 назад. Изначально он был вообще на shell. Это был супер proof of concept, мы решили какие-то наши частные задачи — получилось! Но с shell там проблемы, дальше это наращивать невозможно, программировать на shell — то еще занятие. У нас была привычка писать на Ruby, соответственно, на Ruby мы что-то переделали, развивали, развивали, развивали, и уперлись в то, что community, толпа, которая не говорит «мы хотим или не хотим», воротит нос от Ruby, как это не смешно. Поняли, что должны все это добро писать на Go, чтобы просто соответствовать первому пункту в чек-листе: DevOps-тула должна быть статическим бинарником. На Go или не на Go не так важно, но лучше статический бинарник, написанный на Go.
Потратили силы, переписали dapp на Go и назвали его werf. Dapp больше не поддерживается, не развивается, работает в какой-то последней версии, но есть абсолютный upgrade-путь наверх, и ему можно последовать.
Зачем создавался dapp
— Можешь вкратце рассказать, зачем создавался dapp, какие проблемы он решает?
Дмитрий: Первая причина в сборке. Изначально у нас были сильные проблемы со сборкой, когда Docker не умел multi-stage, и мы сделали multi-stage своими силами. Потом у нас была еще куча вопросов с очисткой image. Все, кто делают CI/CD, скорее раньше, чем позже, сталкиваются с проблемой, что есть куча собранных images, требуется как-то вычищать то, что не нужно, и оставлять то, что нужно.
Вторая причина в деплое. Да, есть Helm, но он решает только часть задач. Как ни смешно, написано, что «Helm — the Package Manager for Kubernetes». Именно, что «the». Еще есть слова «Package Manager» — какое ожидание обычно от Package Manager? Мы говорим: «Package Manager — поставь пакет!» и ожидаем, что он нам скажет: «Пакет поставлен».
Интересно, что мы говорим: «Helm, поставь пакет», а когда он отвечает, что поставил, то выясняется, что он только начал установку — указал Kubernetes: «Вот эту штуку запусти!», а запустилась она или нет, работает или нет, Helm этот вопрос вообще никак не решает.
Получается, что Helm — просто текстовый препроцессор, который загружает данные в Kubernetes.
Но мы в рамках любого деплоя хотим знать — приложение выкатилось на прод или нет? Выкатилось на прод значит, что приложение туда выехало, развернулась новая версия развернулась, и она там хотя бы не падает и корректно отвечает. Helm эту задачу никак не решает. Чтобы ее решить, надо потратить много сил, потому что необходимо отдать Kubernetes команду выкатывать и следить за тем, что же там происходит — развернулось ли оно, выкатилось ли. А еще есть куча задач, связанных с деплоем, с очисткой, со сборкой.
Планы
Еще в этом году мы пойдем в локальную разработку. Мы хотим прийти к тому, что раньше было в Vagrant — набрали «vagrant up» и у нас развернулись виртуалки. Мы хотим прийти к такому состоянию, что есть проект в Git, мы там пишем «werf up», и он поднимает локальную копию этого проекта, развернутую в локальном мини-Kub, с подключенными всеми директориями, удобными для разработки. В зависимости от языка разработки это выполняется по-разному, но, тем не менее, чтобы можно было удобно вести локальную разработку под монтированными файлами.
Следующий шаг для нас — сильно вкладываться в удобство для разработчиков. Чтобы одним инструментом быстро локально развернуть проект, подевелопить, пушнуть в Git, и он точно также выкатится на stage или на тесты, в зависимости от пайплайнов, и потом тем же самым инструментом поехать на прод. Это единство, унификация, воспроизводимость инфраструктуры от локального окружения до прода для нас очень важный момент. Но этого пока нет в werf — только планируем делать.
Но путь к dapp/werf всегда был такой же, как с Kubernetes в начале. Мы сталкивались с проблемами, решали их обходными путями — придумывали для себя какие-то решения на shell, на чем угодно. Потом эти обходные пути старались как-то спрямить, обобщить и консолидировать в бинарники в данном случае, которыми просто делимся.
Есть еще другой взгляд на всю эту историю, с аналогиями.
Kubernetes — это каркас автомобиля с движком. Нет дверей, стекол, радиоприемника, елочки — вообще ничего нет. Только рама и движок. И есть Helm — это руль. Классно — руль есть, но нужны еще рулевой штифт, рулевая рейка, КПП и колеса, а без них никак.
В случае с werf — это еще один компонент к Kubernetes. Только сейчас у нас в альфа-версии werf, например, Helm вкомпиливается вообще внутрь werf, потому что нам надоело это делать самим. Много причин так делать, подробно о том, зачем мы вкомпилили helm целиком вместе с tiller внутрь werf, я расскажу как раз на докладе на РИТ++.
Сейчас werf — это более интегрированный компонент. У нас получается готовый руль, рулевой штифт — я не очень хорошо в автомобилях разбираюсь, но это большой блок, который решает уже достаточно большой спектр задач. Нам не нужно самим лазить по каталогу, подбирать одну деталь к другой, думать, как их прикрутить друг к другу. Мы получаем готовый комбайн, который решает сразу большую пачку задач. Но внутри он устроен все из тех же опенсорсных компонентов, все также использует Docker для сборки, Helm для части функционала, и есть еще несколько других библиотек. Это интегрированный инструмент, чтобы получить быстро и удобно крутой CI/CD из коробки.
Cложно ли поддерживать Kubernetes?
— Ты рассказываешь про опыт, что начали использовать Kubernetes, это для вас рама, движок, и что на него можно много всего разного навесить: корпус, руль, прикрутить педальки, сиденья. Возникает вопрос — насколько сложно вам дается поддержка Kubernetes? У вас богатый опыт, сколько у вас уходит времени и ресурсов именно на поддержку Kubernetes в отрыве от всего остального?
Дмитрий: Это очень сложный вопрос и чтобы ответить, надо понять, что такое поддержка, и что мы хотим от Kubernetes. Может быть, ты раскроешь?
— Насколько мне известно и как я вижу, сейчас много команд хотят попробовать Kubernetes. Все в него впрягаются, ставят на коленке. У меня есть ощущение, что люди не всегда понимают сложность этой системы.
Дмитрий: Все так.
— Насколько сложно взять и поставить Kubernetes с ничего, чтобы это было production ready?
Дмитрий: Как думаешь, насколько сложно пересадить сердце? Понимаю, вопрос компрометирующий. Возить скальпелем и не ошибиться — это не так сложно. Если тебе говорят где отрезать, а где зашить, то сама по себе процедура несложная. Сложно гарантировать из раза в раз, что все получится.
Поставить Kubernetes и заставить работать просто: чик! — поставился, есть куча способов инсталляции. Но что будет, когда возникнут проблемы?
Всегда встают вопросы — что мы еще не учли? Что мы еще не сделали? Какие параметры Linux-ядра указали неправильно? Господи, а мы вообще их указывали?! Какие компоненты Kubernetes мы поставили, а какие нет? Возникают тысячи вопросов, и чтобы ответить на них, нужно 15–20 лет вариться в этой индустрии.
У меня есть свежий пример на эту тему, который может раскрыть смысл проблемы «Сложно ли поддерживать Kubernetes?». Некоторое время назад мы всерьез рассматривали не попробовать ли нам внедрить Cilium в качестве сети в Kubernetes.
Поясню, что такое Cilium. В Kubernetes есть много разных реализаций сетевой подсистемы, и одна из них очень крутая — это Cilium. В чем ее смысл? В ядре некоторое время назад появилась возможность писать хуки для ядра, которые так или иначе вторгаются в сетевую подсистему и в разные другие подсистемы, и позволяют обойти большие куски в ядре.
В Linux-ядре исторически есть ip rout, надфильтр, бриджи и много разных старых компонент, которым по 15, 20 30 лет. В целом они работают, все классно, но сейчас понагородили контейнеров, и это выглядит как башенка из 15 кирпичей друг на друге, а ты стоишь на ней на одной ноге — странное ощущение. Эта система исторически развивалась со множеством нюансов, как аппендикс в организме. В некоторых ситуациях есть проблемы с performance, например.
Есть замечательный BPF и возможность писать хуки для ядра — ребята написали свои хуки для ядра. Пакет приходит в Linux-ядро, они его прямо на входе вынимают, обрабатывают сами как надо без бриджей, без TCP, без IP-стека — короче, в обход всего, что написано в Linux-ядре, и тут же выплевывают в контейнер.
Что получилось? Очень крутой performance, крутые фичи — просто классно! Но мы смотрим на это и видим, что на каждой машине стоит прога, которая подключается к API Kubernetes и по данным, которые получает из этого API, генерирует C-код и компилит бинарники, которые загружает в ядро, чтобы в kernel space эти хуки работали.
Что будет, если что-то пойдет не так? Мы не знаем. Чтобы это понять, надо прочитать весь этот код, понять всю логику, а это обалдеть, как сложно. Но, с другой стороны, есть эти бриджи, net-фильтры, ip rout — я не читал их исходники, и 40 инженеров, которые работают в нашей компании тоже. Может быть, какие-то куски понимают единицы.
И какая разница? Получается, что есть ip rout, ядро Linux, и есть новый инструмент — какая разница, мы ни одну, ни другую не понимаем. Но боимся использовать новое — почему? Потому что если инструменту 30 лет, то за 30 лет все баги нашли, на все грабли наступили и знать про все не нужно — работает, как чёрный ящик, и работает всегда. Все знают, какую диагностическую отвертку в какое место воткнуть, какой tcpdump в какой момент запустить. Все хорошо знают диагностические утилиты и понимают, как этот набор компонентов работает в ядре Linux — не как он устроен, а как им пользоваться.
А офигенно классному Cilium не 30 лет, он еще не выдержан. С Kubernetes такая же проблема, копия. Что Cilium ставится прекрасно, что Kubernetes ставится прекрасно, но, когда что-то не так пойдет в проде, способны ли вы в критической ситуации быстро понять, что пошло не так?
Когда мы говорим, сложно ли поддерживать Kubernetes — нет, очень просто, и да, невероятно сложно. Kubernetes прекрасно работает сам по себе, но с миллиардом нюансов.
Про подход «Мне повезет»
— А есть ли компании, где эти нюансы почти гарантированно появятся? Предположим, Яндекс вдруг поголовно переведет все сервисы на Kubernetes, там будет ого-го какая нагрузка.
Дмитрий: Нет, это же разговор не про нагрузку, а о простейших вещах. Например, есть у нас Kubernetes, мы задеплоили туда приложение. Как понять, что оно работает? Готового инструмента, чтобы понять, что приложение не падает, просто нет. Готовой системы, которая шлет алерты — нет, надо настроить эти алерты и каждый график. А мы вот обновляем Kubernetes.
Есть Ubuntu 16.04. Можно сказать, что это старая версия, но мы до сих пор на ней, потому что там LTS. Там есть systemd, нюанс которого в том, что он не чистит C-группы. Kubernetes запускает поды, создает C-группы, потом поды удаляет, и как-то так получается — я не помню деталей, простите, — что остаются слайсы systemd. Это приводит к тому, что со временем любая машина начинает сильно тормозить. Это даже вопрос не про highload. Если запускаются постоянные поды, например, если есть Cron Job, который постоянно генерирует поды, то машина с Ubuntu 16.04 через неделю начнет тормозить. Там будет постоянно высокий load average из-за того, что создана куча 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 — везде, где нужен Continuous Delivery, где требуется обновлять версии, вести активные изменения, везде, где необходимо выстроить отказоустойчивость — только Kubernetes.
Про микросервисы
— Тут у меня возникает небольшой диссонанс. Чтобы работать с Kubernetes, нужна внешняя или внутренняя поддержка — это первый момент. Второй — когда мы только-только начинаем разработку, мы маленький стартап, у нас еще ничего нет, разработка под Kubernetes или вообще под микросервисную архитектуру может быть сложной, и не всегда оправдана с экономически. Мне интересно твое мнение — нужно ли стартапам с нуля сразу начинать писать под Kubernetes или можно все-таки написать монолит, и потом только прийти к Kubernetes?
Дмитрий: Крутой вопрос. У меня есть доклад про микросервисы «Микросервисы: размер имеет значение». Я много раз сталкивался с тем, что люди пытаются микроскопом забивать гвозди. Сам по себе подход правильный, мы сами внутренний софт проектируем именно этим путем. Но когда это делаешь, нужно четко понимать, что ты делаешь. Больше всего в микросервисах я ненавижу слово «микро». Исторически сложилось, что там возникло это слово, и почему-то люди думают, что микро — это очень маленький, меньше миллиметра, как микрометр. Это не так.
Например, есть монолит, который пишут 300 человек, и все, кто участвовал в разработке, понимают, что там есть проблемы, и его надо бы разбить на микро-кусочки — штук на 10, каждый из которых пишут 30 человек в минимальном варианте. Это важно, нужно и классно. Но когда к нам приходит стартап, где 3 очень крутых и талантливых пацана написали на коленке 60 микросервисов, каждый раз я ищу корвалол.
Мне кажется, про это уже говорили тысячи раз — получили распределенный монолит в той или иной ипостаси. Это экономически не оправдано, очень сложно вообще во всем. Просто я это столько раз видел, что мне прямо больно, поэтому я продолжаю об этом говорить.
К начальному вопросу, что есть конфликт между тем, что, с одной стороны, Kubernetes страшно использовать, потому что непонятно, что там может сломаться или не заработать, с другой стороны, понятно, что все идет туда и ничего, кроме Kubernetes, не будет. Ответ — взвешивать объем пользы, которая приходит, объем задач, который вы можете решить. Это с одной стороны весов. С другой стороны — риски, которые связаны с простоем или со снижением времени отклика, уровня доступности — со снижением показателей работы.
Тут так — или нам быстро двигаться, и Kubernetes позволяет многие вещи выполнять намного быстрее и лучше, или использовать надежные, проверенные временем решения, но двигаться гораздо медленнее. Этот выбор должна делать каждая компания. Можно рассматривать это как дорожку в джунглях — когда идешь первый раз, можно встретить змею, тигра или бешеного барсука, а когда сходил 10 раз — протоптал тропу, убрал ветки и ходить полегче. С каждым разом тропинка шире. Потом это уже асфальтированная дорога, а позже красивый бульвар.
Kubernetes не стоит на месте. Опять вопрос: Kubernetes, с одной стороны, это 4–5 бинарников, с другой — это вся экосистема. Это операционка, которая у нас стоит на машинах. Что это? Ubuntu или Curios? Это ядро Linux, куча дополнительных компонентов. Все эти штуки тут одну ядовитую змею выкинули с дороги, там забор поставили. Kubernetes очень быстро и динамично развивается, и объем рисков, объем неизведанного с каждым месяцем уменьшается и, соответственно, эти весы перебалансируются.
Отвечая на вопрос, что делать стартапу, я бы сказал — приходите к «Фланту», платите 150 тысяч рублей и получайте под ключ DevOps easy service. Если вы небольшой стартап в несколько разработчиков — это работает. Вместо того, чтобы нанимать своего DevOps, которому нужно будет учиться решать ваши проблемы и платить в это время зарплату, вы получите решение всех вопросов под ключ. Да, есть некоторые минусы. Мы, как аутсорсер, не можем быть так вовлечены и быстро реагировать на внесение изменений. Но зато у нас куча экспертизы, готовые практики. Мы гарантируем, что в любой ситуации мы точно быстро разберемся и поднимем с того света любой Kubernetes.
Я категорически рекомендую аутсорсинг стартапам и сложившемуся бизнесу до размера, когда вы можете выделять на эксплуатацию команду из 10 человек, потому что иначе нет смысла. Это категорически имеет смысл аутсорсить.
Про Amazon и Google
— Можно ли рассматривать в качестве аутсорса хост от решения от Amazon или Google?
Дмитрий: Да, конечно, это решает некоторое количество вопросов. Но опять нюансы. Все равно надо понимать, как это использовать. Например, есть тысяча мелочей в работе Amazon AWS: Load Balancer надо прогревать или заранее писать заявку, что «ребята, нам придет трафик, прогрейте нам Load Balancer!» Эти нюансы надо знать.
Когда вы обращаетесь к людям, которые на этом специализируются, вы получаете почти все типовые вещи закрытыми. У нас сейчас 40 инженеров, к концу года их, наверное, будет 60 — мы точно со всеми этими вещами сталкивались. Даже если на каком-то проекте мы еще раз сталкиваемся с этой проблемой, мы уже быстро друг у друга спрашиваем и знаем, как решить.
Наверное, ответ такой — конечно, hosted-история облегчает какую-то часть. Вопрос в том, готовы ли вы доверять этим хостерам, и решат ли они ваши проблемы. Amazon и Google зарекомендовали себя хорошо. Для всех наших кейсов — точно. Больше мы никаких позитивных опытов не имеем. Все остальные clouds, с которыми мы пытались работать, создают очень много проблем — и Ager, и все, что есть в России, и всевозможные OpenStack в разных реализациях: Headster, Overage — все, что хотите. Они все создают проблемы, которые не хочется решать.
Поэтому, ответ — да, но, по факту, зрелых hosted-решений не очень много.
Кому нужен Kubernetes?
— И все-таки кому нужен Kubernetes? Кто должен уже переходить на Kubernetes, кто типичный клиент «Фланта», который приходит именно за Kubernetes?
Дмитрий: Вопрос интересный, потому что сейчас как раз на волне Kubernetes к нам многие приходят: «Ребята, мы знаем, что вы делаете Kubernetes, сделайте нам!». Мы им отвечаем: «Господа, мы не делаем Kubernetes, мы делаем прод и все, что с ним связано». Потому что сделать прод, не сделав весь CI/CD и всю эту историю, в настоящее время просто невозможно. Все ушли от разделения, что у нас разработка разработкой, а потом эксплуатация эксплуатацией.
Наши клиенты ожидают разное, но все ждут некоторого доброго чуда, что у них есть те или иные проблемы, а сейчас — хоп! — Kubernetes их решит. Люди верят в чудеса. Разумом понимают, что чуда не будет, но душой надеются —, а вдруг этот Kubernetes сейчас нам все решит, про него столько говорят! Вдруг он сейчас — чих! — и серебряная пуля, чих! — и у нас 100% uptime, все разработчики могут по 50 раз релизить что попало на прод, и оно не падает. В общем, чудо!
Когда такие люди к нам приходят, мы говорим: «Извините, но чуда не бывает». Чтобы быть здоровым, нужно хорошо питаться и заниматься спортом. Чтобы иметь надежный прод, его нужно сделать надежно. Чтобы иметь удобный CI/CD, его нужно сделать таким. Это много работы, которую необходимо делать.
Отвечая на вопрос, кому нужен Kubernetes — Kubernetes не нужен никому.
У некоторых людей есть ошибочное ощущение, что им нужен Kubernetes. Людям нужно, у них прямо глубокая потребность перестать думать, заниматься, интересоваться вообще всеми проблемами инфраструктуры и проблемами запуска их приложений. Они хотят, чтобы приложения просто работали и просто деплоились. Для них Kubernetes — это надежда, что они перестанут слышать историю, что «мы там валялись», или «не можем выкатиться», или что-то еще.
К нам обычно приходит технический директор. С него спрашивают две вещи: с одной стороны, давай нам фичи, с другой стороны — стабильность. Мы предлагаем взять это на себя и сделать. Серебряная пуля, точнее, посеребрённая, в том, что ты перестанешь думать об этих проблемах и тратить время. У тебя будут специальные люди, которые закроют этот вопрос.
Формулировка, что нам или кому-то нужен Kubernetes — неправильная.
Kubernetes очень нужен админам, потому что это же очень интересная игрушка, с которой можно поиграть, поковыряться. Давайте будем честны — все любят игрушки. Все мы где-то дети, и когда мы видим новую — хотим в нее поиграть. У кого-то это отбито, например, в админстве, потому что уже наигрались и уже надоело до того, что просто не хочется. Но это же не отбито
