Cilium 1.4 как CNI в Kubernetes: eBPF вместо iptables и видимость трафика на уровне HTTP

Один из managed-проектов дорос до точки, где сетевые политики Kubernetes начали выглядеть недостаточно. Стандартный NetworkPolicy работает на уровне IP и портов - а нужно было ограничивать трафик по конкретным HTTP-путям и gRPC-методам. Вариантов несколько: Istio с его sidecar-ами, или CNI-плагин, который умеет это на уровне ядра. Взяли Cilium 1.4 и сравнили с Calico, который стоял до этого.

Что такое Cilium и почему eBPF

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

В классическом CNI (Flannel, Calico с iptables-режимом) каждый пакет проходит через цепочку netfilter: conntrack, NAT, фильтрация. При большом количестве сервисов цепочки iptables вырастают в сотни правил, и каждый пакет идёт по ним линейно. В eBPF-режиме Cilium загружает программы прямо в сетевой стек и обрабатывает пакеты без этого линейного обхода.

Для нас это не просто теория - есть конкретная разница на нагрузке.

Нагрузочный тест: Cilium против Calico

Тестировали на идентичных кластерах: три воркер-ноды, одинаковые Instance Type, тот же образ Kubernetes 1.14. Нагрузку генерировали через iperf3 pod-to-pod между нодами (inter-node трафик) и wrk с HTTP-бенчмарком между двумя сервисами.

Calico в режиме BGP + iptables - наша текущая конфигурация на production. Cilium 1.4 с eBPF-datapath в режиме direct routing.

Результат по пропускной способности pod-to-pod был заметным - Cilium показал порядка 30% выше на inter-node TCP. Latency на p99 тоже лучше, особенно при большом количестве одновременных подключений. Это укладывается в объяснение про iptables: чем больше сервисов и политик, тем сильнее проявляется разница.

Важная оговорка: на небольших кластерах (десяток сервисов, сотня политик) разница будет значительно меньше. У нас кластер уже достаточно большой, чтобы iptables-цепочки стали ощутимыми.

L7-политики: то, ради чего всё затевалось

Вот здесь Cilium делает то, чего нет ни у Calico, ни у стандартного NetworkPolicy. CiliumNetworkPolicy позволяет писать правила на уровне HTTP:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-gateway-policy
spec:
  endpointSelector:
    matchLabels:
      app: order-service
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: api-gateway
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/v1/orders"
        - method: POST
          path: "/api/v1/orders"

То есть billing-service не может вызвать POST /api/v1/orders - только api-gateway. Это не IP-фильтрация и не порт - это именно HTTP-метод и путь, разбираемые eBPF-программой в ядре. Для gRPC работает аналогично, только вместо path указывается имя метода.

До Cilium для этого нужен был либо Istio с sidecar (со всем его overhead-ом), либо авторизация на уровне самих сервисов. Теперь политика описывается на уровне инфраструктуры - и это существенно меняет подход к zero-trust внутри кластера.

Встроенный мониторинг трафика

Cilium 1.4 включает встроенный инструмент наблюдаемости за потоками. Он читает данные прямо из eBPF-карт без какого-либо дополнительного сниффинга или sidecar-ов.

cilium monitor --type l7 --related-to production

Вывод - живой поток HTTP-запросов между подами: откуда, куда, метод, путь, код ответа, задержка. Без каких-либо правок в приложениях. На тест мы запустили его на несколько минут и сразу увидели неочевидное: один из сервисов делал запросы к другому сервису в три-четыре раза чаще, чем ожидалось по архитектуре - оказалось, там был лишний retry-цикл без backoff-а.

С Calico ничего подобного нет в принципе. Это принципиально разный уровень видимости: не «что происходит с трафиком» по метрикам, а «какие именно запросы между кем идут прямо сейчас».

Прозрачное шифрование

В 1.4 добавили WireGuard... нет, не WireGuard - IPsec-шифрование pod-to-pod без sidecar. Включается одним параметром при установке через Helm:

helm install cilium cilium/cilium \
  --set encryption.enabled=true \
  --set encryption.type=ipsec

Ключи управляются через Kubernetes Secret, ротация - вручную или через внешний инструмент. На production мы это пока не включали - нужно сначала замерить overhead на latency, данных по этому режиму в 1.4 у нас ещё нет.

Что не гладко

Установка сложнее Calico. Calico ставится одним манифестом, Cilium требует аккуратной настройки под конкретный cloud-провайдер и режим маршрутизации. У нас ушло несколько часов на правильную конфигурацию для нашего bare-metal окружения.

Документация местами сырая. Примеры CiliumNetworkPolicy в официальных docs покрывают типичные случаи, но edge cases приходится разбирать через исходники и GitHub issues. Это нормально для проекта такого возраста, но нервирует в рабочем режиме.

Встроенный мониторинг в 1.4 ещё не production-ready. Он работает, данные показывает, но retention ограничен, UI минимальный, и настройка алертов на аномалии - это уже вручную через API. Как диагностический инструмент «посмотреть прямо сейчас» - отлично. Как постоянно работающий observability-слой - пока нет.

Где сейчас

На production кластер Cilium не переехал - держим Calico, пока не накопим уверенности. Но на staging он уже работает штатно несколько недель. L7-политики включены для части сервисов, cilium monitor используется при разборе аномалий.

Основное наблюдение: eBPF-based networking - это не просто быстрее. Это другой уровень контроля и видимости, который с iptables-моделью принципиально недостижим. Для кластеров с серьёзными требованиями к безопасности и наблюдаемости Cilium выглядит как направление, в котором стоит двигаться.