Сравнение архитектур Service Mesh и Ambient Mesh: новый взгляд на Istio25.12.2024 14:00

Современные распределённые системы требуют надёжных, безопасных и масштабируемых способов управления сетевым взаимодействием между сервисами. Технологии Service Mesh, такие как Istio, предоставляют набор инструментов для решения этих задач. Недавно в экосистеме Istio появилась новая архитектура — Ambient Mesh, предлагающая альтернативный подход к реализации сетевых функций. В данной статье мы рассмотрим, чем отличаются классический Service Mesh и Ambient Mesh в контексте Istio, а также их преимущества и недостатки.

Что такое Service Mesh?

Service mesh на практике, он же sidecar mode

Service Mesh — это архитектура, которая внедряет дополнительный слой управления сетевым взаимодействием между микросервисами. Ключевые функции Service Mesh включают:

• Балансировку нагрузки (Destination Rule)

• Шифрование (mTLS) и управлением трафиком (Virtual service)

• Авторизацию и аутентификацию запросов

• Логирование, мониторинг и трассировку запросов

В традиционных реализациях Service Mesh, таких как Istio, используется концепция sidecar-прокси. Эти прокси развёртываются рядом с каждым приложением в виде отдельного контейнера или процесса, отвечая за перехват и обработку всего входящего и исходящего трафика.

Преимущества sidecar-архитектуры:

• Чёткое разделение сетевой логики и логики приложения.

• Возможность использования зрелых и надёжных прокси, таких как Envoy.

• Гибкость в настройке маршрутизации и политики безопасности.

• Полное observability по всему кластеру

Недостатки sidecar-архитектуры:

• Усложнение инфраструктуры за счёт увеличения количества контейнеров.

• Повышенные требования к ресурсам, так как каждый sidecar потребляет память и процессорное время.

• Более сложная отладка и управление в крупных кластерах.

• Также критична версия istio из-за разности подхода в использовании xDS API для управления Envoy

Преимущества ambient-архитектуры:

• Упрощённая архитектура: отсутствие sidecar-прокси уменьшает количество контейнеров.

• Снижение затрат на ресурсы, так как функции распределены между общими компонентами.

• Возможность поддержки как L4, так и L7 уровней, что позволяет гибко адаптироваться к требованиям приложений.

• Упрощение процессов отладки и поиска ошибок благодаря чёткой сегментации функций между ztunnel и waypoint-прокси.

Недостатки ambient-архитектуры:

• Новизна подхода: технология ещё не достигла зрелости и требует дальнейших доработок. Можно сказать еще не все issue устоялись

• Очень много фич находятся в стадии Alpha и Beta тестирования, тот же VirtualService в Alpha на момент публикации статьи

Сравнение Service Mesh и Ambient Mesh

• Архитектура:

  • Sidecar предполагает развертывание побочного прокси рядом с каждым сервисом в поде. Это позволяет управлять трафиком и безопасностью на уровне пода, обеспечивая высокую степень изоляции.

  • Ambient устраняет необходимость в sidecar, перекладывая обработку трафика на инфраструктуру плоскости данных. Это упрощает внедрение и управление, но снижает уровень изоляции.

• Производительность:
  Sidecar создает дополнительную нагрузку на поды, так как каждый прокси потребляет ресурсы. В Ambient Mesh обработка трафика вынесена из подов, что может снизить задержки и нагрузку на приложения.

• Обновление:
  В sidecar-архитектуре обновление компонентов требует перезапуска каждого пода, что может быть сложно при масштабных развертываниях. Ambient Mesh облегчает процесс обновления, так как изменения применяются централизованно.

• Безопасность:
  Sidecar обеспечивает безопасность трафика внутри пода, изолируя его от других компонентов. Ambient Mesh больше полагается на безопасность сети, что может быть уязвимым в случае недостаточного контроля.

• Деплой:
  Sidecar требует более сложной конфигурации, что увеличивает время на развертывание и поддержку. Ambient Mesh, благодаря своей упрощенной архитектуре, легче в управлении.

• Гибкость:
  Sidecar подходит для сценариев, где требуется детальная настройка и высокая степень контроля. Ambient Mesh больше ориентирован на сценарии с минимальными требованиями к изоляции и простым масштабированием.

• Трассировка и логирование:
  В sidecar подходе наблюдение за трафиком встроено в прокси, что позволяет отслеживать события на уровне приложения. Ambient Mesh использует сетевые механизмы, что иногда ограничивает глубину анализа.

