Skip to content

Using Hubble from the CLI or Hubble UI: CCA practice questions

Two tools read Hubble data: the hubble command-line client and the Hubble UI web interface. Both normally work through Hubble Relay, which has to be enabled first, for example with cilium hubble enable or the Helm value hubble.relay.enabled=true. Adding --ui to cilium hubble enable, or setting hubble.ui.enabled=true, deploys the UI as well.

By Ibrahim Yesilay · Published · Updated

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

What Using Hubble from the CLI or Hubble UI covers in CCA

Two tools read Hubble data: the hubble command-line client and the Hubble UI web interface. Both normally work through Hubble Relay, which has to be enabled first, for example with cilium hubble enable or the Helm value hubble.relay.enabled=true. Adding --ui to cilium hubble enable, or setting hubble.ui.enabled=true, deploys the UI as well.

The CLI expects Relay at localhost:4245. Three ways to get there are documented: cilium hubble port-forward, kubectl -n kube-system port-forward service/hubble-relay 4245:80, or the -P flag on the hubble command itself, which sets up the port-forward automatically. If you forward to another local port, point the client at it with --server or the HUBBLE_SERVER environment variable. hubble status then checks health and shows how many flows are buffered against the maximum, the flow rate and how many nodes are connected.

hubble observe is where most of the work happens. Without arguments it prints recent flows; -f follows new ones; -o picks compact, dict, json, jsonpb or table output. Filters cover nearly every flow field: --pod, --namespace (-n), --label, --to-fqdn, --protocol (for example tcp, udp, dns or http), --port, --verdict (FORWARDED, DROPPED, AUDIT, REDIRECTED, ERROR, TRACED, TRANSLATED), --type for event types (capture, drop, l7, policy-verdict, trace, trace-sock), and HTTP filters such as --http-method, --http-path and --http-status, which takes a prefix like 404 or 5+. Encrypted and reply traffic have their own switches, --encrypted, --unencrypted, --reply and --not-reply.

Filter logic is worth knowing exactly. Several values of one flag are alternatives, so --http-method put --http-method get matches either method. Different flags must all match, so adding --to-namespace foo narrows the result to flows that end in foo. Prefixing a filter with --not reverses it. Flows saved with -o jsonpb can be replayed later with --input-file, in which case follow, last and server flags are ignored.

Hubble UI is opened with cilium hubble ui, which forwards the hubble-ui service to local port 12000 and keeps running while the forward is active. After you choose a namespace, the UI draws the services as a dependency map built from observed flows, at L3/L4 and, where L7 visibility exists, at L7, and lists recent flow events below the map. Running cilium connectivity test in a loop and opening the cilium-test namespace is the documented way to see a busy map.

Key points

  • hubble defaults to localhost:4245; use --server or HUBBLE_SERVER for any other address.
  • hubble observe -P forwards the Relay service automatically for one command.
  • Repeated values of one filter are ORed, different filters are ANDed, and --not reverses a filter.
  • cilium hubble ui forwards hubble-ui to local port 12000.

Three sample questions

11 CCA questions on Using Hubble from the CLI or Hubble UI, 11 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 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: A

hubble observe --http-status 404 shows only flows whose HTTP status code matches the prefix 404 (the flag also accepts prefixes such as 5+). Why the other options are wrong. "--type http": --type filters event types (capture, drop, l7, policy-verdict, trace, trace-sock), and http is not one of them. "--status-code": no such flag; the flag is --http-status. "--filter": hubble observe has no free-form expression filter.

Sources: Hubble CLI source: observe flags (cilium v1.20.4), Cilium docs: Inspecting Network Flows with the CLI

Question 3

Which Hubble CLI command would filter flows to show only traffic that was dropped due to network policies?
  1. A.hubble observe --verdict DENIED
  2. B.hubble observe --verdict DROPPED --type policy
  3. C.hubble observe --policy-dropped
  4. D.hubble observe --verdict DROPPED

Correct answer: D

The command "hubble observe --verdict DROPPED" shows traffic that was dropped for any reason, including due to network policies. While this will show all dropped traffic (not just policy drops), it's the closest match among the options.

Practice this topic

Focus mode keeps every question on Using Hubble from the CLI or Hubble UI 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.

Frequently asked questions

Why does hubble observe --type http fail?

--type selects event types, and the valid ones are capture, drop, l7, policy-verdict, trace and trace-sock. Use -t l7 for parsed requests or --protocol http to filter HTTP flows.