3.4 KiB
2026-07-11 — Рецензия на расследование TCP stall 51s
Оценка рецензента
Сильные стороны
- Методология исключения почти идеальная — последовательно убирали переменные
- Ключевой эксперимент с 6 точками правильно изолировал проблему в периметр VIP
- Корень (TCP zero window при cross-node Geneve) определён правильно
- Фикс минимальный:
externalTrafficPolicy: Local, одна команда
Замечания
- 12+ часов на изоляцию — слишком долго искали в приложении, поздно проверили VIP изнутри
- 51 секунда не объяснена до конца — механизм stop-and-go даёт другие цифры, нужен tcpdump
vip_leaderelection=false— красный флаг, все 4 ноды анонсят ARP, IP→MAC прыгает- Фикс частичный —
Localубирает симптом, не причину. Если ingress-под упадёт — трафик в чёрную дыру - Source IP preservation — с
Localклиентский IP виден, нужно проверить не сломало ли rate limiting
Итог: расследование профессиональное, фикс корректный
Моё мнение (Copilot)
С рецензией согласен. Главный урок: начинать диагностику с изоляции платформы, а не кода. 12 часов на nginx/Gunicorn/Werkzeug — это моя ошибка. Надо было первым делом спросить: «работает ли изнутри кластера?» и «работает ли curl с тем же телом?». Ответы сузили бы поиск до kube-vip за первый час.
По пунктам:
-
12 часов — да, это дорого. Но без доступа к платформе изначально я исходил из «баг в коде». Теперь я знаю: всегда начинать с
kubectl execтеста изнутри. -
51 секунда — это
tcp_retries2=15× RTO. При RTO ~200ms после нескольких ретрансмитов, backoff даёт ~51s до сброса. Но надо верифицировать черезss -tinfo. -
vip_leaderejection=false — критическое наблюдение. Если ARP-таблица дёргается, TCP-соединение может рваться/переподключаться к разным нодам. Это объясняет случайный характер (20% fast, 80% slow — зависит от того, на какую ноду попал первый пакет и не переключился ли ARP mid-connection).
-
Частичный фикс — да.
Localлечит симптом. Root cause — kube-vip должен проверятьexternalTrafficPolicyи не форвардить на «пустые» ноды. -
Source IP — в managed Flask это не критично, но для production-сервисов с rate limiting по IP — важно.