Привет, Хабр! Я являюсь разработчиком ПО и увлекаюсь изучением английского языка. Представляю вашему вниманию перевод статьи "Demystifying Istio Ambient Mesh for Total Beginners" автора Antonio Berben. Она показалась мне интересной, актуальной и образной, автор проводит отличные аналогии с реальным миром. Итак, перейдём к переводу.
В своем недавнем выступлении я постарался прояснить основные концепции Istio таким образом, чтобы их могли понять новички. В этом посте мы рассмотрим проблемы, возникающие в режиме sidecar, и то, как Istio Ambient Mesh изобретательно решает их, минимизируя использование прокси-серверов, упрощая масштабируемость и поддерживая безопасность. Давайте разберемся.
Service Mesh, каким мы его знаем сегодня
В современном мире мобильные телефоны стали вездесущими, фактически являясь эпицентром нашей повседневной жизни. Мы используем наши мобильные телефоны для общения, будь то приложения для обмена сообщениями, такие как WhatsApp и Twitter, или традиционные телефонные звонки.
У некоторых людей есть любопытная привычка при звонках спрашивать: "Где ты?". Однако в большинстве случаев это не является основной целью нашего звонка, не так ли? Это всего лишь обычный вопрос. Наши звонки или сообщения часто служат разным целям, и знать точное местоположение собеседника не так уж важно.
Рассмотрим международные звонки: они предполагают набор универсального формата номера, что обеспечивает безопасную, зашифрованную связь, которую невозможно перехватить. В наших телефонах можно найти множество статистических данных, от записей звонков до данных об использовании приложений и их потреблении. Они даже позволяют нам блокировать нежелательных абонентов.
Учитывая, что мы во многом полагаемся на мобильные телефоны и их стандартизированный, удобный для пользователя подход, почему мы не применили аналогичную философию к многочисленным сервисам, работающим в наших системах? Не следует ли нам принять аналогичную стратегию для наших цифровых сервисов?
![](https://habrastorage.org/getpro/habr/upload_files/a17/3e9/67b/a173e967b63da9ea2d91d515db912d3a.png)
И это, по сути, и есть Service Mesh. Вместо мобильного телефона, которым владеет человек, это прокси рядом с приложением. В Kubernetes, поскольку прокси-сервер развертывается в качестве sidecar, эта архитектура называется режимом sidecar.
![](https://habrastorage.org/getpro/habr/upload_files/a49/254/167/a49254167cc171699d87be576bd7571b.png)
Ambient Mesh, Концепция
Теперь, когда мы поняли, что можно назвать Service Mesh на базе мобильных телефонов, давайте поднимем дискуссию на более высокий уровень.
Представьте, что вы находитесь в офисе и проводите совещание с удаленными коллегами. Вы и ваша местная команда собираетесь в конференц-зале.
![](https://habrastorage.org/getpro/habr/upload_files/34e/15b/aa8/34e15baa835ce2ba521a6d7138cf2a1c.png)
Учитывая, что мы в основном общаемся через наши мобильные телефоны, кажется, логично для каждого человека, включая ваших товарищей по команде, использовать свои отдельные мобильные телефоны в конференц-зале? Или было бы более эффективно поместить центральный динамик в комнату, позволяя каждому использовать одно устройство? Опасения по поводу безопасности снижаются благодаря физическому ограждению конференц-зала.
В этом, по идее, и заключается суть Ambient Mesh: реархитектура Service Mesh, направленная на минимизацию количества прокси-серверов, упрощение масштабирования и сохранение уровня безопасности, который обеспечивал режим sidecar. В Kubernetes, поскольку такая архитектура не заставляет вас разворачивать прокси для каждого пода (pod), она называется sidecarless режимом.
![](https://habrastorage.org/getpro/habr/upload_files/f56/acb/456/f56acb456d5a3b59d94e47efc38b9347.png)
Внутри конференц-зала стены образуют безопасный периметр, обеспечивая открытое общение. В области 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 и т.д.) для интеграции в приложения на этапе сборки.
Эти библиотеки решали важнейшие задачи, такие как аутентификация, авторизация, безопасность, маршрутизация, обнаружение сервисов и наблюдаемость. На первых порах все работало в рамках одного приложения.
![](https://habrastorage.org/getpro/habr/upload_files/5c2/0b2/d9c/5c20b2d9cb63c914197bdcfe1467c170.png)
Однако с появлением облачно-нативных подходов и Kubernetes эта парадигма сместилась в сторону паттерна sidecar. Вместо того чтобы встраивать эти задачи в каждое приложение, они были добавлены в качестве sidecar-прокси, расположенные рядом с приложением в среде Kubernetes.
![](https://habrastorage.org/getpro/habr/upload_files/bb8/108/64e/bb810864e5fd71807f9c42c9ee03564f.png)
В результате каждый pod теперь развертывает свой прокси, что приводит к ощутимому увеличению потребления ресурсов.
Ожидаемые vs. фактические результаты
Одна из главных проблем режима sidecar в Istio - это культура. Исторически сложилось так, что между разработчиками (devs) и операторами (ops) идет упорная борьба. Часто можно услышать: "Это не мой код, это ваша машина".
![](https://habrastorage.org/getpro/habr/upload_files/3bf/901/812/3bf9018125009370bbeeb69a3d4c62f1.png)
DevOps попытался преодолеть этот разрыв, объединив два мира, но это потребовало изменения культуры, чему многие предприятия воспротивились. В крупных компаниях изменения происходят медленнее. Поэтому, даже если они заявляли, что являются "DevOps", они часто не создавали полностью целостных (end-to-end) команд, что является важнейшим требованием DevOps.
Теперь, с появлением архитектуры Service Mesh и sidecar, эта битва вновь разгорается. Как правило, разработчики предпочитают кодить, а не изучать Kubernetes, которым обычно управляет отдел эксплуатации (Ops). Ops создает простые YAML-файлы для разработчиков, чтобы они могли развернуть свои приложения в Kubernetes.
![](https://habrastorage.org/getpro/habr/upload_files/a09/7f3/e99/a097f3e99a73a26e30631ef85f74e816.png)
При развертывании исключительно в Kubernetes развертывается все, что содержится в YAML. Если у приложения один контейнер, разработчик видит только его.
Но в режиме sidecar, когда разработчик развертывает приложение, он видит контейнеры своего приложения и еще два: Istio и Istio-init. Незаметно Istio вводит свои прокси и инициаторы.
![](https://habrastorage.org/getpro/habr/upload_files/a73/d36/813/a73d3681353f979d372b37e21a1695d1.png)
Разработчику не нужно разбираться в тонкостях Istio. Однако если его приложение выходит из строя, он может заподозрить, что это дополнительное приложение как-то конфликтует.
Например, пользователь сталкивается с проблемой, когда приложение использует порт 15006. Без Istio оно прекрасно работало в Kubernetes, но с Istio оно вышло из строя, поскольку этот порт зарезервирован для прокси и не может быть изменен.
Внесение изменений в прокси влечет за собой переразвертывание приложений
Третья интригующая задача связана с Day-2 operations. В режиме sidecar архитектура объединяет жизненные циклы разработки двух компонентов: приложения и прокси, поскольку они используют один и тот же pod.
Когда развертывается новая версия приложения, прокси в том же pod также перезапускается. Это не является серьезной проблемой, поскольку изменения происходят в приложении, а не в прокси.
Проблема возникает, когда прокси-серверу требуется обновление. В таких случаях операционная команда (Ops) должна обеспечить плавное завершение работы pod.
![](https://habrastorage.org/getpro/habr/upload_files/9ff/eb3/38b/9ffeb338be6a176a868e9944b1297477.png)
Хотя мы живем в мире облачных нативных приложений, не все приложения в Kubernetes соответствуют 12-factor правилам, определяющим облачные нативные приложения.
Фактор номер 9 в этих правилах относится к запуску и плавному завершению работы 12-факторного приложения:
IX. Утилизируемость
Максимизируйте надёжность с помощью быстрого запуска и корректного завершения работы
Процессы 12-факторного приложения являются утилизируемыми, то есть их можно запустить или остановить в любой момент. Это способствует быстрому эластичному масштабированию, быстрому развертыванию кода или изменений конфигурации, а также надежности производственных (production) развертываний.
Для приложений, не совместимых с 12-факторной системой, развертывание прокси может привести к сбоям в работе.
Зачем нужна sidecarless архитектура
Основные проблемы и трудности связаны с шаблоном sidecar, используемым в текущих реализациях Service Mesh, который препятствует развитию и широкому распространению Service Mesh.
Чтобы лучше понять новую архитектуру, давайте вернемся в эпоху объектно-ориентированного программирования и принципов SOLID. Многие архитекторы когда-то были разработчиками, и они применили уроки, полученные при проектировании монолитной функциональности, для проектирования решений на базе микросервисов. Один из ключевых принципов — принцип единой ответственности, который Мартин Фаулер определил так: "У класса или модуля должна быть одна, и только одна, причина для изменения.”
![](https://habrastorage.org/getpro/habr/upload_files/7b9/f3e/24d/7b9f3e24d2998db8457ee7260919ac4c.png)
Применение этого принципа к нашему решению на основе микросервисов, Service Mesh, вызывает вопросы. Зачем нам обновлять Layer 4 прокси (отвечающий за шифрование, безопасность, zero trust и т.д.), если мы изменяем только функциональность Layer 7, например, аутентификацию?
![](https://habrastorage.org/getpro/habr/upload_files/639/867/10e/63986710e20fb1be0648eb08debe156d.png)
Логичным выводом является разделение Layer 4 прокси и Layer 7 прокси. Прокси-сервер Layer 4 служит основой и проходит отдельный жизненный цикл разработки по сравнению с Layer 7 прокси-сервером.
![](https://habrastorage.org/getpro/habr/upload_files/931/984/151/931984151fbb6a0f9535a5a480671768.png)
Прокси 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.