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

Мы пообщались с Павлом Селивановым, архитектором Yandex Cloud, и написали эту короткую статью. Расскажем, какие возможности есть у K8s, как увидеть в нём что-то большее, чем простую «запускалку контейнеров» и как это пригождается на практике. Статья будет полезна тем, кто глубоко не разбирается в Kubernetes, но хочет узнать больше о его возможностях.

Подробнее обо всём этом мы рассказываем на курсе «Kubernetes База: стартовый курс для администраторов». Если заинтересуетесь, приходите к нам учиться.

Какие задачи по работе с контейнерами решает Kubernetes в умелых руках

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

Доставка трафика внутри кластера и маршрутизация между контейнерами. При создании Kubernetes выделяет контейнеру IP-адрес, чтобы он мог «общаться» с другими контейнерами. Кроме того, существует такая абстракция, как сервис — просто зная имя сервиса, приложения внутри кластера могут обращаться друг к другу и обмениваться данными.

Доставка трафика снаружи кластера. Часто к запущенному на серверах приложению нужно обеспечить доступ какому-нибудь внешнему пользователю. K8s решает и этот вопрос с помощью Ingress.

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

Взаимодействие контейнеров между собой. По умолчанию все контейнеры в кластере открыты и могут свободно взаимодействовать друг с другом, что не безопасно. Без Kubernetes нужно применять файрвол или iptables, открывать отдельные порты на нодах и серверах и только к нужным ресурсам. В K8s iptables напрямую не используется, зато есть встроенные сетевые политики, которые позволяют контейнерам обращаться только к конкретным внешним ресурсам или другим контейнерам. Также можно настроить взаимодействие между неймспейсами — например, запретить стейджевым ходить в продовые и наоборот.

Хранение данных. Контейнеры — достаточно эфемерная штука, не рассчитанная на долгосрочное хранение данных. Чтобы это исправить, у Kubernetes есть Container Storage Interface, который позволяет подключать к контейнерам конкретные тома для считывания или записи данных. Причём если контейнер вдруг переедет на другую ноду, том с данными переедет за ним — K8s всё сделает сам.

Хранение и распространение конфигов. Когда нужно запустить несколько инстансов одного и того же приложения, на каждый приходится доставлять один и тот же конфиг. Причём так, чтобы при изменении он обновился на уже запущенных инстансах. У Kubernetes для этой задачи есть инструмент Configmap, который всё делает автоматически.

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

Kubernetes для управления инфраструктурой

Управление контейнерами — далеко не всё, что может K8s. Кроме подов, деплойментов и сервисов в его документации описано множество других объектов, с помощью которых можно управлять всей инфраструктурой приложения. Например, существуют следующие объекты:

• Statefulset, который позволяет запустить то, что имеет состояние, то есть stateful-приложение.

• Jobs, для запуска процесса, который должен выполниться один раз, допустим, миграции на базу данных. 

• Cron Jobs, для запуска процессов по расписанию.

Для большинства специфичных задач в Kubernetes уже есть готовые объекты и инструменты, а если нет — их можно привнести благодаря CRD, Custom Resource Definition. Это специальный ресурс в K8s, который позволяет вносить любые данные.

Получается, в Kubernetes можно полностью описать всё приложение. Тогда почему бы не пойти дальше и не передать ему ещё и управление всеми объектами облака? Для этого существует проект Crossplane, который позволяет все объекты облака превратить в объекты Kubernetes  — сделать объектами виртуальные машины, сеть, подсети, менеджер базы данных и все, что там есть.

Crossplane позволяет создавать виртуальные машины и сети так же, как поды или деплойменты. Kubernetes берёт предоставленное описание, внутри K8s запускается Crossplane, который идёт в облако и создаёт всё, что нужно. Таким образом Crossplane становится центральным источником управления вообще всей инфраструктурой.

При этом если нужно управлять чем-то специфическим, а в Kubernetes оператора для этого нет — его можно создать. Мы разбирали, как это сделать, на открытом вебинаре «Kubernetes-оператор за час», на примере создания кастомного ресурса для команд.

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

Почему весь мир ещё не перешёл на Kubernetes

Лучше всего K8s работает там, где есть активная продуктовая разработка с командой разработчиков, которая постоянно создаёт новые сервисы или улучшает существующие. В компании с простой CRM для работы, 1С для бухгалтерии и сайтом команде админов Kubernetes для работы не пригодится.

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

Ещё есть компании, в которых много legacy-инструментов. У них всё уже настроено и в целом стабильно работает на каких-нибудь скриптах. Конечно, на поддержку и модернизацию этого может уходить много времени, но тут всё индивидуально, и, возможно, им Kubernetes не нужен.

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

В некоторых случаях помогает взять managed-Kubernetes в облаке — он уже развёрнут, настроен, и управлять им достаточно просто. Но его возможностей может не хватить, если есть специфичные задачи или по какой-то причине компания не может использовать облака. В таком случае нужен собственный Kubernetes, и понадобится команда инженеров, которая будет его поддерживать.

Kubernetes хорош именно тем, что он стандартный. Если прийти на новое рабочее место и увидеть там K8s — сразу станет понятно, что и как работает, не придётся полгода разбираться в самописных инструментах и костылях.

Плюсы перехода на Kubernetes и его изучения для IT-специалистов

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

Кроме того, сегодня знание Kubernetes — это пропуск в крупные компании и на интересные вакансии. Именно знание K8s обычно требуют в вакансиях высокооплачиваемых DevOps-специалистов.