doc: план v2 от DeepSeek V4 Pro (новый чат) — стратегия изоляции слоёв; сравнение с Flash
This commit is contained in:
“Naeel”
@@ -0,0 +1,137 @@
|
||||
# Стратегия доказательства сетевого бага 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 → тикет.
|
||||
Reference in New Issue
Block a user