Kubernetes Diagram Generator — Visualize K8s YAML Instantly

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.

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

How connections are inferred

InfraSketch doesn't need a running cluster to understand topology. It infers connections from the YAML itself:

Supported Kubernetes resource kinds

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.