Skip to content

Network Observability: CCA practice questions

Hubble is the observability layer of Cilium, and it works because it reads from the same eBPF datapath that forwards the traffic. The Hubble server is embedded in the Cilium agent on every node and exposes flow data over gRPC. By default that API covers only its own node, which the hubble CLI can query through a local Unix socket.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Network Observability covers in CCA

Hubble is the observability layer of Cilium, and it works because it reads from the same eBPF datapath that forwards the traffic. The Hubble server is embedded in the Cilium agent on every node and exposes flow data over gRPC. By default that API covers only its own node, which the hubble CLI can query through a local Unix socket. Hubble Relay connects to every node's Hubble server and offers one cluster-wide view, and Hubble UI uses Relay to draw a service dependency and connectivity map. Relay depends on TCP port 4244 being reachable on all nodes running Cilium.

Setup is short. A Helm installation enables Hubble by default; cilium hubble enable, or the Helm value hubble.relay.enabled=true on an upgrade, adds Relay. cilium status should then report Hubble Relay as OK. To reach Relay from a workstation, pass -P to hubble commands, run cilium hubble port-forward, or forward the hubble-relay Service with kubectl to local port 4245. hubble status shows the health of the system, current and maximum flows, flows per second and the number of connected nodes.

hubble observe prints flows. Each line shows a timestamp, the source and destination as namespace, pod and port, the event type and a verdict such as FORWARDED or DROPPED, and a dropped flow carries its reason, for example Policy denied. Filters narrow the stream: --pod and --protocol select a workload and protocol, --verdict DROPPED keeps only drops, and --encrypted or --reply select encrypted or reply traffic. For the full list, the docs point to hubble help observe.

Layer 7 detail needs more than the datapath. HTTP and DNS fields appear only when the traffic is redirected through the proxy, which happens when a CiliumNetworkPolicy contains layer 7 rules. Such a policy also restricts traffic, so the visibility example uses wildcard DNS and HTTP rules to permit everything on the selected ports while still sending it through the proxy. hubble observe -t l7 then shows http-request and http-response events with method, URL, status code and latency. By default Hubble does not redact sensitive data in layer 7 flows; --hubble-redact-enabled with header allow or deny lists, and options for URL query parameters and user info, reduce what is kept.

Metrics are a separate switch from flows. With hubble.enabled=true, the list in hubble.metrics.enabled chooses which metric groups exist, for example dns, drop, tcp, flow, port-distribution, icmp and httpV2. They are served on port 9965 by default under the hubble_ prefix, for example hubble_flows_processed_total, hubble_drop_total labelled by reason and protocol, and hubble_http_requests_total. Each of these is disabled until enabled. The agent's own metrics use the cilium_ prefix on port 9962 once prometheus.enabled=true, while the operator exposes metrics on port 9963 by default. Dynamic metrics configuration allows changing metrics without restarting the agent.

Key points

  • Without Relay, Hubble only sees the node it runs on; Relay gives the cluster-wide view.
  • HTTP and DNS details appear only for traffic redirected to the proxy by L7 policy rules.
  • Hubble metrics are opt-in per group through hubble.metrics.enabled and are served on port 9965.
  • Hubble does not redact sensitive L7 data unless redaction is enabled.

Three sample questions

13 CCA questions on Network Observability, 13 with explanations. How practice works

Question 1

What command would you use to view real-time network flows between pods with Hubble?
  1. A.kubectl exec -n kube-system cilium-xxxx -- cilium monitor
  2. B.cilium hubble ui
  3. C.hubble observe --follow
  4. D.kubectl logs -n kube-system hubble-xxx

Correct answer: C

The command "hubble observe --follow" shows a real-time stream of network flows between pods using Hubble.

Question 2

Which Hubble component is responsible for aggregating flow data from all nodes in a cluster?
  1. A.Hubble UI
  2. B.Hubble Relay
  3. C.Hubble Server
  4. D.Hubble Collector

Correct answer: B

Hubble Relay is the component responsible for aggregating flow data from all nodes in a cluster. It collects data from individual Hubble servers running on each node and provides a unified API for querying cluster-wide flow data.

Question 3

Which of the following CLI commands would show HTTP flows with status code 404?
  1. A.hubble observe --http-status 404
  2. B.hubble observe --type http --http-status 404
  3. C.hubble observe --protocol http --status-code 404
  4. D.hubble observe --filter "http.status == 404"

Correct answer: B

The correct command to show HTTP flows with status code 404 is "hubble observe --type http --http-status 404". This filters for HTTP traffic and specifically for responses with the 404 status code.

Practice this topic

Focus mode keeps every question on Network Observability until you leave it. 10 free guest answers, then a free account; no credit card.

Or open CCA practice across all topics.

Sources

The explanation above was checked against these official documents.