Как устроен Cilium: eBPF-технологии в сетевой подсистеме Kubernetes

24 июня 2026 г.

Евгений Левашов

Автор статьи

Когда микросервисов становится несколько сотен и каждый из них постоянно общается с другими, сеть кластера перестаёт быть просто инфраструктурой и сама становится узким местом. Классические инструменты вроде iptables, которые создавались для совершенно другой задачи, начинают тормозить: каждый новый под добавляет правила, и ядро вынуждено прогонять каждый пакет через тысячи проверок подряд. Именно здесь появляется Cilium — CNI-плагин, который убирает эту цепочку целиком и заменяет её кодом, работающим прямо внутри ядра Linux через eBPF.

11 октября 2023 года Cilium получил статус Graduated в CNCF — высшую ступень зрелости, до которой раньше добрались только Kubernetes, Prometheus и ещё несколько проектов. К февралю 2025 года (релиз 1.17.0) у него было более 20 800 звёзд на GitHub, а к 2026 году — свыше 24 000.

В этой статье вы разберетесь, почему классическая связка kube-proxy + iptables перестаёт тянуть большие кластеры, как eBPF меняет сетевой стек Linux, из каких компонентов состоит Cilium и как он реализует маршрутизацию, балансировку, L7-политики и наблюдаемость в Kubernetes. А затем увидите, как этим воспользоваться в Managed Kubernetes от VK Cloud.

Статья подготовлена вместе с экспертом

Станислав Погоржельский, технологический евангелист VK Cloud&Data

Почему классические сети Kubernetes на iptables не справляются с highload

iptables создавался для статических файрволов, а не для динамической маршрутизации трафика в Kubernetes. Каждый новый Service или Pod добавляет в ruleset новые правила, и на больших кластерах их число разрастается до десятков тысяч.

Проблема здесь алгоритмическая. В режиме iptables размер ruleset у kube-proxy растёт линейно — O(N) от суммы числа сервисов и эндпойнтов. Для каждого первого пакета нового соединения ядро последовательно сканирует весь список, пока не найдёт совпадение. Из-за этого на кластере с 5000 сервисов и десятками тысяч эндпойнтов растёт задержка на первом пакете нового соединения и увеличивается время обновления самих правил.

Сообщество Kubernetes решало это поэтапно — путь kube-proxy прошёл iptables → IPVS → nftables. Режим nftables стал stable в Kubernetes 1.33; По данным Kubernetes blog, p50-latency у nftables при 5000–10 000 сервисах примерно соответствует лучшему случаю iptables.

Cilium же предложил другой путь — полную замену kube-proxy через eBPF.

Что такое eBPF и как он работает

eBPF (Extended Berkeley Packet Filter) — механизм, который запускает безопасный пользовательский код прямо в контексте ядра Linux в ответ на события: например, на приход сетевого пакета. eBPF работает in-kernel, без переключения контекста между user space и kernel space. Программа исполняется там, где живёт сетевой стек, — отсюда более низкая latency и более высокий throughput.

Безопасность кода гарантирует verifier — компонент ядра, который проверяет программу до запуска. Он работает как абстрактный интерпретатор: символически исполняет все возможные пути программы и доказывает, что код не зациклится, не уронит ядро и не обратится к чужой памяти. Только после этой проверки программа проходит JIT-компиляцию в нативный машинный код.

Но У verifier есть и обратная сторона — это сложный security-critical компонент ядра.

Архитектура Cilium: как устроено сетевое взаимодействие в кластере

Основа Cilium — Cilium Agent, который разворачивается как DaemonSet и работает на каждой ноде. Агент подписан на Kubernetes API и следит за появлением новых подов, сервисов и сетевых политик. Когда состояние кластера меняется, он компилирует под него eBPF-программы и загружает их в ядро ноды.

Перехват трафика происходит на раннем этапе сетевого пути. eBPF-код Cilium цепляется к пакетам на уровне виртуального интерфейса пода (veth) через хуки tc и XDP, и пакет идёт в целевой под кратчайшим путём, минуя длинные цепочки правил iptables.

Скорость поиска назначения обеспечивают eBPF hash maps. Вместо линейного перебора правил Cilium резолвит адрес сервиса через хеш-таблицу за O(1) — время поиска не зависит от числа сервисов в кластере. Именно этот переход от O(n)-перебора к O(1)-lookup снимает деградацию на больших кластерах.

