Kubernetes Cluster Requirements: Control Plane, Workers and the Monthly Cost

Kubernetes has a published minimum and an unpublished reality. The minimum, from the kubeadm installation page checked on 1 November 2026, fits on a laptop; the reality is set by the workloads you schedule. This guide reads the project's own requirements, explains what the control plane and the workers each need, and prices three cluster layouts of the Kubernetes package on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic), where the control plane is an ordinary node with no per-cluster fee.

What the Kubernetes project requires

The kubeadm installation guide for Kubernetes v1.37 lists the requirements under "Before you begin": a compatible Linux host, 2 GB or more of RAM per machine, with the note that any less "will leave little room for your apps", 2 CPUs or more for control plane machines, full network connectivity between all machines, a unique hostname, MAC address and product_uuid per node, and a set of open ports, with the pod network plugin possibly needing more.

Swap gets its own rule. The kubelet's default behaviour is to fail to start if swap is detected; swap must be disabled (swapoff -a and the fstab entry removed) or explicitly tolerated with failSwapOn: false. On MassiveGRID PaaS the question does not arise, because a container has no swap; when a pod needs memory the node scales by the cloudlet up to its limit instead.

Control plane and workers want different things

The control plane runs the API server, etcd, the scheduler and the controller manager. Its load grows with the number of objects and the rate of change, not with the traffic your applications serve; for a cluster of a few dozen nodes the 2 GB minimum is tight and 2 to 4 GiB is comfortable. What it needs more than memory is fast disk for etcd and the absence of noisy neighbours, which is why the project advises against running your workloads on it.

The workers are the cluster's capacity. Every pod's resource requests come out of worker memory and CPU, and the kubelet reserves some of each for itself and the system. The rule that matters for sizing is that the sum of pod requests on a node cannot exceed what the node allocates, so a worker pool is sized to the requests of the workloads you intend to run, plus headroom for rolling updates, which temporarily run old and new pods side by side.

The marketplace package deploys a control plane, a worker pool, an ingress controller, the dashboard, monitoring, Helm and persistent storage, and it can be installed in a development layout (one control plane node) or a production layout (three). The control-plane bill post explains why that matters commercially.

The three configurations on PaaS and their cost

Cloudlets are 128 MiB RAM plus 400 MHz CPU, billed at $0.003372 per cloudlet-hour, $2.46 per cloudlet-month. There is no cluster management fee: the control plane nodes are billed like the workers.

The Starter row is the kubeadm minimum on both node types, which suits development and a few small services. Standard gives 8 GiB of worker capacity for production workloads with a single control plane. Production adds the three-node control plane that survives a node loss and 18 GiB of worker capacity. All three are ceilings before volume discounts; a development cluster hibernated outside working hours with the Start/Stop Scheduler add-on is billed for the hours it runs, which is the right-hand column. The PaaS pricing calculator prices other pools.

Sizing the worker pool from requests

Add up the CPU and memory requests of the deployments you will run, multiply by 1.3 for rolling-update headroom, add roughly 10% for the kubelet, the CNI and monitoring agents, and divide by the node size you prefer. Three 2 GiB workers and one 6 GiB worker hold the same requests, but the three small nodes survive a node loss better and the one large node packs memory-hungry pods better; most teams land on nodes of 4 to 8 GiB.

Then set limits sensibly. A pod with no memory limit can take the node with it, and the kubelet's eviction will not save a node whose containers all claim everything. The requests and limits guide covers the arithmetic; on the platform, a worker's cloudlet limit is the outer bound the kubelet sees as node capacity, and vertical scaling within it is automatic.

Horizontal scaling of the worker pool is a trigger on the layer: a CPU or memory threshold adds a worker, which joins the cluster on its own, and a cooldown removes it later. For preview environments the whole cluster can be cloned and deleted per pull request, which the ephemeral clusters post automates.

What a managed cluster elsewhere adds to the bill

The large clouds charge a management fee per cluster-hour on top of the nodes, and bill load balancers, persistent volumes and egress separately. The honest comparison is therefore not node for node but cluster for cluster: a three-node development cluster that costs under $80 a month here is often two or three times that on a hyperscaler once the fee and the load balancer are counted, while a large production cluster narrows the gap because nodes dominate. Figures move, so put your own numbers beside the table above rather than quoting ours; the calculator link gives the platform side for any pool.

What the hyperscalers include that this package does not is their ecosystem: managed identity, their proprietary load balancers and storage classes, and a control plane someone else upgrades. The package's control plane is yours to upgrade, from the dashboard, with the cluster's own tooling; the trade is control and a lower bill for a little more operations. Sovereignty is the other side of the same coin, as the single-jurisdiction cluster post sets out.

Frequently Asked Questions

What are the minimum requirements for a Kubernetes node?

Per the kubeadm installation guide checked on 1 November 2026: 2 GB or more of RAM per machine, 2 CPUs or more for control-plane machines, full network connectivity, unique hostname and MAC address, the required ports open, and swap disabled or tolerated. The Starter configuration on MassiveGRID PaaS gives each node 2 GiB.

Is there a control-plane fee on MassiveGRID PaaS?

No. The control plane node or nodes are billed by the cloudlet like the workers; there is no per-cluster charge. A Starter cluster costs about $78.72 a month always on, and a cluster hibernated outside working hours is billed only for its hours.

How big should the worker nodes be?

Size the pool to the sum of your pods' resource requests with about 30% headroom for rolling updates and 10% for system agents, then choose a node size: several 2 to 4 GiB nodes survive a loss better, one large node packs memory-hungry pods better. The Standard configuration gives two 4 GiB workers, Production three 6 GiB workers with a three-node control plane.