docs: сортировка History по темам (sonnet, opus, llm, sse, ux-frontend, upload, infra, plans, tests, base, code-fixes)

2026-08-24 15:23:31 +03:00
parent 25e4b46e76
commit db7cdbdd84
69 changed files with 0 additions and 0 deletions
@@ -0,0 +1,44 @@
+# Запрос к 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 (кроме указанных трёх файлов).
@@ -0,0 +1,35 @@
+# Opus: проверка PROBLEM-AND-SOLUTION.md на ошибки
+
+**Дата:** 2026-07-13
+
+---
+
+## Найденные ошибки
+
+### 1. TCP backoff — неправильные числа
+
+**Было:** `1с → 3с → 7с → 15с → 25с = 51с` — выдумано.
+
+**Правильно:** начальный RTO = 200ms, удвоение:
+```
+0.2с → 0.4с → 0.8с → 1.6с → 3.2с → 6.4с → 12.8с → 25.6с = 51с
+```
+8 ретрансмитов от 200ms = ровно 51 секунда (Linux kernel default).
+
+### 2. DSR — неверное объяснение причины stall
+
+**Было:** «двойной инкапсуляции return-трафика (главная причина stall)».
+
+**Правильно:** stall на **входящем** трафике (клиент → pod), а не на return. DSR оптимизирует обратный путь, но не решает проблему inbound MTU black-hole.
+
+### 3. Ping измеряет pod MTU, не underlay
+
+Утверждение что `ping -M do` доказывает underlay = 1450 — неточно. Ping из пода измеряет MTU пода (1450 = 1500 − 50 Cilium). Физический underlay = 1450 подтверждён эмпирически (фикс сработал), а не прямым замером.
+
+## Что верно
+
+- Geneve overhead 50 байт: outer IP(20) + UDP(8) + Geneve(8) + inner Eth(14) = 50 ✓
+- `mtu: 1450` → pod MTU = 1400 ✓
+- `rollout restart ds/cilium` обязателен ✓
+- iptables может не работать с eBPF dataplane ✓
+- Корень проблемы и решение верны ✓
@@ -0,0 +1,31 @@
+# Opus: финальная проверка PROBLEM-AND-SOLUTION.md
+
+**Дата:** 2026-07-13
+
+---
+
+## Вердикт
+
+Документ технически добротный. Диагноз и корневое решение (`mtu: 1450` + `Cluster` + `replicaCount: 2`) — правильные.
+
+## Исправлено
+
+1. **Ethernet 14** — уточнено: «инкапсулируемый L2-кадр 14» (внутренний Ethernet, не внешний)
+2. **51с = прикладной таймаут** — смягчено: «браузер/curl разрывает ожидание» вместо «соединение разрывается»
+
+## Что подтверждено как верное
+
+- PMTU blackhole как причина — классический сценарий
+- Cilium: `mtu` в configmap = underlay девайса, pod MTU = mtu − overhead
+- Geneve overhead = 50 байт (внешний IP 20 + UDP 8 + Geneve 8 + L2 14)
+- Решение: `mtu: 1450` → pod 1400 → Geneve-пакет 1450 → влазит в path 1450
+- `rollout restart ds/cilium` обязателен
+- `externalTrafficPolicy: Local` → `Cluster` после фикса MTU
+- DSR решает только обратный путь, stall на inbound
+- iptables может не работать с eBPF dataplane
+
+## Мелкие замечания (не исправлены, допустимы)
+
+- 200ms RTO — корректно для сценария (уже установленное TCP-соединение)
+- Тип туннеля (Geneve vs VXLAN) — overhead одинаков (50), математика не меняется
+- Замеры из таблицы результатов — эмпирические, из кода не подтвердить
@@ -0,0 +1,77 @@
+# Opus: валидация MSS Clamping плана
+
+**Дата:** 2026-07-13
+
+---
+
+## Ключевое исправление
+
+В плане ошибка: `mtu: 1450` в cilium-config — это MTU **underlay-сети**, не туннеля. Cilium сам вычитает 50 байт на Geneve:
+
+```
+mtu: 1450  →  tunnel MTU = 1450 − 50 = 1400
+```
+
+По умолчанию Cilium автодетектит underlay 1500 → туннель 1450. Если stall всё равно есть — underlay реально < 1500. **Число надо измерить, не гадать.**
+
+---
+
+## Ответы на вопросы
+
+### 1. Корректно ли решение?
+
+Да, направление верное. Но:
+- ConfigMap сам не применяется — нужен `rollout restart ds/cilium`
+- Число 1450 — гипотеза, нужен замер между нодами
+- `mtu` глобален на весь кластер
+- Существующие TCP-соединения не поменяют MSS — только новые
+
+### 2. Что ещё нужно?
+
+1. Измерить underlay MTU: `ping -M do -s 1472 <ip_другой_ноды>` (уменьшать пока не пройдёт)
+2. `kubectl rollout restart ds/cilium -n kube-system`
+3. Пересоздать поды приложения (ingress, drhider)
+4. Вернуть `externalTrafficPolicy: Cluster`
+
+### 3. Как проверить?
+
+```bash
+# Измерить до:
+ping -M do -s 1472 <ip_другой_ноды>
+tracepath <ip_другой_ноды>
+
+# После изменения:
+kubectl -n kube-system exec ds/cilium -- cilium-dbg status | grep -i mtu
+ip link show | grep -E 'cilium|geneve'
+tcpdump -ni any 'tcp[tcpflags] & tcp-syn != 0' -vv | grep mss
+
+# Функционально: файл >5 MB без паузы
+```
+
+### 4. Риск для других сервисов?
+
+Понижение MTU безопасно (меньше = консервативнее). Небольшой рост числа пакетов, микро-потеря throughput. Функционально ничего не ломает. Рестарт агентов — возможны короткие блипы, лучше в окно.
+
+### 5. iptables равноценен?
+
+**Нет.** Cilium с eBPF обходит netfilter FORWARD — правило может не видеть пакеты. Надёжнее `cilium-config`. Если iptables — то на всех 4 нодах (kube-vip раздаёт VIP на все).
+
+### 6. Вердикт
+
+Путь правильный. Уточнённый план:
+1. Измерить path MTU между нодами
+2. Выставить `mtu` = измеренное значение (вероятно < 1500)
+3. Рестарт агентов + подов
+4. Вернуть `Cluster` policy
+
+При `Cluster` проблема реплик исчезает сама (2 хватает).
+
+---
+
+## Моё мнение
+
+Opus прав. План нужно дополнить **замером**. Без замера `1450` — пальцем в небо. Обновлю `MSS-CLAMPING-PLAN.md` с учётом:
+- Добавить шаг 0: измерение path MTU
+- Исправить формулу: `mtu` = underlay, туннель = `mtu - 50`
+- Добавить `rollout restart ds/cilium` + рестарт подов
+- Убрать iptables как основной вариант (ненадёжен с Cilium)