Что такое kubernetes и зачем он нужен

Основы Kubernetes

В этой публикации я хотел рассказать об интересной, но незаслуженно мало описанной на Хабре, системе управления контейнерами Kubernetes.

Что такое Kubernetes?

Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.

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

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

Концепции Kubernetes

Nodes (node.md): Нода это машина в кластере Kubernetes.
Pods (pods.md): Pod это группа контейнеров с общими разделами, запускаемых как единое целое.
Replication Controllers (replication-controller.md): replication controller гарантирует, что определенное количество «реплик» pod’ы будут запущены в любой момент времени.
Services (services.md): Сервис в Kubernetes это абстракция которая определяет логический объединённый набор pod и политику доступа к ним.
Volumes (volumes.md): Volume(раздел) это директория, возможно, с данными в ней, которая доступна в контейнере.
Labels (labels.md): Label’ы это пары ключ/значение которые прикрепляются к объектам, например pod’ам. Label’ы могут быть использованы для создания и выбора наборов объектов.
Kubectl Command Line Interface (kubectl.md): kubectl интерфейс командной строки для управления Kubernetes.

Архитектура Kubernetes

Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet) и компоненты мастера (APIs, scheduler, etc), поверх решения с распределённым хранилищем. Приведённая схема показывает желаемое, в конечном итоге, состояние, хотя все ещё ведётся работа над некоторыми вещами, например: как сделать так, чтобы kubelet (все компоненты, на самом деле) самостоятельно запускался в контейнере, что сделает планировщик на 100% подключаемым.

Нода Kubernetes

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

Kubelet

Kubelet управляет pod’ами их контейнерами, образами, разделами, etc.

Kube-Proxy

Также на каждой ноде запускается простой proxy-балансировщик. Этот сервис запускается на каждой ноде и настраивается в Kubernetes API. Kube-Proxy может выполнять простейшее перенаправление потоков TCP и UDP (round robin) между набором бэкендов.

Компоненты управления Kubernetes

Система управления Kubernetes разделена на несколько компонентов. В данный момент все они запускаются на мастер-ноде, но в скором времени это будет изменено для возможности создания отказоустойчивого кластера. Эти компоненты работают вместе, чтобы обеспечить единое представление кластера.

Состояние мастера хранится в экземпляре etcd. Это обеспечивает надёжное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния.

Kubernetes API Server

Kubernetes API обеспечивает работу api-сервера. Он предназначен для того, чтобы быть CRUD сервером со встроенной бизнес-логикой, реализованной в отдельных компонентах или в плагинах. Он, в основном, обрабатывает REST операции, проверяя их и обновляя соответствующие объекты в etcd (и событийно в других хранилищах).

Scheduler

Scheduler привязывает незапущенные pod’ы к нодам через вызов /binding API. Scheduler подключаем; планируется поддержка множественных scheduler’ов и пользовательских scheduler’ов.

Kubernetes Controller Manager Server

Все остальные функции уровня кластера представлены в Controller Manager. Например, ноды обнаруживаются, управляются и контролируются средствами node controller. Эта сущность в итоге может быть разделена на отдельные компоненты, чтобы сделать их независимо подключаемыми.

ReplicationController — это механизм, основывающийся на pod API. В конечном счете планируется перевести её на общий механизм plug-in, когда он будет реализован.

Пример настройки кластера

В качестве платформы для примера настройки была выбрана Ubuntu-server 14.10 как наиболее простая для примера и, в то же время, позволяющая продемонстрировать основные параметры настройки кластера.

Для создания тестового кластера будут использованы три машины для создания нод и отдельная машина для проведения удалённой установки. Можно не выделять отдельную машину и производить установку с одной из нод.

Подготовка нод

Требования для запуска:

Установка ПО на ноды

Установку Docker можно произвести по статье в официальных источниках:

Дополнительная настройка Docker после установки не нужна, т.к. будет произведена скриптом установки Kubernetes.
Установка bridge-utils:

Добавление ssh-ключей

Выполняем на машине, с которой будет запущен скрипт установки.
Если ключи ещё не созданы, создаём их:

Копируем ключи на удалённые машины, предварительно убедившись в наличии на них необходимого пользователя, в нашем случае core.

Установка Kubernetes

Далее мы займёмся установкой непосредственно Kubernetes. Для этого в первую очередь скачаем и распакуем последний доступный релиз с GitHub:

Настройка

Для того, чтобы использовать последний, на момент написания статьи, релиз 0.17.0 необходимо заменить:

На этом настройка заканчивается и можно переходить к установке.

Установка

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

В процессе установки скрипт потребует пароль sudo для каждой ноды. По окончанию установки проверит состояние кластера и выведет список нод и адреса Kubernetes api.

Посмотрим, какие ноды и сервисы присутствуют в новом кластере:

