Skip to main content

Select VM size & pool

The correct sizing depends heavily on your workload. A cluster that is oversized does not make full use of its resources and results in higher costs; a cluster that is undersized will experience reduced performance or errors when CPU or memory utilisation is at full capacity.

You can find an overview of instance types C0 to C8, including prices, under Pricing & Limits. The basic selection criteria are described in Choose a Plan.

Selecting the node size and number of nodes

  • Node size: Determines the maximum amount of memory that can be allocated to a single pod. A pod can never be larger than the node on which it runs. Bear in mind that a portion of the node’s resources is reserved for system components such as kubelet and the container runtime.
  • Number of nodes: Determines the cluster’s total CPU, RAM and storage. More nodes mean greater flexibility in load balancing and increased reliability.

For production clusters, we recommend at least 2 nodes per node pool to ensure your application remains accessible during upgrades and maintenance work.

Making data-driven decisions

  • Benchmarking and load testing: Test your workload under simulated load after creating the cluster, rather than simply estimating the required capacity.
  • Analysing resource usage: Monitor CPU and memory utilisation in the Analytics tab and adjust the node size to match actual requirements. See View metrics.

Additional storage

The nodes’ local NVMe storage is tied to the respective node and is not suitable for data that needs to be stored permanently. For permanent data, use a persistent volume (CSI/PVC) or S3 Object Storage.

See Storage Features.

Important to note

  • CPU and RAM peaks: CPU utilisation in a Kubernetes cluster typically fluctuates significantly, whilst memory requirements remain more constant. Size the CPU to accommodate peak loads.
  • Memory cannot be compressed: If a node reaches its memory limit, pods will be terminated (OOMKilled). Make sure to set aside a reserve here.
  • Changes after creation: The number of nodes and additional node pools can be adjusted at any time. You can change the instance type of an existing pool by creating a new pool and migrating the workloads to it.
  • Networks are final: The size of pod and service networks cannot be changed once the cluster has been created. Plan these areas generously from the outset.

As the number of nodes can be adjusted at any time, it makes sense to start small and scale up based on actual performance data.