В 03:00 алерты обвиняют CoreDNS и ingress: резолвинг зависает, новые подключения не проходят. Типовой разбор такой аварии начинается ниже Kubernetes. На ноде заполнена таблица conntrack. Если ядро не может вытеснить запись, пакет, которому нужна новая запись, отбрасывается. Уже отслеживаемые соединения могут продолжать работать. Поэтому успешный запрос по старому keepalive ничего не доказывает. На пострадавшей ноде: sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max; затем conntrack -S дважды с интервалом. Смотрим прирост drop и early_drop: первый требует разбирательства с потерями, второй показывает досрочное вытеснение записей. journalctl -k --since '15 min ago' ищет «nf_conntrack: table full, dropping packet». Лог ограничивается по частоте: отсутствие свежей строки не оправдывает ядро. Один снимок count после пика тоже не оправдывает. Граница диагноза: речь о потоках, проходящих через conntrack этой ноды. DNS по UDP тоже занимает записи; новые запросы не обязательно создают новые записи, если совпадает tuple. В схеме с отслеживаемым Service DNAT DNS и ingress конкурируют за одну таблицу. Масштабирование Pod на той же ноде лимит не устраняет. Платить за ещё один слой оркестрации вместо измерения этого ресурса — налог на лень. Сначала ограничиваем источник всплеска новых потоков. Поднимать nf_conntrack_max можно как временную меру после оценки памяти и размера хеш-таблицы; бездумный conntrack -F снесёт состояние, включая NAT. Для профилактики нужны count/max, скорость роста, дельты drop и early_drop, а также проверка новых DNS-запросов и TCP-подключений. Эксплуатация начинается с бюджета состояния ядра: https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=conntrack-table-full-v-03-00-pochemu.