В этом материале
Медленный DNS lookup внутри Pod может возникать из-за search domains и ndots, даже когда сетевой маршрут исправен. Проверьте фактический /etc/resolv.conf и последовательность запросов. Задержку разрешения имени следует отделять от времени соединения и выполнения GPU-задачи.
Медленный 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 получает контекст именно этой области, а не всего кластера без ограничений.
Разберите роль ndots
Ndots влияет на выбор порядка поиска имени с определённым количеством точек относительно search list. При длинном списке suffix resolver может выполнять несколько запросов прежде, чем обратиться к ожидаемому внешнему имени. Поведение зависит и от используемой библиотеки, поэтому одно число в файле не доказывает реальную последовательность. Смотрите запросы и ответы через разрешённые средства наблюдения. Полностью квалифицированная запись с завершающей точкой полезна в контролируемом опыте, но пригодность для приложения проверяют отдельно.
Сравните одинаковую зависимость
В учебном тесте 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; vllm localhost container port.