Насколько знаком с Kubernetes на уровне пользователя

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

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

Как отвечать

Назовите уровень честно и покажите рабочий набор. Диагностика: kubectl get pods, kubectl describe pod (события объясняют Pending, ImagePullBackOff, CrashLoopBackOff), kubectl logs --previous для упавшего контейнера, kubectl port-forward и kubectl exec для проверки руками.

Объекты, которые нужны пользователю:

• Pod: единица запуска, сам по себе не восстанавливается;
• Deployment: катит новую версию через ReplicaSet, умеет откат;
• Service: стабильный адрес и балансировка на поды по селектору меток;
• ConfigMap и Secret: конфигурация и чувствительные значения снаружи образа;
• Ingress: вход снаружи кластера.

Дальше то, что касается именно вашего кода: readiness и liveness пробы, requests и limits, поведение при SIGTERM. Go-сервис должен закрывать http.Server через Shutdown, отменять context фоновых задач и укладываться в terminationGracePeriodSeconds.

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

Отвечают как администратор: рассказывают про etcd, kubelet и установку кластера, но не могут объяснить, почему собственный под перезапускается по кругу. Спрашивают ровно про пользовательскую диагностику.

Путают пробы. Liveness перезапускает контейнер, readiness лишь убирает под из эндпоинтов Service. Liveness, который ходит в базу, при её недоступности перезапускает всё приложение вместо того, чтобы просто снять с него трафик.

Игнорируют лимиты. Превышение памяти заканчивается OOMKilled и перезапуском, а превышение CPU только троттлингом: сервис не падает, но отвечает медленно. Это разные симптомы, и их часто называют одним словом «упало».