Service Mesh глазами бэкендера: умный дирижёр микросервисного оркестра

[Evgenym]

Не совсем понял, что будет с уже текущими сервисами внутри кластера?

У меня есть кластер, там взаимодействие подов идет через обычные сервисы. Если я ставлю Истио, то что будет? Коммуникация через обычные сервисы продолжит работать? Можно будет гнать траффик как через виртуальные сервисы Истио, так и через обычные? Или нужно будет перенастроить все на Истио?

Если у меня есть network policy, как с ними будет работать Истио?

[usharik]

1. Istio не внедряет sidecar контейнеры в поды, которые были в созданы до установки и настройки Istio

2. После установки Istio во все новые поды sidecar контейнер будет внедряться, т.е. их трафиком уже будет управлять Istio

3. Если пересоздать все поды, то все они  окажутся под управлением Istio.

4. По умолчанию поды с и без sidecar контейнером могут взаимодействовать между собой. Думаю так и будет при дефолтных настройках, но если включить mTLS или egress, то появятся ограничения.

В целом Istio хорошо приспособлен к постепенному развертыванию в кластере где его раньше не использовали.

[Nicknnn]

Вообще в дефолтной инсталяции istio добавляет sidecar только в неймспейсы и lebel istio-injection (или както так)

[usharik]

Именно так.

[frkntony]

Если в namespace или project включен флаг ниже, то все новые поды получат сайдкар, а значит при установке будет помещены в Serivce Mesh.

istio-injection=enabled

Чтобы старые сервисы не попадали в Service Mesh, нужно добавить аннотацию в deployment

sidecar.istio.io/inject: "false"

Можно плавно вводить микросервисы в Istio. Например, если добавишь аннотацию

traffic.sidecar.istio.io/excludeOutboundPorts: "9092"
// при 
sidecar.istio.io/inject: "true"

то сервисы с Istio-прокси смогут общаться с сервисами без сайдкара (например, с kafka), а так же внешними серверами через этот порт, игнорируя Istio. Это дает гибкость, можно поэтапно подключать сервисы к Service Mesh. Маршрутизация внутри Istio хорошо продумана, сложно только первый раз понять как работает.

У меня на работе Service Mesh юзают только для двух вещей
1) Он обрубает все коннекты по дефолту и в архитектурном чеклисте это помечено как секьюрно
2) Работа с внешними сервисами через mTLS
3) Раньше еще фишки Observability использовали, но потом пришлось от них отказаться из-за внутренних бизнес-требований.

[usharik]

В моем случае главным поводом к использованию было mTLS для шифрования всего внутреннего трафика

[kokafff]

У вас устаревший код. mTLS включается не так в актуальной версии. Плюс апишки alphav3. Не вводите людей из 2025 в заблуждение.

[usharik]

Спасибо за уточнение. Я исходил из того когда, который в настоящее время использую на ряде проектов. Это скорее хорошо чем плохо, но API тут меняется с какой-то немыслимой скоростью.

В ближайшее время проверим и исправим статью.

[jenki]

Проще говоря, Service Mesh – это «умная» сеть для сервисов, которая управляет их взаимодействием без необходимости вносить изменения в сам код.

Как бы вам не хотелось, но маршрутизацией, каковой она должна быть по вашему замыслу, вам придётся управлять. Она сама себя не настроит, её надо описывать. Иногда редоктировать.

Она позволяет маршрутизировать трафик, обеспечивать его безопасность, управлять отказоустойчивостью и проводить мониторинг работы сервисов.

В статье идёт описание работы Service Mesh в среде Kubernetes. Только маршрутизация трафиком, управление отказоустойчивостью и даже мониторинг довольно хорошо уже реализовано в это среде.

Разрабатывать каждый сервис так, чтобы он сам по себе решал задачи маршрутизации, шифрования и мониторинга трафика, конечно, возможно. Однако это ведёт к усложнению кода, увеличивает риск ошибок и делает систему менее управляемой. Гораздо удобнее вынести эти задачи в унифицированное коробочное решение, которым можно централизованно управлять.

Но если у вас есть Kubernetes, там уже есть маршрутизация и немного мониторинга. Всё это без усложнения кода.

Многие компании пытались решать проблемы маршрутизации, балансировки и отказоустойчивости по-разному

Многое из описанного решается средствами среды Kubernetes, причём, довольно просто. Намного и намного проще чем с помощью Istio. Когда используется облачное развёртывание среды Kubernetes, можно использовать облачные балансировщики, которые по своим возможностям будут куда лучше того, что предоставляет Istio.

Если вы уже работаете с Kubernetes и микросервисной архитектурой, использование Service Mesh – это логичный следующий шаг.

Можно объяснить почему?
1 Почему надо использовать дополнительный слой маршрутизации и балансировки к уже имеющемуся by design?
2 Какой логикой надо надо пользоваться для принятия такого решения?
3 Не видите ли тут нарушения KISS?