📖 Estimated reading time: 6 min
One of the most common challenges when setting up Kubernetes clusters is correctly sizing the necessary resources for the nodes that make up the cluster. How many vCPUs and how much RAM do you really need for your workloads? If you request too many resources, you’re wasting money; if you request too few, you’ll face performance issues or even failures.
These requests directly impact the Kubernetes scheduler and influence node sizing, whether they’re local virtual machines or cloud instances.
To help with this sizing process, I’ve developed an interactive calculator that you can use to accurately estimate CPU and memory requirements based on your planned deployments.
To better understand how these parameters affect actual resource consumption and infrastructure planning, we’ve developed an interactive request calculator. It helps estimate how many resources a cluster needs, based on your deployment definitions, making it easier to project workload and choose the optimal size for your compute instances.
Kubernetes is a powerful platform for container orchestration that uses two fundamental concepts to manage computing resources:
⒈ Requests: The minimum amount of resources that Kubernetes guarantees for a pod
⒉ Limits: The maximum value of resources that a pod can consume
When a pod is created, the Kubernetes scheduler looks for a node that has enough available resources to satisfy the pod’s requests. If the nodes in your cluster don’t have enough resources, the pods will remain pending.
An undersized cluster can cause:
− Pods in pending state
− Degraded application performance
− Frequent pod evictions
− Container restarts due to OOMKilled (Out of Memory Killed)
An oversized cluster can lead to:
− Significant waste of resources
− Unnecessary infrastructure costs
− Low resource utilization efficiency
− Reduced ROI on your Kubernetes investments
The calculator offers two operation modes:
The basic mode is perfect for quick calculations and includes:
− Total number of pods
− CPU request per pod
− Memory request per pod
With just these three values, you get an initial estimate of the resources needed for your VM.
For more precise sizing, the advanced mode allows you to specify:
− CPU and memory (both requests and limits)
− Additional buffer for growth
− Node type (standard or high availability)
− Custom utilization factor
The calculator provides three main metrics:
⒈ Total CPU Required: Sum of CPU requests multiplied by the number of pods, with adjustments for system utilization
⒉ Total Memory Required: Sum of memory requests, converted into appropriate units (Mi/Gi)
⒊ Recommended VM: Suggested virtual machine size that would accommodate your workloads
Additionally, you can see detailed calculations by clicking on “View detailed calculations,” which shows exactly how the numbers were derived.
The calculator assumes that you shouldn’t plan to use 100% of the available resources on a VM. This is because:
− Kubernetes itself consumes resources
− The operating system and base services need resources
− Reserving margin is crucial for unexpected load spikes
By default, the calculator uses a utilization limit of 80% for standard nodes and 70% for high-availability nodes.
In advanced mode, you can define an additional buffer to accommodate:
− Future workload growth
− Unexpected variations in resource usage
− Horizontal Pod Autoscaler (HPA) requirements
A 20% buffer is a conservative choice for most environments.
− CPU: Start by measuring your application’s base usage and add a 20-30% buffer
− Memory: Base it on average usage plus a 30-40% buffer (memory tends to vary more than CPU)
− CPU: Typically 1.5x to 2x the request value
− Memory: At most 1.5x the request value (to avoid OOMKilled)
For a typical web application:
resources:
requests:
cpu: 0.5
memory: 256Mi
limits:
cpu: 1.0
memory: 384Mi
− Can have a smaller buffer
− Focus on request/limits ratio to maximize density
− Need larger buffer to avoid disruptions
− Should consider I/O peak loads
− Memory requirements typically more critical than CPU
− Consider adding at least a 50% buffer for memory
Remember that the calculated values are just a starting point. Once your cluster is running:
⒈ Monitor actual resource usage
⒉ Compare with allocations
⒊ Adjust requests and limits as needed
⒋ Recalculate the optimal node size
When scaling deployments in Kubernetes (for example, increasing replicas to 50 pods) it’s not uncommon to see several pods get stuck in the Pending state. This typically happens when the cluster does not have enough available resources to satisfy the requests defined in the pod spec.
Let’s say each pod has a CPU request of 500m (half a vCPU):
resources:
requests:
cpu: 500m
If you try to deploy 50 pods with this configuration, the total requested CPU will be:
50 pods × 0.5 vCPU = 25 vCPUs
If your worker nodes each have only 8 vCPUs, and there are no other free nodes or autoscaling in place, the Kubernetes scheduler will not be able to place all pods. It will keep scheduling them only where resource requests can be satisfied. Once all nodes are full (or can’t fit the requested CPU), the remaining pods stay in Pending.
− Requests are guaranteed allocations: The scheduler will not place a pod unless it can fully guarantee the requests value.
− Scheduler doesn’t overcommit requests: Even if real usage is low, the scheduler only looks at requested resources, not actual usage.
− Node capacity is finite: If nodes are already hosting pods that use up most of their CPU or memory (based on requests), there’s no room left.
− Properly size your nodes: Use tools like the request calculator to estimate total CPU and memory usage.
− Add more nodes: Use a Cluster Autoscaler or manually scale your node pool or MachineSet.
− Review and reduce CPU requests: Confirm if your application really needs 500m. Over-provisioning is common.
− Use Vertical Pod Autoscaler: This tool can help adjust CPU/memory requests automatically based on usage.
− Split the workload: Instead of deploying 50 replicas at once, consider progressive rollouts.
If you want to visualize why pods are pending, use:
kubectl describe pod <pod-name>
Look for the “Events” section. You’ll typically see messages like:
0/3 nodes are available: 3 Insufficient cpu.
This means that the scheduler couldn’t find nodes with enough available CPU to meet the request.
Understanding this behavior is essential when scaling workloads and planning cluster capacity. The calculator provided in this article can help you anticipate such situations before they happen.
Properly sizing resources for Kubernetes clusters is a mixture of science and art. This calculator provides a solid starting point, but continuous monitoring and adjustments are essential to optimize the balance between performance and cost.
Try different scenarios, compare the results, and use this information to make more informed decisions about VM sizing for your next Kubernetes cluster.
− Official Kubernetes documentation on resource management
− Best practices for requests and limits
− Vertical Pod Autoscaler - A complementary tool to automatically adjust requests
Share this post and keep following our site for more news about Kubernetes and open-source technologies!
Check out these other interesting articles! 🔥
Did you like what you found here? With each click on a banner, you help keep this site alive and free. Your support makes all the difference so we can continue bringing content you love. Thank you! 😊