Ночью: нода в кластере K3s внезапно теряет поды. Мониторинг кричит об OOM, но free -m показывает 60% свободной RAM. dmesg — да, OOM-killer убил kubelet. Но почему? Запускаем tcpdump на обоих концах BGP-сессии: видим тысячи дублирующихся UPDATE с одинаковыми ASPATH. Это петля. В это время ss -s показывает 480k TCP-соединений в ESTABLISHED. Проверяем /proc/net/nfconntrack — заполнен под завязку, nfconntrackcount == nfconntrackmax. Ядро не может выделить память для новых conntrack-записей, slab allocation fails, и OOM-killer активируется — не из-за user-space memory pressure, а из-за исчерпания kernel slab cache. Решение: clamp MSS, ограничить maxtracked connections, и внедрить двусторонний tcpdump + traceroute как часть runbook для любого сетевого инцидента. Подробный разбор: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=dvustoronniy-tcpdump-i-traceroute-r

Ночью: нода в кластере K3s внезапно теряет поды. Мониторинг кричит об OOM, но free -m показывает 60% свободной RAM. dmesg — да, OOM-killer убил kubelet | Сетка — социальная сеть от hh.ru