See it as a diagram
Everything below, as a diagram you can edit. Describe yours and see it in seconds.
No account needed · Editable canvas, not a picture
The icon set is a resource vocabulary
The Kubernetes project publishes a labelled icon per resource kind, and the abbreviation printed on each one matches the short name you already type. Workloads: pod, deploy, rs, sts, ds, job, cronjob. Networking: svc, ing, netpol, ep. Config and storage: cm, secret, pv, pvc, sc, vol, quota, limits. Identity: sa, role, rb, c-role, crb, user, group. Structure: ns, crd, hpa, psp.
Control plane pieces have their own marks: api for the API server, etcd, sched for the scheduler, c-m for the controller manager, c-c-m for the cloud controller manager, kubelet, and k-proxy, plus node and a control-plane container mark. Forty-one files in total, which is the whole vocabulary, and it is small enough that you can hold it in your head after one read. That also means the two very different diagrams people both call a cluster diagram draw from disjoint halves of it, which is a useful signal that you should pick one.
Because the labels are printed on the icons, a Kubernetes diagram carries more meaning per box than a cloud diagram does. A reader who knows kubectl reads sts and immediately knows about ordered rollout and stable network identity. Use that: prefer the correct kind over a generic box even when the shape looks the same.
Two diagrams, both called a cluster diagram
The control plane diagram shows the API server, etcd, the scheduler, the controller manager, and the kubelet and kube-proxy running on each node. It is close to identical for every cluster on the planet, which makes it good onboarding material and useless as documentation of your system. Draw it once, keep it in the internal handbook, and do not maintain a copy per cluster.
The workload diagram shows namespaces, deployments, services, ingress, and persistent volume claims. It is entirely specific to you, it is the one people actually need during an incident, and it is the one that goes stale within a sprint. If your title says cluster diagram, say which of the two you mean in the subtitle.
On managed clusters, a third variant is worth drawing: the boundary between what the cloud provider runs and what you run. For EKS, AKS, and GKE the control plane is a managed service, so the correct picture uses the cloud provider service icon for the control plane and Kubernetes resource icons for everything inside. Mixing sets here is not a mistake, it is the accurate rendering. See EKS cluster architecture diagrams for the AWS case.
Namespaces as zones, and where to stop
One zone per namespace is the layout that matches how teams reason about a cluster. Namespaces are the boundary for RBAC, resource quotas, and network policies, so drawing them as containers puts the three most common questions in the right place. Put the ResourceQuota on the zone label.
Inside a namespace, draw the Deployment as one node with the replica count on the label. Do not draw three pod icons. Pods are scheduler output, they change hourly, and a diagram that renders them is a screenshot of a moment rather than a description of a system. The exception is a StatefulSet where ordinal identity matters, and even then the count belongs on the node.
Draw Service and Ingress on the edge into the namespace, with the ingress host and path on the edge label, because that is the routing question. Attach PersistentVolumeClaims to the workload that mounts them and point them at a StorageClass. Show ConfigMaps and Secrets only when the workload consumes them in a way worth knowing, for example a secret mounted from an external secret store.
Datadef ships all 41 of those labelled marks alongside 439 AWS, 624 Azure, and 226 Google Cloud icons in one index, so a diagram that mixes a managed control plane with in-cluster resources resolves in a single pass rather than by opening two libraries and matching styles by eye.
From manifests to a picture that stays true
The fastest first draft is a sentence: the namespaces, the workloads, and the ingress path. The canvas comes back with namespaces as zones and the right resource icons, and you edit from there rather than starting from an empty grid. Export to PNG or JPEG for the runbook.
The version that stays true is generated from the manifests in the repository. When the corpus is assembled, Kubernetes manifests are one of the highest-priority classes, sampled up to fourteen files under an architecture-focused sync against a total budget of forty files and 250KB, so a cluster with a dozen workload manifests is read essentially whole rather than skimmed. Anything larger than 30KB is truncated with a marker rather than dropped, so a long generated manifest still contributes its top-level shape.
Living diagrams from Kubernetes manifests covers that loop, and a live embed in the repository README means the picture in the docs is the one from the last sync rather than from the last time someone remembered.
FAQ
Which icon represents a Kubernetes Deployment?
Should a Kubernetes diagram show individual pods?
What is the difference between a control plane diagram and a workload diagram?
How should namespaces appear on a cluster diagram?
Do I use cloud provider icons or Kubernetes icons for EKS, AKS, and GKE?