Cilium Hubble: практическое руководство по eBPF-мониторингу сетевых потоков и безопасности в Kubernetes

Зачем нужен Hubble: eBPF-наблюдаемость для Kubernetes

Традиционный мониторинг сетевого трафика в Kubernetes строится на sidecar-прокси вроде Envoy или агентах на узлах, которые перехватывают пакеты в userspace. Этот подход создает три проблемы: дополнительная задержка на каждый запрос, рост потребления CPU и памяти пропорционально числу подов, слепые зоны при отказе прокси. В кластере из 50 микросервисов накладные расходы sidecar-контейнеров могут достигать 20-30% ресурсов узла.

Cilium Hubble решает эти проблемы через eBPF - технологию, которая выполняет программы мониторинга прямо в ядре Linux, без копирования пакетов в userspace. Hubble дает полную видимость сетевых потоков на уровнях L3/L4 и L7 (HTTP, gRPC, Kafka, DNS) без изменения кода приложений или инжекции дополнительных контейнеров. Каждый пакет обрабатывается один раз в точке перехвата eBPF-программой, которая за 50-100 наносекунд извлекает метаданные и отправляет их в Hubble. Это на порядок быстрее, чем пересылка пакета в userspace-агент.

Ключевые возможности Hubble, которые вы получите сразу после установки:

Визуализация карты зависимостей сервисов в реальном времени с детализацией до конкретного пода и протокола.
Мониторинг всех сетевых потоков с вердиктами (allowed/dropped) и полными метаданными L7.
Аудит сетевых политик Kubernetes и CiliumNetworkPolicy - вы видите, какое правило заблокировало или разрешило соединение.
Встроенный алертинг на основе метрик Prometheus для обнаружения аномалий трафика.

Сравнение с аналогами: Weave Scope требует отдельного агента и уступает в производительности на кластерах свыше 100 узлов. Istio Kiali привязан к service mesh и добавляет задержку через sidecar-прокси. Hubble работает на уровне ядра, не требует service mesh и обрабатывает потоки с минимальным overhead - около 2-5% CPU на узел при стандартной нагрузке. Для команд, которые уже используют Cilium как CNI-плагин, Hubble включается одним флагом в Helm-чарте. Если вы еще выбираете CNI, сравнение Cilium, Calico, Flannel и Weave Net поможет принять взвешенное решение.

Архитектура Hubble: как eBPF собирает данные о трафике

Hubble состоит из трех компонентов, которые работают как единый конвейер: сбор событий на узле, агрегация в кластере и представление данных пользователю. Понимание этой цепочки избавляет от отношения к Hubble как к «черному ящику» и позволяет осознанно настраивать фильтрацию и решать проблемы производительности.

Агент Hubble встроен в демон Cilium на каждом узле Kubernetes. Когда пакет проходит через сетевой интерфейс, eBPF-программа, закрепленная на хуке ядра TC (Traffic Control), извлекает из пакета метаданные: source/destination IP и порт, идентификаторы пода и namespace, протокол L7, verdict сетевой политики. Эти данные записываются в eBPF-карту - структуру в памяти ядра, доступную для чтения из userspace. Агент Hubble читает карту через gRPC-стрим и отправляет события на Hubble Relay.

Hubble Relay - центральный сервис агрегации, который собирает потоки со всех узлов кластера, дедуплицирует их и предоставляет единый gRPC-эндпоинт для CLI и UI. Relay не хранит исторические данные - он транслирует поток событий в реальном времени. Для долгосрочного хранения метрики экспортируются в Prometheus, а логи потоков можно направить во внешнюю систему через экспортер.

Hubble UI и CLI - интерфейсы для работы с данными. CLI выполняет точечные запросы через gRPC: hubble observe --from-pod api-gateway --to-namespace payment. UI строит интерактивную карту сервисов и таблицу потоков с фильтрами. Оба инструмента подключаются к Hubble Relay.

Поток данных выглядит так: системный вызов ядра → eBPF-программа на TC-хуке → eBPF-карта → агент Hubble в Cilium → gRPC-стрим → Hubble Relay → gRPC → CLI/UI. Фильтрация на уровне eBPF-программы отбрасывает ненужные пакеты до того, как они попадут в userspace. Это ключевой фактор низкого overhead: если вас интересуют только dropped-пакеты, eBPF-программа не будет обрабатывать успешные соединения.

Развертывание Cilium с Hubble в кластере Kubernetes

