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

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

Глубину, а не факт знакомства. Разница между тем, кто выполняет подсказанные команды, и тем, кто понимает, как его сервис живёт внутри кластера. Для Go это особенно предметно: часть проблем в кластере решается не манифестом, а поведением самого приложения при старте, выкатке и остановке.

Как отвечать

Разложите по слоям и честно отметьте границу своих знаний.

• что деплоили: Deployment для бесстатусных сервисов, StatefulSet там, где нужен стабильный идентификатор и диск;
• чем описывали: Helm-чарты или оверлеи Kustomize, где лежат значения для разных сред;
• конфигурация: ConfigMap и Secret, переменные окружения против монтирования файлом;
• наблюдаемость: метрики, логи в stdout, разбор падений через describe и логи предыдущего запуска.

Дальше Go-специфика, она и отличает сильный ответ. Readiness и liveness это разные пробы с разным смыслом: первая убирает под из балансировки на время недоступности зависимостей, вторая перезапускает контейнер. Приложение должно ловить SIGTERM, переставать принимать новые запросы и дожидаться текущих внутри отведённого на остановку времени. Про ресурсы: рантайм по умолчанию ориентируется на число ядер узла, а не на лимит CPU контейнера, поэтому число процессоров задают явно; память Go возвращает системе не сразу, и при заниженном лимите контейнер получает OOMKilled.

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

Вешают одну и ту же проверку на liveness и readiness. Зависимость притормозила, readiness справедливо выключил бы под из балансировки, но вместо этого срабатывает перезапуск, и сервис входит в цикл рестартов под нагрузкой.

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

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