Что такое Kubernetes: объяснение для разработчика, а не для админа

Kubernetes принято либо бояться, либо считать обязательным. Разработчику при этом обычно не нужно уметь поднимать кластер: нужно понимать, как туда попадает ваш сервис, где смотреть логи и почему он перезапускается каждые две минуты.

Разберём с этой стороны.

Какую задачу решает

Есть контейнер с вашим приложением. Дальше возникают вопросы, на которые надо отвечать каждый раз заново.

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

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

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

Основные понятия

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

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

Сервис это стабильный адрес для группы подов. Поды приходят и уходят, адреса меняются, а имя сервиса остаётся.

Ингресс пускает внешний трафик внутрь: маршрутизация по доменам и путям, обычно тут же терминируется TLS.

ConfigMap и Secret хранят настройки и чувствительные данные отдельно от образа. Один и тот же образ едет во все окружения, отличаются только конфиги.

Namespace логически разделяет ресурсы: команды, окружения, проекты.

Этих шести штук хватает, чтобы понимать, что происходит с вашим сервисом.

Что должен уметь разработчик

Скромный, но обязательный набор.

Прочитать манифест своего сервиса и понять, что там написано.

Посмотреть логи пода и состояние деплоймента.

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

Настроить пробы: liveness говорит, жив ли процесс, readiness говорит, готов ли он принимать трафик. Перепутанные пробы это классическая причина бесконечных перезапусков.

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

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

Типичные грабли

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

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

Логи пишутся в файл. В кластере логи собираются из стандартного вывода. Файл внутри контейнера исчезнет вместе с ним.

Неверные лимиты памяти. Самая частая причина загадочных перезапусков.

Секреты в образе. Пароль, зашитый в контейнер, уезжает во все окружения и остаётся в истории сборок.

Нужен ли он вам

Честный ответ: не всегда.

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

Для одного сервиса на паре машин это лишняя сложность: managed-платформа или docker compose справятся, а поддерживать придётся заметно меньше.

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

Что спрашивают на собеседовании

Что такое под и чем он отличается от контейнера. Зачем нужен сервис, если у пода есть адрес. Как происходит обновление версии без простоя. Чем liveness отличается от readiness. Что произойдёт, если под превысит лимит памяти. Где хранить конфиги и секреты. Как посмотреть, почему под не стартует.

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

Про соседние темы писали отдельно: CI/CD и выкатка и HTTP как основа взаимодействия сервисов.

Как попробовать

Поднимите локальный однонодовый кластер (minikube или k3d), запустите в нём своё приложение, сломайте под специально, посмотрите логи и события. Вечер практики снимает большую часть мистики.

Проверить себя вопросами можно в Сеньорчике: блок по инфраструктуре и контейнерам входит в треки бэкенда и дата-инженерии, вопросы с реальных собеседований с разбором каждого. Движок возвращает темы, где вы ошибаетесь. Десять минут в день в Telegram, бесплатно.