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

Что такое Service Mesh?

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

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

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

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

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

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

Преимущества 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)

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

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

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

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

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

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

Режим 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:

• Ztunnel фокусируется на предоставлении метрик уровня L3-L4, что включает:

  • Количество открытых TCP-соединений.

  • Объем переданных и полученных данных (байты).

  • Ошибки соединений (таймауты, сбросы).

  • Время установления соединения.

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, выглядят следующим образом:

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

• Прозрачную маршрутизацию: позволяет передавать трафик через 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 - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  labels:
    istio.io/waypoint-for: service
  name: test
  namespace: default
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE
EOF

Здесь у нас L7 трафик будет идти только на service test, остальные service будут работать через ztunnel по умолчанию. Данная фича еще находится в стадии beta на момент публикации статьи.

По умолчанию waypoint обрабатывает только трафик, направленный на службы в его пространстве имён. Вы можете изменить это поведение, добавив метку istio.io/waypoint-for в объект Gateway:

• service — трафик для Kubernetes-сервисов.

• workload — трафик для IP-адресов подов или ВМ.

• all — трафик для сервисов и нагрузок.

• none — без обработки (для тестирования).

По умолчанию waypoint будет обрабатывать только трафик, предназначенный для service в namespace где находится. Этот выбор был сделан, поскольку трафик, направленный только на pod, встречается редко и часто используется для внутренних целей, таких как scrape Prometheus, а дополнительные накладные расходы на обработку L7 могут быть нежелательны.

Также возможно, что waypoint будет обрабатывать не весь трафик, а обрабатывать только трафик, отправленный напрямую на рабочие нагрузки в кластере, или вообще не обрабатывать трафик. Типы трафика, которые будут перенаправлены на точку маршрута, определяются меткой istio.io/waypoint-forна Gatewayобъекте.

Если вы не хотите заморачиваться с L7 на определенный объект, то просто добавьте к namespace:

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

После добавления метки в namespace все запросы от любых модулей будут автоматически подвергаться L7 обработке. Еще есть некоторые уникальные фишки которые подойдут для геораспределенных кластеров по настройке. Более детально почитайте здесь

Метки управления ресурсами

Чтобы значение метки istio.io/use-waypoint работало корректно, убедитесь, что Waypoint proxy настроен для обработки указанных типов ресурсов. По умолчанию Waypoint принимает трафик для сервисов. Например, если вы добавили метку istio.io/use-waypoint на Pod, указывающую определенный Waypoint, последний должен быть помечен меткой istio.io/waypoint-for со значением workload или all.

Трафик через ztunnel: что происходит под капотом

Перенаправление трафика в контексте Ambient Mode — это функция плоскости данных, которая перехватывает трафик, отправляемый и получаемый рабочими нагрузками с включенным Ambient Mesh. Этот трафик направляется через локальные прокси-узлы Ztunnel, которые обрабатывают основной путь данных. Часто для описания этого процесса также используется термин "захват трафика". Ztunnel создан для прозрачного шифрования и маршрутизации трафика приложений. Чтобы достичь этого, требуется механизм для захвата всего трафика, входящего в и выходящего из подов в сети ("in mesh"). Это критически важно для безопасности: если трафик сможет обойти Ztunnel, политики авторизации также окажутся под угрозой.

Основная архитектурная идея перенаправления трафика внутри пода в Ambient Mode заключается в использовании возможностей Ztunnel для захвата данных внутри сетевого пространства имен Linux. Это достигается благодаря взаимодействию двух компонентов: узлового агента istio-cni и локального прокси ztunnel. Этот подход позволяет Istio работать с любым плагином Kubernetes CNI, оставаясь прозрачным для пользователей и не нарушая базовые функции сетей Kubernetes.

Когда новый под создаётся или добавляется в Ambient Mesh, процесс начинается с того, что узловой агент istio-cni реагирует на события, такие как создание или удаление подов, а также отслеживает изменения в API-сервере Kubernetes. При обнаружении нового пода или его включении в Ambient Mesh istio-cni срабатывает и устанавливает дополнительный плагин CNI, который вызывается после выполнения основного CNI-плагина. Этот плагин уведомляет istio-cni, когда новый под создаётся в пространстве имен, уже включённом в Ambient Mode. После получения уведомления агент входит в сетевое пространство имен пода и устанавливает правила перенаправления сети. Эти правила перехватывают все пакеты, входящие в под и выходящие из него, и перенаправляют их на локальный экземпляр Ztunnel, слушающий на стандартных портах (15008, 15006, 15001).

Для достижения этой интеграции istio-cni передаёт низкоуровневый дескриптор сетевого пространства имен пода в Ztunnel через Unix-сокет. Локальный Ztunnel создаёт новый логический экземпляр прокси, выделенный для пода, и запускает соответствующие порты внутри его сетевого пространства имен. После завершения настройки под добавляется в Mesh, и весь его трафик начинает проходить через Ztunnel.

Debug перехвата трафика

Для проверки работоспособности есть 3 стандартных паттерна: логи, наличие открытых портов и таблица маршрутизации

Убедитесь, что сокеты на портах 15001, 15006 и 15008 открыты и находятся в состоянии прослушивания:

$ 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            *:*

Также еще можно посмотреть логи ztunnel которые связаны с inpod:

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

Для проверки настроек iptables внутри одного из подов можно выполнить следующую команду:

$ 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

Вывод команды показывает, что в таблицы NAT и Mangle netfilter/iptables внутри сетевого пространства пода добавлены дополнительные цепочки Istio. Весь TCP-трафик, входящий в под, перенаправляется на прокси Ztunnel для обработки входящего трафика. Если трафик не зашифрован (порт источника != 15008), он перенаправляется на внутренний порт Ztunnel для незашифрованного трафика (15006). Если трафик передаётся по протоколу HBONE (порт источника == 15008), он перенаправляется на порт 15008 для обработки HBONE. Весь TCP-трафик, покидающий под, перенаправляется на порт 15001 Ztunnel для обработки исходящего трафика, а затем отправляется с использованием инкапсуляции HBONE.

Более подробно о дебаге перехвата трафика можно почитать ztunnel и waypoint

Заключение

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

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

Использование таких решений, как Istio, в сочетании с гибкостью новых архитектур, позволяет создавать устойчивые системы, способные адаптироваться к современным вызовам и требованиям. Независимо от выбранного подхода, ключевым остаётся понимание ваших задач и грамотное внедрение технологий для достижения максимальной эффективности и устойчивости вашей инфраструктуры.

P.S. Большинство схем взято с официального сайта istio, я лишь наглядно хотел объяснить преимущества ambient mode над sidecar архитектурой