138 lines
9.7 KiB
Markdown
138 lines
9.7 KiB
Markdown
# Стратегия доказательства сетевого бага 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
|
||
```
|
||
|
||
«Виновата платформа» доказано, если ВСЕ три условия:
|
||
1. Таймауты воспроизводятся на пути БЕЗ нашего кода (сырой TCP, эхо) с тем же паттерном.
|
||
2. tcpdump фиксирует потерю сегмента клиент↔кластер при том, что под/nginx
|
||
ответил за миллисекунды (по логам).
|
||
3. Потери коррелируют с 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. Пошаговый план: дешевле → дороже
|
||
|
||
1. Инвентаризация логов: nginx access/error за тестовый период (499, request_time
|
||
30+/51), логи приложения (фактическое время обработки). Параллельно открыть
|
||
тикет Nubes.
|
||
2. 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.
|
||
3. Второй клиент из другого сегмента (VPS/другой ISP): тот же скрипт.
|
||
Воспроизвелось → исключены ISP и локальная сеть пользователя.
|
||
4. Сырые TCP на 32391 с обеих точек: потери на больших сегментах без HTTP →
|
||
исключены HTTP и приложение.
|
||
5. kubectl port-forward с ВМ на shared-sqs (localhost:4100): чистый тест →
|
||
приложение и под исправны (в обход шлюза через API-туннель).
|
||
6. tcpdump на клиенте + сверка с nginx access log: классификация таймаутов.
|
||
7. Эхо-сервис NodePort без ingress: А/Б 512/1400 тем же клиентом. Остались
|
||
таймауты → nginx и приложение исключены; исчезли → завести эхо через ingress
|
||
и повторить (изоляция nginx).
|
||
8. Захват в кластере: debug-контейнеры tcpdump, cilium monitor drop, логи
|
||
kube-vip/kube-proxy; двусторонняя корреляция по seq.
|
||
9. Матрица размеров (опционально): 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 → тикет.
|