18.06.2026 16:15
Andrey_Biryukov 0 5800 Источник

Привет, Хабр! Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги. Сейчас никого уже не удивишь фразой «мы используем Kubernetes в продуктивной среде». Но, удивляет другое: как многие до сих пор мирятся с сетевым стеком, собранным на коленке из iptables и молитв. Пока вы спите, ваш kube‑proxy методично перебирает цепочки правил, словно архивариус в пыльном подвале. А ведь на дворе — эра eBPF, когда сетевая магия творится прямо в ядре, без лишних телодвижений и копирования данных.

В этой статье мы без сантиментов разберем, почему классический подход с iptables рассыпается при первых признаках нагрузки, как eBPF с XDP переписывает правила игры и почему даже в 2026 году не все так однозначно с «бесплатным ускорением».

Почему iptables больше не тянет

Давайте сразу к цифрам. При сравнении Flannel (overlay), Calico (routing) и Cilium (eBPF), был обнаружен неприятный факт: традиционные решения, построенные на iptables или IPVS, вносят измеримую задержку даже при средних нагрузках. Казалось бы, мелочь. Но когда у вас микросервисная архитектура, где один запрос проходит через 10, 20, 50 сервисов — эта мелочь превращается в секунды ожидания для пользователя.

Причина торможения кроется, в том, что классический kube‑proxy в режиме iptables работает по принципу линейного перебора. Каждый пакет, пришедший на Service IP, должен пройти через цепочку правил, пока не найдет свое соответствие. Если у вас тысяча сервисов (а в нормальном кластере это не предел), то приходящий пакет «стучится» в каждое правило, пока не дойдет до нужного. Сложность — O(n), где n — количество сервисов. Это как искать книгу в библиотеке, где каталог не систематизирован, а просто перечислены все книги подряд.

Есть еще режим IPVS, он использует хеш‑таблицы и работает быстрее, но даже он не решает проблему полностью. При высоких нагрузках и частом обновлении правил (например, при горизонтальном масштабировании подов) накладные расходы существенно растут.

Компания Isovalent (создатели Cilium) приводит такие цифры: при тестировании TCP Connect/Request/Response (CRR) eBPF на порядок обгоняет iptables‑режим kube‑proxy, причем разрыв увеличивается пропорционально числу сервисов. Чем больше ваш кластер — тем больнее вы ощущаете задержки kube‑proxy. 

eBPF и XDP: когда ядро становится программируемым

Теперь — о прекрасном, то есть о eBPF (Extended Berkeley Packet Filter). Забудьте всё, что вы знали о старом добром BPF, который использовался для сниффинга пакетов. Современный eBPF — это виртуальная машина внутри ядра Linux, позволяющая выполнять программы в безопасной песочнице в ответ на системные события.

Что это значит на практике? Раньше, чтобы добавить какую‑то логику в обработку пакетов, нужно было либо писать модуль ядра (рискованно, сложно, требует пересборки), либо поднимать прокси в user‑space (медленно из‑за копирования данных). eBPF позволяет загрузить программу прямо в работающее ядро, причем верификатор проверит, что эта программа не положит систему (нет бесконечных циклов, нет опасных операций).

Но самое интересное — это XDP (eXpress Data Path). XDP позволяет привязать eBPF‑программу к самому раннему этапу обработки пакета — прямо к драйверу сетевой карты, до того, как пакет вообще попал в сетевой стек ядра. Представьте: пакет только что прибыл на NIC, еще не было ни одного прерывания (interrupt), ни одного переключения контекста — а ваша программа уже решила, что с ним делать. DROP? PASS дальше в стек? Перенаправить (REDIRECT) сразу в другой интерфейс? Всё это на скорости, измеряемой в миллионах пакетов в секунду.

Некоторые продвинутые сетевые карты поддерживают даже offload XDP прямо на железо, то есть программа выполняется вообще без загрузки CPU. Но это уже уровень хардварной обработки.

Cilium: Хаббл, карты и никакого kube‑proxy

Cilium — это не просто CNI‑плагин, а целая экосистема вокруг eBPF. Архитектурно Cilium работает так: вместо того, чтобы поддерживать огромные цепочки iptables, он хранит правила маршрутизации и безопасности в BPF maps — специальных хеш‑таблицах внутри ядра. Сложность поиска — O(1). Пакет, пришедший на Service IP (ClusterIP), обращается к карте, мгновенно находит IP эндпоинта (пода) и направляется напрямую, минуя весь зоопарк NAT и маршрутизации.

Более того, Cilium может полностью заменить kube‑proxy. В режиме kube‑proxy replacement он берет на себя всю логику сервисов, а стандартный компонент kube‑proxy отключается. Это упрощает отладку (не нужно копаться в iptables) и убирает накладные расходы.

