В «Авито» Александр Лукьянченко строит внутреннюю платформу для всех разработчиков на базе оркестратора Kubernetes. В «Слёрме» готовит уже третий интенсив по service mesh, который пройдет 9-11 декабря 2022 года.
Начнём с основ: что такое service mesh?
Service mesh — это подход, который позволяет организовать внутри системы умную сеть, а эта сеть в свою очередь даёт возможность решать определённые задачи и проблемы. Например, более гибко управлять трафиком, создавать более безопасное общение между узлами системы, организовывать деплой канареечными релизами, внедрять гибкие механизмы выкатки новых микросервисов, да и любых частей системы.
Это подход, когда мы — неважно, какая у нас технология, на каком стеке написана система — добавляем в каждый узел sidecar-контейнер и через него получаем возможность внедрять в сетевое взаимодействие любую логику. В результате можем внедрять разного рода вещи, которые я упомянул, а также инструменты observability — для понимания, как все эти кусочки системы взаимодействуют.
Как узнать, что компании пора внедрять service mesh решения?
Самое главное — это понять, какие проблемы есть в системе, и закрывает ли их service mesh.
- Управление трафиком: канареечные деплои, деплои по методу blue-green, различные схемы балансировки (round-robin, хеш-балансировки и т. д.) между микросервисами. Это про эффективность и условное тестирование в продакшене, чтобы меньше аффектить пользователей в случае проблем.
- Безопасность. Когда мы хотим не только снаружи, но и внутри иметь безопасное общение между всеми узлами в системе. Много кто идет в технологию, исходя именно из этого пункта. Если есть много компонентов в системе и надо сделать так, чтобы каждый из них взаимодействовал с другим по защищенному соединению, протоколу — это задача сложная не только в плане имплементации, но и в плане поддержки. Надо заниматься ручной ротацией сертификатов или писать инструменты, которые это будут делать. А service mesh закрывает эти проблемы.
- Observability. В развитой микросервисной архитектуре не всегда можно быстро найти причину деградации или какого-нибудь падения. Service mesh даёт возможность простого внедрения унифицированного распределенного трейсинга, мониторинга. Это в том числе и логирование, но логирование именно сетевого взаимодействия. Например, envoy proxy позволяет удобно и в подробном виде получать логи всех взаимодействий.
- Объединение в единую сеть больших кусков системы. Например, нескольких Kubernetes-кластеров. Это тоже важный момент. Здесь есть два поинта. Первый — мы с помощью такого подхода обновляем Kubernetes-кластера на новые версии, делая это не inplace для постепенного перехода. И второй — когда у нас есть, например, несколько публичных облачных провайдеров либо своих дата-центров, мы можем с помощью этого подхода объединять их в единую сеть.
- Отказоустойчивость системы. В распределенной системе в разных частях могут возникать периодические сетевые ошибки. С помощью паттернов circuit breaker, outlier detection, retry политик можно эти проблемы обойти. Но реализовывать в каждом узле их затратно. С service mesh это также можно решить.
Это основные моменты. На мой взгляд, их наличие — хороший сигнал о том, что надо посмотреть на service mesh.
Также по косвенным признакам: когда есть развитая микросервисная архитектура со множеством независимых кусков, которым надо взаимодействовать между собой; когда сложно понимать, как они взаимодействуют; когда нужно выстраивать между ними более надежные и безопасные взаимодействия и сделать это руками всё ещё возможно, но дорого и сложно — вот тогда компания приходит к service mesh.
Если система состоит буквально из нескольких микросервисов или представляет собой одно монолитное приложение, то это можно решить другими средствами, и абсолютно не обязательно — я бы даже сказал, не имеет смысла — использовать service mesh.
Как к внедрению service mesh пришли в «Авито»?
Были две глобальные задачи: решить проблемы с пониманием того, что происходит в системе и более гибко управлять трафиком. Сначала мы хотели улучшить observability, получить унифицированный мониторинг и трейсинг. Это была первая цель, которой мы добивались, внедряя service mesh.
Спустя какое-то время понадобилось добавить возможности по управлению трафиком: внедрить канареечные релизы, использовать несколько Kubernetes-кластеров в одном окружении. Мы не обновляем Kubernetes-кластеры inplace, а вместо этого создаём Kubernetes-кластера рядом и переносим все сущности из одного кластера в другой. Без создания единой сети и service mesh делать это было больно, потому что приходилось в каждом узле системы переписывать правила прохода трафика — говорить, что вот сейчас мы идем в другой Kubernetes-кластер.
Эти две глобальные задачи возникли с разницей примерно в год. Когда только начали подступаться к решению, помимо истории с observability был ещё один технический аспект, почему мы вообще пошли в эту технологию, начали её ресёрчить и внедрять, почему стали смотреть на Istio.
Дело в том, что к тому моменту мы уже использовали в продакшене Сontour.io от Heptio (сейчас VMware). Contour — это ingress-контроллер на базе envoy proxy. Это более мощное решение, нежели стандартный ingress-контроллер на базе Nginx. Он позволяет делать много разных штук, которые умеет envoy, в том числе внедрять более мощные стратегии управления трафиком, нативные канареечные релизы. Кроме того, Contour обладал лучшим перфомансом, чем механика, которую использовал Nginx (reload конфигураций со сторонним контроллером и множеством логики на lua).
Но что самое интересное, по сути Contour использовал тот же стек технологий и тот же подход, что и решения service mesh. У него был свой control plane, очень похожий на то, что есть в Istio (в то время это был pilot компонент). Он использовал то же самое прокси-решение — envoy proxy. Мы понимали подход и знали, что envoy proxy уже production ready, и его можно использовать в нашей системе. Поэтому мы начали входить в Istio.
В докладе о service mesh ты говорил, что его внедрение было обусловлено ещё и задачами тестирования.
Да, это как раз трек про управление трафиком. В непродакшн средах нам действительно нужна была фича — перенаправление динамического трафика на новую версию микросервиса.
Это один из подходов, который позволял нам дешево тестировать: мы просто выкладываем новую версию сервиса и с помощью service mesh перенаправляли на неё трафик только для конкретно этих тестовых запросов с помощью специальных заголовков.
Возвращаясь к переходу от Contour к Istio: чем эти решения различаются?
Contour — это ingress-контроллер, то есть решение, которое позволяет принимать внешний трафик внутрь Kubernetes-кластеров. По сути, только эту задачу он и решает.
Istio и вообще service mesh технологии — это технологии, которые позволяют использовать те же подходы, но решать проблемы взаимодействия узлов внутри системы. Например, обеспечивать подачу различного трафика между микросервисами, внедрять mTLS-общение между узлами. По сути это тот же самый подход, но масштабированный на всю систему.
Надо сказать, что почти все service mesh решения предоставляют возможность (на том же самом control plane, на тех же технологиях) использовать свой ingress-контроллер. Например, в Istio есть Gateway. Но есть и отдельные проекты, которые делают чисто ingress-контроллеры, Contour — это один из них.
Рассматривали ли вы другие решения, кроме Istio?
В то время (а это был, по-моему, 2017 год) существовало два проекта, которые мы рассматривали — Istio и Conduit (сейчас переименован в Linkerd 2). Почему мы выбрали Istio?
Первый поинт был в используемых технологиях, потому что envoy proxy в то время был уже продакшн-реди продукт, который использовался большими компаниями. Например, в «Lyft», где и разработали envoy proxy, его уже использовали по паттерну service mesh. Мы понимали, что это решение, скорее всего, будет хорошо подготовлено к нагрузкам и будет успешно использоваться и в «Авито» с точки зрения перфоманса. А в Conduit было свое решение, написанное на Rust. У нас экспертизы по этому языку было немного, и казалось, что это не очень правильный подход, что там ещё свой прокси.
Второй момент — это, конечно, маркетинг Istio и внедрение его в индустрию Google и IBM. Они очень качественно представили проект в индустрии: выпустили много презентаций и видео о возможностях Istio. Где-то за год им удалось сделать так, что если кто-то узнавал о service mesh или говорил, то рядом обязательно всплывало слово «Istio». Istio стало как бы дефолтной реализацией.
И мы понимали, что скорее всего на горизонте нескольких лет именно Istio будет основной реализацией, которую будет использовать большинство компаний. Остальные имплементации может быть и останутся, но будут менее популярными и менее поддерживаемыми, чем Istio.
Каким образом вы начали внедрение? В своем интервью ты говорил, что перед этим тестировали Istio около года.
Начав его внедрять, мы уже примерно понимали, как всё устроено и как организовать процесс.
Начинали с песочницы?
Естественно, раскатывали постепенно. Сначала на staging-кластерах тестировали механику работы, разбирались в логике. Затем начали постепенно, посервисно внедрять. Спустя несколько месяцев дошли до продакшена.
К тому времени в основном Kubernetes-кластере у нас была уже достаточно большая система: тысячи инстансов, тысячи подов микросервисов. Поэтому новая система сразу же проверялась на перфоманс — насколько она готова к такому объему.
При внедрении Istio в продакшн и всплыли явные проблемы, в том числе та, из-за которой мы спустя время решили отказаться от Istio. Самой большой проблемой оказался как раз перформанс работы Istio. Об этом я много рассказывал на конференциях.
Причина этой проблемы скрывалась в архитектуре, и устранить её нельзя было без сильного внедрения в исходный код Istio. Каждый инстанс содержал в себе знание о всей системе, и так как у нас уже была большая система с тысячами инстансов, каждый из узлов потреблял большое количество оперативной памяти. Вместе с тем, чтобы получать эти знания, Istio сильно утилизировал и сеть, и CPU.
Мы посмотрели, как это всё ведет себя в проде, умножили на количество наших инстансов и в принципе даже были готовы потянуть такой объем (хотя он был огромным, терабайты оперативной памяти просто так). Но понимали, что в будущем мы будем расти, и этот объём тоже будет расти, причём квадратично. То есть решение просто не масштабируется.
Помимо этого при внедрении возникали какие-то проблемы, встречались баги — мы их сами фиксили. К тому времени у нас уже был свой форк Istio — вещи, которые мы быстро не могли протащить в апстрим, исправляли сами. Но исправить проблему с перфомансом в то время было крайне сложно, потому что нужно было переписать процентов 30 кодовой базы Istio.
Получалось, что мы вроде как используем Istio, но при этом должны его сильно менять, и в итоге получить свой уникальный service mesh, просто на базе Istio.
Тогда мы начали понимать, что в Istio таком виде у нас в проде не может лететь в долгую. Совместно с еще одним моментом, на который закрывали глаза: Istio был не очень стабилен по API и от релиза к релизу делал ломающие изменения. Для больших компаний это проблема, потому что когда есть много мест, где используется технология, менять по каждому из вхождений имена — это большая работа. Но мы были готовы с ней мириться, если бы не проблема с перфомансом.
Как могло получиться, что Istio разрабатывали такие большие компании, но с большими нагрузками она справляется плохо?
Istio и многие другие service mesh решения развивались эволюционно. Взять даже envoy proxy. В первой версии протокола использовался не gRPC, который позволяет делать сервер-пуши для обновления конфигураций в каждом узле. Там использовался обычный http, который давал оверхед на взаимодействие control plane с прокси-контейнерами. Соответственно, на это потреблялось большое количество CPU и сети, чтобы делать long polling, затем, спустя время перешли на gRPC.
В случае с Istio ровно та же история. Сначала сделали базовое решение, которое в целом решало нужные проблемы, но еще без больших внедрений. На мой взгляд, архитектурные решения вроде раздачи всего discovery в каждый узел — были приняты исходя из того, что они просто работали. Да, они работали до определенного уровня и на этапе зарождения технологий это было не так важно. Внедрение на каких-то не очень больших проектах работало хорошо и позволяло быстро достичь результата.
Забегая вперед скажу, что в конце 2018 года в Istio решили внедрять механизм чёткого декларирования зависимостей. Этот подход мы использовали в своём control plane, разработанном уже после отказа от Istio. В Istio он появился примерно в 2019 году и как раз позволял чётко задекларировать, какому узлу какие данные нужны — и решить таким образом проблемы с потреблением памяти, сети и вообще, в целом, оптимизировать всю эту систему. Но это было спустя несколько лет.
Отказавшись от Istio, вы стали разрабатывать своё решение. На какие характеристики делали упор в первую очередь?
У нас был достаточно длинный путь. После первого внедрения Istio мы преследовали те же задачи, повышение observability в первую очередь.
Чтобы просто иметь возможность получать с каждого узла нужные метрики, а с каждого микросервиса — трейсинг-спаны, мы разработали альтернативный прокси. Заменили envoy proxy на собственную реализацию, которая потом стала называться Netramesh. Это технология тоже service mesh, она позволяла нам без control plane, без настраивающей части прокси-контейнера получать со всей системы нужную нам информацию о том, как взаимодействуют части системы. С этим решением мы жили достаточно долго, и до сих пор оно в продакшене.
Со временем возникла новая задача — объединить несколько Kubernetes-кластеров в единый контур. Однажды получилось так, что у нас появилось несколько равноценных Kubernetes-кластеров, которые использовались в одном окружении. Нужно было управлять ими с помощью единой сети, и мы снова пришли к service mesh.
Только в этом случае нужно было в каждом узле знать всю систему, все Kubernetes-кластеры. Нам нужен был тот самый control plane — выделенный компонент, который бы всем рассказывал, куда нужно ходить, какие у нас есть зоны, какие зоны отказа и так далее. Так мы пришли к созданию дополнительного решения, по своей архитектуре очень похожего на Istio.
Мы взяли envoy proxy, написали control plane под его протокол xDS и назвали это решение Navigator (здесь можно посмотреть базовое описание и исходный код).
Таким образом сейчас мы имеем в продакшене сразу два прокси-контейнера: Netramesh, который занимается задачами observability, и envoy proxy, который настраивается с помощью Navigator и управляет трафиком.
В результате мы получили возможность связать Kubernetes-кластера в единую систему и объединить в единую сеть. Сейчас мы используем большое количество envoy proxy и service mesh подход как раз с помощью Navigator. В том числе различные схемы балансировки трафика между сервисами, канареечные деплои, mTLS, стики-сессии (по кукам, по хедерам), настраиваем зоны приоритетов подачи трафика, везде используем outlier detection, connect retries.
Путь такой. Соответственно, каждое из этих решений закрывало определенную проблему. Сначала проблему observability закрыла Netra, сейчас Navigator управляет взаимодействием между инстансами микросервисов.
Когда возникла необходимость объединить кластеры, вы не рассматривали Istio снова?
Да, перед внедрением Navigator мы ещё раз пробовали внедрить Istio, проводили перфоманс-тесты, уже зная проблемы, но он всё еще был не готов.
Это было примерно полтора года назад, а спустя ещё полгода эта проблема в Istio была решена с помощью специальной sidecar-сущности, которая позволяет отрезать discovery.
Я общался в комьюнити Istio и знал, что решение будет, и что оно будет именно такое, но ждать мы не могли — были проблемы и потребности, которые нужно было закрыть. Тогда мы подумали, что сможем за достаточно короткий срок разработать свой control plane, который будет решать конкретный набор задач (не всё, что есть в Istio, а лишь определенный пул).
Примерно так и вышло. Мы разработали первую версию Navigator буквально за месяц. Причем большую часть времени заняло написание инфраструктуры мощного мультикластерного e2e тестирования. Без них было нельзя, потому что это корневой инфраструктурный компонент.
В итоге мы получили стабильное решение, которое смогли ввести в продакшн значительно раньше, чем если бы продолжили дожидаться Istio и решений с его стороны.
А если предположить, что тогда Istio был бы готов. Вы бы стали его внедрять?
Мы бы запустили следующий перфоманс-тест, и если вы всё было хорошо, то смотрели бы на стабильность в плане логики работы. Если бы там не было больших проблем (скорее всего их бы не было, потому что мы их еще несколько лет назад полноценно ревьюили и репортили), то да, скорее всего мы бы пошли в сторону Istio.
Кроме оверхеда у Istio было ещё одно не очень приятное для нас качество — большие возможности. С одной стороны, это круто, ты можешь делать очень много с помощью инструмента. С другой стороны, порог входа и удобство использования оставляло желать лучшего. Это огромное количество разной документации разного уровня качества. Входить и разбираться в проект, в котором есть большое количество возможностей, крайне сложно и вводить в такой инструмент нескольких инженеров достаточно затратно.
Сейчас разработчики Istio сворачивают управление его возможностями в небольшой set кастомных ресурсов, возможностей конфигурации. Делают, чтобы по дефолту все работало максимально в том виде, в каком нужно пользователям в продакшене.
Возможно, какие-то такие вещи могли бы нас еще остановить, но в целом это всё решаемое. Скорее всего, мы бы взяли Istio как основное решение.
Сейчас Istio всё ещё на позиции лидера, или есть какие-то более-менее равноценные аналоги?
Я бы сказал, что есть три продукта, которые точно стоит рассматривать.
Не стоит фокусироваться чисто на Istio. Стоит посмотреть, попробовать, как минимум изучить, какие есть возможности и архитектура работы трех решений. Первое — Istio, второе — Linkerd2, несмотря на то, что он без envoy proxy, посмотреть на его механику работы, попробовать в каких-то частях своей системы, я думаю, стоит. Так как у этого проекта как раз долгое время был упор на перфоманс, на более эффективную работу, и возможно, что в конкретном кейсе он подойдёт лучше, где нужно будет более эффективно сделать взаимодействие. Хотя на горизонте нескольких лет все-таки есть уверенность, что победят service mesh на базе envoy.
Третье решение, которое точно стоит посмотреть, — это Consul Connect от HashiCorp. Это решение, по сути, альтернатива. Оно в текущих версиях ушло от своего прокси-контейнера тоже в сторону envoy proxy. И сейчас Consul Connect умеет настраивать envoy и умеет решать задачи мультиклауда — если у нас несколько дата-центров, либо несколько публичных облаков, он позволяет объединять это в единую сеть. Если в стеке технологий в компании уже есть Consul или другие продукты от HashiCorp, то, возможно, это вообще очень хороший кандидат в том плане, что он позволяет объединять в единую сеть в том числе ворклоады и части системы, которые находятся, например, вне Kubernetes-кластеров, вне стандартных решений, на которые обычно ложатся service mesh.
Ну и с точки зрения стабильности HashiCorp имеет реальных клиентов, и они в них внедряют и отлаживают эту систему, поэтому она продакшн-реди, и ее можно рассматривать как хорошее решение для внедрения к себе.
Если смотреть на эти три проекта в целом, то всё ещё кажется, что выиграет Istio, но вполне возможно, что будет просто несколько альтернативных решений как сейчас. Consul Connect, на мой взгляд, сейчас достаточно популярен. Менее популярен, чем Istio, но есть определенный набор компаний, который его использует в продакшене и успешно.
Интересно, что ты не упомянул связку, которую вы используете.
Да, могу рассказать про нашу связку. Мы заопенсорсили наш продукт: и Netra, и Navigator можно найти на GitHub, их можно использовать. В принципе, это один из вариантов, который можно внедрить, и он действительно — с точки зрения перфоманса и тех фич, которые реализованы, — очень стабилен, проверен уже временем, там несколько лет активного использования в продакшене.
Но есть один момент. Наши решения решали проблемы именно «Авито» в первую очередь. Поэтому здесь можно посмотреть, насколько наши решения закрывают все потребности.
Сейчас мы не предоставляем наше решение как продукт с возможностями платной или бесплатной поддержки. Мы, конечно, отвечаем на вопросы тем, кто использует, например, Netra (она давно используется в нескольких компаниях и помимо Авито), но надо понимать, что это не бизнес в данный момент. Это просто open source решение.
Ты был основным разработчиком этого решения?
Одним из основных. Конкретно Netra занимался в основном я и в будущем было еще несколько человек, это уже точечные contribution по добавлению дополнительной функциональности. Всего в сумме поучаствовало где-то 5-6 человек. Navigator — это уже более мощное решение, в его разработке изначально участвовало уже три инженера и в будущем подключались еще на различные проекты и фичи, которые были нужны, еще несколько человек. Это те, кто активно развивали продукт.
Текущие решения, которые используются в «Авито», закрывают все задачи, которые были поставлены до этого?
Те проблемы, которые мы хотели решить этими инструментами, мы их решили, но, как и любой инструмент, любой продукт не может быть заморожен, у него все равно с течением времени появляются какие-то новые фича реквесты, новые хотелки, которые нужны. И мы продолжаем его активно дорабатывать. Внедряем какие-то новые фичи, например, из последних вещей, mTLS тот же самый и внедрение его по всей системе сейчас в активной фазе развития. То есть, такого рода вещи, которые мы изначально не ставили в цель решение с помощью этих инструментов, но сейчас такие задачи появились, и мы их закрываем этими решениями. Navigator растет, развивается. Изначальные задачи были решены, но есть и новые.
Предположим, компания решила внедрять service mesh. Какие компетенции необходимы команде?
Вообще технология service mesh лежит посередине между разработчиками и теми, кто занимается эксплуатацией. Какие необходимы знания? Надо точно понимать, как происходит взаимодействие тех узлов в системе, в которые мы хотим это внедрять. Какие протоколы используются, какая сетевая подсистема, Kubernetes, как сейчас происходит взаимодействие инстансов в нашей системе. Вообще представлять, как работает на текущий момент наша система.
Ключевым я бы назвал понимание именно сетевого стека работы всех систем, протоколов, TCP, прикладных протоколов, которыми общаются микросервисы в системе. И в целом понимание того, как архитектурно работают такие распределенные системы.
Чего-то особенного тут, в принципе, нет. Это система, которая использует достаточно стандартные подходы, стандартные технологии для своего внедрения, поэтому каких-то базовых знаний, в принципе, достаточно. Но важно понимать именно сетевую составляющую, как происходит взаимодействие узлов.
Ты сказал, что service mesh — это нечто посередине между разработчиками и теми, кто занимается эксплуатацией. А какая роль разработки здесь? И вообще, внедрение service mesh влияет на работу разработчиков?
Это зависит от того, каким образом оно внедряется и потом поставляется. Я имел в виду, что, с одной стороны, инфраструктурный компонент, который достаточно низкоуровнево внедрятся во взаимодействие между узлами, на самом деле решает те задачи, которые обычно решают разработчики в своем коде, прямо в своих микросервисах. И это инструмент, который позволяет как бы перевести на уровень ниже это. Поэтому здесь и возникает такой момент, что, с одной стороны, внедряют это обычно ребята из платформы, те, кто занимается инфраструктурой, но, с другой стороны, в результате получаются фичи, которые нужны в первую очередь разработчикам микросервисов. Например, circuit breaker паттерн.
Это вещи, которые нужны разработчикам и поэтому разработчики обычно здесь вовлечены с той стороны, что они, во-первых, должны понимать, какого рода дополнительные фичи вносятся во взаимодействие. И во-вторых, в зависимости от того подхода, который выбирает компания, они могут либо их настраивать (то есть понимать, какие есть возможности и применять манифесты для настройки этого взаимодействия), либо с помощью каких-то более высокоуровневых абстракций, инструментов, также опосредованно использовать эту технологию. Например, говорить: я хочу, чтобы ко мне была другого вида балансировка трафика. И оно там под капотом в итоге улетает в service mesh и применятся. Поэтому это что-то посередине. Конечно, с точки зрения внедрения, это больше со стороны инфраструктуры, но интересует и разработчиков.
О чем ты будешь рассказывать на интенсиве по service mesh?
Когда мы приходим компанией к тому, что эта технология нам полезна, и мы хотим ее потрогать, посмотреть и внедрить в будущем в своей компании, здесь есть два поинта.
Первый состоит в том, что эта технология достаточно сложна в первоначальном входе, есть много различных компонентов, возможностей, настроек, и нужно разобраться вообще, как это все архитектурно устроено, за что каждый компонент отвечает. Понять, как работают все эти механизмы, чтобы подступиться к внедрению технологии или наоборот понять, что такой подход нам вообще неинтересен и неприменим в конкретном случае. Поэтому первый момент, который будет раскрываться, это именно сама механика работы. Что это за технология, как она позволяет закрывать эти проблемы, которые мы обсуждали.
Второй момент очень важен для компаний, особенно крупных, у которых есть фокус на то, что все системы должны работать стабильно, без даунтаймов и действительно нет возможностей для экспериментов на продакшене. На самом деле, большинство компаний такие. Крайне важно понимать, какими шагами можно прийти к тому, чтобы эту систему полноценно внедрить и внедрить без каких-то неожиданностей в продакшене. И здесь есть путь, который мы прошли, есть большое количество граблей, на которые мы наступили и сами словили в момент и внедрения, и эксплуатации этого решения.
Поэтому есть важные моменты, которые в каждой части курса мы будем рассматривать, как правильно подходить к внедрению разных частей service mesh. Расскажем в целом, как этот процесс вести таким образом, чтобы не ронять всю систему и понимать в будущем, в момент эксплуатации, что у нас вообще происходит.
Service mesh — это технология, которая на самом низком уровне радикально меняет инфраструктуру. И если вдруг в момент эксплуатации что-то идёт не так, это обычно приводит к катастрофе — полные даунтаймы системы, серьезные последствия. Поэтому очень важно понимать, как все устроено и как в эксплуатации быть уверенным в том, что все работает в штатном режиме и в случае проблем быстро это исправлять.
Основной упор всё-таки будет сделан на Istio?
С помощью Istio мы будем рассматривать именно подходы и брать его как основную реализацию. То есть, смотреть, как это все использовать, все основные фичи и так далее. Но envoy proxy — это сейчас основное решение, вокруг которого базируется большинство service mesh, и мы не будем прямо сильно фокусироваться на каком-то интерфейсе Istio и, грубо говоря, изучать, какие ключи нужно ввести, чтобы получить определенную настройку.
Мы будем смотреть в сторону возможностей и просто с помощью Istio их быстро настраивать, чтобы понять, как оно работает внутри, как это правильно внедрить в свою систему, какие там механики действуют под капотом, потому что это самое важное при внедрении и при использовании технологии — понимать, как оно всё работает внутри. Но Istio – это хороший пример, потому что практически все возможности в нём реализованы, и с использованием этого инструмента мы как раз можем пощупать это со всех сторон, всё попробовать.
Как будет проходить практика?
Несмотря на то, что service mesh — это подход, мы говорим о конкретных технологиях и конкретных решениях, и поэтому большая часть интенсива будет посвящена практике. Рассмотрим различные зоны возможностей этой технологии и попробуем их внедрить на конкретной системе.
Ключевой момент – будем не просто смотреть на то, какие там фичи есть, и пробовать их, мы будем работать в условиях, максимально приближенных к реальным. У нас будет некоторый проект без service mesh, он будет крутиться в Kubernetes-кластере, жить своей жизнью. И мы будем внедрять эту технологию, смотреть, как это корректно делать именно в таких условиях, когда у нас уже что-то есть. Потому что большинство компаний будут внедрять не с нуля, и нам это важно отработать. Также все кейсы мы берем из реальной практики и будем последовательно закрывать возникающие проблемы с помощью service mesh.
Кому не стоит идти на этот курс?
Тем, кто осознал все возможности и особенности и понял, что никакая проблема из существующих не решается с помощью service mesh. Тем, кто работает с системой, которая состоит из одного кусочка, где просто нет этого уровня проблем: проблем взаимодействия большого числа узлов, безопасности и так далее. Потому что очевидно: когда у нас 1-2 элемента в системе, это всё можно сделать руками, без использования этих подходов.
А если говорить про уровень специалистов? Интенсив рассчитан на техлидов или специалистов, которые потенциально могли бы это внедрять?
С одной стороны, можно сказать, что это будет полезно тем, кто еще сомневается, не принял решение, и это могут быть техлиды и вообще человек, который активно не работал с Kubernetes — он получит одного рода инсайты из этого курса. Но я проектировал интенсив направленный на то, чтобы человек после него имел полное представление о технической части, как возникающие проблемы решаются и в итоге качественно и с полным пониманием технологии мог её внедрять. Поэтому целевая аудитория — практикующие инженеры эксплуатации, платформенные и инфраструктурные разработчики. Их и ожидаю увидеть!
Третий интенсив по Service Mesh пройдет 9-11 декабря 2022 года, с подробной информацией можно познакомиться по ссылке: https://slurm.club/3Oc9ciD .
