Service mesh решает реальные задачи - mTLS между сервисами, управление трафиком, наблюд... — 8 июня 2026 г. в 09:00:16.887
Service mesh решает реальные задачи - mTLS между сервисами, управление трафиком, наблюдаемость, - но нужен не каждому кластеру. Несколько лет классический sidecar-подход (Envoy в каждый pod) добавлял столько накладных расходов и операционной сложности, что многие команды от него отказывались: по данным CNCF, доля sidecar-меша в 2024 году снизилась. Каждый pod требовал прокси, а обновление меша означало перезапуск приложений. Ситуацию изменил ambient mode: с конца 2024 года Istio умеет работать без sidecar. Трафик разделён на два уровня: L4 (mTLS, телеметрия) закрывает общий ztunnel на узле, а L7-прокси разворачивается только там, где нужна маршрутизация HTTP. Это убрало главный барьер - overhead на каждый pod. Service mesh оправдан, когда у вас десятки и сотни сервисов, нужен mTLS по умолчанию, канареечные выкатки и единая наблюдаемость. Для пары сервисов это избыточно: проще обойтись API gateway и сетевыми правилами. Развернуть кластер Kubernetes под такую архитектуру.