2.1 KiB
2.1 KiB
Вопрос Соннету: найти ОДНУ точку отказа внутри 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-флаппинга?