The Hubble UI
The Hubble UI draws the live service map: which workloads talk to which, and where traffic is dropped, updating as connections happen. It is the quickest way to see a namespace's real dependencies. It also has no login, so how you reach it matters more than usual.
Warning
The Hubble UI shows the full cluster flow data to anyone who can reach it, with no login screen. Never expose it on a type: LoadBalancer Service on a cluster shared by more than one team or reachable from the internet. That publishes your entire service map, unauthenticated, to anyone who reaches the IP.
How to reach it
Port-forward, so nothing is exposed to the network:
$ kubectl port-forward -n kube-system svc/hubble-ui 12000:80
Then open http://localhost:12000. This is the right choice for a quick investigation by one person.
Put the UI behind an ingress that requires authentication, using the same identity provider your organization already uses. The UI has no login of its own, so that check has to happen at the ingress, through an auth proxy or your ingress controller's authentication support. It also has no per-namespace access control, so everyone who gets in can switch to any namespace. Give access only to people who should see cluster-wide traffic.
Combine it with the other signals
Hubble shows network activity only. When you are investigating an incident, read it next to audit logs , which show who changed the policy, and node integrity , which shows whether a file changed on a node.
Alert on dropped packets
A rise in dropped packets means a workload is being blocked or probed, so alert on hubble_drop_total and keep a queryable flow log.
Monitor cluster and machine health
Syself runs the management cluster and heals your clusters, but the Cluster API objects it reconciles are yours to watch, so alert on their status.