Видим список из установленных нод в состоянии Ready и два предустановленных сервиса kubernetes и kubernetes-ro — это прокси для непосредственного доступа к Kubernetes API. Как и к любому сервису Kubernetes к kubernetes и kubernetes-ro можно обратиться непосредственно по IP адресу с любой из нод.

Запуск тестового сервиса

Для запуска сервиса необходимо подготовить docker контейнер, на основе которого будет создан сервис. Дабы не усложнять, в примере будет использован общедоступный контейнер nginx. Обязательными составляющими сервиса являются Replication Controller, обеспечивающий запущенность необходимого набора контейнеров (точнее pod) и service, который определяет, на каких IP адресе и портах будет слушать сервис и правила распределения запросов между pod’ами.

Любой сервис можно запустить 2-я способами: вручную и с помощью конфиг-файла. Рассмотрим оба.

Запуск сервиса вручную

Начнём с создания Replication Controller’а:

Далее создаём service который будет использовать наш Replication Controller как бекенд.
Для http:

Для проверки запущенности можно зайти на любую из нод и выполнить в консоли:

В выводе curl увидим стандартную приветственную страницу nginx. Готово, сервис запущен и доступен.

Запуск сервиса с помощью конфигов

Для этого способа запуска необходимо создать конфиги для Replication Controller’а и service’а. Kubernetes принимает конфиги в форматах yaml и json. Мне ближе yaml поэтому будем использовать его.

Предварительно очистим наш кластер от предыдущего эксперимента:

Был создан Replication Controller с именем nginx и количеством реплик равным 6. Реплики в произвольном порядке запущены на нодах, местоположения каждой pod’ы указано в столбце HOST.

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

Для проверки запущенности можно зайти на любую из нод и выполнить в консоли:

В выводе curl увидим стандартную приветственную страницу nginx.

Заметки на полях

В качестве заключения хочу описать пару важных моментов, о которые уже пришлось запнуться при проектировании системы. Связаны они были с работой kube-proxy, того самого модуля, который позволяет превратить разрозненный набор элементов в сервис.
PORTAL_NET. Сущность сама по себе интересная, предлагаю ознакомиться с тем, как же это реализовано.
Недолгие раскопки привели меня к осознанию простой, но эффективной модели, заглянем в вывод iptables-save:

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

Источник

Что такое Kubernetes?

Kubernetes — это платформа с открытым исходным кодом для управления кластером контейнерных приложений и сервисов, которую часто называют операционной системой для облака. Платформа Kubernetes была разработана инженерами Google Джо Беда (Joe Beda), Бренданом Бернсом (Brendan Burns) и Крейгом Маклакки (Craig McLuckie) в 2014 году, вскоре после этого ее исходный код стал открытым, а сама она превратилась в самостоятельную cloud native экосистему. Сегодня Kubernetes, что на древнегреческом означает «рулевой» или «пилот», управляется фондом Cloud Native Computing Foundation (CNCF), частью проекта Linux Foundation.

Kubernetes стал первым законченным проектом для CNCF и одним из самых быстрорастущих проектов с открытым исходным кодом в истории. К настоящему моменту Kubernetes насчитывает более 2300 участников и широко используется как крупными, так и мелкими компаниями, а также половиной списка Fortune 100.

Основы Kubernetes—Основные термины

Для начала познакомимся с несколькими основными терминами, связанными с Kubernetes. Более подробный список представлен на странице глоссария стандартных терминов по Kubernetes. Можно также воспользоваться Памяткой по Kubernetes, содержащей список популярных флагов и команд kubectl.

Кластер

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

Виртуальная или физическая машина. Кластер состоит из главного узла и нескольких рабочих узлов.

Облачный контейнер

Образ, содержащий программное обеспечение и его зависимости.

Модуль

Один контейнер или набор контейнеров, работающих в кластере Kubernetes.

Развертывание

Объект, управляющий реплицированными приложениями, которые представлены модулями. Модули развертываются на узлах кластера.

Набор реплик

Обеспечивает одновременное выполнение определенного количества реплик модулей.

Сервисы

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

Что такое KubeCon?

KubeCon — это ежегодная конференция разработчиков и пользователей Kubernetes. Со времени первой конференции KubeCon, прошедшей в 2015 году и собравшей 500 участников, KubeCon стала важным событием для сообщества разработчиков облачных технологий. В 2019 году команда KubeCon в Сан-Диего, штат Калифорния, собрала 12 000 разработчиков и инженеров по обеспечению надежности сайтов для проведения мероприятия, посвященного созданию экосистемы с открытым исходным кодом на базе платформы облачной оркестрации Kubernetes.

Что такое контейнеры Kubernetes?

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

Сравнение Kubernetes и Docker

Из каких компонентов состоит Kubernetes?

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

Плоскость управления включает следующие компоненты.

Компоненты узла включают следующее.

Какие преимущества дает Kubernetes?

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

Возможности, которые Kubernetes дает компаниям:

Какие проблемы возникают при использовании Kubernetes?

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

