В конце мая «Флант» участвовал в конференции DevOpsConf 2021, которая наконец-то вернулась в offline, пусть и с некоторыми ограничениями. Я выступил с докладом о том, как делать Kubernetes так, чтобы были довольны все: разработчики, инженеры и бизнес.
Представляем видео с докладом (там ~40 минут, поэтому информативнее статьи) и основную выжимку из него в текстовом виде. Поехали!
Сперва определим, какую роль играет Kubernetes во взаимодействии инженеров (Operations) и разработчиков (Development).
У разработчиков таких инструментов, конечно, еще больше. И это логично: обычно именно они приносят бизнесу основную прибыль. Хотя сегодня уже неприлично отделять Operations от Developers, я все-таки это сделаю для наглядности.
Вообще, вся конференция DevOpsConf — про эту стрелку между Operations и Developers. Мы здесь пытаемся понять, как организовать коммуникацию и совместную работу, как улучшить процессы и какие практики использовать. Это непросто: у каждого из «кланов» свой инструмент, или язык. Инженеры и разработчики общаются на разных языках, но хотели бы найти общий.
Вопрос: каков основной инструмент передачи информации между двумя этими «кланами»?
На мой взгляд, до недавнего времени ответом на этот вопрос была наскальная живопись.
Например, как обычно разработка объясняет что-то инженерам? «Вот у нас здесь такая штука, она подключается сюда, а еще есть вот эта, которая подключается туда». То есть Operations и Developers пытаются общаться, не имея для этого нормального языка.
Большое изменение происходит в тот момент, когда мы заменяем наскальную живопись на Kubernetes.
На мой взгляд, главная ценность Kubernetes'а в том, что это универсальный язык общения между Operations и Developers.
Но надо понимать, что этот язык общения нужно еще выучить.
Например, английский — международный язык общения. Но вы начинаете получать кайф от английского только того, когда вы его знаете. Пока вы его не знаете, это барьер.
До тех пор, пока Kubernetes’ом пользуются исключительно инженеры эксплуатации, никакой добавленной стоимости он не приносит. Она появляется, как только Kubernetes осваивают разработчики — когда вместо мычания они могут четко сказать:
Доля компаний, которые используют Kubernetes в production, приближается к 50%.
Источники данных для этих графиков
Казалось бы, Kubernetes уже практически везде. Но нюанс в том, что если компания использует Kubernetes в production, это еще не значит, что все ее приложения развернуты в контейнерах. В этом смысле, на мой взгляд, самый важный отчет — у Gartner. Там говорится, что в 2020 году в контейнерах (не в Kubernetes, а просто в контейнерах) запускалось всего 5% enterprise-приложений. По прогнозам агентства, в 2024 году этот показатель вырастет до 15%.
Тем не менее, само распространение Kubernetes уже достаточно широко, в том числе по отраслям. Kubernetes применяют в медицине, фастфуде, авиастроении и даже в космосе.
Другая аналогия: «железо» и стандарты POSIX. Нам теперь не нужно думать о том, как устроено то или иное аппаратное обеспечение — мы работаем в операционной системе и взаимодействуем с hardware через стандартизованный API.
С моей точки зрения, Kubernetes дал нам такой же качественный скачок. Мы перестали заниматься низкоуровневыми задачами: настроить что-то на сервере, заказать виртуальную машину и т. п. Мы просто деплоим pod’ы в Kubernetes и получаем результат.
Я думаю, в следующее 10-летие мы забудем, что такое виртуальные машины и весь этот нижний уровень. Мы забудем, что такое Linux — точно так же, как мы забыли, что такое Assembler и работа с «железом». Потому что Kubernetes дает достаточный уровень абстракции, чтобы просто на этом уровне жить и ниже не спускаться.
Отвечать на вопрос «Что такое Kubernetes?» в духе «это система оркестровки контейнеров», на мой взгляд, вообще неправильно. Kubernetes не об этом. Kubernetes — это язык инфраструктуры.
Итак, мы выяснили, что Kubernetes — :
DevOps-инженеры — это платформенная команда (platform engineering product teams). Задача платформенной команды — поддерживать продуктовые команды, чтобы они могли наилучшим образом доставлять ценности на рынок.
При этом платформенная команда должна фокусироваться на двух вещах:
Эксперты ThoughtWorks рекомендуют использовать модель платформенной команды как основную для организации DevOps-процессов. Формально они объявили её готовой к широкой адаптации совсем недавно, в апреле 2021 года.
В итоге у нас есть корабль, на борту которого — продуктовая и платформенная команды. Теоретически его уже можно отправлять в плавание.
На этом, наверное, можно было бы закончить доклад «Как правильно сделать Kubernetes». Но есть пара нюансов.
То есть получается, экипаж у нас недоукомплектован.
Возникает вопрос: а чем занят существующий экипаж?
Но прежде, чем на него ответить, давайте вспомним, что нас — людей вообще и инженеров в частности — мотивирует.
Лучше всего нас мотивируют две вещи:
Узнавая новое и решая интересные проблемы, мы получаем дофамин. Иногда в этом деле мы доходим до фанатизма, до есть до появления NIH-синдрома (not invented here) — когда мы ищем, что бы такого нового узнать и какую бы такую неизвестную проблему решить.
Возвращаясь к вопросу «Чем занят экипаж?», мы видим, что у нас инженеры часто могут оказываться где-то в трюме — там, где больше дофамина. Но проблема в том, что получение новых знаний и решение интересных проблем не всегда связано с задачами бизнеса.
А теперь вернемся в мир Kubernetes.
Можно пойти еще глубже. Собирать логи, делать горизонтальное масштабирование, работать со StatefulSets, Helm-шаблонами — это уже тот объём «языка», который должен знать каждый senior-разработчик.
Дальше еще интереснее. Нужно знать, как развернуть Kubernetes, как подключаться к Service Discovery, настроить взаимодействие с сервисом мониторинга Prometheus с помощью PromQL. И вот где-то здесь, на мой взгляд, заканчивается здравый смысл и необходимость копать глубже.
Почему?
Всё заканчивается тогда, когда мы идем в репозиторий Kubernetes и создаем KEP (Kubernetes Enhancement Proposal). То есть когда понимаем, что нам не хватает какой-то фичи в Kubernetes, создаем дискуссию и патчим control-plane.
Вот «Флант» уже занимается такими вещами, но надо ли это вам?
По сути, Kubernetes — это гигантская штука, которая чем глубже, тем страшнее. Поэтому никто не хочет сам управлять Kubernetes: делать это своими руками слишком сложно, долго и дорого.
Возвращаясь к нашим аналогиям… У корабля, который пытается выжить в мире Kubernetes исключительно за счет собственных ресурсов, есть две серьезные проблемы:
Но я уверен, что если всё правильно организовать, правильно относиться к мотивации, не лезть на глубину и осознавать, что Kubernetes — это сложная система, всё получится.
Может возникнуть вопрос: но откуда тогда брать дофамин, если мы используем готовое решение? Ответ: соблюдать баланс между новым-интересным и пользой для бизнеса. И здесь помогает правильный фокус.
Когда вы выполняете четыре эти задачи сами, у вас всё хорошо с поиском нового, с исследованиями; у вас всегда много интересной работы. Всё остальное лучше покупать.
В начале я говорил, что мой доклад называется «Как правильно сделать Kubernetes». На самом деле настоящее название доклада: «Перестаньте “делать” Kubernetes. Используйте его». Потому что самая большая ценность Kubernetes — в том, чтобы им пользоваться.
В завершение добавлю, что наша платформа Deckhouse помогает использовать Kubernetes и закрывает все сопутствующие потребности: CI/CD, observability, security и service mesh. Ранний доступ к ней — см. на сайте проекта и в Telegram-чате.
Представляем видео с докладом (там ~40 минут, поэтому информативнее статьи) и основную выжимку из него в текстовом виде. Поехали!
Мои 15 лет работы с контейнерами
Начну с небольшого погружения в предысторию и контекст, чтобы показать, как мы пришли к Kubernetes и что этому сопутствовало.- 2006. Я впервые услышал о контейнерах и попробовал с ними работать — это были OpenSolaris Zones. Пробовал использовать патчи Linux-VServer для Gentoo.
- 2008. Мы с Димой Шуруповым основали «Флант», чтобы помогать компаниям с Linux’ом. В том же году написали собственную утилиту, чтобы делать очень простые контейнеры в userspace — procfs v1. Тогда же появился LXC, и мы начали им пользоваться.
- 2009. Написали свой примитивный «Докер» на Python — jailer.
- 2013. Опубликовали свой первый Open Source-проект — модуль nginx_http_rdns. И начали использовать уже настоящий Docker.
- 2014. Появился первый Docker в Production.
- 2016. Сделали первый коммит в CI/CD-утилиту werf (первоначально — dapp). Мы еще не пользовались Kubernetes, поэтому главной задачей werf была эффективная сборка Docker-контейнеров.
- 2017. Начали использовать Kubernetes. Первый коммит в Deckhouse — нашу платформу на базе K8s.
- 2018. У нас уже 50 кластеров Kubernetes.
- 2019. «Флант» — первый в России сертифицированный провайдер Kubernetes. Мы обслуживаем 100 кластеров. К середине года у werf 1000 звезд на GitHub.
- 2020. 150 кластеров Kubernetes. Релиз первой стабильной версии werf v1.0, а к концу года у проекта 2000 звезд.
- 2021. Наш фреймворк shell-operator для Kubernetes собирает 1000 звезд на GitHub. У плагина grafana-statusmap — 6 млн инсталляций. В мае мы покупаем сервис мониторинга Okmeter. Нас 120 человек.
Что такое Kubernetes
Казалось бы, в 2021 году все знают, что такое Kubernetes: пять бинарников, kubelet, вот это всё… Но хотелось бы акцентировать внимание на более полном понимании, что такое на самом деле Kubernetes и в чем его самая большая добавленная ценность.Сперва определим, какую роль играет Kubernetes во взаимодействии инженеров (Operations) и разработчиков (Development).
Как общаются инженеры и разработчики
У каждого инженера свой инструментарий: Bash, Ansible, Puppet, Terraform и так далее. Нередко используются танцы с бубном — они незаменимы, например, для диагностики проблем.У разработчиков таких инструментов, конечно, еще больше. И это логично: обычно именно они приносят бизнесу основную прибыль. Хотя сегодня уже неприлично отделять Operations от Developers, я все-таки это сделаю для наглядности.
Вообще, вся конференция DevOpsConf — про эту стрелку между Operations и Developers. Мы здесь пытаемся понять, как организовать коммуникацию и совместную работу, как улучшить процессы и какие практики использовать. Это непросто: у каждого из «кланов» свой инструмент, или язык. Инженеры и разработчики общаются на разных языках, но хотели бы найти общий.
Вопрос: каков основной инструмент передачи информации между двумя этими «кланами»?
На мой взгляд, до недавнего времени ответом на этот вопрос была наскальная живопись.
Например, как обычно разработка объясняет что-то инженерам? «Вот у нас здесь такая штука, она подключается сюда, а еще есть вот эта, которая подключается туда». То есть Operations и Developers пытаются общаться, не имея для этого нормального языка.
И тут приходит Kubernetes
В обиходе инженеров становится всё меньше Terraform, потому что больше не так нужны виртуалки. Уходит Ansible и другие инструменты конфигурации, потому что больше не надо ничего настраивать: собранные Docker-контейнеры сами улетают в Kubernetes. Даже танцы с бубном почти уходят — остаются только те, что скрыты за K8s. Но всё это небольшое внутреннее изменение, которое на самом деле ни на что не влияет.Большое изменение происходит в тот момент, когда мы заменяем наскальную живопись на Kubernetes.
На мой взгляд, главная ценность Kubernetes'а в том, что это универсальный язык общения между Operations и Developers.
Но надо понимать, что этот язык общения нужно еще выучить.
Например, английский — международный язык общения. Но вы начинаете получать кайф от английского только того, когда вы его знаете. Пока вы его не знаете, это барьер.
До тех пор, пока Kubernetes’ом пользуются исключительно инженеры эксплуатации, никакой добавленной стоимости он не приносит. Она появляется, как только Kubernetes осваивают разработчики — когда вместо мычания они могут четко сказать:
- вот здесь у них backend — это Deployment,
- а consumers — это еще один Deployment,
- а RabbitMQ в StatefulSet’е и трафик туда заруливается Ingress’ом…
Насколько распространен «язык» Kubernetes
Судя по свежим исследованиям, доля компаний, которые используют K8s, близится к 75%.
Доля компаний, которые используют Kubernetes в production, приближается к 50%.
Казалось бы, Kubernetes уже практически везде. Но нюанс в том, что если компания использует Kubernetes в production, это еще не значит, что все ее приложения развернуты в контейнерах. В этом смысле, на мой взгляд, самый важный отчет — у Gartner. Там говорится, что в 2020 году в контейнерах (не в Kubernetes, а просто в контейнерах) запускалось всего 5% enterprise-приложений. По прогнозам агентства, в 2024 году этот показатель вырастет до 15%.
Тем не менее, само распространение Kubernetes уже достаточно широко, в том числе по отраслям. Kubernetes применяют в медицине, фастфуде, авиастроении и даже в космосе.
Чем обусловлена популярность Kubernetes
Понятно, что Kubernetes сейчас на хайпе. Но, на мой взгляд, этот хайп логичен, потому что Kubernetes хорошо решает два очень серьезных пласта задач:- Технологические: оркестрация, планирование, деплой и т. д.
- Социально-культурные: K8s — это отличное средство коммуникации.
Другая аналогия: «железо» и стандарты POSIX. Нам теперь не нужно думать о том, как устроено то или иное аппаратное обеспечение — мы работаем в операционной системе и взаимодействуем с hardware через стандартизованный API.
С моей точки зрения, Kubernetes дал нам такой же качественный скачок. Мы перестали заниматься низкоуровневыми задачами: настроить что-то на сервере, заказать виртуальную машину и т. п. Мы просто деплоим pod’ы в Kubernetes и получаем результат.
Я думаю, в следующее 10-летие мы забудем, что такое виртуальные машины и весь этот нижний уровень. Мы забудем, что такое Linux — точно так же, как мы забыли, что такое Assembler и работа с «железом». Потому что Kubernetes дает достаточный уровень абстракции, чтобы просто на этом уровне жить и ниже не спускаться.
Отвечать на вопрос «Что такое Kubernetes?» в духе «это система оркестровки контейнеров», на мой взгляд, вообще неправильно. Kubernetes не об этом. Kubernetes — это язык инфраструктуры.
Итак, мы выяснили, что Kubernetes — :
- это универсальный язык инфраструктуры;
- классный, потому что решает множество технологических задач;
- технология, без которой уже нельзя, потому что хайп давит (если не обучиться ему сегодня, на рынке труда будет сложно).
Kubernetes как основной инструмент платформенной команды
Согласно иерархии Team Topologies, основное направление для любой продуктовой компании — это поток изменений или поток создания ценности (flow of change): с одной стороны — идеи, с другой — рынок, потребности которого мы удовлетворили. Также у нас есть stream-aligned teams (продуктовые команды), которые этот поток создают, — разработчики.
DevOps-инженеры — это платформенная команда (platform engineering product teams). Задача платформенной команды — поддерживать продуктовые команды, чтобы они могли наилучшим образом доставлять ценности на рынок.
При этом платформенная команда должна фокусироваться на двух вещах:
- Thinnest Viable Platform («Как можно более тонкая платформа»). Команда должна использовать минимум сервисов, достаточных для решения задач.
- Developer Experience («Опыт разработчика»). Платформенная команда должна делать так, чтобы разработчикам было как можно более комфортно.
Эксперты ThoughtWorks рекомендуют использовать модель платформенной команды как основную для организации DevOps-процессов. Формально они объявили её готовой к широкой адаптации совсем недавно, в апреле 2021 года.
В итоге у нас есть корабль, на борту которого — продуктовая и платформенная команды. Теоретически его уже можно отправлять в плавание.
На этом, наверное, можно было бы закончить доклад «Как правильно сделать Kubernetes». Но есть пара нюансов.
Проблемы с экипажем
О ситуации с DevOps-инженерами на рынке труда всем известно (подтверждается реакцией зала). Но на всякий случай добавлю официальной статистики: согласно исследованию Яндекса, за три года (с 2016 по 2019) востребованность DevOps-инженеров выросла на 70%; а по информации «Ведомостей», все крупнейшие компании России ищут специалистов в DevOps. Подобное мнение популярно и на профильных «народных» ресурсах:
То есть получается, экипаж у нас недоукомплектован.
Возникает вопрос: а чем занят существующий экипаж?
Но прежде, чем на него ответить, давайте вспомним, что нас — людей вообще и инженеров в частности — мотивирует.
Лучше всего нас мотивируют две вещи:
- Узнавать новое.
- Решать интересные проблемы.
Узнавая новое и решая интересные проблемы, мы получаем дофамин. Иногда в этом деле мы доходим до фанатизма, до есть до появления NIH-синдрома (not invented here) — когда мы ищем, что бы такого нового узнать и какую бы такую неизвестную проблему решить.
Возвращаясь к вопросу «Чем занят экипаж?», мы видим, что у нас инженеры часто могут оказываться где-то в трюме — там, где больше дофамина. Но проблема в том, что получение новых знаний и решение интересных проблем не всегда связано с задачами бизнеса.
А теперь вернемся в мир Kubernetes.
Kubernetes — это айсберг
На первый взгляд, в мире Kubernetes у нас всё прекрасно и понятно. Наверху — Docker, Pod’ы, Deployment, kubectl; чуть ниже — Ingress, Secrets, Jobs и т. п. Этих двух уровней обычно достаточно, чтобы решать 85% задач в Kubernetes. Мне кажется, каждый разработчик должен понимать эти сущности и уметь работать с ними.
Можно пойти еще глубже. Собирать логи, делать горизонтальное масштабирование, работать со StatefulSets, Helm-шаблонами — это уже тот объём «языка», который должен знать каждый senior-разработчик.
Дальше еще интереснее. Нужно знать, как развернуть Kubernetes, как подключаться к Service Discovery, настроить взаимодействие с сервисом мониторинга Prometheus с помощью PromQL. И вот где-то здесь, на мой взгляд, заканчивается здравый смысл и необходимость копать глубже.
Почему?
- Этих знаний достаточно, чтобы решить 99% задач в Kubernetes.
- Ниже — уже… совсем сложно.
Всё заканчивается тогда, когда мы идем в репозиторий Kubernetes и создаем KEP (Kubernetes Enhancement Proposal). То есть когда понимаем, что нам не хватает какой-то фичи в Kubernetes, создаем дискуссию и патчим control-plane.
Вот «Флант» уже занимается такими вещами, но надо ли это вам?
По сути, Kubernetes — это гигантская штука, которая чем глубже, тем страшнее. Поэтому никто не хочет сам управлять Kubernetes: делать это своими руками слишком сложно, долго и дорого.
Возвращаясь к нашим аналогиям… У корабля, который пытается выжить в мире Kubernetes исключительно за счет собственных ресурсов, есть две серьезные проблемы:
- нехватка экипажа;
- существующий экипаж — это банда «дофаминовых наркоманов» (извините, что обвиняю кого-то, но я и сам такой…).
Но я уверен, что если всё правильно организовать, правильно относиться к мотивации, не лезть на глубину и осознавать, что Kubernetes — это сложная система, всё получится.
Что делать?
Есть несколько возможных путей.- Нанять больше людей. Правда, из этого ничего не выйдет, потому что на рынке, как мы знаем, нет инженеров. Вместо этого нужно принять проблему дефицита ресурсов. Не думайте, что прямо завтра появятся крутые спецы, которые всё вам сделают. Их просто нет.
- Уменьшить диапазон технологий. Желательно отказаться от всех технологий и сервисов, от которых можно отказаться. Если зайти на сайт Cloud Native Landscape, можно увидеть просто бесконечное количество технологий. Вы не сможете все это освоить, у вас будет когнитивный перегруз. Да и не нужно. Нужно следовать принципу Thinnest Viable Platform.
- Использовать готовое. Не стоит делать Kubernetes самим. Используйте Managed Kubernetes от cloud-провайдеров типа AWS, Yandex.Cloud, Selectel. Или же — готовые платформы типа OpenShift, Rancher и Deckhouse от «Фланта». На основе своей платформы мы предлагаем managed K8s, который работает на любой инфраструктуре (от bare metal до публичных провайдеров и приватных облаков).
Может возникнуть вопрос: но откуда тогда брать дофамин, если мы используем готовое решение? Ответ: соблюдать баланс между новым-интересным и пользой для бизнеса. И здесь помогает правильный фокус.
Правильный фокус — developer experience
Он формируется за счет четырех направляющих:- Упрощение платформы. Каждый разработчик, каждая продуктовая (stream-aligned) команда должна максимально полно понимать, как ей деплоить и как получать обратную связь с помощью платформы.
- Интеграция всех используемых технологий и сервисов друг с другом. Это гигантский объем интересных задач.
- Research. Вы должны знать, что будет завтра для того, чтобы быть к этому готовым.
- Guidance. То есть руководства, чтобы всем этим управлять.
Когда вы выполняете четыре эти задачи сами, у вас всё хорошо с поиском нового, с исследованиями; у вас всегда много интересной работы. Всё остальное лучше покупать.
В начале я говорил, что мой доклад называется «Как правильно сделать Kubernetes». На самом деле настоящее название доклада: «Перестаньте “делать” Kubernetes. Используйте его». Потому что самая большая ценность Kubernetes — в том, чтобы им пользоваться.
В завершение добавлю, что наша платформа Deckhouse помогает использовать Kubernetes и закрывает все сопутствующие потребности: CI/CD, observability, security и service mesh. Ранний доступ к ней — см. на сайте проекта и в Telegram-чате.
P.S.
Читайте также в нашем блоге:- «Как мы обновляли Kubernetes 1.16 до 1.19… с удовольствием»;
- «werf — наш инструмент для CI/CD в Kubernetes» (Дмитрий Столяров; 27 мая 2019 на DevOpsConf);
- «Мониторинг и Kubernetes» (Дмитрий Столяров; 28 мая 2018 на RootConf);
- «Наш опыт с Kubernetes в небольших проектах» (Дмитрий Столяров; 6 июня 2017 на RootConf).