Files
drhider/History/2026-07-13-opus-query-mss-clamping.md
2026-07-13 17:22:54 +04:00

2.4 KiB

Запрос к 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:

# 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 (кроме указанных трёх файлов).