Есть ли у вас опыт работы с Helm, манифестами и шаблонами для Kubernetes

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

Понимаете ли вы, как ваш Python-сервис попадает в кластер, а не только то, что Helm «как-то деплоит». Бэкендеру не обязательно быть DevOps-инженером, но чарт своего сервиса он должен уметь прочитать и поправить. Следом обычно спрашивают, как выкатываются миграции и как откатить неудачный релиз.

Как отвечать

Если опыт есть, опишите его через устройство чарта и жизненный цикл релиза:

• структура: Chart.yaml с метаданными и версией, values.yaml с настройками по умолчанию, templates/ с манифестами на шаблонах Go, общие куски в _helpers.tpl;
• окружения: отдельные values-staging.yaml и values-prod.yaml передаются через -f и различаются образом, числом реплик, ресурсами;
• выкатка: helm upgrade --install с автоматическим откатом при неуспехе (в Helm 3 это --atomic), а вручную helm history и helm rollback. Перед выкаткой полезны helm lint, helm template и плагин helm diff;
• секреты: не в values.yaml в гите, а через External Secrets, Sealed Secrets или SOPS.

Дальше покажите специфику Python. Deployment для uvicorn или gunicorn с числом воркеров, согласованным с resources.limits, liveness и readiness пробы на отдельный эндпоинт здоровья, Celery-воркеры отдельным Deployment. Миграции Alembic лучше запускать отдельным Job через хук pre-upgrade или на этапе CI, а не при старте каждого пода: при трёх репликах три процесса одновременно полезут менять схему.

Если с Helm не работали, так и скажите и расскажите, что было: голые манифесты и kubectl apply, Kustomize, docker compose. Покажите, что понимаете, какую проблему Helm решает: параметризацию одних и тех же манифестов под разные окружения и историю релизов с откатом.

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

Путают роли и говорят о Helm как об оркестраторе. Helm только рендерит манифесты и ведёт историю релизов, поды запускает сам Kubernetes.

Хранят пароли в values.yaml в репозитории или рассказывают про Tiller как про действующую часть Helm. Tiller убрали ещё в третьей версии.

Не умеют отлаживать: при падении релиза не знают, что сначала смотрят отрендеренный манифест через helm template, а затем события и логи через kubectl describe и kubectl logs.