Что такое сервисная сетка и какие задачи управления инфраструктурой она решает? Как в Авито реализовали сервисную сетку и почему отказались от популярного Istio? Почему вы начали писать аналог и что у вас в итоге получилось? Об этом в интервью Slurm рассказал Александр Лукьянченко, руководитель архитектурной команды Авито и разработчик интенсива по service mesh. В «Авито» Александр Лукьянченко строит внутреннюю платформу для всех разработчиков на базе оркестратора Kubernetes. Уже готовлю в Slurm второй интенсивный курс по Service Mesh , который стартует в сентябре 2021 года.
Начнем с основ: что такое сервисная сетка?
Сервисная сетка — это подход, который позволяет организовать умную сеть внутри системы, а эта сеть, в свою очередь, дает возможность решать определенные задачи и проблемы.Например, более гибко управлять трафиком, создавать более безопасную связь между узлами системы, организовывать развертывание канареечных релизов, внедрять гибкие механизмы развертывания новых микросервисов, да и вообще любых частей системы.
Это подход, когда мы — неважно, какая у нас технология, на каком стеке написана система — добавляем в каждый узел сайдкар-контейнер и через него получаем возможность реализовать любую логику в сетевом взаимодействии.
В результате мы можем реализовать всякие вещи, о которых я упомянул, а также инструменты наблюдаемости — чтобы понять, как взаимодействуют все эти части системы.
Как узнать, что компании пора внедрять сервисные решения?
Самое главное — понять, какие проблемы есть в системе и покрывает ли их сервисная сетка.
- Управление трафиком: канареечные развертывания, сине-зеленые развертывания, различные схемы балансировки (кадровый перебор, хеш-балансировка и т. д.) между микросервисами.
Речь идет об эффективности и условном тестировании на производстве, чтобы меньше влиять на пользователей в случае возникновения проблем.
- Безопасность.
Когда мы хотим не только внешне, но и внутренне иметь безопасную связь между всеми узлами системы.
Многие люди обращаются к технологиям исходя из этого.
Если в системе много компонентов и нужно сделать так, чтобы каждый из них взаимодействовал с другим через безопасное соединение, протокол — это сложная задача не только с точки зрения реализации, но и с точки зрения поддержки.
Вам необходимо вручную чередовать сертификаты или написать инструменты, которые будут это делать.
И сервисная сетка решает эти проблемы.
- Наблюдательность.
В развитой микросервисной архитектуре не всегда можно быстро найти причину деградации или какого-то сбоя.
Service Mesh позволяет легко реализовать унифицированную распределенную трассировку и мониторинг.
Это включает в себя ведение журнала, но именно ведение журнала сетевого взаимодействия.
Например, прокси-сервер envoy позволяет удобно и подробно получать логи всех взаимодействий.
- Интеграция крупных частей системы в единую сеть.
Например, несколько кластеров Kubernetes. Это также важный момент. Здесь есть два момента.
Во-первых, используя этот подход, мы обновляем кластер Kubernetes до новых версий, делая это не для постепенного перехода.
А во-вторых, когда у нас есть, например, несколько провайдеров публичных облаков или собственные дата-центры, мы можем использовать этот подход для объединения их в единую сеть.
- Отказоустойчивость системы.
В распределенной системе периодические сетевые ошибки могут возникать в разных частях.
С помощью автоматического выключателя, обнаружения выбросов и шаблонов политики повторных попыток вы можете обойти эти проблемы.
Но реализация их в каждом узле обходится дорого.
Эту проблему также можно решить с помощью сервисной сетки.
На мой взгляд, их наличие — хороший сигнал о том, что нужно присмотреться к сервисной сетке.
Также по косвенным признакам: когда имеется развитая микросервисная архитектура со множеством независимых частей, которым необходимо взаимодействовать друг с другом; когда сложно понять, как они взаимодействуют; когда нужно выстроить между ними более надежные и безопасные взаимодействия и сделать это вручную еще можно, но дорого и сложно — тогда компания приходит к сервисной сети.
Если система состоит буквально из нескольких микросервисов или представляет собой одно монолитное приложение, то это можно решить и другими средствами, и совершенно не обязательно — я бы даже сказал, бессмысленно — использовать сервисную сетку.
Как на Авито пришли к внедрению сервисной сетки?
Глобальных задач было две: решить проблемы с пониманием происходящего в системе и более гибко управлять трафиком.Сначала мы хотели улучшить наблюдаемость, получить единый мониторинг и трассировку.
Это была первая цель, которую мы достигли, внедрив сервисную сетку.
Через некоторое время потребовалось добавить возможности управления трафиком: реализовать canary-релизы, использовать несколько кластеров Kubernetes в одной среде.
Мы не обновляем кластеры Kubernetes на месте, а вместо этого создаем кластеры Kubernetes рядом и переносим все сущности из одного кластера в другой.
Без создания единой сети и сервисной сетки делать это было болезненно, потому что в каждом узле системы нам приходилось переписывать правила прохождения трафика — сказать, что теперь мы идём в другой кластер Kubernetes. Эти две глобальные задачи возникли с разницей примерно в год. Когда мы только начали подходить к решению, помимо истории с наблюдаемостью, был еще один технический аспект, почему мы вообще пошли на эту технологию, начали ее исследовать и внедрять, почему мы начали смотреть на Istio. Дело в том, что к тому моменту мы уже использовали в продакшене Contour.io от Heptio (сейчас VMware).
Contour — это входящий контроллер на основе прокси-сервера envoy. Это более мощное решение, чем стандартный входной контроллер на базе Nginx. Он позволяет вам делать много разных вещей, которые может делать посланник, включая реализацию более мощных стратегий управления трафиком и встроенных канареечных выпусков.
Кроме того, у Contour была лучшая производительность, чем у механики, которую использовал Nginx (перезагрузка конфигураций со сторонним контроллером и много lua-логики).
Но что самое интересное, Contour, по сути, использовал тот же технологический стек и тот же подход, что и решения Service Mesh. У него был собственный самолет управления, очень похожий на тот, что есть у Istio (на тот момент это был пилотный компонент).
Он использовал то же прокси-решение — прокси-сервер посланника.
Мы поняли подход и знали, что прокси-сервер посланника уже готов к использованию и может использоваться в нашей системе.
Итак, мы начали заходить в Istio.
В отчет Про сервисную сетку вы сказали, что ее реализация также определялась задачами тестирования.
Да, это всего лишь трек про управление дорожным движением.
В непроизводственных средах нам очень нужна была функция — перенаправление динамического трафика на новую версию микросервиса.
Это один из подходов, который позволил нам дешево протестировать: мы просто публикуем новую версию сервиса и с помощью сервисной сетки перенаправляем на него трафик только для этих конкретных тестовых запросов с помощью специальных заголовков.
Возвращаясь к переходу с Contour на Istio: чем эти решения отличаются?
Contour — входящий контроллер, то есть решение, позволяющее получать внешний трафик внутри кластеров Kubernetes. По сути, это единственная проблема, которую он решает. Istio и технологии Service Mesh в целом — это технологии, которые позволяют использовать одни и те же подходы, но решают проблемы взаимодействия между узлами внутри системы.Например, обеспечивать различный трафик между микросервисами, реализовывать связь mTLS между узлами.
По сути, это тот же подход, но масштабированный на всю систему.
Надо сказать, что практически все сервисные решения предоставляют возможность (в одной плоскости управления, на одних и тех же технологиях) использовать собственный ингресс-контроллер.
Например, у Istio есть Gateway. Но есть и отдельные проекты, которые делают чисто входные контроллеры, Contour — один из них.
Рассматривали ли вы другие решения, кроме Istio?
На тот момент (а это был, по-моему, 2017 год) было два проекта, которые мы рассматривали — Istio и Conduit (теперь переименованный Линкерд 2 ).Почему мы выбрали Istio? Первый момент был в используемых технологиях, ведь envoy proxy на тот момент уже был готовым к производству продуктом, который использовали крупные компании.
Например, в Lyft, где разработали прокси-сервер envoy, он уже использовался по шаблону service mesh. Мы понимали, что это решение, скорее всего, будет хорошо подготовлено к нагрузкам и будет успешно использоваться в Авито с точки зрения производительности.
А у Conduit было собственное решение, написанное на Rust. У нас было мало экспертизы в этом языке, и казалось, что это не очень правильный подход, что у него тоже есть свой прокси.
Второй момент — это, конечно же, маркетинг Istio и внедрение его в индустрию компаниями Google и IBM. Они очень хорошо представили проект в отрасли: выпустили множество презентаций и видеороликов о возможностях Istio. Примерно за год им удалось сделать так, что если кто-то узнавал о сервисной сетке или говорил о ней, то рядом с ней всплывало слово «Istio».
Istio стал своего рода реализацией по умолчанию.
И мы понимали, что, скорее всего, в перспективе нескольких лет Istio станет основной реализацией, которую будет использовать большинство компаний.
Другие реализации могут остаться, но они будут менее популярны и менее поддерживаемы, чем Istio.
Как вы начали реализацию? В своем интервью вы сказали, что до этого около года тестировали Istio.
Приступив к реализации, мы уже примерно понимали, как все работает и как организовать процесс.
Вы начали с песочницы?
Естественно, они распространялись постепенно.Сначала мы протестировали механику работы на staging-кластерах и поняли логику.
Потом начали внедрять постепенно, сервис за сервисом.
Через несколько месяцев мы добрались до производства.
К тому моменту у нас уже была достаточно большая система в основном кластере Kubernetes: тысячи инстансов, тысячи микросервисных подов.
Поэтому новую систему сразу проверили на производительность – насколько она готова к такому объему.
При внедрении Istio в производство всплыли очевидные проблемы, в том числе и та, из-за которой мы через некоторое время решили отказаться от Istio. Самой большой проблемой оказалась производительность работы Istio. Я много говорил об этом на конференциях.
Причина этой проблемы была скрыта в архитектуре, и ее нельзя было исправить без сильной реализации в исходном коде Istio. Каждый экземпляр содержал знания обо всей системе, а поскольку у нас уже была большая система с тысячами экземпляров, каждый из узлов потреблял большой объем оперативной памяти.
В то же время для получения этих знаний Istio активно задействовала как сеть, так и ЦП.
Мы посмотрели, как это все повело себя в продакшене, умножили на количество наших инстансов и в принципе даже были готовы справиться с таким объёмом (хотя он был огромный, терабайты ОЗУ просто так).
Но мы понимали, что в будущем мы будем расти, и этот объём тоже будет расти, причём квадратично.
То есть решение просто не масштабируется.
Кроме того, в ходе реализации возникли некоторые проблемы, были обнаружены ошибки – мы их исправили сами.
К тому времени у нас уже был свой форк Istio — вещи, которые мы не могли быстро запихнуть в апстрим, мы исправили сами.
Но исправить проблему с производительностью на тот момент было крайне сложно, ведь нужно было переписать 30 процентов кодовой базы Istio. Получилось, что мы вроде бы используем Istio, но при этом нам пришлось его сильно изменить, и в итоге получить свою уникальную сервисную сетку, просто на основе Istio. Потом мы начали понимать, что Istio в таком виде в нашем производстве долго летать не сможет. Вместе с еще одним моментом, на который они закрыли глаза: Istio был не очень стабилен с точки зрения API и от релиза к релизу вносил ломаные изменения.
Для крупных компаний это проблема, ведь когда мест, где используется технология, много, менять названия для каждого случая — это большой труд. Но мы были готовы с этим мириться, если бы не проблемы с производительностью.
Как могло случиться, что Istio разработан такими крупными компаниями, но плохо справляется с большими нагрузками?
Istio и многие другие решения Service Mesh развивались эволюционно.Возьмите даже доверенное лицо посланника.
Первая версия протокола не использовала gRPC, что позволяло серверу обновлять конфигурации на каждом узле.
Он использовал обычный http, который обеспечивал накладные расходы на взаимодействие плоскости управления с прокси-контейнерами.
Соответственно, это потребляло большое количество ресурсов ЦП и сети на долгий опрос, затем через некоторое время перешли на gRPC. В случае с Istio точно такая же история.
Сначала мы сделали базовое решение, которое в целом решило необходимые проблемы, но без серьезных реализаций.
По моему мнению, архитектурные решения вроде распределения всех открытий по каждому узлу были приняты исходя из того, что они просто работают. Да, они работали до определенного уровня и на этапе зарождения технологий это было не так важно.
Внедрение на некоторых не очень крупных проектах сработало хорошо и позволило быстро добиться результата.
Забегая вперед, скажу, что в конце 2018 года Istio решила реализовать механизм четкого объявления зависимостей.
Мы использовали этот подход в нашей плоскости управления, разработанной после отказа от Istio. Он появился в Istio где-то в 2019 году и как раз позволял четко заявить, какому узлу какие данные нужны — и таким образом решить проблемы с потреблением памяти, потреблением сети и в целом оптимизировать всю эту систему.
Но это было несколько лет спустя.
Отказавшись от Istio, вы начали разрабатывать собственное решение.
На какие характеристики вы обратили внимание в первую очередь? Нам предстояло довольно долгое путешествие.
После первой реализации Istio мы преследовали те же цели, повышая в первую очередь наблюдаемость.
Чтобы просто иметь возможность получать необходимые метрики от каждого узла и отслеживать промежутки от каждого микросервиса, мы разработали альтернативный прокси.
Мы заменили прокси-сервер envoy своей собственной реализацией, которая позже стала известна как Netramesh. Это тоже технология service mesh, она позволила нам без плоскости управления, без конфигурирующей части прокси-контейнера получить от всей системы необходимую нам информацию о том, как взаимодействуют части системы.
Мы жили с этим решением довольно долго, и оно до сих пор находится в производстве.
Со временем возникла новая задача — объединить несколько кластеров Kubernetes в единый контур.
Однажды выяснилось, что у нас есть несколько эквивалентных кластеров Kubernetes, которые используются в одной среде.
Пришлось управлять ими с помощью единой сети, и мы снова пришли к сервисной сетке.
Только в этом случае нужно было знать всю систему, все кластеры Kubernetes, в каждой ноде.
Нам нужна была та самая плоскость управления — специальный компонент, который сообщал бы всем, куда идти, какие у нас зоны, какие зоны отказа и так далее.
Так мы пришли к созданию дополнительного решения, по архитектуре очень похожего на Istio. Мы взяли прокси-сервер, написали плоскость управления для его протокола xDS и назвали это решение Navigator ( Здесь Вы можете увидеть основное описание и исходный код).
Таким образом, сейчас у нас в продакшене два прокси-контейнера: Netramesh, который занимается задачами наблюдаемости, и envoy proxy, который настраивается с помощью Navigator и управляет трафиком.
В результате нам удалось соединить кластеры Kubernetes в единую систему и объединить их в единую сеть.
Сейчас мы используем большое количество прокси-серверов и сервисную сетку с использованием Navigator. Включая различные схемы балансировки трафика между сервисами, canary-развертывания, mTLS, липкие сессии (по кукам, по заголовкам), настройку зон приоритета трафика, использование обнаружения выбросов и повторных попыток подключения везде.
Это способ.
Соответственно, каждое из этих решений решало конкретную проблему.
Во-первых, Нетра закрыла проблему наблюдаемости, теперь взаимодействием между экземплярами микросервиса управляет Навигатор.
Когда возникла необходимость объединить кластеры, вы снова рассматривали Istio?
Да, перед внедрением «Навигатора» мы пытались еще раз внедрить Istio, проводили тесты производительности, уже зная проблемы, но он все еще был не готов.Это было где-то полтора года назад, а еще через полгода эту проблему решили в Istio с помощью специальной сайдкар-субъекта, позволяющей отсекать обнаружение.
Я общался в сообществе Istio и знал, что решение будет, и что оно будет именно таким, но мы не могли ждать — были проблемы и потребности, которые нужно было решать.
Тогда мы подумали, что в достаточно короткие сроки сможем разработать собственную плоскость управления, которая будет решать конкретный набор задач (не всё, что есть в Istio, а только определённый пул).
Примерно так и произошло.
Первую версию «Навигатора» мы разработали всего за месяц.
Более того, большая часть времени была потрачена на написание мощной мультикластерной инфраструктуры e2e-тестирования.
Без них было невозможно, потому что это корневой компонент инфраструктуры.
В результате мы получили стабильное решение, которое смогли запустить в производство гораздо раньше, чем если бы мы продолжали ждать Istio и ее решений.
И если предположить это, то Istio будет готов.
Вы бы это реализовали? Запускаем следующий тест производительности и, если все в порядке, смотрим на стабильность с точки зрения логики работы.
Если бы там не было больших проблем (скорее всего, их бы и не было, потому что мы их полностью рассмотрели и сообщили несколько лет назад), то да, скорее всего, мы бы пошли в сторону Istio. Помимо накладных расходов, у Istio было еще одно не очень приятное для нас качество — большие возможности.
С одной стороны это круто, с инструментом можно многое сделать.
С другой стороны, порог входа и удобство использования оставляли желать лучшего.
Это огромное количество различной документации разного уровня качества.
Вйти и разобраться в проекте, имеющем большое количество возможностей, крайне сложно, а ввести в такой инструмент нескольких инженеров — довольно дорого.
Теперь разработчики Istio сжимают управление его возможностями в небольшой набор пользовательских ресурсов и параметров конфигурации.
Они следят за тем, чтобы по умолчанию всё работало максимально в том виде, в котором это нужно пользователям в продакшене.
Возможно, какие-то такие вещи еще могли бы нас остановить, но в целом это все решаемо.
Скорее всего, в качестве основного решения мы бы взяли Istio.
Istio сейчас по-прежнему лидирует или есть более-менее равноценные аналоги?
Я бы сказал, что есть три продукта, на которые определенно стоит обратить внимание.Не сосредотачивайтесь исключительно на Istio. Стоит поискать, попробовать и хотя бы изучить, каковы возможности и операционная архитектура трех решений.
Первый — Istio, второй — Linkerd2, несмотря на то, что у него нет прокси-сервера посланника, думаю, стоит посмотреть на его механику и попробовать его в некоторых частях вашей системы.
Поскольку в этом проекте долгое время был упор на производительность, на более эффективную работу, возможно, он лучше подойдет в конкретном случае, где необходимо будет сделать взаимодействие более эффективным.
Хотя на горизонте нескольких лет все еще есть уверенность, что service mesh на базе envoy победит. Третье решение, на которое определенно стоит обратить внимание, это Консул Коннект от ХашиКорп.
Это решение по сути является альтернативой.
В текущих версиях он отошел от своего прокси-контейнера и стал использовать прокси-сервер посланника.
И теперь Consul Connect умеет настраивать envoy и может решать мультиоблачные задачи — если у нас несколько дата-центров или несколько публичных облаков, это позволяет нам объединить это в единую сеть.
Если в стек технологий компании уже входит Consul или другие продукты от HashiCorp, то, возможно, это вообще очень хороший кандидат в том смысле, что он позволяет объединить рабочие нагрузки и части системы, находящиеся, например, за пределами Kubernetes, в единый сетевые кластеры, выходящие за рамки стандартных решений, которые обычно поддерживают сервисные сетки.
Ну а с точки зрения стабильности у HashiCorp есть реальные клиенты, и они у них эту систему внедряют и отлаживают, так что она готова к производству, и ее можно рассматривать как хорошее решение для внедрения дома.
Если посмотреть на эти три проекта в целом, то все равно кажется, что Istio победит, но вполне возможно, что альтернативных решений просто будет несколько, как сейчас.
Consul Connect, на мой взгляд, сейчас достаточно популярен.
Менее популярен, чем Istio, но есть определенный круг компаний, которые используют его в производстве и успешно.
Интересно, что вы не упомянули комплект, который используете.
Да, я могу рассказать тебе о наших отношениях.
Мы получили наш продукт: и Нетра , И Навигатор можно найти на GitHub и использовать.
В принципе, это один из вариантов, который можно реализовать, и действительно, с точки зрения производительности и реализуемых возможностей, он очень стабилен, проверен временем, было несколько лет активного использования в продакшене.
.
Но есть один момент. Наши решения решили проблемы Авито в первую очередь.
Таким образом, здесь вы можете увидеть, как наши решения покрывают все ваши потребности.
В настоящее время мы не предоставляем наше решение в виде продукта с платной или бесплатной поддержкой.
Мы, конечно, отвечаем на вопросы тех, кто пользуется, например, Нетрой (она уже давно используется в нескольких компаниях, кроме Авито), но надо понимать, что это не бизнес на данный момент. Это просто решение с открытым исходным кодом.
Вы были основным разработчиком этого решения?
Один из основных.Конкретно над Нетрой в основном работал я и в дальнейшем было ещё несколько человек, это уже целенаправленный вклад в добавление дополнительного функционала.
Всего приняло участие около 5-6 человек.
Навигатор — уже более мощное решение; В его разработке изначально участвовали три инженера, а в дальнейшем еще несколько человек были задействованы в различных проектах и функциях, которые были необходимы.
Это те, кто активно развивал продукт.
Покрывают ли текущие решения, используемые в Авито, все задачи, которые были поставлены ранее?
Мы решили проблемы, которые хотели решить с помощью этих инструментов, но, как и любой инструмент, любой продукт нельзя заморозить; со временем у него все еще появляются новые запросы на функции, новые пожелания, которые необходимы.И мы продолжаем активно его дорабатывать.
Мы вводим некоторые новые функции, например, из последних вещей, mTLS тот же и его внедрение во всю систему сейчас находится в активной фазе разработки.
То есть это такие вещи, которые мы изначально не ставили целью решить с помощью этих инструментов, но сейчас появились такие проблемы, и мы решаем их этими решениями.
«Навигатор» растет и развивается.
Первоначальные проблемы решены, но есть и новые.
Допустим, компания решает внедрить сервисную сеть.
Какие компетенции нужны команде? В целом технология Service Mesh находится посередине между разработчиками и теми, кто занимается эксплуатацией.
Какие знания необходимы? Нам необходимо понять, как именно происходит взаимодействие тех узлов системы, в которую мы хотим ее реализовать.
Какие протоколы используются, какая сетевая подсистема, Kubernetes, как сейчас взаимодействуют инстансы в нашей системе.
В общем, представьте, как сейчас работает наша система.
Я бы сказал, что ключом является понимание сетевого стека всех систем, протоколов TCP, протоколов приложений, которые взаимодействуют с микросервисами в системе.
И вообще понимание того, как архитектурно работают такие распределенные системы.
В принципе, ничего особенного здесь нет. Это система, которая использует достаточно стандартные подходы, стандартные технологии для ее реализации, поэтому некоторых базовых знаний в принципе достаточно.
Но важно понимать сетевую составляющую, как взаимодействуют узлы.
Вы сказали, что сервисная сетка — это что-то среднее между разработчиками и теми, кто занимается эксплуатацией.
Какова здесь роль развития? И вообще, влияет ли внедрение сервисной сетки на работу разработчиков? Это зависит от того, как это будет реализовано и затем доставлено.
Я имел в виду, что с одной стороны инфраструктурный компонент, реализованный на достаточно низком уровне во взаимодействии между узлами, фактически решает те задачи, которые разработчики обычно решают в своем коде, прямо в своих микросервисах.
И это инструмент, который позволяет вам как бы опустить это на более низкий уровень.
Поэтому здесь возникает момент, что, с одной стороны, это обычно реализуют ребята с платформы, те, кто занимается инфраструктурой, но, с другой стороны, в результате получаются фичи, которые нужны в первую очередь разработчикам микросервисов.
Например, схема выключателя.
Это вещи, которые нужны разработчикам и поэтому обычно разработчики занимаются тем, что им, в первую очередь, нужно понять, какие дополнительные возможности привносятся во взаимодействие.
А во-вторых, в зависимости от подхода, который выберет компания, они могут либо настроить их (то есть понять, какие возможности доступны и использовать манифесты для настройки этого взаимодействия), либо с помощью каких-то более высокоуровневых абстракций, инструментов и т. д. косвенно использовать это.
технологии.
Например, скажите: Я хочу, чтобы ко мне приходил другой тип балансировки трафика.
И именно там под капотом со временем вылетает в сервисную сетку и используется.
Так что это где-то посередине.
Конечно, с точки зрения реализации это больше со стороны инфраструктуры, но и разработчикам это интересно.
О чем вы будете говорить на мартовской встрече? интенсивная сервисная сетка ?
Когда мы как компания приходим к выводу, что эта технология нам полезна, и мы хотим прикоснуться к ней, посмотреть и внедрить ее в будущем в нашей компании, здесь есть два момента.Во-первых, эта технология поначалу довольно сложная, там много разных компонентов, возможностей, настроек и нужно вообще понимать, как это все архитектурно устроено, за что отвечает каждый компонент. Понять, как работают все эти механизмы, чтобы подойти к реализации технологии или, наоборот, понять, что такой подход нам вообще неинтересен и неприменим в конкретном случае.
Поэтому первым моментом, который раскроется, является именно механика самой работы.
Что это за технология, как она позволяет решать те проблемы, которые мы обсуждали.
Второй момент очень важен для компаний, особенно крупных, у которых упор делается на то, что все системы должны работать стабильно, без простоев, а возможности для экспериментов на производстве действительно нет. На самом деле, большинство компаний именно такие.
Крайне важно понимать, какие шаги можно предпринять, чтобы эта система была полностью внедрена и внедрена без каких-либо сюрпризов в производстве.
И здесь есть путь, который мы прошли, есть большое количество ошибок, на которые мы наступили и поймали себя в момент как внедрения, так и эксплуатации этого решения.
Поэтому есть важные моменты, которые мы будем рассматривать в каждой части курса, как правильно подойти к реализации разных частей сервисной сетки.
Расскажем в общих чертах, как провести этот процесс так, чтобы не уронить всю систему и понять в дальнейшем, в момент эксплуатации, что у нас происходит. Service Mesh — это технология, которая на самом низком уровне радикально меняет инфраструктуру.
И если вдруг во время работы что-то пойдет не так, это обычно приводит к катастрофе – полному простою системы, серьезным последствиям.
Поэтому очень важно понимать, как все работает и как в работе быть уверенным, что все работает нормально и в случае возникновения проблем быстро это исправить.
Будет ли основное внимание по-прежнему уделяться Istio?
С Istio мы рассмотрим именно подходы и возьмем его за основную реализацию.То есть посмотреть, как всем этим пользоваться, все основные возможности и так далее.
Но envoy proxy сейчас является основным решением, вокруг которого базируется большинство сервисных мешей, и мы не будем напрямую сильно зацикливаться на каком-то интерфейсе Istio, а, грубо говоря, изучать, какие ключи нужно вводить, чтобы получить ту или иную настройку.
Мы рассмотрим возможности и просто воспользуемся Istio для их быстрой настройки, чтобы понять, как это работает внутри, как правильно внедрить в свою систему, какие механики работают под капотом, ведь это самое главное при внедрении и использовании.
технология - понять, как все это работает внутри.
Но Istio — хороший пример, потому что в нем реализованы практически все возможности, и с помощью этого инструмента мы можем просто ощутить его со всех сторон, все попробовать.
Как будет проходить стажировка?
Хотя service mesh — это подход, но речь идет о конкретных технологиях и конкретных решениях, а потому большая часть интенсива будет посвящена практике.Давайте посмотрим на разные Теги: #Управление разработкой #Системное администрирование #Kubernetes #DevOps #slurm #service mesh #istio #linkerd2 #avito #envoy proxy #consul Connect
-
- Мы Обязательно Вам Перезвоним
19 Oct, 24 -
В Здании Apple Произошел Пожар.
19 Oct, 24 -
Руткит Выгоняется Руткитом
19 Oct, 24
