Что такое Service Mesh?

Введение в Service Mesh

Service mesh — это настраиваемая инфраструктура, используемая для управления межсервисными коммуникациями в микросервисных системах. Её цель — обработка трафика между микросервисами, также известного как восточно-западный трафик.

В облачных приложениях приложение может состоять из сотен сервисов. Каждый сервис может иметь несколько экземпляров, и каждый из этих экземпляров может постоянно изменяться. В такой сложной среде выполнения возникает огромная задача: как обеспечить пользователям надежный доступ и поддерживать стабильную работу сервисов. Таким образом, появилось решение под названием service mesh.

Service mesh похож на TCP/IP для микросервисов, который обрабатывает межсервисные функции, такие как сетевые вызовы, ограничение скорости, мониторинг и т.д. Мы в основном применяем service mesh на платформе Kubernetes. Также, наиболее классическим шаблоном является sidecar, который абстрагирует некоторые общие функции в контейнер sidecar и монтирует его вместе с контейнером сервиса в один pod. На изображении ниже показано, почему это называется service mesh.

Sidecar — не единственный шаблон, применяемый в service mesh; помимо него существуют шаблон DaemonSet и шаблон Ambient mesh:

• Разница между шаблоном DaemonSet и шаблоном sidecar заключается в том, что шаблон DaemonSet позволяет каждому узлу в кластере Kubernetes запускать только один pod, и этот pod работает как sidecar-прокси. По сравнению с шаблоном sidecar, шаблон DaemonSet использует гораздо меньше ресурсов машины, но имеет недостатки, такие как плохая изоляция, сложность предсказания вызовов ресурсов и т.д. Подробнее о различиях можно узнать в этой статье: Sidecars and DaemonSets: Battle of containerization patterns.

• Ambient mesh — это новый режим плоскости данных, представленный Istio 7 сентября 2022 года. Чтобы решить проблему связанности инфраструктуры и развертывания mesh, Ambient mesh отделяет прокси плоскости данных от pod приложения, что позволяет развертывать их отдельно.

Ambient mesh разделяет плоскость данных на безопасный оверлейный слой и слой обработки L7: Безопасный оверлейный слой обрабатывает такие функции, как маршрутизация TCP, метрики мониторинга, логирование доступа, туннелирование mTLS; помимо всех функций безопасного оверлейного слоя, слой обработки L7 имеет множество дополнительных функций, таких как управление трафиком через маршрутизацию HTTP, наблюдаемость и реализация богатых политик авторизации L7.

Кроме того, Ambient mesh использует общий агент под названием ztunnel (zero-trust tunnel), который работает на каждом узле внутри кластера Kubernetes и безопасно соединяет и аутентифицирует рабочие нагрузки внутри mesh. Подробнее о режиме Ambient mesh можно узнать в этой статье: Introducing Ambient Mesh

Зачем нужен service mesh?

До того как service mesh стал популярным, управление сервисами в архитектуре микросервисов осуществлялось через микросервисный фреймворк в сотрудничестве с платформой управления. Однако этот метод имеет следующие проблемы:

1. Тесная связь между фреймворком и сервисом, что делает общую сложность и сложность обслуживания очень высокой. Также разработчикам необходимо понимать публичные библиотеки, что мешает им сосредоточиться на реализации сервисов.
2. Необходимость поддерживать многоязычный фреймворк, что увеличивает затраты на обслуживание.
3. Высокая стоимость обновления микросервисов, и обычно требуется перезапуск сервиса во время обновления.
4. Существование множества различных версий фреймворков, что вынуждает учитывать сложную совместимость.

Чтобы решить эти проблемы, бывший инженер Twitter Уильям Морган, один из основателей Linkerd, предложил концепцию "Service Mesh". Service mesh использует шаблон sidecar для разделения инфраструктуры и логики сервиса без влияния на приложение, что позволяет унифицировать обновление и эксплуатацию для всех языков.

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

Как работает service mesh?

Service mesh не добавляет новых функций в среду выполнения приложения, поэтому все приложения в рамках фреймворка по-прежнему нуждаются в соответствующих правилах, чтобы указать, как отправлять запросы от A к B. Разница в том, что service mesh извлекает межсервисные коммуникации из логики управления и абстрагирует их в уровень инфраструктуры.

