CrestVPS

kubernetes vps

Kubernetes worker nodes

Cheap per core, dense, and identical every time.

What we would deploy

€46.83/mo

€66.9030% annual

Cluster economics are decided by cost per dedicated core, not by cost per instance. EPYC Bergamo gives us a hundred and twenty-eight cores in a socket at a clock that is perfectly adequate for containerised services, which is why TORQUE is the cheapest way to buy a genuinely dedicated core anywhere in our range. Talos and Flatcar images are prebuilt, and the private VLAN carries pod traffic without egress billing.

Why this configuration

TORQUE gives dedicated cores at the lowest price per core we can build. Put the control plane on one, workers on the rest, and connect them over a private VLAN so intra-cluster traffic never touches the public interface or your bandwidth allowance.

What we would deploy

PlanTORQUE T2
vCPU8 (dedicated)
RAM32 GB
Storage400 GB
ImageTalos Linux 1.9

Sizing

Price the cluster per dedicated core, not per instance. TORQUE Bergamo gives dense real cores, so a three-node control plane at 4 cores and 8 GB each carries roughly 100 workers. Size workers so losing one costs under a third of capacity: five 16-core nodes beat two 40-core nodes. Reserve a core and 2 GB per node for kubelet, containerd and the CNI before counting allocatable. Below 8 cores a node spends too much of itself on system daemons.

Talos, and what goes away with it

Talos is one of the 48 images and it removes an entire category of node drift. There is no shell, no SSH, no package manager. Configuration arrives as a machine config over an API and the root filesystem is immutable and verified. In practice that means node rebuild becomes cheaper than node repair, which is the correct posture for a worker anyway. Median provisioning of 47 seconds makes that a real workflow rather than a slogan. Keep the machine config in the same repository as the manifests, apply upgrades with talosctl, and treat any node that needs manual attention as one to be replaced.

The private VLAN and cost per core

Kubernetes generates far more east-west traffic than most operators expect: service mesh sidecars, CSI replication, etcd, metrics scrape, and every cross-node pod call. Putting that on a private VLAN keeps it off the public interface, out of the DDoS scrubbing path, and away from anything that could enumerate your CNI. It also simplifies NetworkPolicy, because the node network stops being reachable from outside. On cost, dedicated Bergamo cores mean no steal time and no noisy neighbour, so requests match reality. With annual billing at 30% off and fleet discounts stacking to 10% from ten servers, the per-core figure is predictable enough to budget against.

What goes wrong

  • Stretching etcd across cities. etcd needs fsync latency in single-digit milliseconds and quorum RTT below about 10 ms. Keep all three members in one metro and stretch only the workers.
  • Forgetting system reserved. Without kube-reserved and system-reserved set, the scheduler packs a node to its nominal memory and the kubelet starts evicting pods it just admitted.
  • Running pod-to-pod traffic over public addresses. Overlay traffic on the public NIC is unencrypted by default, counts against your egress path, and exposes the CNI ports. Put it on the private VLAN.

Tune the machine

  • Addressing and transitPrivate VLAN between your servers · €6
  • CPU schedulingPinned physical cores · €9
  • Everything elseSecond-resolution metrics + alerting · €5