Kubernetes Diagram Generator — Visualize K8s YAML Instantly

A Kubernetes application is rarely a single file. A modest service might span a Deployment, a Service, an Ingress, a ConfigMap, a Secret, an HPA, and a NetworkPolicy — often split across directories or generated by Helm. The relationships that matter (which Service routes to which Deployment, what the Ingress exposes, which Pods read which Secret) are expressed indirectly through label selectors and name references, not visible structure. This guide explains how those connections are inferred from manifest YAML, how namespace grouping works, and how to read the resulting topology.

Why manifests hide the architecture

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

Related articles

• How to Visualize Your Docker Compose Setup
• How to Create AWS Architecture Diagrams in 2026
• Auto-Post Architecture Diagrams on Every IaC Pull Request