Меня зовут Алексей Шарапов. Я занимаюсь построением процессов и командами в AkBars Digital. В нашем формате работы девопсы погружены в продуктовые команды, то есть у нас не сервисная модель. Еще я разрабатываю наше внутреннее облако, автоматизирую и запускаю проекты на Kubernetes. В статье рассмотрим оба аспекта моей работы: немного поговорим про командное взаимодействие и немного про инструментарий.

Одни из самых частых вопросов от инженеров, которые я слышу: «Есть проект 10 микросервисов, пора ли запускать его в K8s или нет?» или «У нас есть проект, мы хотим поехать в K8s — надо ли нам это делать или нет?». Мы много занимались его решением, в том числе, с компаниями в формате аудита. Из этого опыта и родилась статья.

Сначала немного порефлексируем. Представим, что у новой большой компании или стартапа начинается новое направление. PO нанимает пару разработчиков, берет фронтендера, дизайнера, инженеров, и они пилят какой-то проект. Пилят неделю, вторую, месяц, и получают готовый продукт. После этого, естественно, хотят выйти на рынок и как-то его монетизировать. Еще, как вариант, есть внутренняя активность. Но для чего они хотят это сделать, в данном случае — не важно. Главное, что перед ними встает большой вопрос — где запускаться?

На самом деле, даже несмотря на все февральские события, выбор достаточно большой:

Думаю, многие работали с Google Cloud, может, до сих пор кто-то пользуется. Есть AmazonEKS, в котором можно также запускать свои сервисы. А еще Kubespray или даже Rancher для локального запуска.

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

Чек-лист

В первую очередь важно понимать, готовы ли к переходу:

1. Команда;

2. Архитектура приложения (даже если это стартап или у вас куча микросервисов, это на самом деле ничего не значит);

3. Окружение и процессы;

4. DevOps.

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

Команда

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

Готовность к новым инструментам

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

• Отладка кода;

• Запуск локально;

• Внутренние абстракции.

Например, есть скомпилированный варник в Java — что с ним делать? Запускать локально? Но как проверить все взаимодействие, как он будет работать? Использовать внутренние абстракции, например, упаковку в Docker или Podman? Или может быть делать все на Docker Compose и потом переносить?

Понимание платформы

Сейчас формируется мнение, что Kubernetes становится новой платформой, даже новой операционной системой, так как уровень и количество абстракций, которые в нем работают, соответствуют именно уровню ОС. Но пользоваться его возможностями, пока умеют не все. А это приводит к проблемам и формированию негативного образа.

Видел интересные кейсы — ребята запускаются в K8s, сверху по привычке лепят всякие внешние Nginx, а внутренние вообще не используют. Балансируют, берут, например, NodePort, и потом удивляются: «Почему у нас плохо работает, трафик странно ходит, и вообще ваш Кубер какой-то нерабочий».

После таких рецензий появляется еще больше вопросов. Например, а где теперь сертификаты? Если вы сталкивались с госухой, там есть разные виды сертификатов — ГОСТовые, неГОСТовые, самоподписанные — куда их класть?

Как теперь работает DNS, сеть и остальное? Это вообще можно отдельно и долго обсуждать. Например, начать говорить про то, зачем нам какое-то внутреннее пространство имен? Очень странный подход, который не работает и начинает ломать саму парадигму работы с Kubernetes.

Это очень важно! Команда должна осознавать, зачем и почему все это нужно делать.

Понимание процессов

Здесь вопросов не меньше. Кто делает трассировку и вообще зачем она нужна? Зачем нам прослеживаемость? Как выбрать ip, на котором мы будем разруливать и подсоединяться к базам? А если базы внутри, как они будут взаимодействовать? А если к нам кто-то проберется?

Многие команды хотят дебажить по старинке: «Вроде бы все нормально, понятно — мы берем какие-то дампы». На самом деле нет. Когда заходит разговор про observability, до сих пор возникает много споров. Кто как это строит, какие инструменты использует, и не у всех уровень зрелости дошел до использования нормальных систем.

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

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

Начиная с этого уровня роль DevOps достаточно важная — объединение процессов.

Архитектура

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

Монолиты

Например, в классном стартапе впопыхах что-то напилили, получили большое хтоническое чудовище, которое ест 50 гигов оперативки и как-то пытается шевелиться, и его хотят затолкать в Кубер. Может быть, это даже и запустится, но какой в этом будет профит? И вообще готовы ли мы к этому?

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

Использование абстракций k8s 

