# DNS в Pod отвечает медленно: search domains и ndots

Диагностика: DNS в Pod отвечает медленно: search domains и ndots. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kubernetes-dns-ndots-search-latency/
Language: ru

Медленный DNS lookup внутри Pod может возникать из-за search domains и ndots, даже когда сетевой маршрут исправен. Проверьте фактический /etc/resolv.conf и последовательность запросов. Задержку разрешения имени следует отделять от времени соединения и выполнения GPU-задачи.

## Сохраните resolver конкретного Pod

Получите dnsPolicy, dnsConfig и содержимое resolv.conf из нужной среды. У hostNetwork и обычного Pod могут различаться правила. Сравните короткое имя сервиса, полное DNS-имя и имя внешней зависимости. Не переносите результат nslookup на хосте непосредственно внутрь контейнера: search list, nameservers и библиотека resolver могут отличаться. Зафиксируйте также namespace, поскольку короткое имя Service получает контекст именно этой области, а не всего кластера без ограничений.


[Официальный источник 1](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/).

## Разберите роль ndots

Ndots влияет на выбор порядка поиска имени с определённым количеством точек относительно search list. При длинном списке suffix resolver может выполнять несколько запросов прежде, чем обратиться к ожидаемому внешнему имени. Поведение зависит и от используемой библиотеки, поэтому одно число в файле не доказывает реальную последовательность. Смотрите запросы и ответы через разрешённые средства наблюдения. Полностью квалифицированная запись с завершающей точкой полезна в контролируемом опыте, но пригодность для приложения проверяют отдельно.


[Официальный источник 2](https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/).

## Сравните одинаковую зависимость

В учебном тесте worker обращается к artifact.example.org, а resolv.conf содержит несколько cluster search domains и ndots 5. Сначала измеряется lookup из приложения, затем тот же адрес с полностью квалифицированной формой в диагностическом инструменте. Число 5 здесь отражает пример конфигурации, не универсальную причину или рекомендацию. Сохраните количество запросов, коды ответов и длительности, чтобы отличить дополнительные NXDOMAIN от ожидания недоступного DNS-сервера.

| Проверка | Наблюдаемое различие |
| --- | --- |
| Короткое имя | Учитывает namespace и suffix |
| Полное имя | Меньше неоднозначности назначения |
| Resolver Pod | Реальная конфигурация workload |
| Resolver хоста | Отдельная область сравнения |

## Меняйте DNS policy адресно

Исправьте некорректный search list, dnsPolicy или обращение приложения, если причина подтверждена. Не задавайте всем Pod минимальное ndots только по одному внешнему запросу: короткие внутренние имена могут начать вести себя иначе. Если запросы доходят быстро, но ответ задерживается, исследуйте CoreDNS и upstream. Если проблема только в одном бинарном образе, сравните resolver implementation. Изменение timeout соединения приложения не устраняет лишнюю цепочку DNS lookup до самого соединения.

## Проверьте оба класса имён

После изменения повторите внешнюю зависимость и внутренний Service lookup из нового Pod с тем же образом. Сохраните resolv.conf, query sequence и измерение отдельной DNS стадии. Успех должен включать ожидаемое разрешение имён без ухудшения нужных внутренних обращений. Артефакт связывает configuration scope и наблюдаемое поведение. Он позволяет после обновления образа проверить resolver заново, не приписывая DNS задержку производительности GPU или вычислительному движку.

Связанные разборы: [network and uptime](/ru/journal/network-and-uptime/); [vllm localhost container port](/ru/journal/vllm-localhost-container-port/).