doc: черновик тикета в Nubes (явления A/B, 6 доказательств); все фазы плана выполнены

doc/thinking/nubes-ticket.md

@@ -0,0 +1,55 @@
+# Тикет в Nubes: периодические сетевые таймауты внешнего пути (shared-sqs)
+
+**Дата:** 2026-08-15
+**Сервис:** shared-sqs (SQS-очередь, Go), инстанс iot-naeel,
+ns f1ffb134-7d16-45bd-8bef-69f6ec8ab33c, deployment containerk8s.
+**Внешний адрес:** 185.247.187.151:443 (домен sqs.containerk8s.dev.nubes.ru,
+NodePort 32391), kube-vip, ingress shturval-ingress-controller.
+
+## Явление A: большие POST (~51с зависания)
+
+- MSS, анонсируемый шлюзом = 1448 (проверено на живом соединении), MTU пода
+  1400, underlay MTU 1450. Сегменты 1488 байт превышают underlay → дроп при DF.
+- PMTUD не работает: ICMP Type 3 Code 4 до клиента не доходит.
+- Воспроизводится POST с телом >~1.4KB: зависание ~51с (экспонента ретрасмитов
+  1-2-4-8-16с).
+- Просьба: исправить MSS анонса на шлюзе (или включить MSS clamping /
+  PMTUD на внешнем шлюзе).
+
+## Явление B: периодические таймауты на МАЛЫХ телах (512 байт) — ГЛАВНОЕ
+
+**Симптом:** с внешней машины SQS-операции с телом 512 байт получают
+ReadTimeout 30с с периодом **31.2–32.9с** (внутри прогона стабилен до 0.1с;
+18+9+8 интервалов измерены в трёх прогонах). Параллельный канал Yandex YMQ с
+той же машины — 1 ошибка на 959 запросов.
+
+**Доказательства (все — в HISTORY/2026-08-14-session-log.md):**
+1. **nginx access-log** за 30-мин тест: 862×200, **max request_time 68мс,
+   499=0**. nginx все запросы обрабатывает за миллисекунды.
+2. **Серверный tcpdump** (ephemeral-контейнер в поде shared-sqs, eth0:4100):
+   в момент каждого таймаута — «дыра» 29.5с БЕЗ единого пакета: ни SYN, ни
+   данных, ни ретрансмитов. Зависший запрос **не доходит до пода** (иначе был
+   бы виден). 8 дыр на 8 сбоев, период 31.2с.
+3. **cilium monitor --type drop** на ноде пода во время теста — **0 дропов**.
+4. **kubectl port-forward** (в обход шлюза) — тот же клиент, та же нагрузка:
+   **24977 раундов, 0 сбоев**. Приложение невиновно.
+5. С ВМ (внутренняя сеть): таймаутов нет вообще (p50 6–8мс).
+6. **kube-vip в ошибках**: все 4 vip-пода каждую ~1с не могут создать leader
+   election record (namespaces "0a42bef3-7ce1-42b7-aa80-4274c4d9568f" not found),
+   provider — «failed to ensure load balancer: no address pools could be found»
+   (ретраи с backoff до 5 мин). vipHost закреплён за control-plane нодой.
+
+**Вывод:** запросы периодически теряются на участке внешний клиент → ingress
+(шлюз/VIP/kube-vip/NodePort платформы). Внутри кластера потерь нет. Период
+31–33с указывает на платформенный таймер/цикл (сессионный таймер шлюза,
+kube-vip announce, conntrack GC).
+
+**Просьба:**
+1. Проверить конфигурацию kube-vip (leader election в несуществующем
+   namespace, address pools) и внешний шлюз 185.247.187.151.
+2. Объяснить/устранить периодический сбой каждые ~31с.
+3. Исправить MSS анонс (1448 → ≤1410) для явления A.
+
+**Как воспроизвести:** приложить tests/ (long_compare_local.py, tcp_mtu_probe.py)
+или: цикл send/receive/delete 512б с retries=0 и read_timeout=30 с внешней
+машины → сбой каждые ~31с.