Это схема из картинок Google:

Видно, сколько появляется новых точек взаимодействия, на которые разработчикам, администраторам ЦОД, DevOps-инженерам стоит обращать внимание. Например, зачем там нужен какой-нибудь kubelet? Почему такая куча прокси, когда мы снаружи уже вроде прокси поставили, а тут еще какие-то прокси?

Все эти вопросы начинают возникать по ходу работы. На самом деле неправильное использование абстракций, непонимание, как это работает внутри, хотя бы на базовом уровне, приводит к построению странных больших хтонических систем, которые потом сложно поддерживать. Отсюда возникают всякие противоречия, типа: «Мы запустились, все плохо работает! Все эти ваши хайповые штуки на самом деле не нужны!».

Правильные подходы к написанию кода

Двенадцать факторов приложения, где все прописано — тоже достаточно важный момент. Если пройтись по всем этим факторам, можно хотя бы верхнеуровнево накидать рабочую архитектуру своего приложения. Это отношение к средам и базам данных, то, как у вас всё будет работать внутри, то есть новые подходы к построению кода. Это достаточно полезная статья, про которую мы часто разговариваем, но часто про нее забываем. К ней есть достаточно большое количество отсылок в хороших микросервисных докладах. На самом деле там 6 пунктов про разработку глубоко, а 6 где-то на стыке. Для DevOps практик они являются неким постулатом, с которым тоже можно поработать. 

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

Окружение и процессы

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

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

Хранилище артефактов

Первый вопрос — есть ли у вас хранилища артефактов (пакеты для сборки, хранилище образов)? Как вы вообще с ними работаете — собираете локально, не локально? 

Слышал страшные истории, когда ребята собирали локально имиджи, брали их, делали docker save, docker load и каким-то образом пытались их локально хранить. Фактически это как tar-архивы. Да, это до сих пор существует, это та реальность, которая нас на самом деле окружает. Есть крутые ребята, которые запускаются и весь этот цикл делают. Но есть еще огромное количество компаний, которые к этому не пришли и этого уровня зрелости не добились.

Определить релизный цикл 

Это отдельный важный пункт. Многие работают рядом с разработкой или разработчиками, и касаются релизного цикла. Но если копнуть поглубже, особенно в больших энтерпрайз-компаниях, когда много проектов, есть мобильная разработка (может быть, даже waterfall процессы), а часть уже переехала на Agile — разработчики часто не понимают общий релизный цикл и его ценность.

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

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

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

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

Инструменты поставки

Инструменты поставки — такой же спорный вопрос. На конференциях рассказывают о куче разных инструментов CI/CD. Например, TeamCity, Jenkins, GitLab CI могут обеспечивать CI цикл. Если идти в Kubernetes native, там CD можно разделить на Argo CD. У вас уже будет разделение процесса, а к этому добавятся шаблоны и вспомогательные инструменты.

Шаблонизаторы — Helm, базовые манифесты. Тут не так важно, что вы используете, важно, почему и как вы к этому подходите. Например, часто используют Helm, который как шаблонизатор нормально работает. Кто-то пишет с помощью bash какие-то обертки, кто-то использует Helmfile, есть Skaffold, есть customize. Про весь этот огромный спектр инструментария, часто забывают. Да, у вас image появился, но что с ним дальше делать, как правильно довезти? Неправильный подход к процессу доставки также ломает взаимодействие и восприятие того, как это происходит.

Правильно организованный мониторинг

Про это вообще часто забывают. Остается какой-то Zabbix, Nagios — все что угодно. А нужны Cloud native и понимание, какие метрики важны для правильной работы приложения.

Здесь мы опять вспомним observability, какие данные мы собираем. Если представить, что вы ушли в Managed Kubernetes, то данные, которые вы получаете, например, с железячных хостов, вообще перестают быть важными. На самом деле важен тот перформанс, который выдает приложение, и именно данные ближе к бизнес-метрикам, с которыми вы работаете. То есть вы переходите на уровень выше.

Про это часто забывают, собирают какие-то базовые метрики и потом начинается: «Что-то нам не так удобно работать, как раньше, что бы такого придумать?».

И вроде бы всё, но нет…

Security

Про безопасность мало кто думает именно в формате Kubernetes, а там вообще свой отдельный мир, который обозвали DevSecOps. Это анализаторы кода и сканы:

• Static application security testing (SAST);

• Dynamic application security testing (DAST);

• Container scans;

• Compliance scans;

• Dependency scans.

