Envoy Tap Filter: перехватываем и анализируем HTTP-трафик в Istio Service Mesh
Привет, Хабр! Меня зовут Валентин, я DevOps-инженер команды Platform V Kintsugi . Мы развиваем облачный сервис и часто сталкиваемся с задачами эксплуатации распределённых систем, созданных на основе Kubernetes и Istio/ Platform V Synapse Service Mesh . Одна из самых неприятных задач — поиск проблем в обработке запроса внутри Service Mesh на базе Envoy. Типичная ситуация: один из сервисов внезапно начинает получать 503, появляются неожиданные повторы, запросы перестают проходить из-за AuthorizationPolicy или уходят не в тот upstream. При этом само приложение работает нормально, в его журналах нет ошибок, а конфигурация Istio, на первый взгляд, выглядит корректной. Мы начинаем разбираться и смотрим access-журналы. Видим результат обработки запроса, но не всегда понимаем, что именно Envoy получил, какие заголовки и тело запроса он увидел, какие фильтры уже успели его изменить и почему в итоге запрос пошёл именно по этому пути. Сетевой дамп тоже не всегда помогает. При включённом mTLS на уровне сети мы можем увидеть зашифрованный трафик, но не тот HTTP-запрос, который уже расшифровал и обрабатывает Envoy. Получается неприятный диагностический разрыв, когда приложение видит одно, сеть показывает другое, а решение принимает Envoy. Возникает главный вопрос, что на самом деле видит Envoy и приложение в момент обработки HTTP-запроса? В этой статье разберём, как с помощью Envoy Tap Filter заглянуть внутрь этого процесса — перехватить HTTP-запрос и ответ уже после расшифровки mTLS, отфильтровать только нужный трафик и сохранить результат в файл. На практике посмотрим, как подключить Tap Filter к Istio через EnvoyFilter, настроить точечный отбор запросов, выбрать формат сохранения тела и проанализировать полученные JSON-файлы. В результате получим инструмент для тех случаев, когда стандартных журналов недостаточно, а сетевой дамп показывает только зашифрованный транспорт. Читать далее