Насколько глубоко вы погружались в Kubernetes и через какие инструменты его использовали

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

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

Как отвечать

Назовите свой уровень честно, а потом покажите практический минимум:

• kubectl get pods и статусы: CrashLoopBackOff, ImagePullBackOff, Pending, OOMKilled, и что каждый из них означает;
• kubectl describe pod для событий: не хватило ресурсов на узле, не примонтировался том, не прошла проба;
• kubectl logs и обязательно логи предыдущего запуска, иначе после перезапуска причина падения теряется;
• kubectl port-forward для доступа к сервису в обход внешнего маршрута и exec для проверки конфигурации внутри контейнера.

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

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

Заводят баг с формулировкой «приложение не работает», не открыв события и логи. ImagePullBackOff это проблема доступа к реестру образов, а не дефект кода, и такой баг вернётся с пометкой о невоспроизводимости.

Второе: тестируют не ту версию. Тег образа остался прежним, под не перевыкатился, проверяется старая сборка, а дефект уже починен. Привычка сверять версию до начала проверки экономит часы.

Третье: перечисляют Prometheus, Grafana и Helm как опыт, а на просьбу показать логи упавшего пода ответа нет. Лучше назвать узкий набор команд, которыми реально пользуетесь каждый день.