# Вопрос для Sonnet — TCP stall 51s на первом upload (2026-07-16) ## Ситуация Два сервиса на одном кластере (contractor + drhider), оба Flask на Штурвале. После миграции contractor на Flask: **первый upload файла из браузера зависает на ~51 секунду**, потом проходит. Второй и последующие файлы — мгновенно. ## Симптомы - **Браузер**: первый POST /upload (~63KB) висит 51 секунду на ~95% прогресса, потом ок - **Логи ingress (nginx)**: ВСЕ запросы (включая успешные) проходят за 0.06-0.16 сек - **Зависание происходит ДО того как запрос попадает в nginx** — на уровне TCP - **51 секунда** — стабильно, воспроизводится периодически - **Затрагивает оба сервиса**: и contractor и drhider ## Топология кластера ``` Клиент (браузер) ↓ 185.247.187.151 (kube-vip, LoadBalancer, externalTrafficPolicy: Cluster) ↓ на ЛЮБУЮ из 4 нод shturval-ingress-controller (4 реплики, по одной на каждой ноде) ↓ upstream к поду сервиса pythonk8s (1 под, нода workers-6f74n, IP 172.16.1.221:5000) ``` 4 ноды (k8s 1.34.1): - control-plane-xb699 (10.10.102.2) — поды: 172.16.0.0/24 - workers-6f74n (10.10.102.3) — поды: 172.16.1.0/24 ← **contractor здесь** - workers-bhbvs (10.10.102.4) — поды: 172.16.2.0/24 - workers-v8zq4 (10.10.102.5) — поды: 172.16.3.0/24 Ingress-поды (4 шт): - 172.16.0.73 на control-plane (.2) - 172.16.1.65 на workers-6f74n (.3) ← **локально с contractor** - 172.16.2.144 на workers-bhbvs (.4) - 172.16.3.149 на workers-v8zq4 (.5) Cilium CNI: Geneve-энкапсуляция, MTU 1400, encryption Disabled. kube-vip: DaemonSet (по одному на ноду .2 .3 .4 .5) + provider. ## КЛЮЧЕВАЯ НАХОДКА ```yaml # Ingress ConfigMap: upstream-keepalive-connections: "0" upstream-keepalive-time: 60s ``` **Каждый HTTP-запрос от ингресса к бэкенду — новый TCP-рукопожатие.** 75% запросов проходят через Geneve-туннель (ingress на .2/.4/.5 → backend на .3). 51 секунда ≈ `tcp_syn_retries=5`: 1+2+4+8+16 = 31с или 3+6+12+24+48 = 93с. Точнее — зависит от начального RTO ядра. ## Вторая подозрительная находка Cilium на ноде .3 (`cilium bpf tunnel list`) показывает Geneve-туннели: ``` 172.16.3.0 → 10.10.102.5 (нода .5) 172.16.1.0 → 10.10.102.3 (себя) 172.16.0.0 → 10.10.102.2 (нода .2) ``` **Туннель к ноде .4 (172.16.2.0 → 10.10.102.4) ОТСУТСТВУЕТ в списке!** Всего 3 туннеля при 4 нодах. ## Что проверено - `cilium status --verbose`: все healthy, 0 ошибок - `cilium monitor -t drop`: дропов нет - `cilium bpf ct list global`: 4682 записи, conntrack не переполнен - `cilium encrypt status`: Disabled - `cilium bpf lb list`: сервис pythonk8s (10.98.50.130:80 → 172.16.1.221:5000) — OK - Cilium endpoint 1010 (pythonk8s): Disabled/Disabled, ready - Логи ingress (последние 100 запросов): все 200 OK, 0.007-0.162 сек - Ошибок `upstream timed out`, `connect failed`, `502/504` в логах ingress НЕТ - kube-vip поды: все Running - kube-vip provider: Running (рестарт 46ч назад) ## Гипотезы 1. **Первый TCP-рукопожатие ingress→backend через Geneve теряет SYN** - Причина: eBPF-программа Cilium для нового соединения не готова мгновенно - Причина: neighbour discovery для Geneve endpoint - Вопрос: почему именно 51 секунда, а не мгновенный RST или 1-2 секунды? 2. **Отсутствующий Geneve-туннель к ноде .4** - Если запрос попадает на ingress на .4 → трафик к backend на .3 должен идти через туннель - Если туннеля нет в bpf map — куда идёт трафик? Через хост-сеть? Через другую ноду? 3. **externalTrafficPolicy: Cluster + 4 ingress реплики** - kube-vip может отправить трафик на ЛЮБУЮ ноду - Если на ноду без ingress-пода → kube-proxy/Cilium форвардит на другую ноду → двойной Geneve - Может ли это добавлять задержку? 4. **client-body-timeout: 60 + первый upload = гонка** - Если TCP-рукопожатие занимает 51 секунду, а body upload начинается после - Может ли общее время превысить 60 секунд и вызвать 408/413? ## Вопросы 1. Почему `upstream-keepalive-connections: "0"` + Geneve вызывает 51-секундный TCP-stall именно на ПЕРВОМ запросе, а последующие идут мгновенно? 2. Отсутствие Geneve-туннеля к ноде .4 (172.16.2.0) в `cilium bpf tunnel list` на ноде .3 — это норма или баг Cilium? Может ли это быть причиной потери SYN-пакетов? 3. Как диагностировать ГДЕ именно теряется SYN: между kube-vip и ingress, или между ingress и backend? Какие инструменты Cilium/ядренные использовать? 4. Рекомендация: менять `upstream-keepalive-connections` на 2-4 вместо 0 — решит ли это проблему первого запроса? 5. Есть ли ещё что посмотреть в кластере чего мы не проверили?