fix: debug=False, force read body, bump 1.0.6→1.0.7

History/sonnet-question-kubevip.md

@@ -0,0 +1,35 @@
+# Вопрос Соннету: найти ОДНУ точку отказа внутри k8s
+
+## Данные (без догадок)
+
+| Источник | Цель | Результат |
+|----------|------|-----------|
+| Под внутри k8s → VIP 185.247.187.151:443 (100KB POST) | ✅ 10/10 |
+| Под внутри k8s → ingress ClusterIP:443 | ✅ 10/10 |
+| Под внутри k8s → под напрямую:5000 | ✅ 10/10 |
+| Снаружи (интернет) → VIP:443 | ❌ 3-5/10 (TimeoutError) |
+| Снаружи → прямой IP ВМ:443 (не k8s) | ✅ 0 таймаутов |
+
+## Инфраструктура (только k8s)
+- Shturval 2.12.1, Cilium CNI
+- kube-vip DaemonSet (ARP mode, vip_leaderelection=false) на ВСЕХ 4 нодах
+- nginx ingress (hostPort 443), 2 реплики на 2 из 4 worker-нод
+- VIP 185.247.187.151 на ingress LoadBalancer сервисе
+- Pod → VIP работает 100% (CNI маршрутизация в обход внешнего роутера)
+
+## Что уже исключено
+- Flask — работает
+- nginx ingress — работает
+- ModSecurity — DetectionOnly
+- conntrack — чистый
+- MSS/MTU — не помогло
+- proxy_request_buffering off — частично улучшило но не решило
+
+## Гипотеза
+Внешний роутер получает ARP-ответы от ВСЕХ 4 нод (kube-vip без лидера). Часть нод без ingress пода. Когда роутер выбирает MAC ноды без ingress → connection timeout.
+
+## Вопрос
+Как внутри k8s (не трогая внешний роутер/ВМ) сделать так, чтобы внешние соединения на VIP работали 100%?
+- Можно ли ограничить kube-vip DaemonSet только нодами с ingress?
+- Можно ли заставить kube-vip держать VIP только на ОДНОЙ ноде (где есть ingress)?
+- Есть ли другой механизм в kube-vip/Shturval для фикса ARP-флаппинга?