Kubernetes DNS: таймауты, MTU и conntrack — диагностика через CoreDNS, tcpdump и PMTUD

Почему DNS и внешний API «падают», хотя кластер жив

Типичная картина инцидента: часть подов периодически не может сходить во внешний API (timeout), иногда «подвисает» резолвинг (timeout/SERVFAIL/NXDOMAIN), а повторный запрос через секунду уже проходит. В метриках приложения это выглядит как всплески external api timeout, а на уровне кластера — как сетевые «провалы», которые сложно воспроизвести.

В Kubernetes такие симптомы часто складываются из трёх факторов:

• DNS-цепочка длиннее, чем кажется: библиотека резолвинга в контейнере → /etc/resolv.conf (search/ndots/timeout/attempts) → CoreDNS → апстрим-резолверы → интернет.

• MTU mismatch: где-то по пути реальная MTU меньше, чем «думает» отправитель. Крупные UDP-пакеты (DNS с EDNS0, ответы с DNSSEC, большие TXT) или TCP-сегменты могут «чёрно-дыриться» при сломанном PMTUD.

• conntrack: таблица состояний netfilter переполняется или таймауты/учёт UDP ведут себя неожиданно (NAT, много подов, пики трафика). Для DNS по UDP это особенно чувствительно.

Ниже — практическая шпаргалка: как быстро понять, где именно ломается путь, используя логи CoreDNS, tcpdump, conntrack и диагностику PMTUD (ICMP Fragmentation Needed / Packet Too Big).

Быстрый план расследования (чтобы не утонуть в догадках)

В сетевых инцидентах выигрывает тот, кто сначала фиксирует факты «с двух сторон», а потом уже меняет настройки. Удобная последовательность:

1. Определите, что именно timeout: DNS-резолвинг или TCP/HTTPS до внешнего API.

2. Проверьте DNS на уровне пода и на уровне CoreDNS: видит ли CoreDNS запрос и что отвечает.

3. Проверьте PMTUD/MTU на пути до внешнего API и до апстрим-резолверов.

4. Проверьте conntrack: есть ли дропы из-за переполнения, необычные таймауты, массовые записи UDP/53.

5. Сделайте tcpdump в нужной точке: под, нода, CoreDNS — и сравните «запрос ушёл» vs «ответ пришёл».

Держите «линию доказательств» для одного проблемного запроса: время, src/dst, протокол, что увидел клиент, что увидел CoreDNS, что видно на ноде (conntrack и захват).

Шаг 1. Отличаем проблемы DNS от проблем внешнего API

На графиках приложения оба случая выглядят одинаково: timeout. Но лечатся по-разному, поэтому сначала разделяем.

Проверка из пода: резолвинг и TCP к API

Зайдите в проблемный под (или поднимите debug-под в том же namespace/node) и проверьте настройки резолвера:

kubectl exec -it POD -- cat /etc/resolv.conf

Обратите внимание на:

• nameserver (обычно ClusterIP CoreDNS);

• search и options ndots: (слишком большой ndots раздувает количество запросов);

• timeout: и attempts: (агрессивные значения создают «шторм» ретраев).

Далее сравните резолвинг и реальный запрос к API:

kubectl exec -it POD -- sh -lc 'getent hosts api.example.com || true'

kubectl exec -it POD -- sh -lc 'time wget -S -O /dev/null https://api.example.com 2>&1 | head -n 30'

Интерпретация простая:

• DNS стабилен, а TCP/HTTPS падает: это уже не «просто DNS», копаем сеть/MTU/маршрутизацию/фильтрацию до внешнего API.

• Резолвинг то работает, то нет: начинаем с CoreDNS и пути UDP/53.

Шаг 2. Смотрим CoreDNS: видит ли он запросы и что отвечает

CoreDNS — лучшая точка наблюдения. Даже если проблема «где-то в сети», по логам можно понять, доходят ли запросы, есть ли повторы, и сколько времени занимает апстрим.

Включаем полезные логи (временно) и читаем их

Если есть возможность менять ConfigMap CoreDNS, для диагностики обычно включают плагины log и errors. Плагин debug используйте кратковременно: он шумный и может нагрузить CoreDNS.

Проверьте текущий Corefile:

kubectl -n kube-system get configmap coredns -o yaml

Читать логи:

kubectl -n kube-system logs -l k8s-app=kube-dns --tail=200

Что искать в логах CoreDNS:

• Есть ли запрос от IP пода (или от ноды при SNAT) в момент проблемы.

• Коды ответов: SERVFAIL, NXDOMAIN, REFUSED.

• Задержки обработки: если растёт время апстрима, проблема может быть «внешняя», но её видно.

• Повторы одинаковых запросов: часто признак потерь UDP-ответов, NAT/conntrack или MTU/фрагментации.

