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.
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)