Для входящего трафика XDP (eXpress Data Path) обрабатывает NodePort- и LoadBalancer-трафик на уровне сетевого драйвера, до того как пакет попадёт в основной сетевой стек. Socket-level load balancing перехватывает соединения ещё раньше — на уровне сокета.

Четыре главных преимущества Cilium для Kubernetes

Cilium переносит сетевую обработку в ядро Linux через eBPF и закрывает четыре болевые точки кластера: задержку сети, балансировку трафика, фильтрацию на уровне приложений и наблюдаемость.

1. Максимальная производительность (low latency)

eBPF обрабатывает пакеты внутри ядра, без переключения контекста между пространством пользователя и ядром. Там, где iptables перебирает правила за O(n), Cilium берёт запись из hash map за O(1). In-kernel-обработка высвобождает CPU хост-машин под полезную нагрузку.

2. Умная балансировка нагрузки без kube-proxy

Cilium полностью заменяет kube-proxy и распределяет трафик между репликами сервисов через eBPF hash-таблицы прямо в ядре — поиск нужного бэкенда за O(1). Балансировка работает на socket-level и на уровне XDP.

3. Сетевая безопасность на уровне приложений (L7 network policies)

Обычные CNI фильтруют трафик по IP-адресам и портам — на уровнях L3/L4. Cilium за счёт eBPF разбирает прикладной уровень (L7) и применяет сетевые политики к содержимому запросов. Типичный сценарий: разрешить GET-запросы к API-сервису, но запретить POST с того же источника. Такой подход хорошо ложится в модель Zero Trust.

4. Глубокая наблюдаемость сети с Hubble

Hubble — слой наблюдаемости Cilium, построенный на eBPF. Он строит интерактивную карту сетевых взаимодействий (Service Map) микросервисов в реальном времени, собирает метрики для Prometheus и визуализирует service map в Grafana. Hubble показывает, где дропаются пакеты, — без внедрения sidecar-прокси.

Запустите кластер Kubernetes на базе Cilium CNI в один клик. Используйте преимущества eBPF-архитектуры, продвинутой безопасности и мониторинга в Cloud Containers (Managed Kubernetes) от VK Cloud. Платформа берёт на себя всю автоматизацию настройки инфраструктуры.

Интеграция Cilium в Managed Kubernetes

В Managed Kubernetes от VK Cloud Cilium — одна из двух поддерживаемых сетевых подсистем наряду с Calico. Calico реализует маршрутизацию на уровне L3 через iptables и подходит для средних и крупных кластеров. А Cilium на базе eBPF поддерживает фильтрацию L3/L4/L7 и оптимален для очень больших кластеров с высокой нагрузкой и микросервисных архитектур.

Выбрать Cilium можно в списке CNI при создании кластера — плагин подключится автоматически. Cilium доступен для кластеров второго поколения. Обе CNI взаимодействуют с платформой через программно-определяемую сеть собственной разработки SDN Sprut. Подробности — в документации VK Cloud по сетевым подсистемам.

Платформа поставляет CNCF Certified-кластер с авто-обновлением по клику, встроенным мониторингом Prometheus + Grafana и управлением через Terraform — той же парой инструментов, на которую опирается Hubble. IT-команде остаётся сфокусироваться на сетевых политиках безопасности и деплое приложений, а не на настройке хуков eBPF и сопряжении CNI с сетевой моделью облака.

Кому и когда стоит переходить на Cilium

Высоконагруженные проекты (highload, финтех, крупный e-commerce), где критичны миллисекунды задержки сети
Микросервисные архитектуры с сотнями и тысячами подов, где kube-proxy на iptables перегружает CPU нод
Проекты с жёсткими требованиями ИБ — Zero Trust, аудит сетевых вызовов на L7
Команды, уставшие от траблшутинга «слепых зон» в сети Kubernetes — здесь спасает Hubble

Заключение

Cilium на базе eBPF — закономерная эволюция сетевого стека Kubernetes. Он переносит балансировку, фильтрацию и наблюдаемость в ядро Linux, решает проблему производительности за счёт O(1)-доступа вместо линейного перебора iptables, а безопасность — за счёт политик на уровне приложений. Cilium получил CNCF Graduated 11 октября 2023 года и стал 2-м по активности проектом CNCF. В продакшене его используют Adobe, Capital One и Google.