[Перевод] Istio Ambient Mesh для начинающих
Привет, Хабр! Я являюсь разработчиком ПО и увлекаюсь изучением английского языка. Представляю вашему вниманию перевод статьи «Demystifying Istio Ambient Mesh for Total Beginners» автора Antonio Berben. Она показалась мне интересной, актуальной и образной, автор проводит отличные аналогии с реальным миром. Итак, перейдём к переводу.
В своем недавнем выступлении я постарался прояснить основные концепции Istio таким образом, чтобы их могли понять новички. В этом посте мы рассмотрим проблемы, возникающие в режиме sidecar, и то, как Istio Ambient Mesh изобретательно решает их, минимизируя использование прокси-серверов, упрощая масштабируемость и поддерживая безопасность. Давайте разберемся.
Service Mesh, каким мы его знаем сегодня
В современном мире мобильные телефоны стали вездесущими, фактически являясь эпицентром нашей повседневной жизни. Мы используем наши мобильные телефоны для общения, будь то приложения для обмена сообщениями, такие как WhatsApp и Twitter, или традиционные телефонные звонки.
У некоторых людей есть любопытная привычка при звонках спрашивать: «Где ты?». Однако в большинстве случаев это не является основной целью нашего звонка, не так ли? Это всего лишь обычный вопрос. Наши звонки или сообщения часто служат разным целям, и знать точное местоположение собеседника не так уж важно.
Рассмотрим международные звонки: они предполагают набор универсального формата номера, что обеспечивает безопасную, зашифрованную связь, которую невозможно перехватить. В наших телефонах можно найти множество статистических данных, от записей звонков до данных об использовании приложений и их потреблении. Они даже позволяют нам блокировать нежелательных абонентов.
Учитывая, что мы во многом полагаемся на мобильные телефоны и их стандартизированный, удобный для пользователя подход, почему мы не применили аналогичную философию к многочисленным сервисам, работающим в наших системах? Не следует ли нам принять аналогичную стратегию для наших цифровых сервисов?
И это, по сути, и есть Service Mesh. Вместо мобильного телефона, которым владеет человек, это прокси рядом с приложением. В Kubernetes, поскольку прокси-сервер развертывается в качестве sidecar, эта архитектура называется режимом sidecar.
Ambient Mesh, Концепция
Теперь, когда мы поняли, что можно назвать Service Mesh на базе мобильных телефонов, давайте поднимем дискуссию на более высокий уровень.
Представьте, что вы находитесь в офисе и проводите совещание с удаленными коллегами. Вы и ваша местная команда собираетесь в конференц-зале.
Учитывая, что мы в основном общаемся через наши мобильные телефоны, кажется, логично для каждого человека, включая ваших товарищей по команде, использовать свои отдельные мобильные телефоны в конференц-зале? Или было бы более эффективно поместить центральный динамик в комнату, позволяя каждому использовать одно устройство? Опасения по поводу безопасности снижаются благодаря физическому ограждению конференц-зала.
В этом, по идее, и заключается суть Ambient Mesh: реархитектура Service Mesh, направленная на минимизацию количества прокси-серверов, упрощение масштабирования и сохранение уровня безопасности, который обеспечивал режим sidecar. В Kubernetes, поскольку такая архитектура не заставляет вас разворачивать прокси для каждого пода (pod), она называется sidecarless режимом.
Внутри конференц-зала стены образуют безопасный периметр, обеспечивая открытое общение. В области Kubernetes защищенный периметр может быть задан двумя элементами:
Нода (node) кластера, которая группирует приложения на одной ноде, поэтому шифрование этого обмена данными становится бессмысленным.
ServiceAccount, который группирует несколько pod, представляющих сервис, с многочисленными репликами одного pod. Это делает развертывание прокси-сервера для каждой реплики неэффективным.
К этому моменту вы уже поняли, в чем основное преимущество sidecarless подхода по сравнению с sidecar режимом. Однако это еще не все. На протяжении многих лет, по мере того как сообщество тестировало режим sidecar, возникали определенные проблемы, заставлявшие нас переосмыслить архитектуру.
3 основные проблемы, связанные с режимом sidecar
Чтобы продемонстрировать преимущества режима sidecarless (ambient mesh) над режимом sidecar (service mesh), как мы его знаем сегодня, давайте рассмотрим эти проблемы:
Потребление ресурсов
Одной из основных проблем режима sidecar является потребление ресурсов, и эту проблему часто поднимают пользователи, изучающие Service Mesh, такие как Istio.
Чтобы понять, почему так происходит, необходимо разобраться в происхождении Service Mesh. Изначально платформы, подобные Netflix, представляли библиотеки (Hystrix, Zuul, Ribbon и т.д.) для интеграции в приложения на этапе сборки.
Эти библиотеки решали важнейшие задачи, такие как аутентификация, авторизация, безопасность, маршрутизация, обнаружение сервисов и наблюдаемость. На первых порах все работало в рамках одного приложения.
Однако с появлением облачно-нативных подходов и Kubernetes эта парадигма сместилась в сторону паттерна sidecar. Вместо того чтобы встраивать эти задачи в каждое приложение, они были добавлены в качестве sidecar-прокси, расположенные рядом с приложением в среде Kubernetes.
В результате каждый pod теперь развертывает свой прокси, что приводит к ощутимому увеличению потребления ресурсов.
Ожидаемые vs. фактические результаты
Одна из главных проблем режима sidecar в Istio - это культура. Исторически сложилось так, что между разработчиками (devs) и операторами (ops) идет упорная борьба. Часто можно услышать: «Это не мой код, это ваша машина».
DevOps попытался преодолеть этот разрыв, объединив два мира, но это потребовало изменения культуры, чему многие предприятия воспротивились. В крупных компаниях изменения происходят медленнее. Поэтому, даже если они заявляли, что являются «DevOps», они часто не создавали полностью целостных (end-to-end) команд, что является важнейшим требованием DevOps.
Теперь, с появлением архитектуры Service Mesh и sidecar, эта битва вновь разгорается. Как правило, разработчики предпочитают кодить, а не изучать Kubernetes, которым обычно управляет отдел эксплуатации (Ops). Ops создает простые YAML-файлы для разработчиков, чтобы они могли развернуть свои приложения в Kubernetes.
При развертывании исключительно в Kubernetes развертывается все, что содержится в YAML. Если у приложения один контейнер, разработчик видит только его.
Но в режиме sidecar, когда разработчик развертывает приложение, он видит контейнеры своего приложения и еще два: Istio и Istio-init. Незаметно Istio вводит свои прокси и инициаторы.
Разработчику не нужно разбираться в тонкостях Istio. Однако если его приложение выходит из строя, он может заподозрить, что это дополнительное приложение как-то конфликтует.
Например, пользователь сталкивается с проблемой, когда приложение использует порт 15006. Без Istio оно прекрасно работало в Kubernetes, но с Istio оно вышло из строя, поскольку этот порт зарезервирован для прокси и не может быть изменен.
Внесение изменений в прокси влечет за собой переразвертывание приложений
Третья интригующая задача связана с Day-2 operations. В режиме sidecar архитектура объединяет жизненные циклы разработки двух компонентов: приложения и прокси, поскольку они используют один и тот же pod.
Когда развертывается новая версия приложения, прокси в том же pod также перезапускается. Это не является серьезной проблемой, поскольку изменения происходят в приложении, а не в прокси.
Проблема возникает, когда прокси-серверу требуется обновление. В таких случаях операционная команда (Ops) должна обеспечить плавное завершение работы pod.
Хотя мы живем в мире облачных нативных приложений, не все приложения в Kubernetes соответствуют 12-factor правилам, определяющим облачные нативные приложения.
Фактор номер 9 в этих правилах относится к запуску и плавному завершению работы 12-факторного приложения:
IX. Утилизируемость
Максимизируйте надёжность с помощью быстрого запуска и корректного завершения работы
Процессы 12-факторного приложения являются утилизируемыми, то есть их можно запустить или остановить в любой момент. Это способствует быстрому эластичному масштабированию, быстрому развертыванию кода или изменений конфигурации, а также надежности производственных (production) развертываний.
Для приложений, не совместимых с 12-факторной системой, развертывание прокси может привести к сбоям в работе.
Зачем нужна sidecarless архитектура
Основные проблемы и трудности связаны с шаблоном sidecar, используемым в текущих реализациях Service Mesh, который препятствует развитию и широкому распространению Service Mesh.
Чтобы лучше понять новую архитектуру, давайте вернемся в эпоху объектно-ориентированного программирования и принципов SOLID. Многие архитекторы когда-то были разработчиками, и они применили уроки, полученные при проектировании монолитной функциональности, для проектирования решений на базе микросервисов. Один из ключевых принципов — принцип единой ответственности, который Мартин Фаулер определил так: «У класса или модуля должна быть одна, и только одна, причина для изменения.»
Применение этого принципа к нашему решению на основе микросервисов, Service Mesh, вызывает вопросы. Зачем нам обновлять Layer 4 прокси (отвечающий за шифрование, безопасность, zero trust и т.д.), если мы изменяем только функциональность Layer 7, например, аутентификацию?
Логичным выводом является разделение Layer 4 прокси и Layer 7 прокси. Прокси-сервер Layer 4 служит основой и проходит отдельный жизненный цикл разработки по сравнению с Layer 7 прокси-сервером.
Прокси Layer 7 создается по требованию и охватывает группу рабочих нагрузок с одинаковым уровнем безопасности, как правило, на основе service account. Вместо того чтобы иметь один прокси для каждой реплики приложения, у вас есть прокси, который масштабируется иначе, подстраиваясь под конкретные потребности приложений.
Решение проблем
Теперь давайте оценим, насколько эффективно эта архитектура решает перечисленные ранее задачи:
Потребление ресурсов: В наихудшем сценарии мы наблюдаем значительное снижение количества развернутых прокси-серверов по сравнению с режимом sidecar. Более того, по мере масштабирования приложений прокси перестают масштабироваться вместе с ними.
Ожидаемые результаты: Благодаря тому, что компоненты Istio разворачиваются отдельно, разработчики могут работать без путаницы, вызванной внедрением контейнеров Istio в свои приложения. Такая ясность в файлах YAML способствует лучшему пониманию и сотрудничеству, устраняя конфликт между разработчиками и операторами.
Обновление прокси и развертывание приложений: Отделение приложений от компонентов Istio позволяет использовать разные жизненные циклы разработки. Следовательно, изменения в прокси больше не требуют переразвертывания всего стека приложения.
Заключительные размышления
Ambient или sidecarless режим позволил решить не только эти три проблемы, но и привнес значительные инновации.
Полное разделение двух прокси привело к революционному развитию Layer 4 прокси.
Теперь он больше не полагается на Envoy и его язык программирования C. Вместо этого прокси Layer 4 построен с использованием Rust, что обеспечивает превосходную производительность. Кроме того, библиотеки, используемые в прокси, были тщательно протестированы в других продуктах, продемонстрировав свою надежность, что делает добавочную задержку (latency) Service Mesh практически незначительной.
В заключение можно сказать, что Istio Ambient Mesh представляет собой наиболее существенное улучшение Service Mesh за последние годы и является окончательным ответом в дискуссиях о лучшем Service Mesh.
Более серьезные задачи, такие как виртуальные машины, полностью интегрированные в сеть, или IoT (Интернет вещей), не могут быть решены без использования Istio Ambient Mesh.
Habrahabr.ru прочитано 7541 раз
