Running k3s cluster vps hosting setups is how most small teams get production Kubernetes without paying a managed-control-plane premium or babysitting bare metal. This post is a sizing and networking guide for spreading a 3-5 node k3s cluster across VPS instances — how to size each role, what the inter-node network needs to look like, and why hourly billing is the cheapest way to test a topology before you lock in monthly nodes. No fluff, just what we'd tell a colleague setting this up on a Friday afternoon.
Why K3s on a Cluster of VPS Instances
K3s strips the control-plane down to a single binary — no etcd cluster to babysit by default (it ships with embedded SQLite or can run against Postgres/MySQL), no separate control-plane fleet to size and patch. That's what makes it the practical choice for lightweight kubernetes vps deployments: you're not running a managed service with per-cluster or per-node fees stacked on top of compute, and you're not running full upstream Kubernetes' heavier resource floor on boxes that are supposed to be doing application work.
The tradeoff is that you own the topology decisions a managed service would otherwise hide from you: how many nodes, what role each one plays, and how they talk to each other. That's a good tradeoff if you're comfortable with a self-hosted k3s multi-node cluster and want to keep costs proportional to actual usage rather than a flat managed-K8s tax.
Sizing a K3s Cluster VPS Hosting Setup
Most small production clusters we see fall into one of two shapes: a 3-node cluster where every node is both control-plane and worker (fine for dev/staging or low-traffic production), or a 3-5 node cluster with dedicated control-plane nodes separated from workers once you need HA and don't want a workload eviction to also take down the API server.
Here's how that maps onto VPS tiers on our hourly VPS lineup:
| Role | Suggested tier | Specs | Notes |
|---|---|---|---|
| Control-plane (HA, 3x) | VPS II | 4GB/2vCPU/80GB — EUR6/mo | etcd/SQLite plus API server rarely needs more at this scale |
| Worker (general) | VPS III | 8GB/2vCPU/120GB — EUR10/mo | Sweet spot for most app + sidecar workloads |
| Worker (memory-heavy) | VPS V | 16GB/4vCPU/200GB — EUR30/mo | Databases, caches, anything JVM-shaped |
| Single-node dev/test | VPS I | 2GB/1vCPU/40GB — EUR4/mo | Fine for a throwaway k3s install to try a manifest |
A common 5-node production layout: 3x VPS II as HA control-plane, 2x VPS III as workers, scaled up independently as load grows. Since every tier is billed hourly to the second, you can run that exact shape for a weekend load test without committing to a month of any of it.
Private Networking Between Nodes
K3s needs low-latency, non-flaky connectivity between nodes for the Flannel/VXLAN overlay (or your CNI of choice) and for etcd/SQLite replication traffic if you're running HA control-plane. Every node in the cluster gets 1 Gbps unmetered symmetric bandwidth, which covers node-to-node overlay traffic, image pulls, and log/metrics shipping without a bandwidth ceiling forcing a redesign later.
A few things worth doing at the network layer regardless of cluster size:
- Keep etcd/API traffic on a private interface where possible — don't expose the K3s API port to the public internet unmodified.
- Pin your CNI's overlay MTU correctly if you're running behind any tunnel — mismatched MTU is still the most common "pods can't reach each other" bug we see.
- If you're planning to run the cluster across more than one location, our network runs on our own AS60982 with a 400 Gbps DWDM ring linking 13 EU POPs, which keeps intra-network latency sub-5ms — worth checking before you decide cross-location nodes are worth the extra RTT.
Using Hourly Billing to Test Topology First
The part most sizing guides skip: you don't actually know if 3 nodes or 5 nodes is right until you've run real traffic through it. Provisioning a full HA control-plane plus workers on monthly billing to find out you over- or under-sized it is an expensive way to learn.
Since every VPS I-VI tier bills hourly to the second, the practical move is to stand up the candidate topology — say, 3x VPS II control-plane + 2x VPS III workers — run your actual workload or a load-test rig against it for a few hours or a couple of days, then tear it down or resize before switching to monthly if you're keeping it. Nodes deploy in under a minute each, so spinning up an alternate topology to compare (4 workers vs. 2 bigger workers, for instance) is a same-afternoon exercise rather than a planning cycle.
This same logic — provision hourly, measure under real load, then commit — applies to any infrastructure sizing decision, not just a k3s cluster.
Joining Nodes and Practical Gotchas
A few notes from actually doing this:
- Server vs. agent roles. K3s distinguishes `server` (control-plane, can also run workloads) and `agent` (worker-only) nodes. Bootstrap the first server, grab the node token, then join the rest with `k3s agent --server https://:6443 --token `.
- Root SSH access on every node means you're not fighting a provider's own agent or sidecar to get k3s installed — it's a standard curl-pipe-sh install like anywhere else.
- NVMe storage matters more than people expect for etcd/SQLite write latency on control-plane nodes — slow disk is a common cause of flaky leader elections in HA setups.
- IPv4 + IPv6 on every node means you can run the overlay dual-stack from day one if that's a requirement for you.
If your cluster outgrows what VPS-tier nodes comfortably handle — heavy stateful workloads, larger databases, sustained high CPU — dedicated servers are the next step up for specific node roles without re-architecting the whole cluster.
How Noded Can Help
We run the VPS lineup this guide is built around — six tiers from EUR4 to EUR58/mo, all billed hourly to the second, with 1 Gbps unmetered symmetric bandwidth, NVMe storage, and root SSH on every node. If you're testing a k3s topology, that means you can bring up a full multi-node candidate cluster, throw traffic at it, and tear down or resize without waiting on a monthly commitment. When you're ready to lock in, the same nodes switch straight to monthly billing with no migration step. Start from our VPS hosting page to pick tiers for your control-plane and worker nodes.
FAQ
How many nodes do I need for a production k3s cluster?
Three nodes is the practical minimum for HA (so the cluster survives one node failure), with each node running both control-plane and worker roles on small deployments. Once traffic or workload count grows, splitting into 3 dedicated control-plane nodes plus 2 or more workers (5 nodes total) is the more common production shape.
Can I run k3s control-plane and workloads on the same VPS?
Yes — this is the default k3s `server` role and is fine for dev, staging, or low-traffic production. For anything where you can't tolerate the API server going down alongside a workload eviction, separate control-plane nodes from worker nodes once you're past the initial testing phase.
What bandwidth does k3s need between nodes?
It depends on your CNI overlay and workload chattiness, but the overlay traffic, image pulls, and any log/metrics shipping between nodes should never be the bottleneck. 1 Gbps unmetered symmetric per node covers typical 3-5 node clusters comfortably.
Is hourly billing actually useful for a Kubernetes cluster, or just for single VPS testing?
It's arguably more useful for clusters — sizing one VPS wrong costs you one node's difference; sizing a whole cluster topology wrong (wrong node count, wrong tier mix) costs you the whole month across every node. Testing the full topology hourly before switching to monthly catches that upfront.
Do I need a managed Kubernetes service instead of self-hosted k3s on VPS?
Not for most small-to-mid production workloads. Managed K8s buys you a hosted control-plane and integrated tooling, but k3s's embedded control-plane already removes most of that operational burden while letting you size and place nodes yourself instead of paying a per-cluster management fee on top of compute.