[Перевод] Хотите service mesh без sidecar’ов?18.11.2022 12:32

c8035770be57acf1811a18c599bda0db.png

Скорее всего, вы уже слышали про service mesh — в последние два-три года этот подход становится все популярнее. InfoQ в своём отчёте о трендах программной архитектуры за 2021 год отнесли service mesh к категории Early Majority (раннее большинство).

Источник: InfoQИсточник: InfoQ

Одной из распространенных моделей service mesh считается Sidecar-прокси, которые отвечают за сетевое взаимодействие, безопасность и мониторинг. Правда у этой модели помимо плюсов есть и свои минусы: падение производительности, дополнительные издержки при развертывании и др. В этой статье поговорим о том, сможет ли решить эти проблемы плагин с eBPF, а также о том, как он меняет наш подход к работе с service mesh. 

Что такое service mesh

Подробности можно почитать здесь. В двух словах:

service mesh — это технология, которая управляет взаимодействием между сервисами в распределённой системе. Service mesh отвечает за горизонтальный трафик (east-west) внутри дата-центра, кластера Kubernetes или распределённой системы.

Service Mesh: иллюстрация автораService Mesh: иллюстрация автора

Эволюция моделей service mesh

Сейчас хорошо известно два типа моделей service mesh: с общей библиотекой и sidecar-прокси.

Если мы используем модель с общей библиотекой, приложение реализует возможности service mesh с помощью библиотек для конкретных языков. Это может быть не одна библиотека, а несколько.

Иллюстрация автораИллюстрация автора

У этой модели есть свои плюсы и минусы. Более популярная модель с sidecar-прокси реализует функционал service mesh с помощью sidecar-прокси, который размещается рядом с приложением.

Sidecar-прокси — очень важная часть service mesh. Подробнее о них можно почитать в этой статье. Sidecar-прокси отвечают за сетевое взаимодействие, безопасность и мониторинг.

Иллюстрация автораИллюстрация автора

В чем проблема sidecar-прокси

За несколько лет разработчики заметили несколько недостатков этого подхода:

  • Sidecar у каждого приложения требует дополнительных ресурсов и затрат. В этой статье можно почитать о том, как много памяти потребляет прокси Envoy в крупных развёртываниях.

  • Из-за service mesh может падать производительность, как описано в этой статье.

  • Приходится мониторить не только сам сервис, но и его sidecar.

  • Развёртывание и обслуживание sidecar«ов требует дополнительных издержек.

Что даёт eBPF?

Service mesh без sidecar«ов с eBPF

Cilium показали концепцию service mesh на базе eBPF, где заботу о сетевом взаимодействии, безопасности и мониторинге берет на себя плагин с eBPF в ядре.

Больше о eBPF читайте в этой статье.

Схема модели service mesh на базе eBPF:

Иллюстрация автораИллюстрация автора

С помощью eBPF команда Cilium уже расширяет некоторые возможности service mesh, например:

  • безопасность на основе идентификаторов;

  • авторизация и наблюдаемость на уровнях L3–L7;

  • шифрование;

  • балансировки нагрузки;

  • и т. д.

В бета-версии программы представлено несколько недостающих возможностей service mesh:

  • управление трафиком и балансировка нагрузки на L7 (HTTP, gRPC и т. д.);

  • маршрутизация по кластерам, облакам и локальным ресурсам с учётом топологии;

  • терминация TLS;

  • канареечные развёртывания, повторы запросов, rate linit, размыкание цепи (circuit breaker) и т. д. через Envoy;

  • трейсинг с OpenTelemetry и Jaeger;

  • встроенная поддержка Kubernetes Ingress.

Эволюция моделей service meshЭволюция моделей service mesh

Преимущества service mesh с eBPF

Их немало. Например:

  • Начальные эксперименты показывают, что задержки при работе с eBPF гораздо меньше, чем с sidecar-прокси. 

Источник: https://isovalent.com/blog/post/2021-12-08-ebpf-servicemeshИсточник: https://isovalent.com/blog/post/2021–12–08-ebpf-servicemesh

  • При использовании eBPF нам нужно гораздо меньше прокси — по одному на ноду, а не по одному на сервис. Если у нас, например, 30 сервисов на ноде и мы используем sidecar«ы, то их на ноде будет тоже 30, а если у нас eBPF, то прокси на ноде будет всего один.

  • Чем меньше прокси, тем меньше издержек на развёртывание, память и ресурсы.

Заключение

У eBPF есть потенциал стать нативной и очень эффективной реализацией service mesh, которая освободит нас от sidecar«ов. Это позволит нам внедрить технологию прокси в уже существующую концепцию изоляции namespaces, реализованную в ядре. Таким образом она станет частью изящной концепции контейнеров, которую мы используем каждый день. 

Кроме того, eBPF будет брать на себя всё больше и больше функций, которые сейчас выполняют прокси, чтобы и дальше сокращать издержки и упрощать систему.

Источники:

How eBPF will solve Service Mesh — Goodbye Sidecars

How eBPF Streamlines the Service Mesh

Как прокачать навыки работы с service mesh

Когда бизнесу нужно задуматься о внедрении?

  • у вас развитая микросервисная архитектура со множеством независимых кусков, которым надо взаимодействовать между собой;

  • нужно объединить в единую сеть большие куски системы;

  • сложно понимать, как они взаимодействуют;

  • нужно выстраивать между ними более надежные и безопасные взаимодействия, но сделать это руками дорого и сложно;

  • если вы хотите не только снаружи, но и внутри иметь безопасное общение между всеми узлами в системе;

  • когда в распределенной системе в разных частях возникают сетевые ошибки;

  • для канареечных деплоев, деплоев по методу blue-green и различных схем балансировки между микросервисами, чтобы меньше аффектить пользователей в случае проблем

9–11 декабря пройдет 3-й поток интенсива service mesh от Александра Лукьянченко, руководителя юнита PaaS в Авито, и Георга Гаала, Senior Infrastructure Engineer в Workato.

Вы на практике изучите принцип работы технологии, решите реальные бизнес-кейсы и научитесь искать причины проблем. После вы:

  • Будете точно понимать, как правильно подходить к внедрению разных частей service mesh, и как сделать так, чтобы не ронять всю систему.

  • Разберетесь как в эксплуатации быть уверенным в том, что все работает в штатном режиме, а в случае проблем быстро это исправлять.

Как будет проходить интенсив?

Вы не просто посмотрите на то, какие фичи есть у service mesh, а попробуете с ними поработать в специально разработанном приложении онлайн-кинотеатра, состоящего из нескольких микросервисов.

Мы будем внедрять service mesh с нуля, а также смотреть, как это корректно делать именно в таких условиях, когда у нас уже что-то есть.

Большинство компаний будут внедрять не с нуля, и нам это важно отработать. Также все кейсы мы берем из реальной практики и будем последовательно закрывать возникающие проблемы с помощью service mesh.

Отзывы с прошлого потока:

«Интенсив будет хорошим вариантом как сэкономить кучу времени на набивании шишек»,  — Станислав Емец, слушатель предыдущего интенсива, ведущий инженер по эксплуатации в Ростелеком ИТ.

«Набрался знаний, часть из которых начал активно применять на своих проектах почти сразу. Отдельно хочу отметить подачу материала: это было не монотонное вливание материала лектором, а достаточно живая подача, постоянно закрепляемая практикой. Такой формат максимально закрепился в голове и руках»,  — Василий Егоров, Devops-инженер ООО МЛМ-Софт, автор канала RealManual.

Количество мест ограниченно. Узнать подробности и оставить заявку.

© Habrahabr.ru