Эксперты отвечали на самые популярные вопросы по технологии service mesh и вопросы участников мероприятия. Ключевые вопросы АМА-сессии:
- Что такое service mesh,
- Когда внедрять,
- Альтернативы Istio,
- Почему Envoy используется в service mesh, а не Nginx.
Марсель Ибраев, СТО Слёрм, вёл мероприятие, а Александр Лукьянченко, тимлид в команде архитектуры Авито, и Иван Круглов, Staff Software Engineer в Databricks, делились экспертизой.
Оба инженера имеют опыт не просто с работы какой-то конкретной реализацией service mesh, но с построением собственного, что намного круче.
Марсель Ибраев: Что такое service mesh и какие задачи он решает?
Александр Лукьянченко: Я бы начал с базового определения, что service mesh — это в первую очередь подход, который имеет множество конкретных реализаций. Основной смысл в том, что когда у нас есть какая-то распределённая система, которая работает, взаимодействует по сети, мы добавляем дополнительный сетевой уровень, который позволяет нам добавлять какие-то возможности, любую логику в межсервисное взаимодействие сетевых узлов.
Если говорить более простыми словами, когда у нас есть набор микросервисов, каких-то кусочков системы, мы просто добавляем к каждому этому кусочку специальный прокси-сервер и трафик между этими микросервисами пускаем через прокси-серверы. Таким образом, получаем большой сет разных возможностей по управлению трафиком между этими сервисами, по сбору статистики, мониторингу. На самом деле множество ещё всяких крутых штук в виде безопасности, mutual TLS и т.д. Но основное то, что service mesh — это подход.
Иван Круглов: Я с тобой соглашусь. Все мы знаем про микросервисы. И многие из нас берут монолиты и распиливают. У меня такое наблюдение, что люди когда говорят про распил монолита, представляют кирпич и начинают его делить на маленькие кубики. Эти кубики — это их сервисы. И когда мы о них думаем, мы фокусируемся на кубиках, забывая, что сложность, бизнес-логика, которая была в процессе разбиения монолита, никуда не делась. Часть сложности осталась в кубиках, но достаточно много сложностей и проблем остается в пространстве между этими кубиками, в стрелочках, которые люди обычно рисуют тонкими линиями. А там много проблем.
Например, простой вызов функции, который раньше был просто вызовом функции, превращается в удаленный вызов. То есть вы попадаете на все проблемы сетевого взаимодействия, плюс на авторизацию, аутентификацию, трейсинг, мониторинг — в общем, целый набор характеристик. service mesh пытается решить именно проблему сложности межсервисных взаимодействий, этих самых стрелочек, которые связывают наши с вами кубики (микросервисы). Это мое понимание service mesh. Еще я про него думаю как Communication-as-a-Service. Некоторые сервисы, которые позволяют вашим сервисам взаимодействовать между собой, абстрагируя в какой-то мере проблемы взаимодействия и по надежности, и по мониторингу, и по безопасности.
Марсель Ибраев: Можем сделать вывод, что service mesh — это не какая-то конкретная технология, а, скорее, подход, который в практическом ключе представляет из себя добавление прокси-серверов к каждому микросервису. Что позволяет нам более гибко управлять и трафиком, и безопасностью соединения между этими микросервисами. Наверняка есть какой-то условный Control Plane или Daemon, который за всем этим следит, управляет этим, централизованно распределяет конфигурации к этим прокси-серверам и так далее?
Иван Круглов: В целом, да. Однако прокси-сервис — это необязательный атрибут. Для service mesh, я думаю, это будет динамическая конфигурация, потому что в микросервисной среде важно, когда она динамична. Все меняется, масштабируется: скейл ап, скейл даун. И на мой взгляд, динамичность — самый важный критерий. А с остальным я соглашусь.
Александр Лукьянченко: Я бы ещё сказал, что Control Plane — это просто одна из частей service mesh, которая позволяет нам его настраивать, и говорит нам из одной точки прямо на всю систему, какие нам нужны правила, как всё должно взаимодействовать. Такая гибкая возможность контроля над всей системой из одной точки.
Марсель Ибраев: Перейдем к следующему вопросу: когда нам стоит задуматься о том, что нам пора внедрять у себя service mesh? Какие плюсы и минусы его использования? Насколько я знаю, service mesh — относительно молодая технология. В том плане, что сейчас разве что крупные компании позволяют себе его внедрение, только-только начинают этим заниматься, в частности, в России. Насколько простому обывателю стоит задумываться о том, что пора использовать service mesh. Какие факторы служат для того, чтобы определиться с этим? Ну, и что за собой это повлечет, какие плюсы и минусы использования?
Александр Лукьянченко: Я бы в любом случае шёл от потребностей и проблем. Стоит помнить, сейчас эта технология действительно набирает популярность и многие её начинают внедрять или хотят внедрить, но она решает определённые проблемы. Один из очень широко распространённых кейсов для внедрения, это улучшение обсервабилити – понимания того, как вообще взаимодействуют все кубики внутри нашей большой системы. И с помощью service mesh мы унифицированно получаем возможность сделать сразу и полностью на всю систему. Это один из кейсов решения.
То, что Иван говорил по поводу надёжности и устойчивости сетевого взаимодействия, которые мы получаем при переходе на микросервисную архитектуру. Также это одна из проблем, которую можно решить с помощью service mesh, внедрением таких подходов, как Circuit Breaker, автоматические ретраи, то есть паттерны сетевого взаимодействия, причём всё это вне нашей бизнес-логики, вне наших кубиков, единым образом на всю систему.
Имея эти проблемы в нашей системе, мы их как раз можем решить, внедряя service mesh. Очевидно, что решение этих кейсов — это плюсы, и с точки зрения простоты, и особенностей того, как мы можем поставить в свою систему service mesh. Потому что, например, если нам нужно по всей системе настроить какой-то унифицированный мониторинг, сделать так, чтобы у нас со всех сервисов собирались какие-нибудь общие метрики: по задержке, запросам, ошибкам и так далее, это может быть реально сложной задачей. И не в гомогенной среде её может быть сложно решить. В случае с service mesh мы получаем возможность это сделать проще путем того, что добавляем эти прокси-контейнеры и получаем возможность настроить всё по всей системе унифицировано. Это, наверное, одна из ключевых особенностей service mesh.
Я ещё люблю такое определение, что по факту service mesh — это технология, которая могла бы быть полностью решена внутри бизнес-приложений, но из-за сложности, что мы не можем в сотни и тысячи компонентов нашей системы добавлять какую-то единую логику и получать какую-то фичу, мы его просто выносим на другой уровень взаимодействия через эти service proxy и получаем все эти возможности, которые на самом деле могли бы реализовать и в самих бизнес приложениях. И в гетерогенных системах это действительно оказывается очень полезно. Это большой плюс.
Из минусов я бы выделил перформанс. При внедрении нужно точно оценивать то, как взаимодействуют кусочки системы. Например, есть достаточно узкие кейсы, но когда у нас очень большое количество сетевого синхронного взаимодействия, например, по HTTP протоколу внутри системы, то мы получаем дополнительные входы через каждый сервисный прокси. В большинстве случаев это не проблема, но это стоит иметь в виду, внедряя эту технологию, понимать, что она несёт определённый оверхэд в нашу систему, и мы добавляем в неё каждый узел.
И второй минус, который, наверное, даже более жирный, нежели первый, — это сложность конфигурации и внедрения из тех имплементаций, которые сейчас есть. Несмотря на то, что технология уже не очень молодая, до сих пор её не так просто внедрить на большую или среднего размера систему. Это происходит из-за того, что есть большое количество возможностей, большие развесистые конфигурации — порог входа и внедрения этой технологии в систему достаточно высокий.
Иван Круглов: Тоже попытаюсь ответить на этот вопрос. Я зайду издалека. Попытаюсь объяснить, почему я у себя в компании в 2018 году решил внедрять service mesh. Я говорю про Booking.com.
Проблема была в том, что у нас было некоторое количество сервисов и библиотека, которая отвечала за межсервисное взаимодействие. Она умела выдавать метрики, умела выдавать ретраи бэков, то есть reliability-паттерны, и умела дискаверить сервисы. Всё работало хорошо, вроде всё устраивало. Но были две большие проблемы.
Проблема номер один: у меня было 20-30 сервисов. Они находились не под моим контролем. Они деплоились по своему расписанию командой, которая находится в других часовых зонах, а мне надо проапгрейдить какую-то версию. И процесс апгрейда занимал долгое время. Мне нужно было ждать. А ждать это очень долго.
Второе, мы начали в то время переходить на более микросервисный подход. И было понятно, что у нас единый стек. Саша говорил про гомогенные и гетерогенные стеки. Давайте переведу на русский язык. Гомогенный стек — это когда у вас одна технология, например, Java, и все сервисы у вас на Java. Гетерогенные — это когда у вас зоопарк. Один сервис на Python, второй на Java, третий на Go. В Booking.com мы решили не закладываться на гомогенный стэк, мы решили заложиться на то, что стеков будет много. Поэтому было понятно, что библиотеку, в которой всё красиво, придётся переписать на потенциальные 4-5 языков, а потом ещё всё это поддерживать. И ещё желательно сделать так, чтобы они все были в одном тоне. И метрики чтобы они выдавали одинаковые. И reliability-паттерны они реализовывали тоже консистентно. В общем, было понятно, что это огромный геморрой, и поэтому мы придумали решить эти проблемы переходом на единую платформу или подход, то есть деплой прокси, который бы независимо от того, на чём написано стоящее за ним приложение, все метрики, паттерны, и дискавери делал бы одним и тем же способом.
Если говорить более конкретно о применении service mesh, то у меня нет ответа, что вот в этой точке надо применять его, а в этой не нужно. Но в общем, чем больше у вас сервисов и чем на большем количестве языков они написаны, тем большая вероятность, что service mesh вам поможет. Я говорю про вероятность, а не про уверенность, так как там проблем тоже много. И Саша про них рассказал. Если ваши сервисы отвечают за сотни миллисекунд, ну, добавит вам прокси пару миллисекунд — большой разницы вы не почувствуете.
Гораздо бОльшая проблема — это развесистая технология. В Istio сущностей больше, чем в Kubernetes. То есть она сложнее. Они, конечно, сейчас работают над упрощением, но в общем и целом это отдельные технологии, которые нужно поддерживать, под которые нужно выделять ресурсы. Помимо того что ей нужно обучаться самому, ещё в какой-то мере нужно обучить пользоваться ею часть ваших разработчиков.
Марсель Ибраев: Про оверхэд, с точки зрения инфраструктуры, запуск прокси на каждом сервисе — это, то, что я видел, потребление ОЗУ ещё. Каждый под у нас теперь потребляет на 50-70 МБ ОЗУ больше, даже при холостом, если я правильно помню метрики, которые смотрел. То есть надо подумать над тем, действительно ли оно вам надо.
Подрезюмируем, если у вас в компании действительно большой развесистый кластер, большое развесистое приложение с кучей микросервисов, да еще и написанных на разных языках, при этом есть серьёзные требования к отказоустойчивости и быстрому фиксу проблем, чтобы, если какой-то фейл случился, мы смогли быстро всё это пофиксить, главное, быстро понять, в каком месте именно эта проблема возникла. Как сказал Иван, нет какого-то единого фактора или единого аргумента, который скажет, что вот теперь надо внедрять service mesh. Чем больше этих аргументов складывается, тем больше вам стоит уже смотреть в сторону service mesh и подготавливать какую-то почву, может, на тестовом кластере развернуть, поковырять, посмотреть, как это. На продакшн, конечно, ставится он легко, тот же Istio.
Иван Круглов: Это уже рынок. Если ты хочешь завоевать рынок, ты максимально увеличиваешь свою клиентскую базу. А для этого нужно сделать инсталляцию максимально простой. Поэтому под это все и оптимизируют.
Марсель Ибраев: Это да. Следующий вопрос, который хотелось бы обсудить это про то, что если 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 в секунду. Это был самый тяжеловесный сервис в компании.
Марсель Ибраев: Если резюмировать, просто придерживаемся правильного подхода, не делаем резких движений и, как сказал Александр, верхнеуровневую простоту не принимаем за чистую монету, потому что под капотом всё гораздо сложнее. Есть что добавить про service mesh вне Kubernetes: Istio и Linkerd2?
Иван Круглов: Последний раз я смотрел на Istio около года назад — и это было в полурабочем состоянии. Я думаю, оно сейчас находится в нормальном состоянии. Они добавили возможность добавления в Kubernetes, декларирования в нём инстансов, которые находится вне рамок Kubernetes. Почему Istio раньше нельзя было растянуть на Kubernetes? Потому что Istio полагался на примитивы Kubernetes: service, endpoints. То есть Istio вёл свои дискавери оттуда. Они ввели понятие, по-моему, оно называется virtual service или service entry, с помощью которого вы можете задекларировать, прописать, что у меня есть какой-то инстанс, он доступен по такому-то айпишнику. Но как я понимаю, на вас ложится обязанность поддержания этого описания в актуальном состоянии. Если у вас есть железный сервис, на который айпишник прибит гвоздями, то всё нормально. Если более динамичная штука, то придётся руками писать, руками поддерживать.
Александр Лукьянченко: Я этот вопрос понял так: вообще возможен ли service mesh, где нет технологий Kubernetes. Чисто технически это возможно. Потому что Kubernetes это просто оркестратор, есть и другие решения. Изначально Istio проектировался, чтобы работать под разные решения, и там был компонент, который сейчас входит в основную часть Control Plane, под названием Galay. Он как раз занимался тем, что различные манифесты конвертировал в единое описание, которое уже понимает Istio для настройки. Таким образом, мы могли настроить его под практически любое решение. А с точки зрения bare-metal, либо каких-то виртуалок, где нет инструментов автоматизации, там в принципе можно установить Envoy, прописать политики маршрутов, чтобы трафик заходил через Envoy. Но тут вопрос профита от этого и того, какие мы хотим получить фичи. Технически возможно поставить куда угодно, вопрос лишь удобства эксплуатации и необходимости в этом решении.
Иван Круглов: Кстати, чтобы коллеги понимали, Envoy — один из ключевых один из двух ключевых компонентов всех современных service mesh. Он был создан компанией Lyft. У них service mesh был весьма условный. Они свои энвои конфигурировали через конфигурационные файлы. И только позже у них возник некоторый самописный Control Plane. Написать Control Plane, кстати говоря, не так сложно на самом деле. Там есть чётко задекларированный протокол. И есть шаблонные наработки, некоторая обвязка, которая позволяет создать свой Control Plane. По сути, на текущих реализациях свет клином не сошёлся, безусловно, в них много фичей и поддержка коммьюнити, но в общем и целом, если вам нужны какие-то специфические фичи, которые вы не можете найти в том, что есть, то есть возможность написать своё. Конечно, это определенный оверхед, достаточно серьезный, но возможность есть — технология открытая, протоколы все описаны. Если мы рассматриваем вопрос, возможен ли service mesh вне Kubernetes, в широком смысле, да, возможен, никаких ограничений нет. Если говорить в более узком плане, возможно ли Istio растянуть на вне Kubernetes, или Consul растянуть на вне Kubernetes, как говорится, it depends. Чем дальше мы идём, тем больше это становится возможным. В Istio, думаю, это сейчас можно стопудово. Consul Connect, по-моему, заходил в эту сферу как раз-таки без Kubernetes. Поэтому там должно работать из коробки. Я думаю, в Consul Connect всё завязано на Consul Service Discovery. Если ваши сервисы видны в их Discovery, то они будут видны и в service mesh.
Марсель Ибраев: В топе у нас сейчас вопрос от Антона, который спрашивает, что будет на интенсиве по service mesh. Да, мы планируем провести онлайн-интенсив по теме service mesh с 19 по 21 марта. (прим. редактора: первый интенсив прошёл, второй интенсив назначен на 24-26 сентября 2021.) Всем этим буду заниматься наши эксперты. Иван Круглов — лидер практики. Все наши образовательные программы идут от практики, поэтому мы достаточно большое внимание этому уделяем. И спикером интенсива будет как раз Александр Лукьянченко. Какой-то такой капитанской теории там будет мало. Мы по большей части будем делать упор на практику, на практическое применение. Сразу же пойдём ставить service mesh, всё будем делать на примере Istio. Поставим, разберёмся, запустим, разберёмся с абстракциями, сразу пойдём трогать фичи, стратегии деплоя, мультикластерность, mTLS, Chaos engineering и т.д. Всё, что у нас есть в концепции service mesh, всё обязательно потрогаем своими руками, и на выходе вы получите какие-то знания и навыки, которые вам помогут в будущем уже самостоятельно всё это делать и внедрять. Формат обучения, живой, в Zoom.
Это была первая часть расшифровки с АМА-сессии. Продолжение с дополнительными вопросами от участников мероприятия уже в работе, скоро опубликуем. А какой вопрос по service mesh волнует вас?
