docs: PROBLEM-AND-SOLUTION v2 — полный анализ Опуса 4.8
Deploy drhider / validate (push) Waiting to run

This commit is contained in:
2026-07-13 17:49:42 +04:00
parent 68571fbbcd
commit c25b22cfe6
+53 -11
View File
@@ -66,20 +66,62 @@ Underlay MTU = 1450 → Geneve-туннель = 1400 → поды = 1400.
--- ---
## Что сказал Opus (краткий пересказ) ## Полный анализ Опуса 4.8
**Подтвердил:** направление правильное — чинить корень (PMTU blackhole), а не симптом (Local + 4 реплики). ### Главное уточнение
**Уточнил:** `mtu` в cilium-config — это MTU **underlay-сети** (физической сети между нодами), а НЕ туннеля. Cilium сам вычитает 50 байт на Geneve:
1. `mtu` в cilium-config — это underlay-MTU. Cilium сам вычитает 50 байт. `mtu: 1450` → туннель 1400. ```
2. ConfigMap сам не применяется — нужен `rollout restart ds/cilium`. mtu: 1450 → tunnel/pod MTU = 1450 50 = 1400
3. iptables как fallback ненадёжен с Cilium (eBPF обходит netfilter FORWARD). ```
4. Понижение MTU безопасно, но число надо измерять, а не гадать.
5. Итоговое состояние `Cluster` + корректный MTU + `replicaCount: 2` — чистое и согласованное.
--- По умолчанию Cilium автодетектит underlay 1500 → туннель 1450. Если stall всё равно происходит — значит реальный underlay < 1500. Поэтому нужно измерять, не гадать.
## Моё мнение ### Подводные камни
Замер сделан, число подтверждено. План готов к передаче девопсу. Это одно изменение — не костыль, а исправление конфигурации кластера под реальный underlay MTU. Делать. - **ConfigMap сам не применяется.** Нужен `kubectl rollout restart ds/cilium -n kube-system` — без этого агенты продолжат работать со старым MTU.
- **Существующие TCP-соединения не поменяют MSS** — эффект только на новые соединения после рестарта.
- **Нужен рестарт подов приложения** (ingress, drhider) — veth-интерфейс пода получает MTU при создании. Для транзитного (ingress) трафика обновления маршрутов ноды обычно достаточно на новых соединениях, но для чистоты — пересоздать.
- Пересоздавать туннели вручную не нужно — рестарт агента переинициализирует `cilium_geneve` device.
- **Установленный вручную `externalTrafficPolicy: Local`** надо вернуть на `Cluster` через `kubectl patch` (ставился не через Helm, сам не откатится).
### Риски для других сервисов
`mtu` — параметр всего кластера, влияет на ВСЕ поды и ВСЕ ноды. **Понижение MTU безопасно** (меньше = консервативнее). Максимум — небольшой рост числа пакетов / микроскопическая потеря throughput. Функционально ничего не ломает.
Риск в момент раскатки: `rollout restart ds/cilium` перезапускает агенты по нодам. eBPF-датаплейн переживает рестарт (трафик идёт), но возможны короткие блипы. Лучше делать в окно.
Настоящий риск — только если поставить **слишком высокий** MTU (проблема останется) или **слишком низкий без нужды** (лишний оверхед). Поэтому критически важен замер.
### iptables как альтернатива
**Не равноценен и с Cilium может не сработать.** Cilium с eBPF-датаплейном / kube-proxy replacement обходит netfilter `FORWARD` для трафика подов. Правило в `mangle/FORWARD` может просто не видеть нужные пакеты.
`--clamp-mss-to-pmtu` берёт MSS из PMTU исходящего маршрута. Если MTU маршрута неверен — клампинг будет неправильным. Надёжнее явный `--set-mss 1400`.
На какую ноду: kube-vip раздаёт VIP на **все 4 ноды** → правило нужно на всех (DaemonSet/node-level).
Вывод: iptables — костыль-fallback, который с Cilium может оказаться нерабочим. **Правильный путь — `cilium-config`**, потому что Cilium ставит `advmss` на маршрутах (тот же MSS clamping, но нативно в eBPF-датаплейне).
### Верификация после изменения
```bash
# Проверить что Cilium применил MTU
kubectl -n kube-system exec ds/cilium -- cilium-dbg status | grep -i mtu
ip link show | grep -E 'cilium|geneve' # MTU tunnel-девайса
ip route show | grep -E 'advmss|mtu' # advmss на cilium-маршрутах
# Проверить MSS в SYN-пакетах
tcpdump -ni any 'tcp[tcpflags] & tcp-syn != 0' -vv | grep mss
```
Функционально: файл >5 MB через drhider — без паузы 51с. F5 без ERR_TIMED_OUT.
### Более грамотная альтернатива на будущее
Cilium **DSR + `kubeProxyReplacement`** убирает cross-node SNAT на обратном пути целиком — двойной инкапсуляции return-трафика (главная причина stall) просто не возникает. Но это меняет всю сетевую конфигурацию, для быстрого фикса — избыточно.
### Итоговый вердикт
Путь правильный (фикс корня, а не симптома). Конечное состояние `Cluster + корректный MTU + replicaCount: 2` — чистое и согласованное: убирает разом и ручной scale, и Local-костыль.