Ambient Mesh: новый подход

В режиме Ambient Istio реализует свои функции с помощью L4-прокси на узел и, при необходимости, L7-прокси на уровень namespace.

Такой подход позволяет постепенно внедрять Istio: от отсутствия mesh до безопасного L4 overlay и полного L7-функционала и политики на уровне namespace. Workloads в разных режимах работы Istio data plane работают совместимо, позволяя комбинировать возможности в зависимости от потребностей.

Поскольку pods больше не требуют sidecar-прокси для участия в mesh, Ambient Mode часто называют «mesh без sidecar».

Как это работает

Ambient Mode разделяет функциональность Istio на два уровня:

1. Ztunnel: безопасный overlay, который отвечает за маршрутизацию и реализацию Zero Trust для трафика.

2. Waypoint-прокси: предоставляет полный набор функций Istio для L7, таких как управление трафиком и политика. Эти прокси запускаются как часть инфраструктуры и не требуют изменений в pods приложений.

Ztunnel (Zero Trust Tunnel) — это узкоспециализированный L4-прокси на узел, написанный на Rust, который обеспечивает безопасное соединение и аутентификацию workloads в mesh. Он обрабатывает функции L3 и L4, такие как mTLS, аутентификация, авторизация на уровне L4 и телеметрия. ztunnel не завершает HTTP-трафик workloads и не анализирует заголовки HTTP.

Waypoint-прокси — это экземпляр Envoy который написан на C++, используемый Istio для режима sidecar. Эти прокси развертываются вне pods приложений, масштабируется и обновляется независимо от приложений.

Некоторые сценарии использования Ambient Mode ограничиваются функциями L4 secure overlay, не требуя развертывания waypoint-прокси. Для сценариев, требующих управления трафиком и функций L7, необходимо развертывание waypoint-прокси.

Пример реализации Ambient Mode:

1. ztunnel (по умолчанию): Zero Trust Networking (mTLS, туннелирование трафика, авторизация и телеметрия на уровне L4).

2. ztunnel и Waypoint Proxy: Расширенные функции управления трафиком, включая маршрутизацию VirtualService и авторизацию, аутентификацию на уровне L7.

Контрольная плоскость (Control plane)

Принцип работы между control plane и data plane ztunnel

В Ambient Mesh контрольная плоскость остаётся схожей с традиционной архитектурой Istio, обеспечивая:

• Управление конфигурацией: распространение политик и настроек на компоненты рабочей плоскости.

• Выдачу сертификатов: обеспечение безопасности через управление сертификатами для шифрования трафика.

• Мониторинг и телеметрию: сбор метрик и логов для анализа и наблюдения за системой.

Прокси-сервер ztunnel использует API xDS для взаимодействия с контрольной плоскостью Istio (istiod). Прокси ztunnel также получает mTLS-сертификаты для учетных записей служб (Service Accounts) всех подов, запущенных на его узле Kubernetes, используя xDS. Один прокси ztunnel может выполнять функции уровня L4 для любых подов, находящихся на его узле, что требует эффективного получения соответствующей конфигурации и сертификатов. Такая многопользовательская архитектура резко отличается от модели sidecar, где у каждого пода приложения есть собственный прокси.

Рабочая плоскость (Data plane)

Примечание: Хотя на рисунке туннели HBONE показаны между прокси ztunnel, на самом деле они соединяют исходный и целевой модули. Трафик шифруется и инкапсулируется HBONE в сетевом пространстве исходного модуля, а затем расшифровывается и декапсулируется в пространстве целевого модуля. Прокси ztunnel обрабатывает управление и транспорт HBONE из сетевых пространств обоих модулей.

Режим ambient в Istio предлагает более гибкую и производительную архитектуру сетевого плана данных (data plane), минимизируя сложность и упрощая управление сетевым трафиком. Он поддерживает три категории рабочих нагрузок (workloads):

1. Вне mesh (Out of Mesh):
   Обычный pod, не использующий возможностей Istio или ambient data plane. Трафик не перехватывается и не обрабатывается.

2. Внутри mesh (In Mesh):
   Pod включен в ambient data plane, где трафик перехватывается на уровне L4 прокси-сервером ztunnel. Это позволяет применять L4 политики. Для активации этого режима используется метка namespace istio.io/dataplane-mode=ambient

