В 03:00 легко объявить CNI виновником задержек inference. Типовой разбор: p99 скачет, GPU недогружен, команда предлагает hostNetwork ради микросекунд. Но задержка установления соединения уже съедает миллисекунды. Прежде чем снимать сетевую изоляцию, найдите очередь, в которой запрос ждёт воркера. В сетевом namespace воркера запускаем ss -lnt sport = :8000 и nstat -az TcpExtListenOverflows TcpExtListenDrops. Для LISTEN сокета Recv-Q показывает соединения, ожидающие accept(), Send-Q — предел очереди. Снимаем несколько замеров под нагрузкой: заполнение очереди вместе с приростом ListenOverflows указывает на переполнение. Счётчики относятся ко всему namespace, поэтому один nstat конкретный порт не осудит. При tcp_abort_on_overflow=0 переполнение может обернуться повторными передачами и задержкой вместо немедленного RST. В этой ветке расследования затор — на приёме соединений приложением. Проверяем паузы accept(), переиспользование соединений и backlog: его верхнюю границу ограничивает net.core.somaxconn. Просто поднять лимит — разрешить больше ожидания. hostNetwork убирает отдельный сетевой namespace и обычный путь через pod veth/bridge, но не гарантирует обход netfilter или conntrack. И CNI не обязательно использует bridge. Семантика параметров ядра: https://docs.kernel.org/networking/ip-sysctl.html Сравнивать hostNetwork и bridge имеет смысл при одинаковых нагрузке, числе соединений и маршруте до воркера. Меряем отдельно connect latency, время до первого токена и прирост переполнений. Если выигрыш появился только после обхода Service, приписывать его мосту — инженерное жульничество. Kubernetes умеет добавлять сетевые слои; ускорять accept() за приложение он не обязан. https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=host-networking-vs-cni-bridges-dlya
