Скорее всего, вы уже слышали про service mesh — в последние два-три года этот подход становится все популярнее. InfoQ в своём отчёте о трендах программной архитектуры за 2021 год отнесли service mesh к категории Early Majority (раннее большинство).
Одной из распространенных моделей service mesh считается Sidecar-прокси, которые отвечают за сетевое взаимодействие, безопасность и мониторинг. Правда у этой модели помимо плюсов есть и свои минусы: падение производительности, дополнительные издержки при развертывании и др. В этой статье поговорим о том, сможет ли решить эти проблемы плагин с eBPF, а также о том, как он меняет наш подход к работе с service mesh.
Что такое service mesh
Подробности можно почитать здесь. В двух словах:
service mesh — это технология, которая управляет взаимодействием между сервисами в распределённой системе. Service mesh отвечает за горизонтальный трафик (east-west) внутри дата-центра, кластера Kubernetes или распределённой системы.
Эволюция моделей 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 с eBPF
Их немало. Например:
Начальные эксперименты показывают, что задержки при работе с eBPF гораздо меньше, чем с sidecar-прокси.
При использовании 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 и различных схем балансировки между микросервисами, чтобы меньше аффектить пользователей в случае проблем
Приходите на интенсив по service mesh от Александра Лукьянченко, руководителя юнита PaaS в Авито, и Георга Гаала, Senior Infrastructure Engineer в Workato.
Вы на практике изучите принцип работы технологии, решите реальные бизнес-кейсы и научитесь искать причины проблем. После вы:
Будете точно понимать, как правильно подходить к внедрению разных частей service mesh, и как сделать так, чтобы не ронять всю систему.
Разберетесь как в эксплуатации быть уверенным в том, что все работает в штатном режиме, а в случае проблем быстро это исправлять.
Как будет проходить интенсив?
Вы не просто посмотрите на то, какие фичи есть у service mesh, а попробуете с ними поработать в специально разработанном приложении онлайн-кинотеатра, состоящего из нескольких микросервисов.
Мы будем внедрять service mesh с нуля, а также смотреть, как это корректно делать именно в таких условиях, когда у нас уже что-то есть.
Большинство компаний будут внедрять не с нуля, и нам это важно отработать. Также все кейсы мы берем из реальной практики и будем последовательно закрывать возникающие проблемы с помощью service mesh.
Отзывы с прошлого потока:
«Интенсив будет хорошим вариантом как сэкономить кучу времени на набивании шишек», — Станислав Емец, слушатель предыдущего интенсива, ведущий инженер по эксплуатации в Ростелеком ИТ.
«Набрался знаний, часть из которых начал активно применять на своих проектах почти сразу. Отдельно хочу отметить подачу материала: это было не монотонное вливание материала лектором, а достаточно живая подача, постоянно закрепляемая практикой. Такой формат максимально закрепился в голове и руках», — Василий Егоров, Devops-инженер ООО МЛМ-Софт, автор канала RealManual.
Количество мест ограниченно. Узнать подробности и оставить заявку.
