Kubernetes пугает аббревиатурами и YAML-простынями, но в основе лежит одна понятная идея: вы описываете, каким хотите видеть приложение, а кластер сам приводит реальность к этому состоянию. Для разработчика не нужно знать K8s как DevOps - достаточно понимать слои и уметь читать манифесты. Эта статья объясняет Kubernetes по уровням: от контейнера до работающего в проде сервиса.
Коротко:
- Kubernetes - оркестратор контейнеров: запускает, масштабирует и лечит их сам.
- Базовые сущности: Pod, Deployment, Service, Ingress, ConfigMap/Secret.
- Главный принцип - декларативность: вы описываете желаемое состояние, кластер его поддерживает.
- Разработчику нужно понимать слои и манифесты, а не администрировать кластер.
Зачем вообще Kubernetes
Когда приложение - это десятки контейнеров на нескольких машинах, кто-то должен решать: где их запускать, что делать при падении, как обновлять без простоя, как раздавать трафик. Вручную это ад. Kubernetes автоматизирует оркестрацию: следит, чтобы нужное число копий приложения работало, перезапускает упавшие, распределяет по узлам, катит обновления.
Ключевая идея - декларативность. Вы не командуете «запусти контейнер здесь». Вы описываете желаемое состояние («хочу 3 копии этого приложения»), а Kubernetes постоянно сравнивает желаемое с реальным и устраняет разницу. Упал под - поднимет новый. Это называется reconciliation loop.
Слой 1. Контейнер и Pod
В основе лежит контейнер (обычно Docker-образ): ваше приложение со всеми зависимостями. Kubernetes не запускает контейнеры напрямую - он оборачивает их в Pod, минимальную единицу развёртывания. Под обычно содержит один контейнер (иногда несколько тесно связанных), у него свой IP, он эфемерен: упал - заменяется новым, а не чинится.
Под - это «одна работающая копия приложения». Но управлять подами напрямую не стоит - для этого есть слой выше.
Слой 2. Deployment: управление копиями
Deployment описывает, как запускать и поддерживать ваше приложение: сколько копий (реплик), какой образ, как обновлять. Вы говорите «хочу 3 реплики версии 1.2», Kubernetes создаёт и держит 3 пода. Упал один - Deployment поднимет замену. Выкатываете новую версию - Deployment плавно заменит поды (rolling update) без простоя, а при проблеме можно откатиться.
Это рабочая лошадка: 90% времени разработчик имеет дело именно с Deployment.
Слой 3. Service: стабильный адрес
Поды эфемерны, их IP меняются. Чтобы к приложению можно было обращаться стабильно, есть Service - постоянная точка входа, которая балансирует трафик между подами одного Deployment. Один сервис обращается к другому по имени Service, не зная, на каких подах тот живёт сейчас. Service решает проблему «как найти приложение, если поды постоянно меняются».
Слой 4. Ingress: трафик снаружи
Service открывает доступ внутри кластера. Чтобы пустить трафик из интернета и разрулить его по доменам/путям, используют Ingress - правила маршрутизации HTTP(S) на нужные сервисы, с TLS. Условно: запрос на api.example.com Ingress направит на сервис API, а запрос на app.example.com - на фронтенд.
Слой 5. Конфигурация и секреты
Приложению нужны настройки и пароли, и зашивать их в образ нельзя. Для этого есть:
- ConfigMap - несекретная конфигурация (URL, флаги, параметры).
- Secret - чувствительные данные (пароли, ключи, токены), хранятся отдельно.
Они подключаются к подам как переменные окружения или файлы. Это разделяет код и конфигурацию - один образ работает в dev и prod с разными настройками.