GitLab сейчас достаточно сильно вкладывается в платформу для DevOps, они предоставляют CI/CD. У них есть отчет 2021 года, как раз о зрелости команд, о внедрении DevSecOps практик, о том, как их используют. Про это не стоит забывать, что пропуская эти части, строя безопасность по старым подходам, то есть ограждая периметр, пытаясь выстраивать там WAF (firewall), вы начинаете терять гибкость. Насколько компания и команда готова к тому, чтобы в таком цикле работать?

Подобный отчет выпускает Puppet, такие отчеты есть у Google в их обучающем центре. Там достаточно большое количество открытой информации, они это называют Cloud Architecture Google центр. Цикл безопасности этих DevSecOps вопросов очень расширился за последние 2 года, и Google уделяет этому очень много внимания. Если у вас возникает вопрос, а готовы ли мы поехать в K8s, наверное, стоит спросить, а готовы ли наши безопасники переехать в Kubernetes и с ним работать?

Мы недавно внутри компании обсуждали, как делать безопасность. Пришли к тому, что несмотря на то, что распределяем приложение на сетевом уровне L3-L4, подходы инструментально и идеологически абсолютно не похожие на то, что мы использовали, работая, например, с железом. Осознание этого позволяет решать проблемы и ответить на вопрос, насколько мы готовы переехать в K8s, какие инструменты мы используем.

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

DevOps

Думаю, вы помните, откуда пошло движение — инженеры хотели посмотреть свое ПО с разных сторон. Уже больше 10 лет мы обсуждаем это в кулуарах, слушаем доклады. Но про какие-то вещи все равно забываем, в частности, о том, что DevOps — это сначала взаимодействие отделов, и только в следующей части — инструментарий. Можно, конечно, все построить на своих решениях, но в Cloud Native Interactive Landscape, с которым, думаю, все знакомы, сейчас стало еще больше инструментария для использования. Например, у меня в большой монитор всё не влазит. Вы даже не успеете весь этот инструмент попробовать. Если раз в полгода бегать по компаниям, все равно нерстек будет плюс-минус похожий, или вы что-то начнете внедрять.

Но факт остается фактом — не должно быть избыточности в инструментарии, то есть не надо использовать то, что не подходит. Например, внешние секьюрити-инструменты, деплоить на bash. Нужно выбрать то, что валидно для вас. Здесь как раз для DevOps практик становится сложный вопрос взаимодействия не каких-то технических выборов — мы внедрили Argo CD, и вроде у нас DevOps появился. Также с Kubernetes — это огромный мир, просто космос, в который погружаешься и остальные абстракции забываешь.

Выводы

Можно сделать несколько выводов:

• Архитектура приложения — важный пойнт.

• Зрелость команды — про это тоже можно поговорить, подискутировать, чтобы разработчики были готовы к тому, чтобы команда понимала, что она делает.

• Архитектура инфраструктуры — это облако, On-Premise, какие-то другие подходы, вы у кого-то арендуете железо или у вас свое железо, сроки реагирования, как вы будете на горячую менять? Есть огромное количество вопросов, на которые стоит ответить перед тем, как куда-то ехать.

• Архитектура k8s, то есть как вы будете ставить — Kubespray, Rancher, что-то свое напишете. Может, у вас какие-то мини-Кубы будут, и вам этого достаточно.

• Security — большой вопрос, о который куча копий сломано.

• DevOps — без избыточности в инструментарии.

Маленький оффтопчик. Одна знакомая компания переехала в Kubernetes и похвалилась: «Мы мигрировали!» В итоге архитектурно получилось так: тестовая среда у них Nomad, дальше K8s в одной конфигурации, в другой, в третьей. Они постоянно жалуются, что ничего не работает: «Мы из Nomad в K8s передеплоились, все упало, абстракции не учли».

Не надо строить странные схемы. Если вы готовы в это вложиться, наверное, стоит в это вкладываться. 

Если вы задумались, а не поехать ли в K8s или над вами уже маячит его запуск, на ноябрьском HighLoad++ 2022 в секции «DevOps и эксплуатация» будет доклад: «Bare metal K8s, или Туда и обратно. История Quadcode». Докладчик расскажет про три итерации подходов к развертыванию K8s-кластеров из опыта компании за 5 лет. И покажет, как они делают это в DO, Google и Amazon.

А если вам самому есть чем поделиться и вы уже давно хотели стать докладчиком. У нас открыт CFP на DevOpsConf. Принимаем заявки до 1 декабря.