В этом материале
Когда новые соединения пропадают при работающих старых, проверьте conntrack на узле. Сопоставьте nf_conntrack_count и nf_conntrack_max с событиями отказа. Заполненная таблица — отдельная гипотеза: похожий симптом бывает при DNS, политике сети, socket limits и отказе приложения.
Когда новые соединения пропадают при работающих старых, проверьте conntrack на узле. Сопоставьте nf_conntrack_count и nf_conntrack_max с событиями отказа. Заполненная таблица — отдельная гипотеза: похожий симптом бывает при DNS, политике сети, socket limits и отказе приложения.
Определите узел и сетевой путь
Сохраните source Pod, destination, протокол и время неудачной попытки. Выясните, где выполняются NAT и connection tracking в конкретной реализации. Kubernetes Service может использовать kube-proxy либо иной dataplane, поэтому инструкция для одного режима не автоматически применима к другому. Сравните соединение к Pod IP и Service IP на тестовом пути. Эти проверки локализуют проблему, но не должны обходить рабочую политику доступа в production ради удобства диагностики.
Измерьте использование таблицы
Kernel nf_conntrack_count отражает число выделенных flow entries, nf_conntrack_max — соответствующую границу. Снимайте значения в момент сбоя и после него. Большой count сам по себе не доказывает потери: важны предел, динамика и дополнительные признаки отказа. Запишите журнал ядра и доступные счётчики подсистемы, не выгружая лишние чувствительные адреса. На общем узле entries принадлежат нескольким workload, а не только inference worker, который первым сообщил timeout.
Разберите всплеск коротких соединений
В учебном опыте несколько процессов создают много кратких соединений к внешней зависимости. Рабочие соединения продолжают обмениваться данными, а новые попытки становятся неустойчивыми одновременно с ростом таблицы. После прекращения тестового всплеска расход меняется согласно lifecycle записей. Это проверяемая гипотеза, а не обещание конкретного времени освобождения. Таймеры зависят от протокола, состояния и конфигурации kernel; их следует читать в фактической среде.
| Наблюдение | Следующий вопрос |
|---|---|
| Count близок к max | Есть ли подтверждение отказов |
| Растут новые flows | Кто создаёт соединения |
| Только Service path сломан | Как работает dataplane |
| Прямой путь тоже сломан | Проверить общий сетевой участок |
Устраните источник churn
Проверьте корректное повторное использование соединений и ограничение фоновой работы, не меняя прикладной контракт запросов. Увеличение таблицы требует оценки RAM и нагрузки на общий узел. Сокращение timeouts способно нарушить легитимные долгие соединения, поэтому оно не является безопасным универсальным рецептом. Меняйте один параметр на стенде, сохраняя исходную конфигурацию. Если count далёк от предела и отсутствуют признаки drops, не продолжайте бесконечный тюнинг conntrack по совпадению внешнего симптома.
Подтвердите исправление серией
Повторите тот же профиль соединений, фиксируя успех новых подключений, расход таблицы и состояние старых потоков. Артефакт содержит узел, dataplane mode, временные замеры и установленный источник churn. Успех означает исчезновение подтверждённого ограничения без повреждения нужных длинных соединений. При смене CNI повторите область проверки: место учёта и доступные метрики могут измениться. Не приписывайте сетевой эффект производительности GPU только потому, что ошибка обнаружена inference-сервисом.
Связанные разборы: network and uptime; inference capacity planning.