3. Внутри mesh с Waypoint-прокси (In Mesh, Waypoint enabled):
   Pod включен в mesh и использует waypoint-прокси для обработки трафика на уровне L7. Активируется меткой namespace istio.io/use-waypoint=waypoint

Обратите внимание, что локальный трафик, показанный на рисунке от модуля C3 до целевого модуля S1 на рабочем узле W2, также проходит через локальный экземпляр прокси-сервера ztunnel, поэтому функции управления трафиком L4, такие как авторизация и телеметрия L4, будут применяться к трафику одинаково, независимо от того, пересекает ли он границу узла.

Особенности маршрутизации в режиме Ambient

Исходящий трафик (Outbound)

При исходящем запросе из pod в mesh, трафик перенаправляется на локальный ztunnel, который определяет, как обработать запрос. Основные варианты:

• По умолчанию: Трафик направляется как в стандартном Kubernetes: к Service или напрямую к IP pod’а.

• Если цель в mesh: Запрос обновляется до шифрованного канала HBONE.

• Если у цели есть Waypoint-прокси: Запрос проходит через waypoint для применения L7 политик.

Входящий трафик (Inbound)

Входящие запросы перенаправляются на локальный ztunnel, который:

• Проверяет запросы по политикам авторизации (Authorization Policies).

• Принимает HBONE или обычный трафик (plaintext).

Если цель использует waypoint, ztunnel гарантирует, что запрос пройдет через него для применения политик. Однако трафик из сторонних источников (out of mesh), sidecar или шлюзов не учитывает waypoint-прокси.

Наблюдаемость (Observability)

Ztunnel:

Waypoint:

• Waypoint, благодаря использованию Envoy под капотом, генерирует полные L7-метрики, такие как:

  • HTTP-запросы (общее количество, успешные/ошибочные, латентность).

  • Распределение по методам (GET, POST и т.д.).

  • Логи детализированных запросов, включая URI и заголовки.

  • gRPC вызовы и статус коды.

  • Метрики потоковой передачи (например, WebSocket).

Такое разделение позволяет выбирать подходящее решение в зависимости от уровня анализа, который требуется для вашего приложения: Ztunnel — для инфраструктурных задач, Waypoint — для задач, связанных с телеметрией приложений.

HBONE

HBONE («HTTP/2-based Overlay Network Environment») — это протокол, используемый в Ambient Mesh для туннелирования трафика между узлами и подами. Слушает по умолчанию порт 15008 для приложений которые умеют его понимать и обрабатывать. Пока что не умеет обрабатывать HTTP туннелирование (например, UDP)

Поскольку HBONE представляет собой всего лишь комбинацию HTTP/2, HTTP CONNECT и mTLS, пакеты туннеля HBONE, которые передаются между прокси-серверами с поддержкой HBONE, выглядят следующим образом:

Формат пакета HBONE L3

Он обеспечивает:

• Прозрачную маршрутизацию: позволяет передавать трафик через ztunnel без необходимости модификации приложений.

• Шифрование: гарантирует безопасность данных при передаче между сервисами.

Важным свойством туннеля HBONE является то, что исходный запрос приложения может быть проксирован прозрачно, без какого-либо изменения потока трафика базового приложения. Это означает, что метаданные о соединении могут быть переданы на прокси-серверы назначения без изменения запроса приложения — например, устраняя необходимость добавлять заголовки специфичные для Istio к трафику приложения.

Режим с Waypoint-прокси

Waypoint-прокси обрабатывает только HBONE-трафик, применяя L7 политики, такие как:

• AuthorizationPolicy

• RequestAuthentication

• WasmPlugin

• Telemetry

Для Service может быть реализована маршрутизация и балансировка нагрузки. Например, следующая политика направляет запросы к Service reviews на её версию reviews-v1 90% запросов и reviews-v2 10% запросов:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: reviews
  namespace: default
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: reviews
    port: 9080
  rules:
  - backendRefs:
    - name: reviews-v1
      port: 9080
      weight: 90
    - name: reviews-v2
      port: 9080
      weight: 10

Пример работы ztunnel + waypoint:

• L4: Трафик между pod’ами C1 (узел W1) и S1 (узел W2) защищен mTLS через туннели HBONE, организованные ztunnel.

• L7: Если настроен waypoint-прокси, трафик проходит через него, где применяются L7 политики (например: аутентификация по JWT, LB policy или retries), прежде чем попасть на конечный pod.

