Перезапуск CoreDNS — дорогой способ не посмотреть в conntrack. Типовой ночной отказ: в 03:00 мониторинг кричит о DNS-таймаутах и недоступности ingress, хотя CPU свободен. Виновником назначают Kubernetes. Но на узле с conntrack новые DNS-потоки и TCP-соединения конкурируют за одну таблицу состояний. Уже учтённые соединения могут продолжать работу, маскируя отказ. На проблемном узле: sysctl net.netfilter.nfconntrackcount net.netfilter.nfconntrackmax; затем два замера conntrack -S с интервалом. Нужны заполненность и прирост drop/earlydrop: earlydrop показывает вытеснение записей, а drop сам по себе ещё не доказывает переполнение. Проверка журнала: journalctl -k --since '15 minutes ago' | rg 'nfconntrack.table full'. Сообщение «table full, dropping packet» связывает симптомы с механизмом: лимит достигнут, освободить запись не удалось, пакет отброшен. Для приложения это выглядит как молчание сети. Восстановление начинается с ограничения источника новых потоков. Повышение nfconntrackmax допустимо с запасом памяти и оценкой nfconntrack*buckets: больший лимит увеличивает потенциальное потребление памяти и длину цепочек хеш-таблицы. Семантика параметров: документация ядра. Без разбора состава потоков и времени жизни записей новый потолок лишь откладывает следующий отказ. conntrack -F вслепую уничтожает состояния, включая NAT, и способен расширить аварию. После восстановления нужны алерты на заполненность, скорость её роста и прирост потерь. Проверка DNS должна создавать новые запросы, проверка ingress — новые соединения: постоянный keepalive не проверяет возможность выделить запись. Десять реплик на одном узле делят тот же предел ядра. Оркестратор не отменяет учёт ресурсов. Эксплуатация bare metal: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=conntrack-table-full-v-03-00-pochemu