Files
SQS-service/doc/thinking/nubes-network-bug-plan-v4-opus.md
T

80 lines
6.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# План: доказать, что таймауты — в пути/шлюзе Nubes — v4 (ОПУС 4.8)
> ✅ **ПОМЕТКА: план от Claude Opus 4.8** (пользователь передал ответ Опуса,
> который изучил репозиторий и три предыдущих плана).
> Сохранено 2026-08-15. Ниже — план Опуса + ответы основного агента на его
> уточняющие вопросы.
## TL;DR
Доказательство — изоляцией слоёв. «Виновата платформа» = таймауты
воспроизводятся БЕЗ нашего кода (port-forward чист, echo/сырой TCP таймаутит)
+ tcpdump с клиента ловит потерю сегмента, когда nginx/под ответили за
миллисекунды.
**Два РАЗНЫХ явления — раздельно:**
- **A. Большие POST ~51с** — локализовано: MSS=1448 → пакет 1488 > underlay
1450 → дроп при DF, PMTUD мёртв. Осталось зафиксировать порог ping-зондом.
- **B. Малые тела 512б, ~1 таймаут/37с** — MTU не объясняет. Регулярность =
таймер (шлюз VIP / ARP-флап kube-vip / conntrack GC). Главная нераскрытая часть.
## Ответы Опуса на вопросы
1. **Echo vs сырой TCP.** Сырой TCP недостаточен (только SYN/ACK; потери в
фазе данных). Самое дешёвое доказательство невиновности приложения —
`kubectl port-forward` мимо шлюза, а не echo. Echo — позже, только если
port-forward+логи не закрыли вопрос (он внутри кластера, а подозрение на шлюзе).
2. **Поймать таймаут.** tcpdump на клиенте, корреляция по TCP seq/ack: ретрансмиты
SYN → потеря на установлении; тишина после ACK → потеря после nginx; ICMP
frag-needed → PMTUD; кто и через сколько шлёт RST → чей таймер; интервал
между таймаутами → подтвердить ~37с.
3. **Через kubectl.** nginx access-log request_time/upstream_response_time:
499+большой request_time = клиент ушёл; 200+малый upstream без ответа клиенту
= потеря nginx↔клиент; записи нет = потеря до nginx. cilium monitor --type
drop — на cilium-ПОДЕ нужной ноды (не operator). externalTrafficPolicy
Cluster/Local.
## Шаги (дешевле → дороже)
- **Фаза 0 (бесплатно):** nginx access-log за прошлый тест → логи kube-vip
(флапы) → тикет Nubes (A и B раздельно).
- **Фаза 1 (клиент, ~30 мин):** PMTUD-зонд ping -M do (fallback mtr --tcp) →
tcpdump + повтор теста через long_compare_local.py с логом timestamp каждого
таймаута → контрольный канал YMQ во всех прогонах.
- **Фаза 2 (kubectl, без деплоя):** port-forward ПЕРВЫМ (невиновность приложения)
→ cilium monitor drop параллельно → проверка externalTrafficPolicy/nodePort.
- **Фаза 3 (echo, если 0–2 не хватило):** Go echo без ingress на NodePort →
таймаутит → nginx и код исключены → потом echo через ingress (изоляция nginx).
- **Фаза 4 (тикет):** одновременный tcpdump + nginx-log + cilium monitor,
корреляция по seq → pcap+логи+ping в тикет.
**Что считается доказательством:** echo-NodePort таймаутит тем же паттерном →
nginx+код исключены; nginx 200/upstream<100мс без ответа клиенту → потеря
nginx↔клиент; pcap показывает недоставленный сегмент; ping-порог → MTU;
cilium drop → внутри кластера; port-forward чист + внешний IP таймаутит →
приложение невиновно; стабильный интервал ~37с → таймер шлюза.
---
## Уточнения Опуса и ответы основного агента
1. **Второй клиент с другого ISP?** НЕТ. В распоряжении только ВМ
(5.172.178.213), но она рядом с платформой — с неё таймаутов нет, как
«второй клиент из другого сегмента» не подходит. Частичная замена уже есть:
контрольный канал YMQ с той же локали — 1 ошибка на 959 при 49 таймаутах на
Nubes (виноват локальный интернет → YMQ страдал бы так же). Полагаемся на
YMQ-канал; второй ISP — если появится доступ к VPS.
2. **Debug-под с NET_RAW?** Не проверяли; платформа managed, ноды недоступны,
привилегии урезаны — с высокой вероятностью запрещено. Под — alpine без
NET_RAW, серверный tcpdump не получится. Ограничиваемся nginx access-log +
cilium monitor + echo А/Б. Возможность kubectl debug проверяется одной
попыткой.
3. **Echo сразу?** НЕТ — только если фазы 0–2 не дадут однозначного ответа.
Доп. риск: новый NodePort для echo на managed может быть недоступен.
## Поправка основного агента
port-forward идёт через API-сервер (не тот сетевой путь) — он доказывает
только невиновность приложения, а не вину шлюза. Использовать формулировку
Опуса из таблицы доказательств (она корректна).