Наблюдаемость без инструментации: как eBPF заменил флот sidecar-контейнеров
Engineering Team
67% команд Kubernetes перешли на eBPF-наблюдаемость
Согласно ежегодному опросу CNCF 2026, 67% команд Kubernetes теперь используют eBPF-инструменты хотя бы для одного столпа наблюдаемости (метрики, трейсы или логи) — по сравнению с 29% в 2024 и 41% в 2025 году. Переход уже не постепенный — это лавина.
Причина проста: традиционная наблюдаемость на основе sidecar-контейнеров (Envoy-прокси, sidecar-коллекторы OpenTelemetry, агенты Datadog) потребляет огромные ресурсы, добавляет задержку к каждому запросу и требует изменений кода или модификации контейнеров для инструментации. eBPF делает всё это из ядра — без изменений в приложении.
Что такое eBPF и почему это важно
eBPF (extended Berkeley Packet Filter) — это технология, позволяющая запускать изолированные программы внутри ядра Linux без изменения исходного кода ядра или загрузки модулей ядра. Изначально разработанный для фильтрации сетевых пакетов, eBPF эволюционировал в универсальный фреймворк программируемости ядра.
Как это работает
- Напишите небольшую программу на C или Rust (или используйте фреймворк высокого уровня)
- Прикрепите её к точке перехвата ядра — системные вызовы, сетевые события, трейспоинты, входы/выходы функций
- Верификатор eBPF ядра проверяет программу на безопасность (нет бесконечных циклов, нет доступа за пределы, ограниченное выполнение)
- JIT-компилятор транслирует байткод eBPF в нативные машинные инструкции
- Программа выполняется в точке перехвата с производительностью, близкой к нативной
Для наблюдаемости это означает, что вы можете перехватывать каждый HTTP-запрос, DNS-запрос, TCP-соединение, операцию файловой системы и выполнение процесса — без модификации кода приложений, без внедрения sidecar-контейнеров и без перезапуска подов.
// Упрощённая eBPF-программа для трейсинга HTTP-запросов
// Прикрепляется к системному вызову accept() для захвата входящих соединений
SEC("kprobe/tcp_v4_connect")
int trace_connect(struct pt_regs *ctx) {
struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
u32 pid = bpf_get_current_pid_tgid() >> 32;
u16 dport = sk->__sk_common.skc_dport;
u32 daddr = sk->__sk_common.skc_daddr;
struct event_t event = {
.pid = pid,
.dport = ntohs(dport),
.daddr = daddr,
.timestamp = bpf_ktime_get_ns(),
};
bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
&event, sizeof(event));
return 0;
}
Почему это важно для наблюдаемости
Традиционная наблюдаемость требует инструментации — добавления кода, библиотек или sidecar-контейнеров в приложения. У такого подхода три фундаментальные проблемы:
- Накладные расходы на ресурсы — каждый sidecar потребляет CPU и память. В кластере из 500 подов с Envoy-sidecar сами sidecar-контейнеры могут потреблять 30-40% всех ресурсов кластера.
- Пробелы в покрытии — вы можете наблюдать только то, что инструментировали. Сторонние бинарники, события уровня ядра и сетевая инфраструктура остаются слепыми зонами.
- Бремя обслуживания — каждый язык, фреймворк и рантайм требует собственной библиотеки инструментации. Поддержание их в актуальном состоянии на сотнях сервисов — полноценная работа.
eBPF решает все три проблемы: работает в ядре (нулевые накладные расходы на приложение), видит всё, что видит ядро (без пробелов), и работает независимо от языка или фреймворка приложения (инструментируйте один раз, наблюдайте всё).
Стек eBPF-наблюдаемости в 2026 году
Экосистема созрела до набора проверенных в бою инструментов, каждый из которых покрывает определённый домен наблюдаемости:
Cilium + Hubble: сетевая наблюдаемость
Cilium — де-факто CNI (Container Network Interface) для Kubernetes, используемый AWS EKS, Google GKE и Azure AKS как стандартный или рекомендуемый сетевой уровень. Hubble, компонент наблюдаемости Cilium, обеспечивает:
- Видимость потоков L3/L4 — каждое TCP/UDP-соединение между подами с идентификацией источника/назначения, портом, задержкой и объёмом переданных байтов
- Разбор протоколов L7 — HTTP, gRPC, Kafka, DNS и PostgreSQL запросы/ответы без изменений в приложении
- Аудит сетевых политик — видимость того, какие сетевые политики разрешают или запрещают трафик в реальном времени
- Маппинг зависимостей сервисов — автоматическая генерация графа сервисов на основе наблюдаемых паттернов трафика
Pixie: мониторинг производительности приложений
Pixie (проект песочницы CNCF) использует eBPF для APM без инструментации для Kubernetes-нагрузок:
- Автоматический трейсинг протоколов — захват запросов/ответов HTTP/1.1, HTTP/2, gRPC, PostgreSQL, MySQL, Redis, Kafka, DNS, AMQP и NATS
- Непрерывное профилирование CPU — флейм-графы для каждого процесса, генерируемые из стек-трейсов eBPF без профилирующих агентов
- Динамическое логирование — добавление точек трейсинга к работающим приложениям без передеплоя
- Захват полных тел запросов/ответов — просмотр реальных HTTP-заголовков и тел, SQL-запросов и результатов, gRPC-пейлоадов
Tetragon: безопасность и аудит времени выполнения
Tetragon (от Isovalent/Cilium) — инструмент наблюдаемости безопасности и принудительного исполнения политик на основе eBPF:
- Отслеживание выполнения процессов — каждое событие exec, fork и exit с полным контекстом дерева процессов
- Мониторинг файлового доступа — отслеживание чтения, записи и изменения прав доступа к чувствительным файлам
- Аудит сетевых соединений — логирование каждого исходящего соединения с контекстом процесса
- Принудительное исполнение политик безопасности — блокировка подозрительных действий в реальном времени
Grafana Beyla: автоинструментация
Grafana Beyla — агент автоинструментации на основе eBPF, генерирующий OpenTelemetry-совместимые трейсы и метрики без изменений кода:
- Обнаруживает HTTP, gRPC, SQL и Redis-запросы на уровне ядра
- Генерирует OpenTelemetry-спаны с правильной пропагацией контекста трейсинга
- Поддерживает распределённый трейсинг между сервисами
- Интегрируется с Grafana Cloud, Tempo, Mimir и любым OpenTelemetry-совместимым бэкендом
Beyla особенно полезна для команд, мигрирующих с sidecar-коллекторов OpenTelemetry: разверните Beyla как DaemonSet, удалите sidecar-контейнеры — и ваши существующие дашборды Grafana продолжат работать.
Splunk OBI: OpenTelemetry eBPF Instrumentation
На KubeCon EU 2026 (март 2026, Лондон) Splunk анонсировал OBI (OpenTelemetry eBPF Instrumentation) — проект, который вносит автоинструментацию на основе eBPF непосредственно в OpenTelemetry Collector:
- Upstream-first подход — OBI вносится в проект OpenTelemetry, а не является проприетарным инструментом Splunk
- Полная совместимость с OTel — генерирует стандартные сигналы OpenTelemetry (трейсы, метрики, логи) из наблюдений eBPF
- Языково-независимый — работает с любым рантаймом (Go, Java, Python, Node.js, Rust, .NET) без установки SDK
- Гибридный режим — может дополнять существующую SDK-инструментацию данными уровня ядра для полной видимости
OBI представляет конвергенцию экосистем eBPF и OpenTelemetry. Вместо выбора между eBPF-нативными и OTel-нативными инструментами вы получаете оба в одном пайплайне.
Производительность: цифры, которые имеют значение
Экономия ресурсов от eBPF-наблюдаемости драматична. Вот реальные бенчмарки для продакшен-кластера Kubernetes из 500 подов с микросервисным приложением:
Сравнение потребления памяти
| Компонент | Sidecar-подход | eBPF-подход | Экономия |
|---|---|---|---|
| Envoy sidecar (500 подов) | 50 ГБ | 0 (Cilium CNI) | 50 ГБ |
| OTel Collector sidecar (500 подов) | 15 ГБ | 0 (Beyla DaemonSet) | 15 ГБ |
| Агент Datadog (DaemonSet, 20 узлов) | 10 ГБ | Н/Д | 10 ГБ |
| Агенты Cilium (20 узлов) | Н/Д | 8 ГБ | -8 ГБ |
| Агенты Beyla (20 узлов) | Н/Д | 2 ГБ | -2 ГБ |
| Pixie (edge-модули, 20 узлов) | Н/Д | 2 ГБ | -2 ГБ |
| Итого | 75 ГБ | 12 ГБ | 84% снижение |
Нагрузка на CPU
| Метрика | Sidecar-подход | eBPF-подход |
|---|---|---|
| Добавленная задержка на запрос | 1-5мс (hop через Envoy-прокси) | <0.1мс (уровень ядра) |
| CPU-нагрузка на узел | 8-12% | <1% |
| Влияние на хвостовую задержку (p99) | +15-30мс | <1мс |
Операционные метрики
| Метрика | Sidecar-подход | eBPF-подход |
|---|---|---|
| Контейнеры на под | 2-4 (приложение + sidecar) | 1 (только приложение) |
| Время запуска пода | 5-15с (инициализация sidecar) | 1-3с (только приложение) |
| Конфигурационные файлы | 500+ (конфиги sidecar на под) | 20 (конфиги DaemonSet на узел) |
| Языки, требующие SDK | Все (SDK OTel для каждого языка) | Ни одного (уровень ядра) |
| Слепые зоны | Не инструментированные сервисы | Нет (ядро видит всё) |
Менее 1% нагрузки на CPU: как это возможно?
Заявление о менее чем 1% нагрузки на CPU реально и подтверждено независимыми бенчмарками от Isovalent, CNCF и множества компаний-пользователей. Вот почему eBPF так эффективен:
- JIT-компиляция — eBPF-программы компилируются в нативный машинный код JIT-компилятором ядра. Они выполняются с производительностью, близкой к нативной, а не в интерпретаторе.
- Per-CPU карты — структуры данных партиционированы по ядрам CPU, что устраняет конкуренцию за блокировки. Каждое ядро пишет в собственный буфер.
- Ring-буферы — события передаются в пространство пользователя через безблокировочные ring-буферы. Не нужны системные вызовы для каждого события.
- Агрегация в ядре — eBPF-программы могут агрегировать метрики (счётчики, гистограммы) в пространстве ядра, отправляя в пространство пользователя только сводки.
- Селективное прикрепление — eBPF-программы вызываются только в своих конкретных точках перехвата. Программа HTTP-трейсинга запускается только при срабатывании HTTP-связанных системных вызовов.
Руководство по миграции: от sidecar к eBPF
Миграция от мониторинга на основе sidecar к eBPF — поэтапный процесс. Вот рекомендуемый подход:
Фаза 1: Развертывание eBPF-инструментов рядом с sidecar (Недели 1-2)
- Установите Cilium как CNI (если ещё не используете)
- Разверните Hubble для сетевой наблюдаемости
- Разверните Beyla как DaemonSet для автоинструментированных трейсов
- Запустите sidecar и eBPF-наблюдаемость параллельно
- Сравните качество данных и покрытие
Фаза 2: Валидация и настройка (Недели 3-4)
- Убедитесь, что eBPF-инструменты захватывают те же сигналы, что и sidecar-стек
- Настройте обнаружение протоколов Beyla для ваших сервисов
- Настройте разбор L7 Hubble для ваших кастомных протоколов
- Создайте дашборды, зеркалирующие существующие sidecar-дашборды
Фаза 3: Инкрементальное удаление sidecar (Недели 5-8)
- Начните с некритичных сервисов: удалите sidecar-коллекторы OTel
- Мониторьте регрессии качества данных
- Удалите Envoy-sidecar у сервисов, не нуждающихся в продвинутом управлении трафиком
- Сохраните Envoy только для сервисов, требующих его продвинутых функций
Фаза 4: Полный стек eBPF (Недели 9-12)
- Удалите оставшиеся sidecar
- Разверните Tetragon для безопасности времени выполнения
- Консолидируйте алертинг на eBPF-сигналах
- Задокументируйте новую архитектуру наблюдаемости
- Верните освобождённые ресурсы (вы получите 60-80% ресурсов sidecar обратно)
Требования к ядру
eBPF-инструменты наблюдаемости требуют современного ядра Linux. Вот минимальные версии:
| Функция | Минимальное ядро | Рекомендуемое |
|---|---|---|
| Базовый eBPF (карты, программы) | 4.15 | 5.15+ |
| BPF ring buffer | 5.8 | 5.15+ |
| BPF CO-RE (compile once, run everywhere) | 5.5 | 5.15+ |
| BTF (BPF Type Format) | 5.2 | 5.15+ |
| BPF LSM (политики безопасности) | 5.7 | 5.15+ |
Все основные дистрибутивы Kubernetes (EKS с Amazon Linux 2023, GKE с COS, AKS с Ubuntu 22.04) поставляются с ядрами, соответствующими этим требованиям.
Часто задаваемые вопросы
Работает ли eBPF-наблюдаемость с не-Kubernetes нагрузками?
Да. eBPF работает на уровне ядра Linux, поэтому работает с любой нагрузкой — контейнеры, виртуальные машины, bare metal, systemd-сервисы. Cilium и Tetragon могут быть развёрнуты вне Kubernetes, а Beyla поддерживает standalone-режим. Однако наиболее богатый опыт — в Kubernetes, где инструменты могут коррелировать события ядра с метаданными подов и сервисов.
Может ли eBPF заменить распределённый трейсинг?
Для многих команд — да. Beyla и Pixie генерируют распределённые трейсы из наблюдений ядра, включая пропагацию контекста трейсинга. Однако eBPF-трейсы ограничены границами запросов/ответов — они не могут трейсить кастомную бизнес-логику внутри ваших функций. Рекомендуемый подход — eBPF для инфраструктурного трейсинга плюс точечная SDK-инструментация для бизнес-критичных путей.
Как с зашифрованным трафиком (TLS)?
eBPF-инструменты могут трейсить TLS-трафик, прикрепляясь к функциям TLS-библиотеки (например, SSL_read и SSL_write OpenSSL), а не к сетевому уровню. Это захватывает открытый текст до шифрования или после дешифрования. Pixie, Beyla и Cilium поддерживают TLS-трейсинг для OpenSSL, BoringSSL и crypto/tls Go. Поддержка rustls Rust была добавлена в начале 2026.
Безопасен ли eBPF? Может ли баг в eBPF-программе обрушить ядро?
Нет. Верификатор eBPF — это статический анализатор, встроенный в ядро, который проверяет каждую eBPF-программу перед загрузкой. Он отклоняет программы, которые могут вызвать бесконечные циклы, доступ к памяти за пределами или другие нарушения безопасности. Баг в eBPF-программе приведёт к ошибке загрузки — он никогда не обрушит ядро.
Какова общая стоимость владения по сравнению с коммерческими APM-инструментами?
eBPF-инструменты наблюдаемости (Cilium, Hubble, Pixie, Beyla, Tetragon) — open-source. Основные затраты — вычислительные ресурсы (ресурсы DaemonSet — примерно 12 ГБ ОЗУ и 2-3 ядра CPU для кластера из 500 подов) и инженерное время на настройку. По сравнению с коммерческими APM-инструментами (Datadog, New Relic, Splunk), которые берут $15-30 за хост в месяц плюс плата за ингест, eBPF-стеки обычно обходятся на 70-90% дешевле в масштабе.