Generate an architecture diagram from Kubernetes manifests.
Kubernetes YAML contains the whole topology and presents it as several hundred lines in which none of it is visible.
What it reads
Every manifest in the tree: Deployments, StatefulSets, DaemonSets and Jobs for workloads, Services and Ingress for how traffic reaches them, ConfigMaps and Secret references for what they talk to, and PersistentVolumeClaims for what holds state. Kustomize overlays and Helm charts are followed so the diagram reflects a rendered environment rather than a template with placeholders in it.
How manifests become components
Each workload is a component, named from its labels rather than from the file it lives in. A Service becomes the edge between whatever selects it and whatever targets it, which is the relationship the YAML expresses through label selectors and which is precisely the part that is hard to see by reading. Ingress rules put a real edge at the front of the diagram. StatefulSets with volume claims land in the data tier, so stateful workloads are visually distinct from the ones you can restart freely.
Why the layout can be trusted
The agent reads the files listed above and emits a semantic graph: components, the tier each belongs to, and the edges between them, with no coordinates anywhere. The ELK layout engine then computes positions and orthogonal edge routing. This is why the output cannot come back with boxes overlapping or arrows crossing through cards, which is the usual failure when a language model is asked to place things on a canvas itself.
Selectors are the interesting part
The connection between a Service and its pods is expressed as a label match, and label matches are exactly what humans get wrong when reading manifests: a selector that matches nothing looks identical to one that matches correctly. Drawing them makes an orphaned Service visible immediately, which is a debugging use rather than a documentation one and is often the more valuable half.
Your manifests stay on your machine
It runs on your machine. With a local Ollama model nothing leaves the laptop at all, and with your own API key the file contents go to the provider you chose and never through us. For a source that is your actual codebase, that distinction is usually the deciding one.
Kubernetes to diagram
| Resource | In the diagram |
|---|---|
| Deployment, StatefulSet, DaemonSet | Application tier component |
| Job, CronJob | Worker component |
| Service | The edge between selector and target |
| Ingress, Gateway | Edge tier entry point |
| PersistentVolumeClaim | Data tier attachment |
| ConfigMap and Secret references | Edges to external dependencies |
| Namespace | Grouping, when the diagram spans several |
| HorizontalPodAutoscaler | A note on the component it scales |
The prompt
Questions
Related
- Generate a Diagram from a CodebasePoint it at a repository and it surveys the code the way a new engineer would, then draws what it found.
- Generate a Diagram from TerraformTerraform already describes your infrastructure precisely. The diagram is a rendering of something you have written down, not a guess.
- Generate a Diagram from Docker ComposeA Compose file is already a complete description of a small system. It is just written in a format that hides the shape.
- Generate a Diagram from a GitHub RepoClone it and point the app at the directory. Private repositories work exactly the same way, because nothing is uploaded to make it work.