Как диагностировать проблемы с DNS внутри Kubernetes-кластера, если приложение не может резолвить имя другого сервиса?

Короткий ответ

Диагностику начинают с проверки, резолвится ли имя вообще из отладочного пода (nslookup/dig на <service>.<namespace>.svc.cluster.local), затем проверяют статус подов CoreDNS (kube-system), их логи на ошибки, и конфигурацию /etc/resolv.conf внутри проблемного пода — несовпадение search domain или временная перегрузка CoreDNS часто остаются незамеченными при поверхностной проверке.

Как это работает подробнее

каждый под по умолчанию получает resolv.conf с nameserver, указывающим на ClusterIP сервиса CoreDNS, и search-путями, достраивающими короткие имена до полного FQDN (svc.cluster.local и т.п.). Если CoreDNS перегружен, его поды падают, либо NetworkPolicy блокирует трафик к порту 53 — резолвинг начинает сбоить случайным образом, что внешне похоже на "нестабильную сеть".

Пример кода

Команды и выводКопировать

kubectl run -it --rm debug --image=busybox:1.36 -- sh
/ # nslookup backend.prod.svc.cluster.local
/ # nslookup backend

Что использовать на практике

• Практика. полезно сравнить поведение короткого имени (backend) и полного FQDN (backend.prod.svc.cluster.local) — если полное имя резолвится, а короткое нет, проблема в search-путях или в том, что под запущен не в том namespace, где ожидается. Для перегруженного CoreDNS проверяют метрики задержки и количество реплик — при большом числе подов в кластере может требоваться горизонтальное масштабирование CoreDNS или включение NodeLocal DNSCache для снижения нагрузки.

Подводные камни

• Риски. считать любую проблему с подключением "сетевой проблемой" и не проверять именно DNS отдельно от TCP-соединения; не учитывать, что NetworkPolicy, разрешающая доступ к backend-сервису, но блокирующая egress на порт 53 в kube-system, ломает резолвинг имени этого же сервиса; игнорировать логи CoreDNS, где могут быть прямые сообщения о таймаутах upstream DNS или перегрузке.