Hubble — Network Observability for Kubernetes via eBPF

Introduction

Hubble is the observability layer of the Cilium project. It uses eBPF programs running in the Linux kernel to capture network flows, DNS queries, and HTTP requests without modifying application code or adding sidecar proxies. Hubble gives platform teams a real-time view of how services communicate, which policies are being enforced, and where traffic is being dropped.

What Hubble Does

• Captures Layer 3/4 and Layer 7 network flows across all pods in a cluster
• Visualizes service dependency maps showing how microservices communicate
• Monitors DNS resolution with query and response details
• Provides Prometheus metrics for network flow rates, latency, and error counts
• Displays Cilium network policy verdicts (allowed, denied, dropped) per flow

Architecture Overview

Hubble runs as a set of agents on each Cilium-managed node. Each agent reads eBPF event data from the kernel and streams it to the Hubble Relay, a cluster-wide aggregator. The Relay exposes a gRPC API that the Hubble CLI and UI consume. The UI renders a graphical service map and flow table. Because Hubble operates at the eBPF level, it captures traffic data without any application instrumentation or proxy overhead.

Self-Hosting & Configuration

• Prerequisite: a Kubernetes cluster running Cilium as the CNI plugin
• Enable Hubble with cilium hubble enable via the Cilium CLI
• Deploy the Hubble UI with cilium hubble enable --ui for the graphical dashboard
• Install the Hubble CLI to observe flows from the command line
• Export metrics to Prometheus by enabling the Hubble metrics server in Cilium config

Key Features

• Zero-instrumentation observability — eBPF captures data at the kernel level
• Service dependency map shows real-time communication patterns between services
• Network policy verdict logging helps debug connectivity issues and policy misconfigurations
• HTTP, gRPC, Kafka, and DNS protocol-level visibility without sidecars
• Prometheus metrics integration for alerting on traffic anomalies

Comparison with Similar Tools

• Istio/Kiali — requires sidecar proxies for visibility; Hubble uses eBPF with no sidecars
• Pixie — eBPF-based observability focused on application performance; Hubble focuses on network flows and policy
• Jaeger/Zipkin — distributed tracing requires instrumentation; Hubble captures network data transparently
• Weave Scope — agent-based topology mapping; Hubble leverages Cilium's eBPF datapath for lower overhead
• Calico Enterprise — offers flow logs; Hubble provides richer L7 visibility and a dedicated service map UI

FAQ

Q: Does Hubble require Cilium? A: Yes. Hubble is built into Cilium and relies on its eBPF datapath for data collection.

Q: Does Hubble add latency to network traffic? A: No. Hubble reads eBPF events passively. It observes traffic without sitting in the data path.

Q: Can Hubble monitor HTTP requests? A: Yes. When Cilium's L7 policy or visibility annotations are enabled, Hubble captures HTTP method, URL, status code, and latency.

Q: Is the Hubble UI included by default? A: No. Deploy it separately with cilium hubble enable --ui or via the Helm chart.

Sources

• https://github.com/cilium/hubble
• https://docs.cilium.io/en/stable/observability/hubble/