Как настраивать Kubernetes для деплоя микросервисов

Что проверяют

Деплоили ли вы сами или только видели готовые манифесты. Интервьюеру важно, понимаете ли вы, что нужно приложению, чтобы Kubernetes мог безопасно его запускать, обновлять и масштабировать. Следом спрашивают про пробы, graceful shutdown и миграции базы.

Как отвечать

Опишите минимальный набор объектов на один сервис:

• Deployment: реплики, образ с конкретным тегом или digest, стратегия RollingUpdate с maxSurge и maxUnavailable (по умолчанию по 25%);
• Service: стабильное имя и балансировка внутри кластера, обычно ClusterIP. Наружу выводят через Ingress или Gateway API;
• ConfigMap и Secret: настройки через переменные окружения, а не зашитые в образ;
• requests и limits: без requests планировщик не знает, куда ставить под, а HPA не посчитает загрузку CPU в процентах;
• пробы: readinessProbe решает, слать ли трафик, livenessProbe решает, перезапускать ли контейнер, startupProbe даёт время медленному старту;
• HPA и PodDisruptionBudget: автомасштабирование и защита от одновременного выселения всех реплик.

Потом то, что специфично для Python. Число воркеров gunicorn или uvicorn согласуйте с CPU в requests, иначе процессы дерутся за квоту. Обрабатывайте SIGTERM: после него Kubernetes ждёт terminationGracePeriodSeconds (30 секунд по умолчанию) и убивает процесс, так что воркер должен успеть дописать текущие запросы. Миграции Alembic или Django запускайте отдельным Job или шагом пайплайна, а не при старте каждой реплики. Манифесты шаблонизируют Helm или Kustomize, применяет их CI или GitOps через Argo CD либо Flux.

Где спотыкаются

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

Делают livenessProbe, которая проверяет базу. База притормозила, Kubernetes перезапускает все поды разом, и заминка становится аварией.

Считают Secret зашифрованным. По умолчанию это base64, а шифрование в etcd и ограничение доступа через RBAC настраиваются отдельно.