InfraSketch now supports Kubernetes YAML. Paste one or more manifest files into the Kubernetes tab and get a full architecture diagram in seconds — namespace grouping, Ingress-to-Service connections, selector-based Service-to-Deployment wiring, ConfigMap and Secret references, and HPA targets. No login, no cluster access, everything runs in your browser.
Try it now Paste your Kubernetes YAML manifests and see the diagram instantly. Open InfraSketch →
Why Kubernetes needs a diagram tool
A production Kubernetes application typically spans dozens of YAML files — Deployments, Services, Ingresses, ConfigMaps, Secrets, PVCs, HPAs, NetworkPolicies. When something breaks, or when you're onboarding a new engineer, the mental model of "how does this all connect" is not obvious from reading YAML alone.
Tools like kubectl show you state, not topology. k9s gives you resource lists. Lens visualizes the cluster but requires actual cluster access. There's no fast, offline way to go from a set of YAML manifests to a clear connection diagram — until now.
InfraSketch reads your YAML, infers the topology from label selectors and resource references, and renders it as a navigable diagram. No cluster access needed.
How to use it
Open infrasketch.cloud, click the Kubernetes tab, paste your manifests (multiple documents separated by ---), and click Generate Diagram.
kubectl get all -n my-namespace -o yaml | pbcopy # macOS
kubectl get all -n my-namespace -o yaml | xclip # Linux
Tip: Paste manifests from multiple namespaces at once — InfraSketch groups resources by namespace automatically using metadata.namespace.
How connections are inferred
InfraSketch doesn't need a running cluster to understand topology. It infers connections from the YAML itself:
Ingress → Service
Every spec.rules[].http.paths[].backend.service.name becomes a directed arrow from the Ingress to the target Service.
Service → Deployment
Service spec.selector is matched against Deployment/StatefulSet/DaemonSet spec.selector.matchLabels. Matching labels = connection arrow.
Deployment → ConfigMap/Secret
Volume mounts (configMap.name, secret.secretName) and envFrom references become arrows from the workload to the config resource.
HPA → target
spec.scaleTargetRef.name and kind links the HorizontalPodAutoscaler to its Deployment, StatefulSet, or ReplicaSet.
Supported Kubernetes resource kinds
| Kind | Category | Notes |
|---|---|---|
| Deployment | Workload | Main compute unit; selector matching for Service connections |
| StatefulSet | Workload | Persistent workloads; selector matching |
| DaemonSet | Workload | Node-level agents; selector matching |
| Job | Workload | Batch tasks |
| CronJob | Workload | Scheduled batch tasks |
| Pod | Workload | Standalone pods |
| ReplicaSet | Workload | HPA scale target |
| Service | Networking | ClusterIP, NodePort, LoadBalancer — selector → Deployment arrows |
| Ingress | Networking | HTTP routing rules → Service arrows |
| NetworkPolicy | Networking | Pod-level network rules |
| ConfigMap | Config | Referenced via volume mounts and envFrom |
| Secret | Config | Referenced via volume mounts and envFrom |
| PersistentVolumeClaim | Storage | Volume mount references from workloads |
| PersistentVolume | Storage | Cluster-wide storage resources |
| ServiceAccount | Security | Pod identity |
| HorizontalPodAutoscaler | Autoscaling | Linked to scale target via scaleTargetRef |
Namespace grouping
Every resource is placed inside a namespace boundary drawn on the diagram. Resources with the same metadata.namespace value are grouped together in a labelled box. Resources without a namespace go into the default namespace group.
When you paste manifests from multiple namespaces — say production, staging, and monitoring — each namespace gets its own group and resources stay organized. Cross-namespace connections (e.g., an Ingress controller in ingress-nginx routing to a Service in production) are drawn as arrows between the groups.
Example: a typical web application
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
namespace: production
spec:
rules:
- http:
paths:
- path: /
backend:
service:
name: web-service
port:
number: 80
---
apiVersion: v1
kind: Service
metadata:
name: web-service
namespace: production
spec:
selector:
app: web
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-deployment
namespace: production
spec:
selector:
matchLabels:
app: web
template:
spec:
containers:
- name: web
envFrom:
- configMapRef:
name: web-config
- secretRef:
name: web-secrets
---
apiVersion: v1
kind: ConfigMap
metadata:
name: web-config
namespace: production
Paste this and InfraSketch draws: Ingress → web-service → web-deployment → web-config with web-secrets also connected to the deployment. All resources inside a production namespace box.
Use cases
- Onboarding — new engineers understand the application topology in minutes instead of reading dozens of YAML files
- Code reviews — visualize the topology change when a PR adds a new Service or reconfigures selectors
- Incident response — quickly see which Services connect to a misbehaving Deployment
- Documentation — export as PNG or SVG and embed in runbooks, Confluence, or Notion
- Architecture reviews — export as draw.io XML for a fully editable diagram in design docs
Works with Helm and Kustomize output too
InfraSketch reads rendered YAML — it doesn't need the original Helm chart or Kustomize overlay files. Render first, then paste:
helm template my-release ./my-chart | pbcopy # macOS
kustomize build overlays/production | pbcopy # macOS
This works especially well for understanding what a third-party Helm chart actually deploys before you install it in your cluster. Paste the rendered output for NGINX Ingress Controller, cert-manager, or Prometheus Operator and see exactly which resources they create before running helm install.
Common Kubernetes application patterns
Microservices with shared ingress
Multiple Deployments each with their own Service, all routed through a single Ingress with path-based rules, produce a fan-out diagram: one Ingress node with arrows to each Service, each Service connected to its backing Deployment. InfraSketch draws each Deployment-Service pair as a group and fans the Ingress connections out clearly.
Worker with queue
A pattern common in data pipelines: a Deployment that reads from an external queue has no Service (no inbound traffic) but does reference a Secret (for queue credentials) and a ConfigMap (for configuration). InfraSketch draws it as an isolated Deployment node with arrows to the Secret and ConfigMap — the asymmetry in the diagram immediately signals "this is a consumer, not a server."
StatefulSet with PVC
Databases deployed as StatefulSets typically have a PersistentVolumeClaim per replica. InfraSketch draws the StatefulSet connected to its PVC(s) in the storage zone, and any Service that selects the StatefulSet connected from the networking zone. This pattern clearly separates the compute layer from the storage layer in the diagram.
Multi-namespace monitoring stack
Paste Prometheus, Alertmanager, and Grafana manifests from a monitoring namespace alongside your application manifests from production. InfraSketch draws both namespace boxes side by side with the monitoring stack's ServiceMonitor references shown as cross-namespace connections.
Getting YAML from a live cluster
Several kubectl commands produce paste-ready YAML for InfraSketch:
# All resources in a namespace
kubectl get all -n production -o yaml
# Specific resource kinds
kubectl get deployments,services,ingresses -n production -o yaml
# A single Helm release's resources
helm get manifest my-release -n production
# All namespaces at once
kubectl get all --all-namespaces -o yaml
For large clusters, target specific namespaces or resource kinds to keep the diagram readable. Pasting ten namespaces of manifests will produce a technically accurate but visually dense diagram.
Frequently asked questions
Does InfraSketch need access to my cluster?
No. Everything runs in your browser. InfraSketch reads the YAML you paste — it never makes network requests to your cluster, cloud provider, or any external API. Your manifests never leave your browser tab.
My Service selector doesn't match any Deployment — why?
Selector matching requires the Service's spec.selector labels to be a subset of the Deployment's spec.selector.matchLabels. If the manifest is a Deployment template without matchLabels defined (e.g., only spec.template.metadata.labels), InfraSketch falls back to name-based matching. Paste both the Service and its target Deployment together for best results.
What about Custom Resource Definitions (CRDs)?
CRDs with unknown kind values are not mapped to diagram nodes — InfraSketch only renders the 16 built-in Kubernetes kinds listed above. Common operator resources (Certificates from cert-manager, VirtualServices from Istio) are skipped. Support for additional kinds will expand in future releases.
Can I diagram a single Pod's YAML?
Yes — paste any valid Kubernetes YAML, including standalone Pod specs. A single Pod with envFrom referencing a ConfigMap and a volume mounting a Secret will show the Pod connected to both config resources. It works best when you paste related manifests together so InfraSketch can draw the full connection graph.
Generate your Kubernetes diagram now Paste your K8s manifests — or run
kubectl get all -o yamland paste. Free, no login, no cluster access needed. Open InfraSketch →
Top comments (0)