K8s 集群拓扑. Copy the source, paste into the official playground, done. No coordinates — every position is stated relative to something else.
node kubectl "kubectl"
node api "kube-apiserver" below kubectl
node ingress "Ingress" below api level with coredns
node coredns "CoreDNS" right of ingress
node pod1 "pod" below-left of ingress
node pod2 "pod" below-right of ingress
node svc "Service" below pod2
edge kubectl -> api "api"
edge api -> ingress
edge ingress -> svc
edge svc -> pod1
edge svc -> pod2npx reladraw kubernetes-cluster.reladraw -o out.svgUse this when explaining your cluster to someone who does not live in it: new teammates, a security reviewer, or a runbook. It shows the control-plane path (kubectl → apiserver) and how Ingress routes traffic down to pods through a Service.
It also works as the “before” picture in an incident post-mortem.
node app.pod1 "pod" — compound ids render as grouped containers.node nginx "nginx-ingress" below ingress and rewire edge ingress -> nginx, edge nginx -> svc.node user "End user" above kubectl and edge user -> ingress "https" from: top.Model each component — apiserver, Ingress, Services, pods — as a node, then place them along the request path: what a request hits first goes on top. This template follows that convention and renders in one paste.
Use dotted node ids like app.web and infra.jobs. Reladraw treats the prefix as a container, so each namespace becomes a visual box without extra syntax.
Draw two or three pod nodes to suggest a replica set and label them pod-1, pod-2 — or one node labeled “pods ×6”. Explicit layout works best when the count is part of the label, not the topology.