How to Visualize Kubernetes Resource Dependencies — Straight from kubectl

Most Kubernetes visualization tools share a hidden assumption: that you're allowed to install something in the cluster. In practice that's often the blocker — production access is locked down, the change-approval queue is long, or you're consulting on a cluster you'll touch for exactly one afternoon.

This guide shows how to get an interactive dependency map of any resource, namespace, or whole cluster using only your existing kubeconfig — the same credentials kubectl get already uses. Nothing is deployed, nothing is left behind.

The tool: kubectl atlas

kubectl-atlas is the kubectl plugin from the KubeAtlas project (Apache 2.0). It builds a directed dependency graph — workloads, config, networking, storage, RBAC, CRDs — by reading the Kubernetes API, then renders it locally. It runs in three modes, and choosing the right one is most of this guide:

Step 1 — Install the plugin

curl -L https://github.com/lithastra/kubeatlas/releases/latest/download/kubectl-atlas_$(uname -s)_$(uname -m).tar.gz \
  | tar -xz kubectl-atlas && sudo install kubectl-atlas /usr/local/bin/

Verify with kubectl atlas --help. (A kubectl krew install atlas path is in preparation.)

Step 2 — Start small: one resource

kubectl atlas deployment api -n petclinic

This renders the Deployment and its neighborhood: the ConfigMaps and Secrets it mounts, the ServiceAccount it runs as, the Services selecting its Pods, and whatever routes traffic to those Services. It's the fastest way to answer "what is this thing actually wired to?" during a code review or an incident.

Widen the lens as needed:

kubectl atlas namespace petclinic   # everything in one namespace
kubectl atlas cluster               # the whole cluster

Multi-cluster users: the standard --context and --kubeconfig flags work everywhere, so switching clusters is the same muscle memory as plain kubectl.

Step 3 — Go interactive when the SVG gets dense

Static SVGs are perfect for a single resource. For a busy namespace, you want pan, zoom, search, and filtering:

kubectl atlas namespace petclinic --local-ui

This spins up the full KubeAtlas web UI from an in-process server on your laptop — the cartography-style canvas with theme switching, a ⌘K command palette, blast-radius mode with depth and direction controls, and edge-type filters (RBAC / Network / Config / Storage). When you close it, it's gone. No graphviz needed, no in-cluster footprint.

Step 4 — Script it: machine-readable output

The same engine runs as a one-shot CLI emitting JSON, DOT, or SVG — useful for documentation pipelines and diff-based checks:

kubeatlas -once -level=cluster                          > cluster.json
kubeatlas -once -level=namespace -namespace=petclinic   > ns.json
kubeatlas -once -level=cluster -format=svg              > cluster.svg

Two patterns worth stealing:

• Architecture docs that never rot — regenerate the namespace SVG in CI on every merge and embed it in your README. The diagram is now derived from reality, not from memory.
• Topology-aware PR review — the kubeatlas-action GitHub Action attaches the rendered graph to each pull request as a CI artifact. Pin lithastra/kubeatlas-action@v1 for floating updates or @v1.0.0 for byte-identical behaviour.

When to graduate to the in-cluster server

The offline modes rebuild the graph on each run — a snapshot. The in-cluster server adds the dimensions a snapshot can't have:

• History — every resource change recorded (PostgreSQL tier), with "what changed in the last hour?" diffs.
• Federation — one instance attached to N kubeconfigs, every resource tagged with its cluster, one map across your whole fleet.
• Always-on access — a shared UI your whole team can reach, with full-text search across resources.

The mental model: kubectl atlas is the field telescope; the in-cluster server is the observatory. Start with the telescope — it costs you one binary on your PATH — and install the observatory when snapshots stop being enough. The quick-start guide covers the Helm install when you're ready.