Skip to main content
In this lesson we cover the fundamentals of Hubble — the Cilium observability tool for Kubernetes networking. Hubble uses eBPF to capture and analyze network flows in real time, giving operators and developers rich visibility into service-to-service traffic, HTTP requests, Kafka usage, DNS behavior, and policy-enforced denials.
A slide titled "Observability" showing a Kubernetes cluster with two nodes, each hosting a pod and multiple bidirectional network flows between them. A satellite-like probe (Hubble) inspects the traffic while a developer monitors it, with the caption stating Hubble enables real-time traffic flow inspection across the cluster.
Hubble operates at node and cluster scope, and can aggregate observability across clusters. It answers critical operational questions such as:
  • Which services communicate with each other?
  • How frequently do they communicate?
  • What does the service dependency graph look like?
  • Which HTTP endpoints are being called and with what response rates?
  • Which Kafka topics are services producing to or consuming from?
A Hubble slide titled "Service Communication" showing a network icon of a central service connected to others. To the right is a numbered list of five questions about inter-service communication: which services communicate, how frequently, the dependency graph, what HTTP calls are made, and which Kafka topics are used.
From a troubleshooting standpoint, Hubble helps you quickly narrow root causes:
  • Is the failure DNS-related or a service misconfiguration?
  • Is the issue at the application layer (L7/HTTP) or the network/transport layer (L4/TCP)?
  • Are packets being dropped or connections reset?
  • Which policies are blocking traffic?
A presentation slide from Hubble titled "Failures and Troubleshooting" with a wrench-and-screwdriver icon on a blue panel. The right side lists five troubleshooting questions about network communication, DNS, application vs network issues, and layer 4 (TCP) vs layer 7 (HTTP).
Hubble can surface recent error events and metrics such as:
  • DNS resolution failures in the last N minutes.
  • Interrupted TCP connections or connection timeouts.
  • Rate of unanswered TCP SYN requests.
  • 4xx/5xx HTTP response rates across services and clusters.
A slide titled "Error Events" (Hubble logo top-left) with a blue panel showing a code symbol and warning icon. To the right are four numbered questions about recent DNS resolution issues, interrupted TCP connections/unanswered SYN requests, and rates of 4xx/5xx HTTP responses.
Hubble also exposes SLA-related metrics (p95/p99 latency between requests and responses), identifies poorly performing services, and reveals which connections were blocked by network policies or which DNS names were resolved by specific services. Architecture and components Below is a concise overview of the core Hubble components and their roles.
ComponentRoleTypical Deployment
Hubble serverCollects flows and visibility data using eBPF on each nodeRuns inside the Cilium agent (no per-node pod)
Hubble relayAggregates flows from all Hubble servers and provides a single access pointDeployment (pod) in cluster
Hubble CLILocal client for querying flows and streaming eventsInstalled on developer/operator workstation
Hubble UIWeb-based visualization for interactive filtering and dependency graphsDeployment (pod) in cluster
A diagram titled "Hubble Components" showing a Kubernetes cluster with three nodes, each running a Cilium Agent and eBPF Kernel; the middle node also hosts Hubble UI and Hubble relay. At the top an external Graphical UI / developer interacts with the cluster.
Hubble UI draws dependency graphs (who talks to whom), highlights denied attempts due to policies, and shows statuses you can also obtain via the CLI. Enabling Hubble Enable Hubble via your Cilium Helm values (values.yaml). Typical settings: 
hubble:
  # Enable Hubble (true by default).
  enabled: true

  # Enable Hubble Relay (aggregates flows from Hubble servers)
  relay:
    enabled: true

  # Whether to enable the Hubble UI.
  ui:
    enabled: true
After changing values.yaml, upgrade the Cilium Helm chart and restart operator/agent to apply the new configuration: 
helm upgrade cilium cilium/cilium -n kube-system -f values.yaml
kubectl -n kube-system rollout restart deployment/cilium-operator
kubectl -n kube-system rollout restart ds/cilium
Verify Hubble and related components using cilium status: 
> cilium status
  /--\
 /--\ /--\
 \__/ \__/
 /--\ /--\
 \__/ \__/
  \__/
       Cilium:             OK
       Operator:           OK
       Envoy DaemonSet:    OK
       Hubble Relay:       OK
       ClusterMesh:        disabled

