Сценарий: под Running, но сервис не отвечает
Вопрос
Все поды Running и 1/1, но пользователи получают 502 и таймауты через Ingress. Как будешь разбираться?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Уточнить: все запросы или часть, с какого времени, что менялось
Логи Ingress-контроллера: на какой апстрим идут запросы и какой ответ
Service и EndpointSlice: есть ли адреса, совпадает ли `targetPort`
Из отладочного пода: `curl` на сервис и напрямую на IP пода, DNS, NetworkPolicy
Внутри приложения: метрики, задержки зависимостей, троттлинг CPU, пулы соединений
Узлы: kube-proxy/CNI, conntrack, проблемы конкретного узла
Что могут спросить следом
- Чем 502 отличается от 504 на Ingress?
- Почему readiness может «врать»?
Разбор
Сначала уточняю масштаб: все запросы падают или часть, с какого момента, что деплоили. Затем иду по пути запроса. Логи Ingress-контроллера покажут, на какой апстрим ушёл запрос и что вернулось: 502 обычно значит, что соединение с подом не установилось или оборвалось, 504 что под не ответил вовремя. Проверяю Service и EndpointSlice: есть ли адреса, совпадает ли targetPort с портом приложения. Из отладочного пода делаю curl на имя сервиса и напрямую на IP пода: если напрямую работает, а через сервис нет, смотрю NetworkPolicy и kube-proxy или CNI. Если поды отвечают медленно, иду внутрь: метрики приложения, задержки базы и внешних API, исчерпанные пулы соединений, троттлинг CPU. Readiness при этом может «врать», если она проверяет только то, что процесс жив, а не способность обслуживать запросы. Если ошибки только с части подов, ищу общий узел: проблемы конкретного узла, заполненная таблица conntrack, сетевой плагин.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.