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.
Maintained by the Reladraw Templates gallery — an independent, free community resource. Sources are verified against the official Reladraw repository before publishing. Found an issue? Report it and it gets fixed.
The cluster seen from the delivery side: a developer push lands in a GitOps repo, Argo CD syncs it through kube-apiserver into two namespaces.
node dev "Developer"
node git "GitOps Repo" below dev
node argo "Argo CD" below git
node api "kube-apiserver" below argo
node ns1 "ns: frontend" below-left of api
node ns2 "ns: backend" below-right of api
node f1 "deploy" below ns1
node b1 "deploy" below ns2
edge dev -> git "push"
edge git -> argo "sync"
edge argo -> api "apply"
edge api -> f1
edge api -> b1Mermaid renders a K8s topology fast, but it auto-assigns positions — a five-node cluster usually comes out legible, a twelve-node one comes out crossed. Here every placement is stated: ns: frontend sits below-left of kube-apiserver because you said so, and it stays there when you add a third namespace. Use Mermaid for quick inline sketches; use this template when the cluster layout itself carries meaning you need to keep stable across revisions.