> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Hubble Basics > Overview of Hubble observability for Kubernetes networking, covering architecture, deployment, CLI and UI usage, troubleshooting, metrics, and enabling Hubble with Cilium 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. | Component | Role | Typical Deployment | | ------------: | --------------------------------------------------------------------------- | ---------------------------------------------- | | Hubble server | Collects flows and visibility data using eBPF on each node | Runs inside the Cilium agent (no per-node pod) | | Hubble relay | Aggregates flows from all Hubble servers and provides a single access point | Deployment (pod) in cluster | | Hubble CLI | Local client for querying flows and streaming events | Installed on developer/operator workstation | | Hubble UI | Web-based visualization for interactive filtering and dependency graphs | Deployment (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: ```yaml theme={null} 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: ```bash theme={null} 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`: ```bash theme={null} > 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: ```bash theme={null} 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 443/TCP 21h # hubble-relay ClusterIP 10.96.219.164 80/TCP 21h # hubble-ui ClusterIP 10.96.132.144 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): ```bash theme={null} 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: ```bash theme={null} 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: ```bash theme={null} 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): ```bash theme={null} hubble observe --pod green ``` Show flows originating from the "green" pod: ```bash theme={null} hubble observe --from-pod green ``` Show flows destined to the "green" pod: ```bash theme={null} hubble observe --to-pod green ``` Filter by destination port and protocol (e.g., HTTP on port 3000): ```bash theme={null} 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: ```bash theme={null} 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: ```bash theme={null} 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 * Hubble repository and releases: [https://github.com/cilium/hubble](https://github.com/cilium/hubble) * Cilium documentation: [https://docs.cilium.io/](https://docs.cilium.io/) * Kubernetes Concepts: [https://kubernetes.io/docs/concepts/](https://kubernetes.io/docs/concepts/)