Развилка по результату

• CoreDNS не видит запрос — проблема до CoreDNS: CNI, kube-proxy, сетевые политики, MTU/PMTUD на пути под → ClusterIP → CoreDNS, либо conntrack на ноде.

• CoreDNS видит запрос, но отвечает долго или отдаёт SERVFAIL — проверяйте апстрим-резолверы и путь CoreDNS → апстрим (включая MTU).

• CoreDNS отвечает быстро, но клиент таймаутится — ответ, вероятно, не доходит обратно (UDP потери, conntrack/NAT, MTU/фрагментация).

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Если для диагностики вам нужен отдельный «чистый» узел (например, jump-хост, egress-шлюз или апстрим-резолвер для сравнения поведения), удобно поднять это на VDS и стандартизировать MTU и фаервол.

Шаг 3. MTU mismatch и PMTUD: почему таймауты «случайные»

Несовпадение MTU коварно тем, что «маленькие» пакеты проходят, а «большие» — нет. Для DNS это проявляется, когда ответ становится крупным (много записей, DNSSEC, EDNS0, длинные TXT). Для внешнего API это может проявляться на TLS-рукопожатии, HTTP/2, при больших заголовках, а также при проблемах с MSS/размером сегментов.

ICMP Fragmentation Needed и Path MTU Discovery

PMTUD (path mtu discovery) вычисляет максимальный размер пакета по пути. Если на маршруте встречается меньшая MTU, узел должен вернуть ICMP-сообщение о необходимости фрагментации (icmp fragmentation needed для IPv4 или ICMPv6 Packet Too Big). Если такие ICMP режутся фильтрами, отправитель продолжает слать слишком большие пакеты — и вы получаете «мистические» таймауты.

Классический симптом PMTUD blackhole: TCP соединение устанавливается, но зависает на передаче данных или на TLS; иногда «само проходит», если пакеты оказываются меньше.

Практическая проверка MTU до внешней цели

На ноде (или в debug-поде с нужными правами/утилитами) попробуйте «пинг с запретом фрагментации»:

ping -M do -s 1472 api.example.com

1472 — пример для MTU 1500 (1500 - 20 IP - 8 ICMP). Если не проходит, уменьшайте размер, пока не начнёт проходить: так вы оцените реальную MTU по пути.

Аналогично проверьте маршрут до апстрим-резолвера (если он известен). Если ICMP блокируется, вместо явного ответа о фрагментации вы иногда увидите просто «тишину».

Косвенные признаки MTU-проблем в Kubernetes

• Проблемы чаще проявляются при egress через туннели/VXLAN/GRE/WireGuard или при межзональных соединениях.

• На одной группе нод всё хорошо, на другой — плохо (разная подложка, разные MTU интерфейсов).

• DNS-таймауты коррелируют с крупными ответами (DNSSEC, большие TXT, длинные цепочки CNAME).

Шаг 4. conntrack: когда таблица состояний становится узким местом

conntrack хранит состояния соединений (включая UDP «псевдосоединения»). В Kubernetes через него проходит много сервисного трафика: kube-proxy, NAT, egress. Если таблица переполняется или таймауты слишком короткие, пакеты теряются без явной ошибки на уровне приложения.

Проверяем лимиты и текущую загрузку

На ноде:

sysctl net.netfilter.nf_conntrack_max

cat /proc/sys/net/netfilter/nf_conntrack_count

Если nf_conntrack_count близко к nf_conntrack_max, дропы очень вероятны. Нередко это видно и в dmesg сообщениями о переполнении, но полагаться только на это не стоит.

Смотрим conntrack по DNS и симптомам

Если установлен пакет conntrack-tools:

conntrack -S

conntrack -L -p udp --dport 53 2>/dev/null | head -n 50

На что смотреть:

• Счётчики drop/invalid в conntrack -S (если растут в момент проблем).

• Много короткоживущих UDP-записей на 53 порт: признак DNS-штормов или неудачных ретраев.

• Большое число коротких TCP-сессий к внешнему API без keep-alive на уровне приложения тоже «съедает» conntrack.

Важно: лечить проблему только увеличением net.netfilter.nf_conntrack_max иногда правильно, но часто первопричина — поведение клиентов DNS (search/ndots/attempts) или отсутствие кэширования/переиспользования соединений в приложении.

Шаг 5. tcpdump: собираем доказательства (под, нода, CoreDNS)

tcpdump — самый быстрый способ ответить на вопрос «пакет ушёл?» и «ответ пришёл?». В Kubernetes полезно снимать трафик в трёх точках:

• внутри пода (если есть права и утилиты),

• на ноде (на интерфейсе CNI/eth0 или через any),