Предварительные требования: Kubernetes 1.16 или новее, Helm 3, права cluster-admin на установку CRD и DaemonSet. Если кластер уже использует другой CNI-плагин, потребуется миграция - процесс описан в руководстве по управлению сетевым трафиком в Kubernetes.

Установка Cilium через Helm с активацией Hubble

Добавьте репозиторий Cilium и установите чарт с параметрами для включения всех компонентов Hubble:

helm repo add cilium https://helm.cilium.io/
helm repo update

helm install cilium cilium/cilium \
  --namespace kube-system \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set hubble.metrics.enabled="{dns,drop,tcp,flow,port-distribution,icmp,http}" \
  --set ipam.mode=cluster-pool \
  --set cluster.name=prod-cluster-1 \
  --set cluster.id=1

Параметр ipam.mode=cluster-pool указывает Cilium управлять IP-адресами подов из внутреннего пула. Для кластеров с native routing (без оверлея) добавьте --set routingMode=native --set ipv4NativeRoutingCIDR=10.0.0.0/8. Режим encapsulation через VXLAN включается по умолчанию и подходит для большинства облачных сред.

После установки проверьте статус подов:

kubectl -n kube-system get pods -l k8s-app=cilium
kubectl -n kube-system get pods -l k8s-app=hubble-relay
kubectl -n kube-system get pods -l k8s-app=hubble-ui

Все поды должны быть в статусе Running. Если cilium-агенты не стартуют, проверьте логи: kubectl -n kube-system logs -l k8s-app=cilium. Частая проблема - конфликт с kube-proxy. Cilium может заменить kube-proxy полностью, для этого добавьте --set kubeProxyReplacement=true в Helm-команду. Перед этим убедитесь, что ваш сетевой плагин поддерживает прямую маршрутизацию.

Настройка Hubble CLI и доступ к Hubble UI

Установите бинарник Hubble CLI. Для Linux:

curl -L "https://github.com/cilium/hubble/releases/latest/download/hubble-linux-amd64.tar.gz" | tar xz
sudo mv hubble /usr/local/bin/

Для macOS:

brew install hubble

Настройте port-forward к Hubble Relay и проверьте статус:

cilium hubble port-forward &
hubble status
hubble list nodes

Вывод команды hubble status покажет версию, uptime Relay и количество подключенных узлов. Команда hubble list nodes выводит список узлов с именем и статусом соединения - все узлы должны быть в состоянии ONLINE.

Для доступа к Hubble UI выполните port-forward:

kubectl -n kube-system port-forward svc/hubble-ui 12000:80

Откройте http://localhost:12000 в браузере. Для production-доступа настройте Ingress с аутентификацией - Hubble UI не имеет встроенной защиты. Минимальный пример Ingress с basic-auth через секрет hubble-ui-auth:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hubble-ui
  namespace: kube-system
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: hubble-ui-auth
spec:
  rules:
  - host: hubble.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hubble-ui
            port:
              number: 80

Визуализация сетевых потоков с помощью Hubble UI

Hubble UI открывается на карту сервисов (Service Map) - граф, где узлы это поды или сервисы, а ребра - сетевые потоки между ними. Зеленые стрелки обозначают разрешенный трафик (verdict=forwarded), красные - заблокированный (verdict=dropped). Толщина линии пропорциональна объему трафика. При наведении на ребро отображается детализация: протокол, порты, verdict и метка сетевой политики, которая применила решение.

Практический сценарий: после применения NetworkPolicy поды в namespace payment потеряли связь с базой данных. Откройте Hubble UI, выберите namespace payment, включите фильтр «Show dropped flows». На графе появятся красные стрелки от payment-сервисов к базе данных. Кликните на стрелку - Hubble покажет, что пакеты дропаются политикой default-deny. Решение: добавить egress-правило в NetworkPolicy для разрешения трафика на порт 5432.

Таблица потоков (Flows) под картой дает текстовое представление тех же данных с возможностью фильтрации по всем полям: source/destination pod, namespace, IP, порт, verdict, протокол L7, HTTP-метод, код ответа. Фильтр verdict=DROPPED в сочетании с destination_port=443 мгновенно находит все заблокированные HTTPS-запросы. Временная шкала позволяет сузить окно анализа до интервала, когда наблюдалась проблема.

Анализ зависимостей и отладка сетевых политик через Service Map

