20.02.2018 08:07
shurup 0 1600 Источник
В конце прошлого года компания Buoyant, уже прославившаяся выпуском одного из популярнейших решений категории service mesh (т.е. «сетки», обеспечивающей взаимодействие между сервисами) — Linkerd, — анонсировала своё второе детище под названием Conduit. Можно было бы удивиться, что новый продукт — это ещё один service mesh с открытым кодом, но есть тому причины.



Зачем новый service mesh?


Очевидно, что в Buoyant, где Linkerd называют «самым широко используемым в мире production-решением для service mesh», имели веские основания для создания нового продукта схожего предназначения (а значит — и в чём-то конкурирующего). Ответ прост — в компании увидели большой потенциал для service mesh в конкретной нише:

«Мы выяснили, что существуют типы инсталляций, в которых потребление ресурсов Linkerd оказывается неоправданно высоким. Linkerd основан на таких широко распространённых и проверенных в production компонентах, как Finagle, Netty, Scala и JVM. Хотя они и позволяют ему масштабироваться до обслуживания огромных нагрузок, если для этого предоставить необходимое количество CPU и RAM, все эти компоненты не созданы для обратного — уменьшения масштабов до окружений, ограниченных в ресурсах, — в частности, для инсталляций Kubernetes на основе sidecar-контейнеров».

То же самое можно сказать и в контексте главного конкурента Linkerd — Istio, создаваемого гигантами индустрии… тоже для по-настоящему крупных микросервисных инсталляций.

Таким образом, ответ на вопрос о предназначении Conduit — это service mesh для небольших (ограниченных в ресурсах) микросервисных окружений на базе Kubernetes (и только). По утверждению самих авторов, появление этого нового продукта, на что ушло около полугода, практически ничего не значит для Linkerd, потому что Conduit «не ориентирован на великое множество платформ и интеграций, поддерживаемых Linkerd», к которым они относят ECS, Consul, Mesos, ZooKeeper, Nomad, Rancher и различные сложные окружения. Чем же тогда хорош Conduit?

Conduit: архитектура и особенности


Главные фичи продукта, выделяемые его авторами:

  1. лёгкость и скорость работы;
  2. наглядность от начала до конца (возможность видеть поведение всех компонентов приложения без необходимости вносить правки в код);
  3. безопасность из коробки (включённый по умолчанию TLS);
  4. ориентированность на Kubernetes.

Как это достигается? Conduit состоит из двух компонентов: data plane и control plane.


Общая архитектура Conduit (взята из блога Abhishek Tiwari)

Data plane непосредственно отвечает на запросы сервисов и управляет необходимым для этого трафиком. Техническая реализация представлена набором из легковесных прокси, которые деплоятся как sidecar-контейнеры (т.е. «дополнительные» контейнеры, существующие в том же поде по соседству с основными, которые реализуют непосредственные функции сервиса) для каждого экземпляра сервиса. Чтобы сервис был добавлен в Conduit, его поды в Kubernetes необходимо повторно задеплоить, чтобы добавить каждому поду по прокси от Conduit data plane.


Результат деплоя Conduit data plane

Документация обещает, что Conduit «поддерживает большинство приложений без необходимости в конфигурации с вашей стороны», для чего используется автоматическое определение протокола, используемого при каждом подключении. Однако в некоторых случаях это определение не является полностью автоматизированным — например, для WebSockets без HTTPS, а также HTTP-проксирования (с использованием HTTP CONNECT), подключений без использования TLS к MySQL и SMTP. Другие имеющиеся ограничения: приложения, взаимодействующие по gRPC с помощью grpc-go, должны использовать версию библиотеки не ниже 1.3, а также в Conduit пока нет поддержки внешних DNS-запросов (т.е. проксирования этих запросов к сторонним API).

Data plane обеспечивает общение для подов, реализуя сопутствующие вспомогательные механизмы, такие как повторные попытки запросов и таймауты, шифрование (TLS), назначение политик на принятие запросов или отказ от них.

Важная особенность этого компонента заключается в том, что во имя высокой производительности он написан на языке Rust. Для его реализации авторы инвестировали в разработку нижележащих Open Source-технологий: Tokio (событийная платформа ввода/вывода для создания сетевых асинхронных приложений) и Tower (лаконично описывается как fn(Request) > Future<Response>). Такой подход позволил авторам добиться минимальных задержек («sub-millisecond p99») и потребления памяти («10mb RSS»).

Control plane — второй компонент в Conduit, предназначенный для управления поведением прокси из data plane. Он представлен набором из написанных уже на языке Go сервисов, запускаемых в отдельном пространстве имён Kubernetes. Среди их функций: агрегация телеметрических данных и предоставление API, позволяющих как получать доступ к собранным метрикам, так и изменять поведение data plane. API из control plane используют и оба интерфейса к Conduit (CLI и web UI), и могут быть задействованы другими сторонними инструментами (например, системами для CI/CD).


Общий вид веб-интерфейса Conduit

С подробностями о техническом устройстве Conduit и его компонентов можно ознакомиться в документе для разработчиков.

Интеграция с K8s и статус


Conduit изначально создаётся с прицелом на использование в существующих инсталляциях Kubernetes. В частности, для этого консольная утилита conduit подразумевает повсеместное использование kubectl (например, команды conduit install и conduit inject генерируют конфигурации, которые должны быть перенаправлены в kubectl apply -f). В качестве базового эксплуатируемого компонента в Conduit выбрали Deployments (именно они, а не Services, показываются в web UI), чтобы не создавать лишних сложностей в маршрутизации трафика (отдельные поды могут быть частью произвольного числа Services).

Инструкция по тому, как начать использовать Conduit (с вариантом с Minikube и примером инсталляции демонстрационного приложения), доступна в документации проекта. Статистика для развёрнутого с Conduit приложения будет выглядеть примерно так:

conduit stat deployments

NAME                   REQUEST_RATE   SUCCESS_RATE   P50_LATENCY   P99_LATENCY
emojivoto/emoji              2.0rps        100.00%           0ms           0ms
emojivoto/voting             0.6rps         66.67%           0ms           0ms
emojivoto/web                2.0rps         95.00%           0ms           0ms

Текущий статус проекта Conduit — альфа-версия. На данный момент (последняя версия — v0.2.0 — от 1 февраля) поддерживается проксирование всего TCP-трафика и вывод высокоуровневой метрики (коэффициент успешных запросов, задержки — см. пример выше) для всего трафика в HTTP, HTTP/2 и gRPC. В критериях развития проекта (для его доведения до возможности применения в production) отмечаются следующие глобальные задачи:

  1. поддержка всех видов взаимодействия между сервисами (не только HTTP);
  2. предоставление (по умолчанию) межсервисной аутентификации и конфиденциальности;
  3. расширение Kubernetes API для поддержки разнообразных политик эксплуатации из реальной жизни;
  4. контроллер Conduit сам по себе является микросервисом, который будет расширяемым для поддержки плагинов со специфическими для окружения политиками.

За 2,5 месяца существования проекту удалось собрать больше тысячи stars на GitHub и 19 контрибьюторов. Исходный код распространяется на условиях Apache License v2.0 (некоторые используемые компоненты — под MIT License).

В планах Buoyant — активная работа на протяжении следующих месяцев над тем, чтобы подготовить Conduit к использованию в production, а также предоставление коммерческой поддержки.

P.S.


Читайте также в нашем блоге:

Комментарии (0)