Kubernetes 架构图：该画什么
Kubernetes 架构图帮助团队理解集群结构、故障边界与运维职责。
Core Kubernetes components to diagram
Every K8s architecture diagram should show the control plane and the worker nodes. The control plane runs the API server, etcd (the cluster state store), the scheduler, and the controller manager. Worker nodes run the kubelet, the container runtime (containerd or Docker), and the kube-proxy for networking.
Within the cluster, group resources by namespace. Each namespace typically contains Deployments (which manage ReplicaSets and Pods), Services (which provide stable DNS and load balancing), ConfigMaps, Secrets, and PersistentVolumeClaims. Show the relationship between a Deployment and its Pods with a 'manages' arrow.
For ingress and external traffic, show the Ingress controller (NGINX, Traefik, or cloud-provider Ingress) receiving traffic and routing it to Services. If you use a service mesh like Istio or Linkerd, add a sidecar layer to indicate how traffic flows between pods.
Types of Kubernetes diagrams
A cluster topology diagram shows the physical or cloud layout: control plane nodes (usually 3 for HA), worker node groups, and the regions or availability zones they run in. This is what you share during an outage to understand blast radius.
A workload diagram focuses on a specific application: one namespace, showing the Deployments, Services, ConfigMaps, and ingress rules that make the application work. This is what a developer needs to debug a misbehaving service.
A networking diagram shows pod-to-pod communication, network policies (which pods can talk to which), and external connectivity. With tools like Cilium or Calico enforcing network policies, a networking diagram is essential for security reviews.
What to annotate on a Kubernetes diagram
Label each Deployment with its image tag or version, replica count, and resource requests (CPU and memory). This turns a topology map into an operational document — '3 replicas, 500m CPU / 512Mi RAM' is immediately actionable during a capacity incident.
Show PersistentVolumes and StorageClasses for stateful workloads. A database pod backed by a PVC on EBS (gp3) behaves very differently from one using ephemeral storage — this distinction matters for backup strategy and failure recovery.
For multi-cluster setups, use separate diagram boundaries per cluster and show how they connect — via a shared database, a message broker, or a federated identity provider. Cross-cluster communication is often the most complex part of a Kubernetes deployment and deserves explicit documentation.
Generate a Kubernetes diagram with AI
Describe your cluster in plain English — 'Kubernetes cluster with an ingress controller, two deployments (API and worker), a Redis StatefulSet, and a ConfigMap' — and AIDrawIO generates a complete K8s diagram with correct Kubernetes icon shapes and namespace grouping.
The output is draw.io XML compatible with diagrams.net. Edit it to add your actual resource names, replica counts, and storage details. Export as SVG for your runbooks or PNG for Confluence.
免费试用 Kubernetes generator
AI Kubernetes cluster diagrams. Describe in plain English, get draw.io XML in seconds. No account required.
常见问题
What tools can I use to automatically generate a Kubernetes architecture diagram?
k8sviz, Kubectl-graph, and Kubeview can generate topology diagrams from a live cluster. AIDrawIO generates a diagram from a text description without needing cluster access — useful for designing before deployment or documenting without credentials.
How do I diagram Kubernetes networking policies?
Draw pods as circles or rectangles and use colored arrows to show allowed traffic flows. Use a 'deny all' annotation as the base policy and show each explicit allow rule as an arrow with the source and destination labels. Cilium's Hubble UI also generates live network flow diagrams from actual traffic.
What is the difference between a Deployment and a StatefulSet in a K8s diagram?
A Deployment manages stateless pods that are interchangeable. A StatefulSet manages pods with stable identities and persistent storage (like databases). In diagrams, both look similar but annotate StatefulSets with their PersistentVolumeClaims to make the statefulness visible.
Should I draw control plane components on every Kubernetes diagram?
Only if the diagram's purpose requires it — for a cluster topology or a security review. For application-focused diagrams (explaining how a specific service works), omit the control plane and focus on the namespace, Deployments, Services, and Ingress.