Kubernetes Cluster Topology

flowchart TB
  subgraph prod["Cluster: prod-eu (regional, 3 AZ)"]
    direction TB
    cp["Control plane<br/><i>managed · private endpoint</i>"]
    subgraph pools["Node pools"]
      direction LR
      np1["system<br/><i>taint: CriticalAddonsOnly</i>"]
      np2["general<br/><i>3–30 nodes · spot 40%</i>"]
      np3["memory<br/><i>taint: workload=memory</i>"]
      np4["gpu<br/><i>taint: workload=gpu</i>"]
    end
    subgraph ns["Namespaces"]
      direction LR
      n1["team-orders<br/><i>quota · NetworkPolicy<br/>default-deny</i>"]
      n2["team-pricing<br/><i>quota · NetworkPolicy</i>"]
      n3["platform<br/><i>mesh · ingress · logging</i>"]
    end
    cp --- pools
    pools --- ns
  end
  subgraph nonprod["Cluster: nonprod-eu"]
    direction TB
    x1["shared node pool<br/><i>spot 90%</i>"]
  end
  reg[("Image registry<br/><i>signed images only</i>")] --> prod
  reg --> nonprod
  gitops["GitOps reconciler"] -.->|"applies desired state"| prod

What it is

The cluster estate: how many clusters and on what axis they are split, what node pools exist and what each is reserved for, and how tenants are separated inside a shared cluster. The split decision is the architecture — per environment, per region, per tenant, per compliance boundary — and every option trades blast radius against cost and operational load.

When you produce it

Before the second cluster exists, because cluster sprawl is easy to start and expensive to reverse. Revisit whenever a workload arrives with an isolation requirement the current split cannot express.

Who reads it

Platform engineers who run it. Application teams, who need to know what they get and what they are sharing. Security, who care whether namespace isolation is sufficient for the data involved.

What good looks like

• The split axis is stated and justified. "One per environment per region" is a decision; forty clusters that grew is not.
• Taints and tolerations are shown, so it is clear what can land where.
• Namespace isolation is explicit: quotas, network policy default-deny, and whether that is considered a hard boundary.
• Autoscaling ranges and spot proportion are noted — they drive both cost and eviction behaviour.
• Non-production is a separate cluster where the risk warrants it, and the diagram says why.

Common mistakes

• Treating a namespace as a security boundary for genuinely hostile multi-tenancy. It is not; that needs separate clusters or sandboxed runtimes.
• One giant cluster, so an upgrade is a company-wide event.
• A cluster per team, so the platform team operates forty control planes.
• No default-deny network policy, making every namespace reachable from every other.