[Перевод] Обзор платформ service mesh05.12.2022 14:32

Все мы любим микросервисы, но надо признать, что их довольно сложно планировать, проектировать, разрабатывать, развёртывать и администрировать.

Кроме того, нам нужно защищать трафик между сервисами и реализовывать распределённую трассировку, чтобы понимать, сколько времени занимает каждый вызов. Надёжным распределённым сервисам нужны повторы запросов, размыкатели цепи (circuit breaker) и подобные возможности. Микросервисы поддерживают почти любые языки, библиотеки и SDK. Нужно немало времени и денег, чтобы написать универсальное и многоразовое ПО, которое будет управлять общением сервисов с помощью разных протоколов, вроде HTTP, gRPC и GraphQL. В этой статье мы сравним самые популярные платформы service mesh для облачной экосистемы.

Service Mesh

После развёртывания микросервисов команда DevOps мониторит их работоспособность, задержки, логи, события и трассировку, а ещё реализует маршрутизацию на основе политик для сине-зелёных развёртываний, канареечных релизов и последовательного обновления. Наконец, нам нужно собирать метрики, события, логи и предупреждения из многочисленных микросервисов и интегрировать всю эту информацию в существующие стеки мониторинга.

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

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

Самое главное, что service mesh не требует изменений в коде или конфигурации. Service mesh присоединяет к каждому сервису sidecar-прокси, который выступает как агент своего сервиса. Прокси перехватывает все входящие и исходящие вызовы, обеспечивая полную прозрачность стека вызовов. Каждый прокси, связанный с сервисом, отправляет телеметрию, собранную из стека вызовов, в централизованный компонент, который также выступает как control plane. Когда операторы настраивают политику передачи трафика, они отправляют её в control plane, а оттуда она попадает в прокси, который управляет трафиком. SRE-инженеры собирают ценные сведения о приложении благодаря наблюдаемости в service mesh.

Service mesh интегрируется с Kubernetes ingress controller или существующим API-шлюзом. API-шлюз и Ingress обрабатывают вертикальный (north-south) трафик, а service mesh отвечает за горизонтальный (east-west).

Получается, что service mesh — это инфраструктурный уровень для безопасного общения сервисов друг с другом. Рядом с каждым микросервисом развёртывается лёгкий сетевой прокси, а централизованный control plane отвечает за оркестрацию этих прокси и управляет политиками, безопасностью и наблюдаемостью.

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

AWS App Mesh

AWS App Mesh, представленный на AWS re: Invent 2018, позволяет использовать преимущества service mesh в вычислительных и контейнерных сервисах Amazon Web Services. Он хорошо работает с Amazon EC2, Amazon ECS, AWS Fargate, Amazon EKS и даже AWS Outposts. Поскольку App Mesh может служить service mesh как для виртуальных машин, так и для контейнеров, Amazon создаёт уровень абстракции на основе виртуальных сервисов, виртуальных нод, виртуальных маршрутизаторов и виртуальных маршрутов.

Виртуальный сервис представляет фактический сервис, развёрнутый на виртуальной машине или в контейнере. Каждая версия виртуального сервиса сопоставляется с виртуальной нодой, причём у одного виртуального сервиса может быть много виртуальных нод. Когда мы развёртываем новую версию микросервиса, она просто настраивается как виртуальная нода. Виртуальный роутер, по аналогии с физическим, выступает как конечная точка для виртуальной ноды. У виртуального роутера есть один или несколько виртуальных маршрутов, которые соответствуют политикам трафика и повторных запросов. Объект mesh выступает как логическая граница для всех связанных сущностей и сервисов.

Весь внутренний трафик обрабатывается через прокси, привязанные к каждому сервису.

Допустим, мы запустили в AWS два сервиса: servicea.apps.local иserviceb.apps.local.

Их легко можно подключить к service mesh без изменения кода.

Мы видим, что у serviceb.apps.local есть виртуальный сервис, виртуальные ноды и виртуальный роутер с двумя виртуальными маршрутами, чтобы распределять трафик по версиям v1 и v2.