• на ноде, где работает CoreDNS (или внутри CoreDNS-пода при возможности).

Пример: ловим DNS-запросы и ответы

На ноде:

tcpdump -ni any 'udp port 53' -vv

Уточняйте фильтр по IP пода, чтобы не утонуть в шуме:

tcpdump -ni any 'host 10.42.1.25 and udp port 53' -vv

Интерпретация:

• Есть запрос из пода, нет ответа обратно: проблема на обратном пути (conntrack/NAT, MTU/фрагментация, политики/iptables).

• Нет запроса: проблема до ноды/интерфейса (CNI, сетевой namespace, policy).

• На ноде видны и запрос, и ответ, а в поде timeout: ищите, где пакет теряется внутри цепочки CNI/iptables.

Пример: ловим PMTUD (ICMP Fragmentation Needed) на IPv4

Сообщения ICMP, связанные с PMTUD, можно увидеть так:

tcpdump -ni any 'icmp and (icmp[0]=3 and icmp[1]=4)' -vv

Если в момент проблем видно ICMP Fragmentation Needed — это прямое доказательство меньшей MTU на пути (и того, что ICMP хотя бы частично проходит). Если MTU реально меньше, а ICMP вы не видите, это наводит на мысль о PMTUD blackhole (ICMP режется фильтрами).

Пример: внешний API по TCP/443

tcpdump -ni any 'tcp port 443' -vv

Дальше точечно добавляйте host (IP цели) и смотрите на ретрансляции и «зависание» после установления соединения. Ситуация «SYN/SYN-ACK есть, а дальше тишина или бесконечные retransmissions данных» очень часто сочетается с MTU/PMTUD.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Если при разборе выясняется, что проблема упирается в TLS (например, часть клиентов не может завершить рукопожатие, а в трассировках видны retransmissions), проверьте корректность цепочки и сроков. Для продакшена удобно держать актуальные SSL-сертификаты с нормальным процессом продления.

Типовые причины и быстрые фиксы (без «магии»)

Причина 1: Разная MTU у нод/туннелей, PMTUD ломается

• Убедитесь, что MTU в CNI соответствует подложке. Для overlay (например, VXLAN) обычно нужна меньшая MTU, чем 1500.

• Проверьте, что ICMP для PMTUD не режется сетевыми фильтрами/ACL/security groups (для IPv4 и IPv6).

• Если вы контролируете egress-шлюз/NAT, проверьте MSS clamping как временный обходной путь (но лучше чинить первопричину).

Причина 2: conntrack table full или агрессивные UDP-таймауты

• Проверьте и при необходимости увеличьте net.netfilter.nf_conntrack_max (с учётом памяти) и заведите мониторинг nf_conntrack_count.

• Снизьте DNS-шторм: разумный ndots, аккуратный search list, кэширование (в CoreDNS и/или в приложении) и меньше бессмысленных ретраев.

• Проверьте ресурсы CoreDNS: CPU throttling и нехватка реплик легко превращаются в «случайные» таймауты.

Причина 3: CoreDNS не справляется или апстрим тормозит

• Сопоставьте задержки в логах CoreDNS с моментом таймаута у клиента: растёт ли время апстрим-запросов.

• Проверьте сетевой путь CoreDNS → апстрим DNS (маршруты, MTU, потери), отдельно от подов.

• Убедитесь, что кеширование в CoreDNS включено и реально помогает, а конфигурация не создаёт лишних пересылок.

Чеклист: что собрать для отчёта и повторяемой диагностики

• Время инцидента и пример домена/эндпоинта, который даёт timeout.

• /etc/resolv.conf из пода (search/ndots/timeout/attempts).

• Фрагмент логов CoreDNS на тот же момент (виден ли запрос, какой rcode, какая задержка).

• Счётчики conntrack: nf_conntrack_count, nf_conntrack_max, при наличии — conntrack -S.

• tcpdump в 1–2 точках (под/нода/CoreDNS), чтобы показать «запрос есть, ответа нет».

• Проверка MTU/PMTUD: результаты ping -M do и/или наблюдение ICMP в tcpdump.

Итог: как связать всё вместе

DNS-таймауты в Kubernetes редко бывают «просто DNS». Чаще это сеть (MTU mismatch и PMTUD), состояние (conntrack), либо ресурсы/задержки CoreDNS и апстрима. Самый быстрый путь к истине — корреляция трёх источников: логи CoreDNS (видимость и rcode), tcpdump (пакеты туда/обратно) и conntrack (состояние и дропы).

В следующий раз этот чеклист можно превратить в постоянный runbook: готовый debug-под, шаблоны фильтров для tcpdump, и алерты по conntrack/latency CoreDNS — чтобы разбор подобных инцидентов занимал минуты, а не часы.