Kubernetes для backend-разработчика
Kubernetes для backend-разработчика: что важно понимать в первую очередь
Kubernetes не обязательно знать на уровне DevOps-инженера, чтобы быть сильным backend-разработчиком.
Но если сервисы живут в Kubernetes, разработчику важно понимать хотя бы базовую механику: как приложение запускается, получает трафик, перезапускается и умирает.
Вот минимальный набор, который реально влияет на production.
1. Pod - это не «сервер»
Pod - минимальная единица запуска в Kubernetes.
Внутри обычно один контейнер с приложением. Иногда несколько, если нужен sidecar: например, прокси, агент логирования или helper-процесс.
Важно: pod временный. Он может быть пересоздан, переехать на другую ноду, получить новый IP.
Поэтому не стоит относиться к pod как к постоянной машине.
2. Deployment управляет количеством pod
Deployment описывает, сколько копий приложения должно работать и какую версию контейнера нужно запускать.
Если pod упал, Kubernetes создаст новый.
Если выкатываем новую версию, Deployment постепенно заменит старые pod на новые.
Но Kubernetes не знает, безопасна ли новая версия. Он просто выполняет правила, которые мы ему дали.
3. Service даёт стабильную точку входа
Pod могут пересоздаваться и менять IP.
Service нужен, чтобы другие части системы обращались не к конкретному pod, а к стабильному адресу.
Условно: приложение не ходит в pod-123, оно ходит в user-service.
А Kubernetes уже распределяет трафик между подходящими pod.
4. Readiness probe отвечает на вопрос: «можно ли давать трафик?»
Сервис может быть запущен, но ещё не готов:
- не прогрел cache;
- не подключился к базе;
- не применил миграции;
- не загрузил конфигурацию;
- находится в graceful shutdown.
Readiness probe должна показывать именно готовность принимать запросы.
Если readiness = false, Kubernetes убирает pod из балансировки.
5. Liveness probe отвечает на вопрос: «контейнер надо перезапустить?»
Liveness нужна, чтобы Kubernetes понял: процесс завис или сломался так, что сам уже не восстановится.
Но её нельзя делать слишком агрессивной.
Если liveness падает при любой краткой проблеме с базой или внешним API, Kubernetes начнет рестартить контейнеры, хотя проблема не в приложении.
И вместо восстановления можно получить restart loop.
6. Requests и limits помогают планировать ресурсы
Requests - сколько CPU/RAM контейнеру нужно для нормальной работы.
Limits - верхняя граница, за которую контейнеру нельзя выходить.
Если не задавать requests, scheduler хуже понимает, куда размещать pod.
Если неправильно задать memory limit, можно получить OOMKilled: контейнер превысил лимит памяти и был убит.
Для backend-сервисов это особенно важно под нагрузкой.
7. Graceful shutdown нужен для нормальных деплоев
При деплое Kubernetes отправляет контейнеру сигнал завершения.
Приложение должно успеть:
- перестать принимать новые запросы;
- завершить текущие;
- закрыть подключения;
- сохранить состояние, если это нужно.
Если этого нет, rolling update может приводить к обрывам запросов и странным ошибкам у пользователей.
8. Масштабирование работает только для stateless-сервисов
Если сервис хранит важное состояние в памяти, масштабирование до нескольких pod может сломать логику.
Примеры риска:
- in-memory cache без общей стратегии;
- локальные очереди;
- хранение пользовательской сессии в памяти;
- фоновые задачи без распределенной координации.
Kubernetes легко запустит 5 реплик.
Но он не сделает приложение stateless автоматически.
Главная мысль
Для backend-разработчика Kubernetes - это не просто YAML.
Это среда, в которой нужно проектировать поведение сервиса:
- как он стартует;
- когда он готов;
- как принимает трафик;
- что делает при ошибках;
- как завершается;
- сколько ресурсов потребляет;
- можно ли его масштабировать.
Если понимать эти вещи, Kubernetes становится не магией DevOps-команды, а нормальной частью backend-инженерии.
