Kubernetes YAML to a cluster diagram in one paste

A Kubernetes deployment is a stack of YAML that describes a shape it never shows you. An Ingress points at a Service by name, the Service selects Pods by label, the Pods come from a Deployment, and a ConfigMap and a Secret are mounted in somewhere along the way. Every link is a string match buried in a different file. To understand how traffic actually reaches your container, you hold six documents in your head and hope you matched the labels correctly.

The information is all there; it is just never drawn. So draw it. Paste your manifests into LetDraw and it reads the same fields Kubernetes does (selectors, names, references) and lays out a diagram of how the objects connect. What was a folder of YAML becomes a picture you can point at in a review.

The manifests already describe the graph

Kubernetes is, underneath, a graph of objects wired together by labels and names. An Ingress backend names a Service; a Service's selector matches a Pod template's labels; a Deployment owns those Pods; volumes reference a ConfigMap or Secret by name. Those references are exactly the edges of a diagram. You do not have to invent the structure or guess the connections; they are written into the YAML as literal string matches, which is precisely what makes them safe to render automatically.

One paste, whole cluster

You do not export anything special. The manifests you already kubectl apply are the input. Concatenate them (or point at the same multi-document file) and paste into Generate from Code; LetDraw parses the objects and draws the connections it finds.

apiVersion: apps/v1
kind: Deployment
metadata: { name: api }
spec:
  replicas: 3
  selector: { matchLabels: { app: api } }
---
apiVersion: v1
kind: Service
metadata: { name: api }
spec:
  selector: { app: api }   # ← matches the Deployment's pods
  ports: [{ port: 80, targetPort: 8080 }]
---
apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
  rules: [{ http: { paths: [{ backend:
    { service: { name: api } } }] } }]  # ← names the Service

That selector: app: api and that service.name: api are the edges. LetDraw follows them the same way the cluster does, so the diagram reflects how traffic really flows, not how you remember it flowing. Namespaces become the containers everything sits inside, and the icons make each kind of object recognisable at a glance.

The YAML says how the cluster is wired. The diagram is just that wiring, made visible.

Now it is a normal diagram

Once the draft is on the canvas it is yours to shape. This is where the picture becomes something worth keeping:

• Prune the noise. Hide the objects that are not part of the story (the fifteenth ConfigMap nobody needs to see in an onboarding diagram) and keep the request path front and centre.
• Annotate the tricky bits. Mark where the readiness probe lives, which Service is internal-only, where the Secret actually comes from.
• Show more than one namespace. Paste several and let the boundaries make the multi-tenant layout obvious.
• Keep it as code. Export to Mermaid or D2 and drop it in the repo next to the manifests, so the diagram ships with the cluster it describes.

See the cluster you actually deployed

The gap between the YAML you wrote and the cluster you are running is where incidents hide: a selector that matches nothing, a Service pointing at the wrong port, an Ingress route you forgot. Drawing the manifests turns those mismatches into something you can see instead of something you discover at 2am. Paste what you already apply, get a picture of how it connects, and keep it next to the code that produced it.

Copy your manifests, paste them once, and watch the cluster assemble itself into a diagram.