Select a plan
When creating a node pool, select an instance type from the C0 to C8 range. The instance type determines the vCPUs, RAM and NVMe storage per node – and thus both the performance and the cost of your cluster.
A pool that is too large leaves resources unused and incurs unnecessary costs. A pool that is too small leads to degraded performance, unschedulable pods or errors when CPU or memory utilisation is at full capacity.
Available instance types
You can find a full overview of prices under Pricing & Limits.
| Type | vCPU | RAM | NVMe |
|---|---|---|---|
| C0 | 1 | 1 GB | 25 GB |
| C1 | 1 | 2 GB | 50 GB |
| C2 | 2 | 2 GB | 60 GB |
| C3 | 2 | 4 GB | 80 GB |
| C4 | 2 | 8 GB | 100 GB |
| C5 | 4 | 8 GB | 160 GB |
| C6 | 4 | 16 GB | 200 GB |
| C7 | 8 | 16 GB | 320 GB |
| C8 | 8 | 32 GB | 400 GB |
Node size and number of nodes
Two settings determine the capacity of your cluster:
- Node size (instance type): 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 is running. 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 total CPU, RAM and storage capacity of the cluster. More nodes mean greater flexibility in load balancing and improved reliability.
For production clusters, a minimum of 2 nodes per node pool is recommended. This ensures your application remains accessible during upgrades and maintenance whilst nodes are restarted one after the other.
Scale horizontally or vertically
Given the same total capacity, you usually have the choice between many small nodes and a few large ones:
- Many small nodes distribute the load more evenly, are better able to cope with the failure of a single node, and are suitable for many small, stateless pods. However, the overhead for system components is incurred again for each node.
- A few large nodes make sense when individual pods require a lot of memory or when workloads benefit from being located close to one another. However, the failure of a single node here affects a larger proportion of the cluster.
Using multiple node pools
A cluster can contain several node pools with different instance types. This is useful if your workloads differ significantly – for example, a pool with small nodes for stateless web services and a pool with large nodes for memory-intensive processing jobs.
See Add Node Pools.
Data-driven decision-making
- Benchmarking and load testing: Test your workload under simulated load after creating the cluster, rather than simply estimating the required capacity.
- Analyse resource usage: Monitor CPU and memory utilisation in the Analytics tab and adjust the node size to match actual requirements.
- Plan for CPU peaks: CPU utilisation in a Kubernetes cluster typically fluctuates significantly, whilst memory requirements remain more constant. Dimension the CPU to handle peak loads.
What can be changed retrospectively
| Property | Can be changed retrospectively |
|---|---|
| Number of nodes in the pool | Yes |
| Auto-scaling per node pool | Yes |
| Additional node pools | Yes |
| Instance type of an existing pool | Via a new pool and migration of workloads |
| Pod and service networks | No – only during cluster creation |
| High Availability Control Plane | Can be enabled later, but cannot be removed |
As you can adjust the number of nodes at any time and add further pools, it makes sense to start on a small scale and grow based on actual performance data. You should, however, plan the network capacity generously right from the start.