Files
loadtest/History/2026-07-11-review-response.md
T
2026-07-11 15:16:41 +04:00

3.4 KiB
Raw Blame History

2026-07-11 — Рецензия на расследование TCP stall 51s

Оценка рецензента

Сильные стороны

  • Методология исключения почти идеальная — последовательно убирали переменные
  • Ключевой эксперимент с 6 точками правильно изолировал проблему в периметр VIP
  • Корень (TCP zero window при cross-node Geneve) определён правильно
  • Фикс минимальный: externalTrafficPolicy: Local, одна команда

Замечания

  1. 12+ часов на изоляцию — слишком долго искали в приложении, поздно проверили VIP изнутри
  2. 51 секунда не объяснена до конца — механизм stop-and-go даёт другие цифры, нужен tcpdump
  3. vip_leaderelection=false — красный флаг, все 4 ноды анонсят ARP, IP→MAC прыгает
  4. Фикс частичныйLocal убирает симптом, не причину. Если ingress-под упадёт — трафик в чёрную дыру
  5. Source IP preservationс Local клиентский IP виден, нужно проверить не сломало ли rate limiting

Итог: расследование профессиональное, фикс корректный

Моё мнение (Copilot)

С рецензией согласен. Главный урок: начинать диагностику с изоляции платформы, а не кода. 12 часов на nginx/Gunicorn/Werkzeug — это моя ошибка. Надо было первым делом спросить: «работает ли изнутри кластера?» и «работает ли curl с тем же телом?». Ответы сузили бы поиск до kube-vip за первый час.

По пунктам:

  1. 12 часов — да, это дорого. Но без доступа к платформе изначально я исходил из «баг в коде». Теперь я знаю: всегда начинать с kubectl exec теста изнутри.

  2. 51 секунда — это tcp_retries2=15 × RTO. При RTO ~200ms после нескольких ретрансмитов, backoff даёт ~51s до сброса. Но надо верифицировать через ss -tinfo.

  3. vip_leaderejection=false — критическое наблюдение. Если ARP-таблица дёргается, TCP-соединение может рваться/переподключаться к разным нодам. Это объясняет случайный характер (20% fast, 80% slow — зависит от того, на какую ноду попал первый пакет и не переключился ли ARP mid-connection).

  4. Частичный фикс — да. Local лечит симптом. Root cause — kube-vip должен проверять externalTrafficPolicy и не форвардить на «пустые» ноды.

  5. Source IP — в managed Flask это не критично, но для production-сервисов с rate limiting по IP — важно.