Kubernetes развертывает контейнеры, а не исходный код и не создает приложения. Для ведения журналов, промежуточного программного обеспечения, мониторинга, настройки, CI/CD и многих других производственных операций требуются дополнительные инструменты. Тем не менее платформа Kubernetes является расширяемой и доказала свою эффективность в самых разных сценариях использования — от реактивных самолетов до машинного обучения. Фактически поставщики облачных решений, включая Oracle, Google, Amazon Web Services и другие, используют собственную расширяемость Kubernetes для создания управляемых Kubernetes, которые представляют собой сервисы для снижения сложности и повышения продуктивности разработчиков.

Что такое управляемый Kubernetes?

Oracle Cloud Infrastructure Container Engine for Kubernetes — это удобный для разработчиков управляемый сервис, который можно использовать для развертывания контейнерных приложений в облаке. Используйте Container Engine for Kubernetes, если Ваша команда разработчиков хочет надежно создавать, развертывать cloud native приложения и управлять ими. Вы указываете вычислительные ресурсы, которые требуются Вашим приложениям, а Oracle Container Engine for Kubernetes предоставляет их в существующей арендованной облачной инфраструктуре Oracle.

Несмотря на то что Вам необязательно использовать управляемый сервис Kubernetes, решение Oracle Cloud Infrastructure Container Engine for Kubernetes — это простой способ запустить высокодоступные кластеры с контролем, безопасностью и предсказуемой производительностью Oracle Cloud Infrastructure. Container Engine for Kubernetes поддерживает как системы без виртуализации, так и виртуальные машины как узлы, и сертифицирован соответствующим образом организацией CNCF. Вы также получаете все обновления Kubernetes, и совместимость с экосистемой CNCF обеспечивается без каких-либо дополнительных действий с Вашей стороны.

Cloud Native и Kubernetes меняют подход AgroScout к поддержке разработчиков.

Источник

Как правильно сделать Kubernetes (обзор и видео доклада)

В конце мая «Флант» участвовал в конференции DevOpsConf 2021, которая наконец-то вернулась в offline, пусть и с некоторыми ограничениями. Я выступил с докладом о том, как делать Kubernetes так, чтобы были довольны все: разработчики, инженеры и бизнес.

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 человек.

За это время я, конечно, не только научился работать с Linux, контейнерами, Kubernetes и другими технологиями. Я стал разбираться в том, как управлять командами, как строить бизнес и создавать продукты. И, как мне кажется, понял, как правильно делать Kubernetes — одновременно с точки зрения бизнеса, построения команд и применения правильных технологий.

Что такое 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 — это отличное средство коммуникации.

Разницу между привычными инструментами DevOps-инженеров и Kubernetes можно сравнить с разницей между языками Assembler и C. Что принес С? Более высокоуровневые конструкции и, главное, возможность не думать про «железо», про те же процессоры, например. Про «железо» за нас думает компилятор С.

Другая аналогия: «железо» и стандарты 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 («Опыт разработчика»). Платформенная команда должна делать так, чтобы разработчикам было как можно более комфортно.

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

Эксперты 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.

ОБНОВЛЕНО! Поскольку многие нас спрашивали, айсберг из этого доклада мы выложили отдельно в хорошем разрешении: PNG, SVG.

Вот «Флант» уже занимается такими вещами, но надо ли это вам?

По сути, 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 до публичных провайдеров и приватных облаков).

Когда вы используете готовое решение — главное, чтобы была готова большая часть корабля. Кроме K8s, это настроенный CI/CD, наблюдаемость (observability), безопасность и service mesh.

Может возникнуть вопрос: но откуда тогда брать дофамин, если мы используем готовое решение? Ответ: соблюдать баланс между новым-интересным и пользой для бизнеса. И здесь помогает правильный фокус.

Правильный фокус — developer experience

Он формируется за счет четырех направляющих:

Упрощение платформы. Каждый разработчик, каждая продуктовая (stream-aligned) команда должна максимально полно понимать, как ей деплоить и как получать обратную связь с помощью платформы.

Интеграция всех используемых технологий и сервисов друг с другом. Это гигантский объем интересных задач.

Research. Вы должны знать, что будет завтра для того, чтобы быть к этому готовым.

Guidance. То есть руководства, чтобы всем этим управлять.

Когда вы выполняете четыре эти задачи сами, у вас всё хорошо с поиском нового, с исследованиями; у вас всегда много интересной работы. Всё остальное лучше покупать.

В начале я говорил, что мой доклад называется «Как правильно сделать Kubernetes». На самом деле настоящее название доклада: «Перестаньте “делать” Kubernetes. Используйте его». Потому что самая большая ценность Kubernetes — в том, чтобы им пользоваться.

В завершение добавлю, что наша платформа Deckhouse помогает использовать Kubernetes и закрывает все сопутствующие потребности: CI/CD, observability, security и service mesh. Ранний доступ к ней — см. на сайте проекта и в Telegram-чате.

Источник