Подробное описание AWS App Mesh см. в этой статье и руководстве.

Как и большинство других платформ service mesh, AWS App Mesh использует опенсорс-прокси Envoy в data plane. Control plane в App Mesh создан под вычислительные сервисы AWS, а Envoy адаптирован под этот control plane.

Если использовать AWS App Mesh с Amazon EKS, можно автоматически внедрять sidecar«ы и определять сущности App Mesh в YAML. У Amazon есть кастомное определение ресурсов (CRD) для EKS, с которыми проще настроить App Mesh для стандартных объектов Kubernetes.

Телеметрию от AWS App Mesh можно интегрировать в Amazon CloudWatch. Метрики можно экспортировать в сторонние сервисы, например Splunk, Prometheus и Grafana, а также решения для трассировки, вроде Zipkin и LightStep.

Клиенты AWS могут использовать AWS App Mesh бесплатно. 

Consul

Consul от HashiCorp был создан как платформа обнаружения сервисов со встроенным хранилищем пар «ключ-значение». Кроме того, он работает как эффективный и лёгкий балансировщик нагрузки для сервисов на том же хосте или в распределённом окружении. Consul предоставляет интерфейс запросов DNS для обнаружения зарегистрированных сервисов и проверяет работоспособность этих сервисов.

Consul появился задолго до того, как контейнеры и Kubernetes стали мейнстримом. Когда все заговорили о микросервисах и service mesh, HashiCorp доработали Consul до полноценной платформы service mesh. Consul использует компонент Connect для авторизации и шифрования соединений между сервисами с помощью mTLS.

Подробное описание и инструкции по реализации Consul см. в руководствах по обнаружению сервисов в Consul и Consul Connect.

Поскольку sidecar — предпочитаемый подход к service mesh, Consul Connect предлагает собственный прокси для обработки входящих и исходящих соединений. В качестве альтернативы можно использовать Envoy.

Consul обеспечивает безопасность и наблюдаемость. По умолчанию Consul добавляет сертификат TLS к конечным точкам сервисов, чтобы реализовать mTLS для шифрования всех данных между сервисами. Политики безопасности реализуются с помощью намерений, которые определяют контроль доступа для сервисов и указывают, какие сервисы могут устанавливать соединения. Намерения могут разрешать или запрещать трафик от определённого сервиса. Например, сервис базы данных может запретить входящий трафик, поступающий напрямую от веб-сервиса, но разрешить запрос через сервис бизнес-логики.

Когда в качестве прокси с Consul Connect используется Envoy, нам доступны преимущества наблюдаемости на уровне L7. Envoy, интегрированный с Consul Connect, можно настроить таким образом, чтобы он отправлял телеметрию на разные ресурсы, включая statsd, dogstatsd и Prometheus.

В зависимости от контекста Consul может выступать как клиент (агент) или сервер. При работе с оркестраторами, вроде Nomad и Kubernetes, он поддерживает внедрение sidecar. Существует Helm-чарт для развёртывания Consul Connect в Kubernetes. Конфигурация Consul Connect и метаданные добавляются как аннотации в спецификацию pod’ов, отправляемую в Kubernetes. Мы можем интегрировать Ambassador, ingress controller от Datawire, который обрабатывает вертикальный трафик.

У Consul нет расширенных возможностей маршрутизации и разделения трафика для сине-зеленых развёртываний или канареечных релизов. По сравнению с остальными реализациями service mesh у него не очень гибкие политики безопасности трафика. При интеграции с Envoy их можно настроить, но у Consul Connect для этого нет интерфейса.

В целом, Consul и Consul Connect предлагают простые в управлении платформы для обнаружения сервисов и service mesh.

Istio

Istio — одна из самых популярных опенсорс-платформ для service mesh. Её поддерживают Google, IBM и Red Hat.

Это одна из первых service mesh, которая стала использовать Envoy как прокси. Istio состоит из стандартных компонентов: централизованный control plane и распределённый data plane.

