Использовали ли Kubernetes для разворачивания инфраструктуры

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

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

Как отвечать

Сначала честно обозначьте роль: кластер поднимали вы, DevOps-команда или это был управляемый сервис в облаке. Потом то, чего вы касались сами:

• образ: Dockerfile для сервиса на FastAPI или Django, многоэтапная сборка, slim-образ, запуск не от root;
• манифесты: Deployment (он сам управляет ReplicaSet, руками их не пишут), Service, Ingress, конфигурация через ConfigMap и Secret;
• пробы: readinessProbe не пускает трафик, пока приложение не готово, livenessProbe перезапускает зависший контейнер;
• ресурсы и масштабирование: requests и limits, HorizontalPodAutoscaler, отдельный Deployment для воркеров Celery;
• жизненный цикл: корректная обработка SIGTERM, миграции отдельным Job до выкатки, а не при старте каждого пода;
• доставка: Helm-чарт или Kustomize, пайплайн в GitLab CI или GitHub Actions, GitOps через Argo CD.

Приведите свой случай: под падал с OOMKilled из-за роста памяти на больших файлах, или деплой отдавал ошибки, пока не настроили readiness. Цифры берите свои.

Если работали только как пользователь кластера, так и скажите: смотрели логи через kubectl logs, пробрасывали порт через kubectl port-forward, правили values в чарте. Для разработчика это нормальный опыт, и честно он звучит лучше приукрашенного.

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

Говорят «настраивал кластер», а на вопросе про пробы или сеть выясняется, что всё делала другая команда.

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

Рассказывают шаблонную историю про рост производительности на 30% без объяснения, откуда цифра и что именно изменилось.