Kubernetes Architecture Visualizer

How it works

Each ----separated document is parsed with js-yaml and kept as a node keyed by kind, namespace, and name. Edges are then found the same way kubectl resolves them: a Service's spec.selector is matched against every workload's pod-template labels in the same namespace; an Ingress's backend.service.name is matched against a Service by name; a workload's containers are scanned for envFrom, env[].valueFrom, and volumes[] entries that name a ConfigMap, Secret, or PersistentVolumeClaim, plus its serviceAccountName; and an HPA's scaleTargetRef is matched by kind and name. Nodes are then arranged into layers the same way this site's Terraform Dependency Visualizer arranges resources — anything referencing nothing else sits at the top, and everything else is placed below whatever it references.

FAQ

How does it know a Service points at a Deployment?

The same way kubectl does: it checks whether every key/value pair in the Service's spec.selector is also present in the pod template's metadata.labels (the Deployment/StatefulSet/DaemonSet's spec.template.metadata.labels) within the same namespace — if all of them match, that's the Service's backing workload.

What if a ConfigMap or Secret I reference isn't in what I pasted?

It's counted and shown as an unresolved reference rather than silently ignored or drawn as a broken node — paste the missing object's manifest alongside the rest to complete that edge.