Part 25: Topology Comparison and Decision Matrix
"Three topologies. One decision tree. Most users land at k8s-multi and stay there."
Why
Acts III and IV have built three topologies. This part is the comparison: when to use which, what each one costs, what each one buys, and which one to default to. It is the operational equivalent of Part 02's budget table, focused on the capabilities rather than the RAM.
The matrix
| Capability | k8s-single | k8s-multi | k8s-ha |
|---|---|---|---|
| Real Kubernetes API | yes | yes | yes |
| CNI policy enforcement (with cilium/calico) | yes | yes | yes |
| Real CSI (Longhorn) | no (local-path only) | yes (3 replicas) | yes (3 replicas) |
| Multi-node failure modes | no | yes | yes |
| Anti-affinity / spreading | no-op (one node) | yes | yes |
| PodDisruptionBudget exercise | no | yes | yes |
| Rolling deploys with multiple replicas spread | no | yes | yes |
| Surviving a control plane outage | no | no | yes |
| etcd quorum behaviour | n/a | n/a | yes |
| kubeadm HA upgrade rehearsal | no | no | yes |
| kube-vip / HAProxy failover testing | n/a | n/a | yes |
| VMs | 1 | 4 | 6-7 |
| RAM (VMs only) | ~16 GB | ~28 GB | ~38 GB |
| RAM (with host OS overhead) | ~19 GB | ~32 GB | ~48 GB |
| Boot time first-run | ~6 min | ~18 min | ~28 min |
| Boot time cached | ~3 min | ~10 min | ~18 min |
| Best for | solo iteration | realistic dev | upgrade rehearsals, HA testing |
The decision tree
Most developers answer:
- "Solo iteration only?" → No, I need to test multi-node behaviour (sometimes).
- "Multi-node failure modes etc.?" → Yes, often.
- "Also HA upgrade etc.?" → Rarely. Maybe once a month before a real production upgrade.
So the typical path is k8s-multi as the daily driver and k8s-ha as the rehearsal-only topology spun up for specific tasks.
When to switch
You can change topology with one config field and a recreate. The recreate destroys the cluster and re-bootstraps from scratch, so all in-cluster state is lost. With the backup framework from Part 32, you can migrate the state across by:
- Take a Velero backup of the workloads in the old topology
homelab k8s destroy- Edit
config-homelab.yamlto the new topology homelab k8s create- Restore the Velero backup into the new cluster
Total time: ~20 minutes for k8s-multi → k8s-ha. The workload state survives intact.
Per-client topology choice
For the multi-client freelancer use case from Part 03, each client picks their own topology:
| Client | Topology | Reason |
|---|---|---|
| Acme (the .NET shop) | k8s-multi | Production runs k8s-multi-equivalent; dev should match |
| Globex (the Spring Boot shop) | k8s-ha | Globex runs HA in production and the freelancer needs to validate HA-specific things |
| Personal | k8s-single | Solo project, minimal RAM |
A 128 GB workstation hosts all three: 32 + 48 + 16 + 16 (host overhead) = 112 GB, with 16 GB of headroom.
What this gives you
A clear matrix. Three topologies. One default. A decision tree the user can follow without reading 50 pages of docs. The cost of each topology is known, the capabilities of each are known, and the user picks the right one for the right task without guessing.
The topology system is the most-touched user-facing surface in K8s.Dsl. Getting it right — three discrete options with predictable costs and capabilities, switchable with one config field — is the foundation for everything in Acts V through VIII.
End of Act IV
We have now defined the cluster, the components, and the three topologies. The cluster machinery is complete. From Part 26 onward, we use this machinery to stand up the actual workloads: Acme's stack on one cluster, Globex's stack on another, with the dogfood loops closing through ArgoCD and the GitLab in DevLab.