SQS-service/doc/thinking/nubes-ticket.md

Тикет в 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.

Дополнение (полный read-only обзор кластера 2026-08-15):

• Внутри кластера цикла с периодом 31–33с НЕТ нигде: kube-vip пишет ошибки каждые 1с, provider/services-controller — каждые 5 мин. Таймер 31с — на внешнем шлюзе (вне кластера), что совпадает с потерей на участке клиент→ingress.
• kube-vip поды 34 дня без рестарта: leader election бьётся в namespace удалённого инстанса (0a42bef3-...) — вероятно, кэш удалённого LB-сервиса; перезапуск DaemonSet убрал бы этот шум.
• ConfigMap kubevip в ns kube-vip отсутствует полностью — пулы LB никогда не были настроены; VIP держится только аннотацией vipHost.

Как воспроизвести: приложить tests/ (long_compare_local.py, tcp_mtu_probe.py) или: цикл send/receive/delete 512б с retries=0 и read_timeout=30 с внешней машины → сбой каждые ~31с.