Переполнение conntrack — гипотеза, которую нужно подтвердить на проблемных нодах; запросы, потерянные до приложения, могут не попасть в его метрики.
Таймауты в чекауте раз в сутки, метрики приложения чистые. Объясните полностью: почему проблема не была видна на уровне приложения, как трейсинг помог локализовать разрыв между ingress и подом, почему conntrack заполнялся только на части нод, какие конкретные лимиты и настройки ядра меняли и почему taint на отдельный пул нод был правильным решением, а не resource limits или NetworkPolicy.
Переполнение conntrack — гипотеза, которую нужно подтвердить на проблемных нодах; запросы, потерянные до приложения, могут не попасть в его метрики.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Переполнение conntrack — гипотеза, которую нужно подтвердить на проблемных нодах; запросы, потерянные до приложения, могут не попасть в его метрики.
Сопоставьте ingress-логи, отсутствующие серверные spans, сетевые потери и nf_conntrack_count/max. Перекос дают размещение ingress, NAT и суточные задания. Размер таблицы и таймауты меняют по измерениям с учётом памяти; готовых значений без данных нет. Выделенный пул требует taint вместе с toleration и node affinity. CPU/memory limits и NetworkPolicy не устраняют переполнение таблицы соединений.