Как это выглядит на уровне кода? В своем докладе на FOSDEM инженеры Isovalent демонстрировали концепцию: eBPF‑программа, привязанная к XDP‑хуку на интерфейсе, может перехватить пакет, залезть в BPF‑карту с маппингом «Service IP → Pod IP» и отправить пакет прямиком в сетевой неймспейс пода через veth‑пару, даже не заходя в полный сетевой стек хоста.

И это не только про скорость. Hubble — обсервабилти‑слой Cilium — использует те же eBPF‑хуки для сбора метрик, flow‑логов и даже security‑инсайтов без необходимости ставить sidecar‑контейнеры или разворачивать дополнительных агентов.

Что там с безопасностью на сокетах?

Традиционные NetworkPolicy в Kubernetes (например, Calico) работают на L3/L4 и используют фильтрацию в ядре, часто на уровне iptables. Это нормально, но имеет свои ограничения: вы не можете сказать «заблокировать HTTP POST на /admin», только «заблокировать TCP порт 443». Для L7-политик обычно нужен сервис‑меш (Istio, Linkerd) с sidecar‑прокси, который стоит между сервисами.

Cilium реализует L7-политики через eBPF, поднимаясь на уровень протокола. Он может инспектировать HTTP‑заголовки, gRPC‑методы, Kafka‑топики, и всё это прямо внутри ядра, без выноса в user‑space. Это дает огромный прирост производительности по сравнению с классическими прокси.

Но, внимание, подвох! Последние исследования 2025–2026 годов показывают, что L7-обработка eBPF — это не серебряная пуля. В свежей работе IEEE Access (2025) сравнивали производительность CNI при включенных L7-политиках.

Результат: eBPF‑шный Cilium на L7 просаживает throughput с 8.9 Gbps до жалких 94 Mbps. Да, вы не ослышались. Потому что анализ HTTP/1.1 или gRPC внутри ядра — это сложно. Ядро не умеет так же эффективно парсить текстовые протоколы, как это делает Envoy в user‑space.

При тестировании mTLS‑оверхеда в сервис‑меше Cilium показал 99% оверхед (из‑за копирования контекстов ядро → user‑space), в то время как Istio Ambient с user‑space прокси — всего 8%. Но при этом на чистом L4 (без глубокой инспекции) и при большом количестве сервисов (>500) eBPF‑решения выигрывают вчистую.

Когда копать глубже: скрытые грабли AF_XDP

Для сценариев, где XDP не хватает (например, нужна сложная обработка, не влезающая в лимиты eBPF по размеру или сложности кода), существует AF_XDP. Этот механизм позволяет переслать пакет из XDP в user‑space через специальный сокет с нулевым копированием (zero‑copy).

Казалось бы, идеально: быстрый путь в ядре плюс гибкость user‑space.

Но и здесь есть нюанс. Если трафик должен уйти локальному приложению в контейнере, то AF_XDP требует забавного маневра: пакет из UMEM (память, разделяемая между ядром и user‑space) нужно скопировать в veth или другой интерфейс, чтобы доставить в сетевой стек и, собственно, в под.

В итоге вместо одной копии мы получаем две, или работаем в режиме copy‑mode, теряя весь профит. В тесте с memcached XDP (ядро) обогнал AF_XDP на 42% по пропускной способности. Так что, если ваш трафик локальный, XDP предпочтительнее.

Итоговая матрица выбора

Так что же выбрать для кластера? Если у вас небольшой кластер (до 500 нод) и примитивный L4-трафик — отключите kube‑proxy, поставьте Cilium в режиме прямого маршрутизации (Direct Routing) и наслаждайтесь жизнью. Вы получите снижение задержек на десятки миллисекунд.

Если у вас огромный кластер (тысячи нод) или вам нужна L7-фильтрация / mTLS по‑настоящему эффективно — присмотритесь к гибридным решениям или вообще к user‑space сеткам вроде Istio Ambient. Исследования показывают, что Istio лучше держит частую смену подов, чем распределенные агенты Cilium, давая выигрыш по throughput в 56% при одном и том же железе. Итак, eBPF — это великая технология, но она не отменяет законов физики и не делает парсинг HTTP бесплатным.

И последний совет: не ленитесь тестировать на своих нагрузках. Один инженер перевел прод на Cilium с включенной L7-политикой и получил падение RPS в 10 раз. Другой отключил kube‑proxy, настроил XDP для DDoS‑защиты (через те же eBPF‑программы на драйвере NIC) и его API‑шлюз начал выдерживать на 40% больше трафика.

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

Тема eBPF быстро выводит разговор о Kubernetes за пределы привычного «настроили кластер — значит, всё работает». Чтобы глубже разобраться в безопасности, наблюдаемости и эксплуатации инфраструктуры, можно присмотреться к открытым урокам OTUS. Они бесплатно проходят в рамках онлайн‑курсов, и на них можно познакомиться с преподавателями и задать вопросы.

  • 24 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться

  • 1 июля, 20:00. «Классические методы перехвата управления в Linux». Записаться

Больше бесплатных уроков — в дайджесте.

Статьи по теме:

Комментарии (0)