DaemonSet           cilium                 Desired: 3, Ready: 3/3, Available: 3/3
DaemonSet           cilium-envoy           Desired: 3, Ready: 3/3, Available: 3/3
Deployment          cilium-operator        Desired: 2, Ready: 2/2, Available: 2/2
Deployment          hubble-relay           Desired: 1, Ready: 1/1, Available: 1/1
Deployment          hubble-ui              Desired: 1, Ready: 1/1, Available: 1/1
Containers:         cilium                 Running: 3
                    cilium-envoy           Running: 3
                    cilium-operator        Running: 2
                    clustermesh-apiserver
                    hubble-relay           Running: 1
                    hubble-ui              Running: 1
You can also inspect Hubble-related pods and services with kubectl: 
kubectl get pod -n kube-system | grep -i hubble
# Example output:
# hubble-relay-59cc4d545b-dv2vc        1/1   Running   0   21h
kubectl get svc -n kube-system
# Example output:
# NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
# hubble-peer    ClusterIP   10.96.168.58    <none>        443/TCP   21h
# hubble-relay   ClusterIP   10.96.219.164   <none>        80/TCP    21h
# hubble-ui      ClusterIP   10.96.132.144   <none>        80/TCP    21h
Hubble server runs inside the Cilium agent on each node (no separate pod per node). Hubble relay and Hubble UI run as separate deployments/pods and aggregate/visualize node-level flow data.
Installing the Hubble CLI Install the Hubble CLI on your workstation to query the relay or stream flows directly. The Hubble project provides prebuilt release binaries. Example (Linux): 
HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
HUBBLE_ARCH=amd64
if [ "$(uname -m)" = "aarch64" ]; then HUBBLE_ARCH=arm64; fi

# Download the tarball and its checksum
curl -L --fail --remote-name-all \
  "https://github.com/cilium/hubble/releases/download/${HUBBLE_VERSION}/hubble-linux-${HUBBLE_ARCH}.tar.gz" \
  "https://github.com/cilium/hubble/releases/download/${HUBBLE_VERSION}/hubble-linux-${HUBBLE_ARCH}.tar.gz.sha256sum"

sha256sum --check "hubble-linux-${HUBBLE_ARCH}.tar.gz.sha256sum"

sudo tar xzvf "hubble-linux-${HUBBLE_ARCH}.tar.gz" -C /usr/local/bin
rm "hubble-linux-${HUBBLE_ARCH}.tar.gz" "hubble-linux-${HUBBLE_ARCH}.tar.gz.sha256sum"
Accessing Hubble relay/UI from your workstation A common approach is to port-forward the hubble-relay service (or use the cilium helper). Example: 
kubectl -n kube-system port-forward service/hubble-relay 4245:80
# Forwarding from 127.0.0.1:4245 -> 4245
Or use the Cilium CLI helper: 
cilium hubble port-forward
Avoid exposing Hubble relay/UI to the public internet. Use port-forwarding, a secure tunnel, or an authenticated proxy when accessing Hubble from your workstation.
Using the Hubble CLI The CLI supports expressive filters for drilling into specific flows. Use --help to view all options. Common examples: Show flows to or from a pod named “green” (both directions): 
hubble observe --pod green
Show flows originating from the “green” pod: 
hubble observe --from-pod green
Show flows destined to the “green” pod: 
hubble observe --to-pod green
Filter by destination port and protocol (e.g., HTTP on port 3000): 
hubble observe --to-pod green --port 3000 --protocol http
Filter by verdict (result of packet handling). Valid verdicts include:
  • FORWARDED
  • DROPPED
  • AUDIT
  • REDIRECTED
  • ERROR
  • TRACED
  • TRANSLATED
Example: 
hubble observe --to-pod green --port 3000 --protocol http --verdict DROPPED
Using the Hubble UI The Hubble UI provides a graphical way to explore flows, dependency graphs, and policy denials. The cilium CLI can forward and open the UI for you: 
cilium hubble ui
# Opening "http://localhost:12000" in your browser...
The UI supports the same filtering options as the CLI (source/destination pod/service, status, protocol, ports, verdicts, time ranges) and is especially useful for interactive debugging and visualizing service dependencies. Summary Hubble (embedded in Cilium) together with Hubble relay and Hubble UI delivers low-overhead, high-fidelity network observability for Kubernetes clusters. Use the CLI for automation and quick inspections; use the UI for visual exploration, dependency graphs, and troubleshooting policy-related denials. Links and references

Watch Video