Комментарии 6
Очень интересно, но при внедрении istio и обмазывание envoy, насколько увеличивается потребление ресурсов кластера в зависимости от трафика и насколько увеличивается latency при использовании сертификатов. Всегда когда внедряют подобные инструменты в явном виде описывают - ванильный постгрес с репликами vs постгрес в кубере с envoy, раз тест, два тест - ванильный постгрес с сертификатами и в кубере и с envoy - вот сравнительная таблица и в наших тестах победил конечно же.....
Спасибо за комментарий — вопрос абсолютно по делу. Статья намеренно сосредоточена на функциональной и архитектурной стороне: как организовать взаимодействие с PostgreSQL через Service Mesh и как построить работу с TLS. Нагрузочные характеристики я здесь вынес за скобки, чтобы не смешивать два разных разговора — этот аспект, на мой взгляд, заслуживает отдельного рассмотрения.
Безусловно, любой дополнительный сетевой слой, включая sidecar-прокси и Egress Gateway, влияет и на потребление ресурсов кластера, и на сетевые характеристики (latency, throughput, время установления соединений, особенно при использовании TLS/mTLS).
Судя по интересу к теме, исследование производительности с измерением накладных расходов Envoy, влияния TLS/mTLS и сравнением разных архитектурных вариантов вполне может лечь в основу следующих публикаций.
Очень крутой, детальный разбор! Особенно ценно, что на контрасте показаны два подхода: когда TLS тащит приложение и когда эту задачу берёт на себя инфраструктура через Service Mesh.
Больше всего впечатлила практическая часть с разбором нюансов протокола PostgreSQL — момент про SSLRequest и то, почему protocol: tcp ломает соединение, а protocol: postgres в Synapse решает проблему, просто блестяще раскрыт. Раньше не задумывался, насколько критично учитывать специфику handshake на уровне прокси, а тут всё разложено по полочкам с дампами и логикой обмена сообщениями.
Сильной стороной материала считаю чёткое выделение ограничений подхода с терминацией TLS на Egress Gateway — про потерю end‑to‑end шифрования и жёсткие рамки маршрутизации в Istio сказано прямо, без попыток приукрасить. Это как раз то, чего часто не хватает в технических статьях: не только «как сделать», но и «где это может аукнуться».
Отдельно радует, что всё подкреплено конкретными манифестами и выводами из реальных логов — сразу видно, как это работает «под капотом». Формат с параллельным разбором конфигов и их смысла делает статью отличным референсом для тех, кто внедряет подобные схемы у себя.
В целом — отличный кейс, который закрывает ощутимый пробел в материалах по безопасной интеграции микросервисов с БД. Уже прикинул, какие моменты из этого можно адаптировать в наших проектах. Спасибо автору за глубину и честность в описании подводных камней!
Спасибо за подробный отзыв и высокую оценку статьи!
На самом деле многие моменты, о которых идет речь в статье, появились не из теории, а из вполне практических вопросов, с которыми мы сами столкнулись при проработке и реализации подобных архитектурных решений. Поэтому при подготовке материала хотелось не просто показать итоговую конфигурацию, а разобрать те детали и подводные камни, которые когда-то сами вызывали у нас вопросы и требовали отдельного исследования.
Буду очень рад, если статья поможет читателям быстрее разобраться в этой теме, избежать типичных сложностей и будет полезна при реализации похожих решений в собственных проектах.
Passthrough-режим, с которого начинают авторы, часто недооценивают: он даёт сквозное шифрование, при котором даже сам mesh не видит содержимое трафика до базы данных. Как только вы переходите к терминации TLS на Egress Gateway, шлюз становится посредником – доверенным, но всё же. В средах с высокими требованиями этот компромисс между наблюдаемостью трафика и сквозной защитой нередко остаётся за кадром при проектировании.
Спасибо за комментарий.
Согласен, выбор здесь в первую очередь определяется требованиями к безопасности. При этом на практике оба подхода могут сосуществовать в рамках одной системы: для менее чувствительных каналов может быть оправдана терминация TLS на Egress Gateway, тогда как для каналов с чувствительными данными и требованиями к end-to-end защите passthrough со сквозным шифрованием зачастую остается единственно допустимым вариантом.
Как мы строили безопасную микросервисную архитектуру с Service Mesh: интеграция с базами данных