Публикуем сессию вопросов и ответов по service mesh. Эксперты отвечали на самые популярные вопросы по технологии service mesh и вопросы участников мероприятия.
Марсель Ибраев, СТО Слёрм, вёл мероприятие, а Александр Лукьянченко, тимлид в команде архитектуры Авито, и Иван Круглов, Staff Software Engineer в Databricks, делились экспертизой. Оба инженера имеют опыт не просто с работы какой-то конкретной реализацией service mesh, но с построением собственного, что намного круче.
Александр Лукьянченко и Иван Круглов являются авторами практического интенсива по Service mesh.
Если service mesh — подход, методология, то какие конкретно есть продукты сейчас?
Александр Лукьянченко: С точки зрения реализации, сейчас имеет смысл попробовать разные имплементации. Если говорить про конкретные названия, то наиболее популярные решения сейчас это Istio, который уже несколько лет очень мощно проводит маркетинговые кампании с точки зрения набора своих фич, старается внедриться везде. Наверное, большинство знает именно Istio. Эта имплементация действительно достаточно долгое время существует, имеет большое количество возможностей, и в принципе после последних релизов она достаточно уже зрелая. Подходит под использование в продакшене и в принципе уже переболела какими-то базовыми проблемами, связанными с перфомансом, первоначальной установкой и настройкой. Настройка упрощается и технология становится более пригодной для внедрения. Но есть ещё несколько технологий, на которые я точно бы обратил внимание.
Первая — это Console Connect. Это разработка от Hashicorp. Технологии Hashicorp и их инструменты достаточно качественные. В случае, если у вас уже есть что-то из их стека, хорошая история посмотреть в том числе на их решение service mesh. С точки зрения количества возможностей, они обычно догоняют Istio, но реализуют более даже продуманно и детально во многом благодаря тому, что hashicorp имеют собственных клиентов, на которых изначально эти продукты обкатывают и затем выдают уже в паблик готовые решения.
И ещё я бы выделил Linkerd2. Он долгое время назывался Conduit. Это решение стоит посмотреть с точки зрения возможностей и перформанс. Потому что оно достаточно сильно отличается от остальных, используется свой прокси сервер. И благодаря этому может предоставить более хорошие возможности по масштабированию. Envoy-proxy в этом плане вполне подходит практически под любую имплементацию используется в крупных компаниях, в том числе у нас, и с точки зрения оверхэда, в первую очередь по ресурсу, сколько мы получаем дополнительного использования процессорного времени, оперативной памяти, в принципе соотношение по сравнению с потреблением бизнес-сервисов приемлемое. То есть это отличие исключительно на сетевое взаимодействие, сетевой стек, обработку запросов и собственно функциональность, которую несет в себе Envoy-proxy.
Собственно, я бы посмотрел с разных сторон на три решения: Istio, Console Connect и Linkerd2. В конце концов, скорее всего, задачи, которые вам нужно решить в своей системе, они реализуют все. Какая из этих технологий лучше подойдёт, уже будет зависеть от того, что вам будет удобнее и что больше понравится. Если говорить о видении, лично мне кажется, что в конечном счете останутся если не победителями, то в большей степени лидерами service mesh решения именно на базе Envoy-proxy, просто потому, что сейчас он набирает огромную популярность, имеет очень большое количество фич из коробки. И, скорее всего, большинство service mesh будут именно на нём. Но тем не менее смотреть всё равно стоит на всё.
Иван Круглов: Я соглашусь с Александром. Istio — самый большой, самый популярный, в том числе потому что за ним Google. Это их технология. Остальные не трогал и не знаю. Но я знаю, что у Hashicorp всё ориентировано на простое использование. Есть смысл посмотреть туда. И если у вас есть сервис Discovery или вы пользуетесь Consul, то тоже есть смысл смотреть туда. Linkerd2 — это третья версия, которая на данный момент есть.
Марсель Ибраев: Почему Envoy используется в service mesh? Почему не более матерые инструменты, как Nginx или Haproxy, которые имеют достаточно большую функциональность? Видимо, чего-то не хватает. Чего?
Иван Круглов: Основная характеристика service mesh — это динамичность. И именно она отсутствует и в Nginx, и в Haproxy. Они были рождены в эру более статичной конфигурации, которую вы могли записать в конфиги, описать, и они либо не менялись, либо менялись не часто. В service mesh изменения ежесекундные. В Envoy и Linkerd есть собственные протоколы, которые позволяют динамически пушить в них конфигурацию. Можно написать сервис, который по HTTP2 будет туда пушить конфигурацию. И они оба динамично перестраивают таблицы, работают очень хорошо. Это для меня основная причина, почему Nginx и Haproxy не приживаются в service mesh.
Александр Лукьянченко: Соглашусь, что динамичность — основная фича, и она закладывалась в дизайн Envoy. Надо сказать, что Haproxy тоже получил эту возможность в последних имплементациях, и сейчас достаточно активно пытаются на его основе делать service mesh. Но есть ещё один момент, который очень важен, на мой взгляд. По той же причине, что Envoy создавался как cloud-native решение, он внутрь себя вкладывал паттерны, такие как достаточно обширную раздачу метрик по всему сетевому взаимодействию. Эти вещи у Nginx есть, но достигается с помощью дополнительных модулей и обвязок, а в Envoy-proxy это есть и все идет из коробки, доступно по умолчанию. И когда вы ставите себе это в систему, сразу получаете ценные данные, которые на других технологиях надо было бы собирать, тестировать и оттачивать.
Марсель Ибраев: Как следствие, получается, если у нас стоят прокси-сервисы в виде Envoy, у нас появляются какие-то возможности, какие-то фичи. И с этим связан следующий вопрос. Если мы говорим про Service mesh, про то, что действительно это тяжело, но вроде как очень здорово и круто, хотелось бы теперь акцентировать внимание на том, какие есть фичи в service mesh? Безопасность, обсервабилити, стратегии деплоя.
Иван Круглов: Под термином обсервабилити обычно понимается совокупность трёх: мониторинг (классические метрики), логирование, трейсинг. Это то, что позволяет вам как оператору сервиса понять, что происходит или происходило в вашем сервисе сейчас или когда-то в прошлом. Сразу скажу, что service mesh логирование не трогает ни в коей мере. То есть в контексте service mesh это про метрики и про трейсинг.
Отвечая на этот вопрос, я его сначала перефразирую. Что внедрение этой технологии даёт бизнесу? На мой взгляд, это консистентность. Сейчас поясню. Представьте, что у вас есть, условно говоря, 100 микросервисов, и вам нужно понять, как они взаимодействуют между собой. Вы можете инструментировать сервисы и заставить их выплёвывать HTTP-метрики. Но скорее всего, у вас получится всё в разнобой. Кто-то будет репортить в секундах, кто-то будет репортить в миллисекундах, кто-то будет выдавать класс ошибок 5xx, кто-то будет выдавать 500. Появляется неконсистентность. Поэтому встаёт вопрос построения единого дашборда, чтобы понять, что происходит с вашей системой. И это всё превращается большой головняк. Потому что у вас метрики называются по-разному, они в разных юнитах и т.д. С service mesh эта проблема решается вся и разом, потому что вы деплоите всё с одним Envoy, он выплевывает метрики с одним именем, в одних юнитах, с одними бакетами и т.д. Просто строится один дашборд, где вы выбираете нужный сервис и видите список всего, что с ним происходит.
С трейсингом чуть сложнее, потому что он построен на хедерах, и эти хедеры нужно прокидывать между входом в приложение и выходом из него. То есть требуется небольшая дополнительная инструментация, но в общем и целом результат то же. Перед вами появляется топология и возможность отслеживания конкретного запроса. В развесистой микросервисной архитектуре понять, что происходит — огромная проблема. Control Plane в service mesh — это централизованная панель управления, поэтому определенные политики вы можете запушить централизованно. Начиная с частоты ретраев, таймаутов. Представьте, что вы создали новый сервис. И если у вас правильно настроены дефолтные настройки, вы сразу из коробки получаете мониторинг, трейсинг, ретраи, бэкоффы, circuit breaker — причем в одних из лучших имплементаций. Вы можете пушить сертификаты, политики доступа (например, этот сервис может разговаривать с одним, а с другим нет).
Подытоживая. Консистентность — это когда в вашей микросервисной архитектуре появляются опорные точки по наблюдению за сервисом, и это возможность централизованного управления политикой, настройками и т. д.
Александр Лукьянченко: Я бы еще добавил, что поскольку service mesh – это про внедрение в синхронное взаимодействие между нашими микросервисами, то здесь безграничные возможности по управлению трафиком, который идет между сервисами. Это возможность там сделать канареечные деплойменты, Blue-green деплоймент, — те вещи, которые из коробки, например, в Kubernetes сделать сложно либо невозможно.
Если говорить про возможности балансировки, то там тоже по внутренним настройкам есть очень богатый набор возможностей. Это различные балансировки с хэш-политиками, чтобы прибивать запрос на определённые эндпоинты, возможность той же самой весовой балансировки, например, защита соединения между микросервисами, mutual TLS, которые в отличие от ручной настройки действительно проще эксплуатировать, т.к. менеджментом сертификатов, их раздачей и ротацией можно заниматься на уровне service mesh, и сами бизнес-сервисы вообще могут не знать, что взаимодействие между сервисами идёт по какому-то защищенному протоколу. Это может быть вообще ключевым моментом, особенно для тех, кто работает в мультиоблачной среде, имея инстансы в одном публичном клауде и в другом, или, например, размазанные инстансы между распределенными датацентрами, также кейсы, в которых эта технология обязательна для внедрения. И при помощи service mesh как раз можно это решить проще, чем если это реализовывать вручную без неё.
Весь набор этих возможностей является очень крутым инструментом решения. Также есть более узкие кейсы, но они могут оказаться ключевыми. Например, Chaos Engineering для внедрения деградаций взаимодействия, или, например, политики. Это действительно получается крутым инструментом решения. Вот также есть более узкие кейсы, но они могут оказаться ключевыми для закрытия конкретной потребности в конкретной компании.
Марсель Ибраев: Получается, если резюмировать, service mesh, независимо от его имплементации, представляет единый централизованный инструмент, позволяющий внедрить ряд фич, в частности, у нас появляется такой единообразный стандартизированной мониторинг или обсервабилити, если говорить в разрезе service mesh, у нас собираются все нужные метрики, трейсинг и всё необходимое. При этом мы можем сразу закрыть вопрос безопасности: можем выстроить сетевые политики, шифрование, и у нас появляются очень гибкие возможности работы с трафиком – различные балансировки, хитрые варианты деплоя и т. д. Этого может быть достаточно, чтобы задуматься о внедрении, особенно на больших проектах.
В продолжение темы внедрения. Допустим, мы продали идею бизнесу и сами пропитались этой идеей, какие шаги должны пройти специалисты с технической и организационной точек зрения? Как правильно внедрить service mesh у себя, если у нас уже работает тот же самый Kubernetes? Как внедрить service mesh и ничего не сломать?
Александр Лукьянченко: Тут немного расскажу про наш опыт. Внедрение этой технологии возможно постепенно. Мы можем чётко выбирать те кусочки системы, на которые мы сейчас раскатываем эту технологию, там тестировать её, смотреть на её влияние на тот же performance, смотреть, получаем ли мы нужный результат, нужный набор фич. И постепенно раскатывать. Например, Istio позволяет внедрять Envoy автоматически к каждому микросервису при помощи технологии веб-хуков, которые под капотом добавляют контейнер к нашему поду. И можно четко сказать, что мы хотим видеть Envoy-proxy в таком-то неймспейсе или уже внедрённый Envoy в таких-то инстансах. Это если говорить про внедрение в продакшен.
А если говорить про организацию, то здесь нужно понять, как технически работает система, как идёт взаимодействие с сервисами, чтобы на этапе проблем уже попытаться и разобраться. И откатать всё это на песочнице. Если есть Kubernetes-кластер, который повторяет продакшен, но с меньшей нагрузкой, можно внедрить, посмотреть и далее идти в продакшен-кластер. Здесь надо продумать все шаги, чтобы в случае проблемы быстро деактивировать эту систему. То есть делая, можно сразу позаботиться о том, чтобы это всё шло постепенно, в том числе по каждому сервису. Сложность отладки заключается в понимании, что реально происходит в какой-то момент, — непростая задача, и чтобы быстро прийти в себя, с точки зрения внедрения в продакшен, я бы точно советовал начинать с песочницы, потому что несмотря на свою высокоуровневую простоту, технология сложна, её отладка непроста, и вам надо чётко понимать, что там происходит, чтобы быстро находить проблемы.
Иван Круглов: Соглашусь. Ты, Саша, говорил в основном про Istio. Чтобы было понятно, когда я говорю про service mesh, я говорю про самописный. Когда мы начинали (в Booking.com), Istio был версии 0.1 и запихать это в продакшен мне ни в коем случае не хотелось, потому что технология была жутко сырая. И ретроспективно всё правильно Ваня сделал. Вторая причина, по которой я решился на написание своего, потому что на тот момент service mesh вне Kubernetes не было. У Istio на тот момент единственной платформой был Kubernetes. Сейчас они потихоньку распиливают его на то, чтобы быть вне Kubernetes, но Kubernetes по-прежнему является центральным звеном. Это то, где хранится конфигурация. А в Booking.com три года назад Kubernetes не было, и мне нужно было жить вне этого. Возвращаясь к основному вопросу, да, я соглашусь с Сашей, что преимущества здесь в том, что его можно внедрять постепенно. Я так и делал. Посервисно. С менее критичных, потом переходя к более критичным. В итоге последний сервис, который у нас переехал на service mesh, был поисковой сервис, который выдавал один миллион RPS в секунду. Это был самый тяжеловесный сервис в компании.