Istio можно использовать с виртуальными машинами, но обычно его интегрируют с Kubernetes. Для pod’ов, развёрнутых в определённых пространствах имён, можно настроить автоматическое внедрение sidecar, то есть Istio будет сам прикреплять компонент data plane к pod’у.

Istio предлагает разработчикам и операторам микросервисов три главные возможности:

• Управление трафиком. Istio упрощает конфигурирование атрибутов на уровне сервисов, например, размыкатели цепи (circuit breakers), таймауты и повторные запросы, а также позволяет создавать такие конфигурации, как A/B-тестирование, канареечные развёртывания и постепенные развёртывания с процентным разделением трафика. Он также предлагает готовые функции восстановления после сбоя, чтобы повысить надёжность приложения в случае сбоев других сервисов или сети. У Istio есть свой Ingress, который управляет вертикальным трафиком. Полное руководство по реализации сине-зелёных развёртываний с Istio см. в этой статье.

• Безопасность. Istio предлагает готовые возможности для защиты коммуникаций между сервисами. Он предоставляет защищённый канал и управляет аутентификацией, авторизацией и шифрованием при общении сервисов в любом масштабе. При использовании Istio взаимодействие между сервисами защищено по умолчанию, а разработчики и операторы могут применять одинаковые политики для разных протоколов и рантаймов, не меняя код или конфигурацию.

• Наблюдаемость. Поскольку data plane Istio перехватывает весь входящий и исходящий трафик, мы можем отслеживать текущее состояние развёртывания. Istio предлагает надёжные функции трассировки, мониторинга и логирования, позволяя собирать всю необходимую информацию о service mesh. В Istio интегрированы уже настроенные Prometheus и Grafana. См. руководство по настройке и просмотру дашбордов в Istio.

Google и IBM предлагают управляемый Istio для своих платформ Kubernetes. Google создал Knative — окружение бессерверных вычислений на базе Istio. Istio лежит в основе таких сервисов Google, как Anthos и Cloud Run. По сравнению с другими реализациями service mesh, Istio считается сложной и тяжёлой платформой, но благодаря своей расширяемости и широким возможностям, пользуется большой популярностью.

Kuma

Kuma был представлен в сентябре 2019 года компанией Kong, Inc, которая предлагает одноимённый API-шлюз (Kong Gateway) как опенсорс и коммерческий продукт. Kuma стал логическим продолжением API-шлюза Kong, только шлюз отвечает за вертикальный трафик, а Kuma — за горизонтальный.

Как большинство других платформ service mesh, Kuma состоит из отдельных компонентов data plane и control plane. Control plane служит источником истины для всех конфигураций сервисов и может масштабироваться без ограничений, чтобы управлять десятками тысяч сервисов по всей организации. Kuma сочетает быстрый data plane с продвинутым control plane, на котором можно легко задавать разрешения, предоставлять метрики и настраивать политики маршрутизации с помощью кастомных определений ресурсов (CRD) в Kubernetes или REST API.

В Kuma data plane тесно интегрируется с прокси Envoy и может выполняться на виртуальных машинах или контейнерах, развёрнутых в Kubernetes.

У Kuma есть два режима развёртывания: универсальный и Kubernetes. При работе в Kubernetes платформа Kuma использует API-сервер и базу данных etcd для хранения конфигурации. В универсальном режиме для хранения данных нужна внешняя PostgreSQL.

Kuma-cp, компонент control plane, управляет компонентами data plane, kuma-dp. Каждый микросервис, зарегистрированный в service mesh, выполняется как эксклюзивная копия kuma-dp. В Kubernetes kuma-cp работает как CRD в пространстве имён kuma-system. Пространство имён для Kuma может внедрять data plane в каждый pod.

У Kuma есть графический пользовательский интерфейс, который предоставляет обзор развёртывания, включая состояние каждого data plane, зарегистрированного в control plane. В том же интерфейсе можно просматривать проверки работоспособности, политики трафика, маршруты и трассировки с прокси, прикреплённых к микросервисам.

