9.7 KiB
Стратегия доказательства сетевого бага Nubes — v2
⚠️ ПОМЕТКА: анализ от DeepSeek V4 Pro (основная модель) в НОВОМ чате — НЕ Соннет. Пользователь задал тот же вопрос в новом чате DeepSeek V4 Pro. Сохранено 2026-08-15. Сравнение с планом DeepSeek V4 Flash — в HISTORY и в конце этого файла.
Стратегия доказательства
Доказывается изоляцией слоёв. Каждый тест исключает один слой пути:
клиент (локальная машина) → интернет → шлюз платформы (VIP 185.247.187.151)
→ kube-vip → NodePort 32391 → kube-proxy → nginx-ingress → Cilium → под shared-sqs
«Виновата платформа» доказано, если ВСЕ три условия:
- Таймауты воспроизводятся на пути БЕЗ нашего кода (сырой TCP, эхо) с тем же паттерном.
- tcpdump фиксирует потерю сегмента клиент↔кластер при том, что под/nginx ответил за миллисекунды (по логам).
- Потери коррелируют с MTU-порогом (~1448) или платформенным таймером (conntrack/RST), а не с логикой приложения.
1. Эхо или сырые TCP
Делать ОБА, в порядке: сырые TCP, потом эхо.
Сырые TCP на 185.247.187.151:32391 — бесплатный первый тест. Покрывает путь до nginx-пода без HTTP и без нашего кода. Отправлять сегменты 512, 1380, 1448, 1488+ байт. Критерий доставки — TCP ACK, не HTTP-ответ (nginx на мусор ответит 400/RST — нормально).
Эхо-сервис — второй шаг, ~20 строк Go, Deployment + Service с отдельным
NodePort (без ingress). Параметризуемый размер тела ответа (?bytes=512|1400) —
большие POST тестируют прямой путь, большие ОТВЕТЫ — обратный. Гонять тем же
клиентом. Таймауты воспроизвелись → nginx-ingress и наше приложение исключены.
2. Как поймать таймаут
tcpdump на клиенте: tcpdump -i any -s 0 -w /tmp/cap.pcap host 185.247.187.151 and tcp port 32391
| Симптом | Что смотреть |
|---|---|
| 51-с зависание большого POST | ACK на сегмент с полным MSS? ретрасмиты и интервалы? чем сессия завершилась (RST/FIN, кто первый) |
| 30-с ReadTimeout на 512 байт | запрос отправлен полностью? ACK получен? ответ не пришёл? RST после idle (conntrack)? keep-alive пул? |
| MTU-гипотеза | ICMP type 3 code 4 (Fragmentation Needed)? Не приходят → PMTUD сломан → механизм зависаний |
Замечание: 51 с не похоже на TCP-backoff Linux (tcp_retries2=15 → сотни секунд). Скорее прикладной таймер (~50–60 с клиента/nginx/шлюза). Точный интервал в pcap покажет, чей таймер.
Серверный захват — только через kubectl: kubectl debug -it <pod> --image=<tcpdump-образ>
(нужны NET_RAW/NET_ADMIN — на managed может быть запрещено). Если запрещено —
роль серверного захвата выполняют nginx access log и эхо-А/Б.
Ключевой приём: двусторонний захват, корреляция по TCP seq/ack (не по времени):
- запрос ушёл с клиента, не появился у пода → потеря на прямом пути;
- ответ ушёл из пода, клиент не получил → потеря на обратном;
- в обоих случаях приложение исключено.
3. kube-vip / NodePort / nginx через kubectl
nginx access log + $request_time $upstream_response_time $status $bytes_sent:
| В логе | Вывод |
|---|---|
| 499 + большой request_time | клиент ушёл до ответа |
| 200 + малый upstream, клиент без ответа | потеря между nginx и клиентом |
| записи нет | потеря до nginx (kube-vip/NodePort/шлюз) |
kube-vip: kubectl get pods -A | grep -i vip, логи (ARP/BGP-анонсы, флап VIP),
сопоставить ноду-держателя VIP с реально принимающей нодой.
kube-proxy/NodePort: kubectl get ds -n kube-system kube-proxy, логи;
externalTrafficPolicy: Cluster → лишний хоп + SNAT; iptables/conntrack ноды
не видны (нет доступа к нодам) — debug-под с hostNetwork+privileged+nodeSelector
или тикет.
Cilium: kubectl exec -n kube-system <cilium-pod> -- cilium monitor --type drop
(в cilium-под, НЕ в operator). Дроп с причиной — прямое доказательство.
Ограничение: внешний шлюз (VIP, MSS=1448) из kubectl не виден. Если кластерные точки чистые, а снаружи потери есть — виноват шлюз/underlay, оформляется тикет.
4. Пошаговый план: дешевле → дороже
- Инвентаризация логов: nginx access/error за тестовый период (499, request_time 30+/51), логи приложения (фактическое время обработки). Параллельно открыть тикет Nubes.
- PMTU-зонд с клиента:
ping -M do -s 1372/1422/1460/1472до VIP (пороги MTU 1400/1450/1488/1500); при запрете ICMP —mtr --tcp -P 443, tcptraceroute. MSS=1448 → сегменты 1488 при underlay 1450 — шлюз анонсирует неверный MSS. - Второй клиент из другого сегмента (VPS/другой ISP): тот же скрипт. Воспроизвелось → исключены ISP и локальная сеть пользователя.
- Сырые TCP на 32391 с обеих точек: потери на больших сегментах без HTTP → исключены HTTP и приложение.
- kubectl port-forward с ВМ на shared-sqs (localhost:4100): чистый тест → приложение и под исправны (в обход шлюза через API-туннель).
- tcpdump на клиенте + сверка с nginx access log: классификация таймаутов.
- Эхо-сервис NodePort без ingress: А/Б 512/1400 тем же клиентом. Остались таймауты → nginx и приложение исключены; исчезли → завести эхо через ingress и повторить (изоляция nginx).
- Захват в кластере: debug-контейнеры tcpdump, cilium monitor drop, логи kube-vip/kube-proxy; двусторонняя корреляция по seq.
- Матрица размеров (опционально): 100–1500 байт на эхо и на 32391. Резкий порог 1380–1448 → MTU; плавный рост → шлюз/перегрузка.
Итог: что считается доказательством
| Наблюдение | Вывод |
|---|---|
| Таймауты на эхо-NodePort (без ingress) с тем же паттерном | исключены nginx и наш код — виноват kube-vip/NodePort/шлюз/underlay |
| nginx: 200 + upstream <100 мс, клиент без ответа | потеря между nginx и клиентом |
| нет записи в access log | потеря до nginx |
| pcap: сегмент не дошёл до пода / ответ не дошёл до клиента | потеря в сетевом пути |
| ping -M do: резкий порог размера | MTU-дефект пути |
| cilium monitor показывает drop | внутрикластерная потеря |
| port-forward чистый, внешний IP таймаутит | виноват шлюз/NodePort/kube-vip |
Итоговая цепочка для тикета: pcap с клиента + access log nginx (200/upstream малый) + воспроизведение на эхо без нашего кода + PMTU-порог ≈1448.
Сравнение с планом DeepSeek V4 Flash (основной агент)
Flash: силён декомпозицией по nginx-логам, но с ошибкой (cilium monitor через cilium-operator), переоценён echo, нет PMTU-зонда, нет порога ping -M do, нет port-forward, нет второго ISP.
Pro (этот план): сильнее методологически — сырые TCP с критерием ACK, PMTU-зонд ping -M do, второй клиент, port-forward, таблица «что считается доказательством». Грубых ошибок нет.
Синтез (рекомендация): дешёвые тесты обоих планов + финал echo. Порядок: nginx-логи → PMTU-зонд → сырые TCP → port-forward → tcpdump клиента → второй ISP (если есть) → cilium monitor → echo → тикет.