Используете ли Kubernetes для деплоя проектов

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

Какая у вас была роль: писали ли вы манифесты и чарты сами или только запускали пайплайн. Следом обычно спрашивают, как были настроены пробы, как проходили миграции базы при выкатке и что происходит с запросами при остановке пода.

Как отвечать

Сначала честно обозначьте уровень: «сервисы жили в Kubernetes, я писал Dockerfile и values для Helm-чарта, кластер вела платформенная команда». Потом покажите, как ваше Python-приложение там живёт:

• объекты: Deployment с репликами, Service и Ingress для трафика, ConfigMap и Secret для конфигурации, Job и CronJob для разовых и периодических задач;
• пробы: readinessProbe решает, слать ли трафик в под, livenessProbe решает, перезапускать ли его, startupProbe даёт время медленному старту;
• ресурсы: requests влияют на размещение пода, limits на троттлинг CPU и OOMKilled по памяти. Число воркеров gunicorn или uvicorn считайте от лимита: os.cpu_count() видит ядра узла, а не контейнера;
• выкатка: rolling update с maxSurge и maxUnavailable. При остановке под получает SIGTERM и по умолчанию 30 секунд на завершение, приложение должно дообработать текущие запросы;
• миграции: alembic upgrade head или manage.py migrate запускают отдельным Job или хуком Helm, а не при старте каждого пода, иначе реплики конкурируют за одну схему.

Celery-воркеры обычно живут отдельным Deployment, и масштабируют их по длине очереди, например через KEDA, а не по CPU.

Если Kubernetes не было, так и скажите и расскажите, как деплоили: docker compose на виртуалке, systemd, PaaS. Покажите, какие проблемы Kubernetes решил бы в вашем случае.

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

Говорят, что Kubernetes масштабирует сам. Для этого нужен настроенный HorizontalPodAutoscaler, источник метрик и заданные requests.

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

Запускают в поде столько воркеров, сколько ядер у узла, и получают OOMKilled или постоянный троттлинг.