У Kuma service mesh есть встроенный центр сертификации (CA), с помощью которого трафик шифруется по протоколу mTLS. Разрешения для трафика можно настроить на основе меток для микросервисов. Трассировку можно интегрировать с Zipkin, а метрики можно перенаправлять в Prometheus.

В Kuma нет продвинутых функций для обеспечения устойчивости, вроде размыкателей цепи, повторных запросов, внесения ошибок и внедрения задержек.

В остальном, Kuma можно назвать хорошо продуманной и аккуратной реализацией service mesh. Это неплохой вариант для тех, кто уже использует шлюз Kong Gateway.

Linkerd 2.x

Linkerd 2.x — это опенсорс-реализация service mesh, созданная Buoyant исключительно для Kubernetes. Он предоставляется по лицензии Apache V2 и развивается как проект Cloud Native Computing Foundation.

Linkerd — это сверхлёгкая и простая для установки платформа service mesh. Она состоит из трёх компонентов: CLI и пользовательский интерфейс; control plane; data plane.

Сначала нужно установить CLI на компьютере, который взаимодействует с кластером Kubernetes, а затем можно одной командной установить control plane. Все компоненты control plane установлены в deployment Kubernetes в пространстве имён linkerd. Web (интерфейс) и CLI используют API-сервер контроллера. Компонент destination (место назначения) сообщает всем прокси с data plane информацию о маршрутизации. Proxy-injector — это контроллер допуска Kubernetes, который получает запрос вебхука каждый раз при создании pod’а. Этот сервис используется для внедрения прокси в качестве sidecar для каждого pod’а в пространстве имён. Компонент identity отвечает за управление сертификатами, чтобы реализовать mTLS между прокси. Компонент tap получает запросы от CLI и веб-интерфейса, чтобы наблюдать за запросами и ответами в реальном времени.

Linkerd поставляется с уже настроенными Prometheus и Grafana с готовыми дашбордами.

У data plane есть лёгкий прокси, который прикрепляется к сервису как sidecar. Через контейнер Kubernetes Init можно настроить iptables, чтобы определить поток трафика и подключить прокси к control plane.

Linkerd предлагает все возможности service mesh — маршрутизацию и разделение трафика, безопасность и наблюдаемость.

Подробный обзор Linkerd см. в этой статье.

Интересно отметить, что Linkerd не использует Envoy в качестве прокси. У него есть свой специальный лёгкий прокси, написанный на Rust. У Linkerd нет встроенного ingress, но он может работать с ingress controller.

Linkerd — вторая по популярности платформа service mesh после Istio. Его главное преимущество — лёгкость и простота использования.

Maesh

Maesh — продукт Containous, компании, которая создала популярный ingress Traefik. Как и Kong, Inc, Containous построили Maesh в дополнение к Traefik. Maesh обрабатывает горизонтальный трафик между микросервисами, а Traefik отвечает за вертикальный трафик. Как и Kuma, Maesh может работать и с другими ingress controller.

Подход Maesh отличается от того, что делают остальные платформы service mesh. Он не использует sidecar для управления трафиком. Вместо этого он развёртывает на каждой ноде Kubernetes по pod’у, который будет предоставлять четкую конечную точку сервиса. Микросервисы могут работать, как работали, даже после развёртывания Maesh, но когда они используют эту альтернативную конечную точку, им доступны возможности service mesh.

Maesh старается предоставить ненавязчивую и неинвазивную инфраструктуру, но при этом ему недостаёт некоторых важных функций, например прозрачного TLS-шифрования.

Maesh предлагает базовые возможности service mesh, включая маршрутизацию и наблюдаемость, но без безопасности. Эта платформа поддерживает новейшие спецификации, определённые в проекте Service Mesh Interface (SMI).

Maesh, возможно, является самой простой и быстрой платформой при развёртывании в Kubernetes.

Узнать еще больше о Service Mesh

© Habrahabr.ru