Согласен, выбор здесь в первую очередь определяется требованиями к безопасности. При этом на практике оба подхода могут сосуществовать в рамках одной системы: для менее чувствительных каналов может быть оправдана терминация TLS на Egress Gateway, тогда как для каналов с чувствительными данными и требованиями к end-to-end защите passthrough со сквозным шифрованием зачастую остается единственно допустимым вариантом.
Спасибо за подробный отзыв и высокую оценку статьи!
На самом деле многие моменты, о которых идет речь в статье, появились не из теории, а из вполне практических вопросов, с которыми мы сами столкнулись при проработке и реализации подобных архитектурных решений. Поэтому при подготовке материала хотелось не просто показать итоговую конфигурацию, а разобрать те детали и подводные камни, которые когда-то сами вызывали у нас вопросы и требовали отдельного исследования.
Буду очень рад, если статья поможет читателям быстрее разобраться в этой теме, избежать типичных сложностей и будет полезна при реализации похожих решений в собственных проектах.
Спасибо за комментарий — вопрос абсолютно по делу. Статья намеренно сосредоточена на функциональной и архитектурной стороне: как организовать взаимодействие с PostgreSQL через Service Mesh и как построить работу с TLS. Нагрузочные характеристики я здесь вынес за скобки, чтобы не смешивать два разных разговора — этот аспект, на мой взгляд, заслуживает отдельного рассмотрения.
Безусловно, любой дополнительный сетевой слой, включая sidecar-прокси и Egress Gateway, влияет и на потребление ресурсов кластера, и на сетевые характеристики (latency, throughput, время установления соединений, особенно при использовании TLS/mTLS).
Судя по интересу к теме, исследование производительности с измерением накладных расходов Envoy, влияния TLS/mTLS и сравнением разных архитектурных вариантов вполне может лечь в основу следующих публикаций.
Спасибо за комментарий.
Согласен, выбор здесь в первую очередь определяется требованиями к безопасности. При этом на практике оба подхода могут сосуществовать в рамках одной системы: для менее чувствительных каналов может быть оправдана терминация TLS на Egress Gateway, тогда как для каналов с чувствительными данными и требованиями к end-to-end защите passthrough со сквозным шифрованием зачастую остается единственно допустимым вариантом.
Спасибо за подробный отзыв и высокую оценку статьи!
На самом деле многие моменты, о которых идет речь в статье, появились не из теории, а из вполне практических вопросов, с которыми мы сами столкнулись при проработке и реализации подобных архитектурных решений. Поэтому при подготовке материала хотелось не просто показать итоговую конфигурацию, а разобрать те детали и подводные камни, которые когда-то сами вызывали у нас вопросы и требовали отдельного исследования.
Буду очень рад, если статья поможет читателям быстрее разобраться в этой теме, избежать типичных сложностей и будет полезна при реализации похожих решений в собственных проектах.
Спасибо за комментарий — вопрос абсолютно по делу. Статья намеренно сосредоточена на функциональной и архитектурной стороне: как организовать взаимодействие с PostgreSQL через Service Mesh и как построить работу с TLS. Нагрузочные характеристики я здесь вынес за скобки, чтобы не смешивать два разных разговора — этот аспект, на мой взгляд, заслуживает отдельного рассмотрения.
Безусловно, любой дополнительный сетевой слой, включая sidecar-прокси и Egress Gateway, влияет и на потребление ресурсов кластера, и на сетевые характеристики (latency, throughput, время установления соединений, особенно при использовании TLS/mTLS).
Судя по интересу к теме, исследование производительности с измерением накладных расходов Envoy, влияния TLS/mTLS и сравнением разных архитектурных вариантов вполне может лечь в основу следующих публикаций.