Service Map решает задачу, которая без Hubble требует часов ручного сопоставления конфигураций: понимание реальных зависимостей между сервисами. В микросервисной архитектуре из 30+ компонентов документация часто расходится с реальностью. Hubble показывает фактические потоки трафика, а не предполагаемые.

Кейс аудита: вы внедряете Zero Trust и применяете политики deny-all с точечными разрешениями. После применения политик часть сервисов продолжает работать, часть - нет. В Hubble UI включаете отображение только dropped-потоков и видите красные стрелки от frontend к cart-service. Политика разрешает трафик от frontend к cart-service, но блокирует обратные соединения, которые cart-service инициирует к frontend для веб-сокетов. Без Hubble эта асимметрия могла бы остаться незамеченной до инцидента в production. Детальнее стратегия внедрения Zero Trust с Cilium разобрана в руководстве по микросегментации Kubernetes.

Мониторинг и оповещения на основе метрик Hubble

Hubble экспортирует метрики в формате Prometheus через порт 9965 на каждом агенте Cilium. При установке через Helm с флагом hubble.metrics.enabled метрики включаются для выбранных доменов: dns, drop, tcp, flow, icmp, http. Полный список доступных метрик зависит от включенных доменов.

Ключевые метрики для мониторинга безопасности:

hubble_drop_total - счетчик заблокированных пакетов с лейблами source, destination, reason (POLICY_DENIED, AUTH_REQUIRED). Резкий рост указывает на атаку или некорректную политику.
hubble_tcp_flags_total - распределение TCP-флагов. Аномальное количество SYN-пакетов с одного source_ip - признак сканирования портов.
hubble_flows_processed_total - общее количество обработанных потоков. Используется для расчета нагрузки на Hubble и выявления всплесков трафика.
hubble_http_requests_total - HTTP-запросы с разбивкой по методу, коду ответа и пути.

Интеграция с Prometheus и Grafana для визуализации метрик

Если в кластере установлен Prometheus Operator, настройте ServiceMonitor для автоматического сбора метрик с агентов Cilium:

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --set prometheus.enabled=true \
  --set operator.prometheus.enabled=true \
  --set hubble.metrics.enabled="{dns,drop,tcp,flow,icmp,http}" \
  --set hubble.metrics.serviceMonitor.enabled=true

После применения Prometheus начнет собирать метрики с эндпоинта cilium-agent:9965/hubble-metrics. Импортируйте дашборд Grafana из официального репозитория Cilium (ID 16611) - он содержит панели для dropped flows, HTTP-трафика, DNS-запросов и распределения трафика по namespace.

Пример PromQL-запроса для графика dropped flows по namespace за последние 5 минут:

rate(hubble_drop_total[5m]) by (source_namespace)

Настройте алерт для обнаружения сканирования портов. Создайте правило Prometheus:

groups:
- name: hubble-security
  rules:
  - alert: PortScanDetected
    expr: rate(hubble_tcp_flags_total{flag="SYN"}[1m]) > 100
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Обнаружено сканирование портов с {{ $labels.source_ip }}"
      description: "Источник {{ $labels.source_ip }} отправил {{ $value }} SYN-пакетов в минуту на узел {{ $labels.destination_ip }}"

Для отправки уведомлений в Slack настройте Alertmanager:

receivers:
- name: slack
  slack_configs:
  - channel: '#k8s-alerts'
    send_resolved: true
    text: "{{ .CommonAnnotations.description }}"

Алерт сработает, когда количество SYN-пакетов с одного IP превысит 100 в минуту в течение двух минут подряд. Порог подбирается эмпирически под профиль трафика вашего кластера.

Аудит сетевых политик и выявление подозрительной активности

Сетевые политики Kubernetes описывают желаемое поведение, но не дают обратной связи о реальном трафике. Hubble закрывает этот разрыв, показывая фактическое применение политик к каждому пакету. CiliumNetworkPolicy расширяет стандартные NetworkPolicy возможностью мониторинга - правило с действием Log не блокирует трафик, но создает событие в Hubble.

Методика регулярного аудита через Hubble CLI:

Поиск всех заблокированных соединений: hubble observe --verdict DROPPED --last 1h. Анализируйте, какие легитимные сервисы теряют связь.
Отслеживание активности конкретного пода: hubble observe --from-pod suspicious-pod-7d8f9b6c4-xk2lm --last 30m. Проверяйте, куда и на какие порты под обращается.
Выявление подозрительных исходящих соединений: hubble observe --type l3-l4 --not-to-namespace kube-system,monitoring --last 1h. Фильтр исключает системный трафик и показывает только межсервисные взаимодействия.