При использовании Waypoint proxy доступны следующие типы маршрутов:

Подробнее о функциональных возможностях маршрутизации можно узнать в документации по управлению трафиком.

Установка waypoint proxy в namespace

Перед развертыванием прокси-сервера waypoint для определенного пространства имен убедитесь, что пространство имен помечено следующим образом:

kubectl label ns default istio.io/use-waypoint=ambient

Далее у нас есть 2 выбора: или установить L7 на весь namespace или выбрать объекты более локально. Пример для установки маршуртизации на выбранный service:

kubectl apply -f - <

kubectl label ns default istio.io/use-waypoint=waypoint

$ kubectl debug $(kubectl get pod -l app=curl -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it -n ambient-demo  --image nicolaka/netshoot  -- ss -ntlp
Defaulting debug container name to debugger-nhd4d.
State  Recv-Q Send-Q Local Address:Port  Peer Address:PortProcess
LISTEN 0      128        127.0.0.1:15080      0.0.0.0:*
LISTEN 0      128                *:15006            *:*
LISTEN 0      128                *:15001            *:*
LISTEN 0      128                *:15008            *:*

kubectl logs ds/ztunnel -n istio-system  | grep inpod
Found 3 pods, using pod/ztunnel-hl94n
inpod_enabled: true
inpod_uds: /var/run/ztunnel/ztunnel.sock
inpod_port_reuse: true
inpod_mark: 1337
2024-02-21T22:01:49.916037Z  INFO ztunnel::inpod::workloadmanager: handling new stream
2024-02-21T22:01:49.919944Z  INFO ztunnel::inpod::statemanager: pod WorkloadUid("1e054806-e667-4109-a5af-08b3e6ba0c42") received netns, starting proxy
2024-02-21T22:01:49.925997Z  INFO ztunnel::inpod::statemanager: pod received snapshot sent
2024-02-21T22:03:49.074281Z  INFO ztunnel::inpod::statemanager: pod delete request, draining proxy
2024-02-21T22:04:58.446444Z  INFO ztunnel::inpod::statemanager: pod WorkloadUid("1e054806-e667-4109-a5af-08b3e6ba0c42") received netns, starting proxy

$ kubectl debug $(kubectl get pod -l app=curl -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it --image gcr.io/istio-release/base --profile=netadmin -n ambient-demo -- iptables-save

Defaulting debug container name to debugger-m44qc.
# Generated by iptables-save
*mangle
:PREROUTING ACCEPT [320:53261]
:INPUT ACCEPT [23753:267657744]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [23352:134432712]
:POSTROUTING ACCEPT [23352:134432712]
:ISTIO_OUTPUT - [0:0]
:ISTIO_PRERT - [0:0]
-A PREROUTING -j ISTIO_PRERT
-A OUTPUT -j ISTIO_OUTPUT
-A ISTIO_OUTPUT -m connmark --mark 0x111/0xfff -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A ISTIO_PRERT -m mark --mark 0x539/0xfff -j CONNMARK --set-xmark 0x111/0xfff
-A ISTIO_PRERT -s 169.254.7.127/32 -p tcp -m tcp -j ACCEPT
-A ISTIO_PRERT ! -d 127.0.0.1/32 -i lo -p tcp -j ACCEPT
-A ISTIO_PRERT -p tcp -m tcp --dport 15008 -m mark ! --mark 0x539/0xfff -j TPROXY --on-port 15008 --on-ip 0.0.0.0 --tproxy-mark 0x111/0xfff
-A ISTIO_PRERT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ISTIO_PRERT ! -d 127.0.0.1/32 -p tcp -m mark ! --mark 0x539/0xfff -j TPROXY --on-port 15006 --on-ip 0.0.0.0 --tproxy-mark 0x111/0xfff
COMMIT
# Completed
# Generated by iptables-save
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [175:13694]
:POSTROUTING ACCEPT [205:15494]
:ISTIO_OUTPUT - [0:0]
-A OUTPUT -j ISTIO_OUTPUT
-A ISTIO_OUTPUT -d 169.254.7.127/32 -p tcp -m tcp -j ACCEPT
-A ISTIO_OUTPUT -p tcp -m mark --mark 0x111/0xfff -j ACCEPT
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ACCEPT
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -p tcp -m mark ! --mark 0x539/0xfff -j REDIRECT --to-ports 15001
COMMIT