# Запрос к Opus: валидация MSS Clamping плана

**Дата:** 2026-07-13

---

## Контекст

Кластер: bare-metal Kubernetes, 4 ноды, Cilium CNI (Geneve-туннель), kube-vip для VIP.
Штурвал управляет ingress через Helm-чарт (`shturval-ingress-controller-2.12.1`).

## Проблема

При `externalTrafficPolicy: Cluster` большие файлы (>5 MB) вызывают TCP stall на 51 секунду.
Диагностика: cross-node Geneve-туннель добавляет overhead (~50 байт) → пакет > MTU 1500 → ICMP Frag Needed блокируется → TCP RTO backoff.

Текущий костыль: `externalTrafficPolicy: Local` + `kubectl scale replicas=4` (Штурвал сбрасывает на 2 каждые ~час).

## Предлагаемое решение

Вместо костыля — выставить MTU в Cilium ConfigMap:

```yaml
# kubectl edit configmap -n kube-system cilium-config
mtu: 1450
```

После этого:
1. Вернуть `externalTrafficPolicy: Cluster`
2. Оставить ingress `replicaCount: 2` (стоковое значение Штурвала)
3. Никаких ручных scale

## Вопросы к Opus

**Читать только:** `docs/MSS-CLAMPING-PLAN.md`, `docs/KUBEVIP-EXTERNAL-TRAFFIC-POLICY.md`, `docs/INGRESS-SOLUTIONS.md`.

1. Корректно ли решение? Есть ли подводные камни при смене MTU через Cilium ConfigMap на работающем кластере?
2. Нужно ли что-то ещё кроме `mtu: 1450`? (например, перезапуск подов, пересоздание туннелей)
3. Как проверить что MSS clamping реально работает после изменения? (конкретные команды)
4. Есть ли риск для других сервисов (Keycloak, etc.) при смене MTU?
5. Если Cilium ConfigMap недоступен — iptables-вариант (`TCPMSS --clamp-mss-to-pmtu`) равноценен? На какую ноду вешать правило?
6. Итоговый вердикт: это правильный путь, или есть более грамотный вариант?

**Не лезть:** в код приложения, в TMP, в History (кроме указанных трёх файлов).