У вас была история с conntrack и плавающими таймаутами в чекауте. Опишите полный путь отладки: как вы определили, на каком слое лежит проблема, какие метрики и логи помогли, почему приложение не видело проблему и как вы выбрали между тремя способами решения — лимитами, NetworkPolicy и физической изоляцией на node pool? Как бы вы организовали наблюдаемость сегодня, чтобы эта проблема была видна раньше?

Проверяйте путь запроса по слоям и сопоставляйте таймауты с conntrack на конкретных узлах. Лимиты, NetworkPolicy и выделенный node pool решают разные задачи и не взаимозаменяемы.

Без фактов инцидента нельзя утверждать его причину. План проверки: клиент и ingress → сетевой путь → приложение → зависимости; сравнение проблемных и здоровых узлов по времени. Смотрите count/max conntrack, отказы вставки, drops, retransmits, журналы ядра и CNI, скорость новых соединений. Приложение может не видеть запрос, потерянный до сокета. Ограничение конкуренции снижает churn; увеличение лимита требует оценки памяти. NetworkPolicy контролирует разрешённый трафик, но не гарантирует изоляцию общей таблицы conntrack. Выделенный node pool уменьшает влияние соседей. Сегодня добавил бы алерты по заполнению и drops, сетевую телеметрию и корреляцию с checkout SLO.

Источник: docs.kernel.org.