Пример выявления аномалии: под frontend неожиданно устанавливает исходящее соединение на внешний IP 198.51.100.7 порт 4444. Команда hubble observe --from-pod frontend-abc123 --to-ip 198.51.100.7 показывает, что трафик разрешен политикой, разрешающей egress в 0.0.0.0/0. Это либо утечка данных, либо компрометация пода. Hubble дает фактические доказательства для расследования инцидента - в сочетании с Falco для runtime-безопасности выстраивается полная картина. Связка Hubble и Falco детально разобрана в руководстве по безопасному мониторингу Kubernetes.

Чек-лист для еженедельного аудита:

Проверить топ-10 dropped flows по количеству пакетов.
Найти поды, генерирующие трафик на нестандартные порты (не 80, 443, 5432, 6379, 9092).
Сверить реальные зависимости из Service Map с документацией архитектуры.
Проверить логи Cilium на предмет ошибок применения политик: kubectl -n kube-system logs -l k8s-app=cilium | grep "policy".

Производительность eBPF-мониторинга: мифы и реальность

Распространенное опасение: eBPF-мониторинг создает высокую нагрузку на ядро и замедляет сетевой стек. Бенчмарки Cilium показывают обратное. На узле с 10 Гбит/с сетевым интерфейсом и 64-байтными пакетами (наихудший сценарий) Hubble добавляет 2-4% нагрузки на CPU при обработке 1 миллиона пакетов в секунду. На стандартных рабочих нагрузках веб-сервисов overhead составляет менее 1% CPU.

Причины низкого overhead:

eBPF-программа работает в контексте ядра без переключения в userspace. Обработка одного пакета занимает 50-100 наносекунд.
JIT-компиляция eBPF-байткода в нативный x86/ARM-код при загрузке программы исключает интерпретацию на лету.
Фильтрация на уровне eBPF-программы отбрасывает пакеты до записи в eBPF-карту. Если вас интересуют только dropped-пакеты, successful flows не создают событий.

Сравнение с sidecar-прокси: Envoy добавляет 2-5 мс задержки на каждый запрос и потребляет 50-100 МБ RAM на под. Hubble не добавляет задержки, так как не встраивается в data path - он наблюдает за трафиком через hook ядра, не модифицируя пакеты. Потребление памяти агентом Hubble фиксировано: около 128 МБ на узел независимо от количества подов.

Рекомендации по тюнингу для крупных кластеров (500+ узлов):

Ограничьте частоту сэмплирования через --set hubble.export.static.allowList[0].verdict=DROPPED - экспортировать только dropped flows, если успешные соединения не нужны для аудита.
Настройте фильтрацию на уровне агента: --set hubble.export.static.allowList[0].destinationPort=443 - мониторить только HTTPS-трафик.
Увеличьте буфер eBPF-карты: --set bpf.eventsBufferSize=65536 - предотвращает потерю событий при пиковых нагрузках.

Чек-лист: быстрый старт с Hubble в production

Шпаргалка для инженеров, которые хотят внедрить Hubble за минимальное время. Каждый шаг отсылает к соответствующему разделу статьи с детальными инструкциями.

Установите Cilium с Hubble через Helm - команда с флагами hubble.enabled=true, hubble.relay.enabled=true, hubble.ui.enabled=true из раздела «Установка Cilium через Helm».
Настройте доступ к Hubble CLI и UI - установите бинарник hubble, выполните cilium hubble port-forward и проверьте статус командой hubble status. Для UI настройте port-forward или Ingress с аутентификацией.
Включите экспорт метрик - добавьте hubble.metrics.enabled с нужными доменами (drop, tcp, flow, http) и настройте ServiceMonitor для Prometheus Operator.
Создайте базовые алерты - настройте правила Prometheus для обнаружения роста dropped flows и сканирования портов, подключите Alertmanager с уведомлением в Slack или другой канал.
Проведите первый аудит политик - выполните hubble observe --verdict DROPPED --last 1h, проанализируйте заблокированные соединения и сверьте реальные зависимости сервисов с документацией.

После внедрения Hubble вы получаете полную прозрачность сетевого взаимодействия в кластере. Для комплексного подхода к наблюдаемости дополните Hubble метриками производительности из руководства по диагностике Kubernetes через метрики мониторинга - это закроет вопросы производительности подов и узлов параллельно с сетевой безопасностью.