Публикуем сессию вопросов и ответов по service mesh. Эксперты отвечали на самые популярные вопросы по технологии service mesh и вопросы участников мероприятия.
Марсель Ибраев, СТО Слёрм, вёл мероприятие, а Александр Лукьянченко, тимлид в команде архитектуры Авито, и Иван Круглов, Staff Software Engineer в Databricks, делились экспертизой. Оба инженера имеют опыт не просто с работы какой-то конкретной реализацией service mesh, но с построением собственного, что намного круче.
Александр Лукьянченко и Иван Круглов являются авторами практического интенсива по Service mesh.
Что можете сказать про 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.