doc: план сетевых экспериментов от DeepSeek V4 Flash (не Соннет) с поправками — nubes-network-bug-plan
This commit is contained in:
“Naeel”
@@ -0,0 +1,106 @@
|
||||
# План сетевых экспериментов: shared-sqs на Nubes
|
||||
|
||||
> ⚠️ **ПОМЕТКА: анализ от СЛАБОГО агента — DeepSeek V4 Flash (не Соннет).**
|
||||
> Пользователь по ошибке задал вопрос DeepSeek V4 Flash вместо Соннета.
|
||||
> План сохранён как рабочий черновик; критику основного агента см. в HISTORY
|
||||
> (2026-08-15) и в конце беседы. Технические неточности Flash см. ниже в разделах
|
||||
> «Поправки основного агента».
|
||||
|
||||
## Контекст
|
||||
|
||||
Платформа Nubes (managed Kubernetes). Сервис shared-sqs (SQS-очередь, Go,
|
||||
HTTP 4100). С ВМ внутри сети p50 = 6–8 мс, таймаутов нет. С интернета —
|
||||
проблемы.
|
||||
|
||||
**Два независимых явления:**
|
||||
1. Большие POST (>~1400 байт) виснут ~51 с — объясняется MTU/MSS 1448
|
||||
(пакеты 1488 > underlay 1450, дроп).
|
||||
2. Малые тела (512 байт): 49 из 888 запросов ReadTimeout 30 с, равномерно
|
||||
~1 в 37 с — MTU-моделью НЕ объясняется. Второй независимый источник потерь.
|
||||
|
||||
Топология: клиент → 185.247.187.151:32391 (kube-vip NodePort) →
|
||||
shturval-ingress-controller (nginx, ns ingress) → Cilium (pod mtu=1400) → под.
|
||||
|
||||
---
|
||||
|
||||
## 1. Echo-сервис или сырые TCP?
|
||||
|
||||
Сырых TCP недостаточно (проверяют только установление). Echo нужен, но:
|
||||
1. Тот же путь: тот же кластер, тот же ingress (отдельный host/path), тот же Cilium.
|
||||
2. Echo должен возвращать **тело запроса** (не «pong»), чтобы гонять тела
|
||||
1400/1500/2000 байт в обе стороны.
|
||||
3. Тот же network policy/namespace.
|
||||
|
||||
## 2. Как поймать момент таймаута
|
||||
|
||||
tcpdump с локали (нет доступа к нодам):
|
||||
- захват: `tcpdump -i any -nn -s 0 'host 185.247.187.151 and port 32391' -w /tmp/cap.pcap`
|
||||
- смотреть: SYN/ретрасмиты/RST/DUP ACK/сегменты >1450 с DF.
|
||||
- `ss -ti` на установленном соединении → реальный MSS.
|
||||
|
||||
Признаки:
|
||||
| Признак | Значение |
|
||||
|---|---|
|
||||
| SYN→SYN-ACK, потом тишина на данных | потери после установления (nginx/Cilium/под) |
|
||||
| ретрасмиты SYN | потери на установлении (kube-vip/NodePort/шлюз) |
|
||||
| ретрасмиты с растущим RTO (1,2,4,8,16,30+) | потеря пакета |
|
||||
| сегменты >1450 с DF без ответа | MTU-гипотеза |
|
||||
| RST | смотреть кто шлёт (платформа vs приложение) |
|
||||
|
||||
Вместо tcpdump на нодах — kubectl:
|
||||
- **cilium monitor --type drop** — дропы с причинами (MTU/policy/conntrack).
|
||||
- Логи nginx-ingress.
|
||||
|
||||
## 3. kube-vip / NodePort / nginx — проверка через kubectl
|
||||
|
||||
Декомпозиция по access-log nginx:
|
||||
- запись есть → дошло до nginx → проблема после nginx.
|
||||
- записи нет → потеря до nginx (kube-vip/NodePort/шлюз).
|
||||
|
||||
Метрики: `request_time` vs `upstream_response_time`:
|
||||
- request_time≈30с, upstream мал → задержка между nginx и клиентом (обратный путь/шлюз).
|
||||
- upstream≈30с → задержка nginx→под (Cilium/наш под).
|
||||
|
||||
Проверки:
|
||||
- `kubectl -n kube-system get pods -o wide | grep kube-vip` + логи.
|
||||
- `kubectl -n ingress get svc -o yaml` — nodePort 32391, externalTrafficPolicy
|
||||
(Local → обслуживает только нода с VIP; Cluster → SNAT через любую ноду).
|
||||
- access-log nginx с таймингами.
|
||||
|
||||
Дешёвый тест без приложения: GET на несуществующий путь через тот же NodePort
|
||||
(ответит nginx default backend) — если GET без тела стабилен, а POST теряется —
|
||||
потери в передаче данных.
|
||||
|
||||
## 4. План «дешевле → дороже»
|
||||
|
||||
1. Анализ access-log nginx за 30-мин тест (бесплатно).
|
||||
2. Connect-тест 32391: 1000+ соединений, мерить connect (бесплатно).
|
||||
3. GET без тела, 1000+ запросов (бесплатно).
|
||||
4. tcpdump с локали + стрельба POST 512 и 1500 байт, поймать 2–3 таймаута в pcap.
|
||||
5. Echo-сервис на ту же платформу (средняя стоимость).
|
||||
6. cilium monitor параллельно со стрельбой.
|
||||
7. Матрица размеров тел 512/1000/1400/1450/1500/2000 × 15+ мин через echo
|
||||
+ контрольный канал к YMQ.
|
||||
8. Тикет платформе с пачкой доказательств.
|
||||
|
||||
Критический вопрос: малые тела теряются ~1 раз в 37 с. Кандидаты: потери на
|
||||
шлюзе, ARP/leader kube-vip, conntrack GC Cilium. Шаги 4–6 должны их разделить.
|
||||
|
||||
---
|
||||
|
||||
## Поправки основного агента (GitHub Copilot)
|
||||
|
||||
1. **Ошибка Flash**: `kubectl exec -n kube-system deploy/cilium-operator -- cilium monitor`
|
||||
— неверно. cilium monitor запускается на **cilium-поде (DaemonSet)**:
|
||||
`kubectl exec -n kube-system <cilium-pod> -- cilium monitor --type drop`.
|
||||
И только на ноде, где живёт интересующий под.
|
||||
2. **Приоритеты**: echo-сервис — НИЖЕ по ценности, чем кажется. Уже известно,
|
||||
что с ВМ таймаутов нет → проблема между интернетом и внутренней сетью
|
||||
(kube-vip/NodePort/шлюз), а echo сидит внутри. Сначала: nginx-логи (ш.1),
|
||||
tcpdump (ш.4), cilium monitor (ш.6) — они дешёвые и локализуют лучше.
|
||||
3. **WSL-нюанс**: tcpdump на локальной WSL-машине может требовать sudo и
|
||||
конкретного интерфейса (`-i any` работает не всегда).
|
||||
4. **Шаг 7 дорогой**: 7 размеров × 15 мин ≈ 2 часа. Достаточно 512/1400/1450/
|
||||
1500/2000 × 10 мин, порог искать бинарно.
|
||||
5. **Шаг 3 неточен**: GET на несуществующий путь того же host может уйти в наш
|
||||
под (его router отдаст 400/404) — «приложение не участвует» не гарантировано.
|
||||
Reference in New Issue
Block a user