DEV.co
Open-Source Observability · cilium

hubble

Hubble is a Kubernetes observability platform built on eBPF that provides real-time visibility into network flows, service dependencies, and security events without application instrumentation. It integrates with Cilium to enable layer 3–7 traffic inspection, HTTP/DNS/Kafka protocol analysis, and network policy enforcement monitoring.

Source: GitHub — github.com/cilium/hubble
4.2k
GitHub stars
287
Forks
Makefile
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositorycilium/hubble
Ownercilium
Primary languageMakefile
LicenseApache-2.0 — OSI-approved
Stars4.2k
Forks287
Open issues44
Latest releasev1.19.4 (2026-06-05)
Last updated2026-07-02
Sourcehttps://github.com/cilium/hubble

What hubble is

Hubble leverages Linux eBPF hooks in the Cilium data plane to capture flow telemetry at kernel level, exposing service maps, protocol-level metrics (HTTP latency, DNS responses, TCP flags), and policy deny events via CLI, metrics exporters, and a web UI. Core components (CLI, Server, Metrics, Relay) are stable; UI is beta.

Quickstart

Get the hubble source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/cilium/hubble.gitcd hubble# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Microservice Dependency Discovery & Mapping

Automatically generate service dependency graphs and visualize L3/L4 and L7 dataflows without code changes, enabling architects to understand and troubleshoot cluster topology.

Network Policy Observability & Compliance

Monitor blocked connections, track policy enforcement, and audit which services access external resources or are reachable from outside—critical for security and compliance audits.

Application & DNS Troubleshooting

Diagnose connectivity failures, DNS resolution errors, HTTP error rates, latency percentiles, and TCP timeout patterns without application-level instrumentation.

Implementation considerations

  • Hubble runs as a DaemonSet in Cilium-managed clusters; you must already have Cilium installed and configured as CNI. Installation adds kernel overhead (~1–5% reported in docs) and memory per node.
  • Flow data retention and export strategy must be planned: local storage, external metrics pipeline (Prometheus, Loki), or streaming to SIEM. Raw flow volume can be high in large clusters.
  • UI (beta) is functional but not production-hardened; CLI and metrics exporters are stable and preferred for critical workflows. Plan for potential UI breaking changes in minor releases.
  • Role-based access control and multi-tenancy are limited; Hubble observes cluster-wide flows. Network policies and Cilium RBAC are the primary isolation mechanisms.
  • Hubble Relay is required for multi-cluster observability; single-node deployments can use direct agent connections.

When to avoid it — and what to weigh

  • Non-Kubernetes Environments — Hubble is tightly coupled to Kubernetes and Cilium; unsuitable for VMs, bare metal, or heterogeneous infrastructure without Cilium.
  • Kernel eBPF Limitations — Requires Linux kernel ≥4.18 with eBPF support; not compatible with Windows or older kernels, and may have reduced visibility on certain network modes or drivers.
  • Application-Layer APM Needs — Hubble provides network and protocol telemetry but lacks distributed tracing, custom instrumentation hooks, or deep application-level profiling; requires Jaeger, Datadog, or similar for that scope.
  • Non-Standard Network Stacks — High-performance or custom networking (e.g., DPDK, VPP, OpenStack SDN) may not integrate or expose events to eBPF; test before commitment.

License & commercial use

Apache License 2.0 (Apache-2.0) — permissive OSI-approved license allowing commercial use, modification, and distribution with attribution and liability disclaimers.

Apache 2.0 explicitly permits commercial use, including in proprietary products, provided you comply with attribution and liability clauses. No commercial support, warranty, or SLA is provided by the upstream project; Isovalent (Cilium commercial entity) offers commercial support and hardened distributions.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationStrong
License clarityClear
Deployment complexityModerate
DEV.co fitStrong
Assessment confidenceHigh
Security considerations

Hubble operates at kernel level via eBPF; inherits Linux eBPF security model (verified programs, kernel lockdown compatibility). No known CVEs in recent releases. Cluster-wide flow visibility means operator access to all traffic; secure RBAC on Hubble API and CLI access. Encrypted flow data transit (TLS for Relay) not explicitly documented—verify with your instance. No built-in secrets redaction; filter sensitive payloads upstream if needed.

Alternatives to consider

Cilium Network Policies + Prometheus

If you only need policy enforcement without observability, Cilium policies alone suffice. For basic metrics, use kube-proxy or node exporter; less rich but lower overhead.

Istio / Linkerd Service Mesh

Provides distributed tracing, mTLS, and L7 observability via sidecar injection. Heavier footprint and requires application restart. Works alongside Hubble but solves different problems (app behavior vs. network flows).

Falco + Vector / Sumo Logic

Falco provides behavioral security and kernel event tracing; Vector/Sumo aggregate logs. Orthogonal to Hubble; used for incident response and forensics rather than operational observability.

Software development agency

Build on hubble with DEV.co software developers

Hubble integrates seamlessly with Cilium. Start with the CLI and flow observe examples, then scale to multi-cluster with Relay and metrics export. Consult the docs and community channels for deployment guidance.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

hubble FAQ

Do I need to modify or instrument my applications to use Hubble?
No. Hubble operates at the kernel level via eBPF; it requires zero application changes and works transparently with any containerized workload.
Can Hubble work without Cilium?
No. Hubble is built on top of Cilium and relies on its eBPF data plane. You must deploy Cilium as your CNI first.
What is the performance overhead of Hubble?
Reported at 1–5% CPU and memory overhead on nodes depending on traffic volume, sampling, and enabled features. eBPF minimizes overhead vs. sidecar-based approaches.
Is Hubble UI production-ready?
UI is marked beta; CLI and core metrics/relay components are stable and production-proven. For critical environments, rely on CLI and metrics export; treat UI as complementary.

Work with a software development agency

Adopting hubble is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source observability software in production.

Ready to gain deep Kubernetes visibility?

Hubble integrates seamlessly with Cilium. Start with the CLI and flow observe examples, then scale to multi-cluster with Relay and metrics export. Consult the docs and community channels for deployment guidance.