Оперативку удвоили. Таймаут остался ровно 30 секунд. Реконструкция ночного отказа, цифры учебные: в 02:46 панель назвала exit 137 «OOM». В сохранённой cgroup контейнера memory.current — 214 MiB при memory.max — 512 MiB; прирост oom и oom_kill в memory.events — ноль. В journalctl -k за окно аварии нет OOM; журнал kubelet показывает провал liveness и SIGKILL после истечения grace period. 137 обозначает SIGKILL, а происхождение убийства приходится расследовать. Смысл счётчиков — в документации ядра. На клиенте и сервере одновременно запустили tcpdump -ni eth0 -nn -tttt -vv 'host 203.0.113.10 and tcp port 443'. За 30 секунд клиентский дамп показал 6 SYN одного соединения, серверный — ноль; оба захвата завершились без kernel drops. Снимки nstat -az до и после дали ΔTcpRetransSegs=5 на изолированном клиенте. Это локализовало потерю между точками захвата, но ещё не доказало петлю. traceroute -n -T -p 443 203.0.113.10 показал чередование A→B→A→B; TCP-режим описан в руководстве traceroute. На транзитном интерфейсе A поймали один SYN с одинаковыми sequence и IP ID: TTL 61, затем 59, затем 57. Вот доказательство кругового движения. Проверка ip route get 203.0.113.10 на обоих маршрутизаторах замкнула дело: A отправлял префикс через B, а B после отзыва BGP-маршрута использовал default через A. Это петля пересылки после изменения BGP, а не циклический AS_PATH. На A сохранился ошибочный статический маршрут, переживший отзыв. Удалили ошибочный маршрут на A, восстановили корректный анонс: TCP handshake снова 8 мс, за следующие 10 минут — ноль рестартов. Liveness перестала зависеть от внешнего HTTPS; доступность зависимости вынесли в отдельную проверку. Покупка памяти лечила подпись на графике. Kubernetes исправно перезапускал жертву и не мог исправить FIB маршрутизатора. Разбор эксплуатации: https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=dvustoronniy-tcpdump-i-traceroute-r.