В настоящее время большинство service mesh используют архитектуру плоскости данных + плоскость управления, которая показана ниже:

Плоскость управления

Плоскость управления управляет и настраивает плоскость данных, а также реализует стратегии во время выполнения сервиса. Все экземпляры внутри плоскости управления в рамках одного service mesh используют одни и те же ресурсы конфигурации.

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

Плоскость данных

Плоскость данных обычно работает как прокси и состоит из множества sidecar-прокси. Sidecar работает параллельно с экземплярами сервиса и управляет трафиком приложения сервиса, перехватывая поток данных сервиса.

Как упоминалось ранее, service mesh реализуется через шаблон sidecar в Kubernetes и оборачивается в контейнер. Sidecar предполагает использование дополнительного контейнера для расширения и усиления основного контейнера, и этот дополнительный контейнер называется sidecar-контейнером, который размещается в том же pod, что и контейнер сервиса. С другой стороны, service mesh — это сеть, состоящая из этих sidecar-прокси.

Применение service mesh

В архитектуре микросервисов инженеры обычно шифруют публичные сервисы или ограничивают доступ для защиты сервиса, но они игнорируют безопасность коммуникаций внутри кластера. До сих пор многие микросервисные приложения не имеют шифрования межсервисных коммуникаций, и внутренний трафик кластера передается в формате сырых данных. В результате внутренний трафик может подвергаться атакам подслушивания и MITM (атака "человек посередине").

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

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

Вместо этого, если мы используем service mesh, мы можем обеспечить mTLS-коммуникации без необходимости осведомленности исходного сервиса. Поэтому в service mesh мы переносим все функции, связанные с коммуникациями, в sidecar-прокси.

Когда два микросервиса нуждаются в коммуникации, sidecar-прокси сначала устанавливает mTLS-соединение и отправляет зашифрованный трафик через это соединение. Sidecar обменивается сертификатами и аутентифицирует друг друга через центр сертификации. Перед подключением sidecar проверяет стратегию аутентификации, отправленную плоскостью управления, чтобы определить, разрешена ли коммуникация микросервиса. Если коммуникация разрешена, sidecar использует сгенерированный ключ коммуникации для установления безопасного соединения и шифрования данных коммуникации между микросервисами. В течение всего процесса приложения сервиса не затрагиваются, что снижает нагрузку на разработчиков.

Из этого сценария можно понять, почему service mesh может расширять текущие функции без влияния на текущий сервис. Однако, помимо реализации функций безопасности внутреннего трафика, таких как mTLS, service mesh также может быстро расширять функции управления трафиком, наблюдаемости и кодирования протоколов, изменяя конфигурацию плоскости управления.

Заключение

Эта статья кратко знакомит с основными концепциями service mesh, его принципами работы и преимуществами, которые он приносит. Service mesh революционизирует архитектуру микросервисов и помогает разработчикам избавиться от сложной среды выполнения микросервисов, чтобы сосредоточиться на разработке функциональности сервисов.

Хотя service mesh решает многие болевые точки в архитектуре микросервисов, он всё же имеет ограничения. Сложность разработки программного обеспечения вечна, и она просто переносится из одной части в другую. Когда мы абстрагируем управление сервисами в отдельный уровень, мы сталкиваемся с дополнительными трудностями эксплуатации и увеличением количества связей трафика. Более того, service mesh должен использоваться в облачной среде, что предъявляет более высокие требования к профессиональным навыкам и опыту работы DevOps. Именно поэтому мы говорим, что технология — это всего лишь инструмент для решения проблем, но нам нужно взвешивать преимущества, которые приносит service mesh, в зависимости от его практического применения.

С взрывным развитием облачных технологий и оптимизацией service mesh, service mesh, вероятно, полностью заменит архитектуру микросервисов в будущем и станет первым выбором для перестройки архитектуры микросервисов и облачных приложений в каждой компании.

Если вы хотите узнать больше об управлении API, свяжитесь с нами в любое время: https://api7.ai/contact.