Cloud-Native Microservices With Kubernetes - 2nd Edition

Considerations When Setting Resource Requests and Limits

You may have many questions about how these values work in practice and in some edge cases. Let's explore some of them.

Consider the following configuration, and let's study how it works in practice:

resources:
  requests:
    cpu: "1.5"
  limits:
    cpu: "3"

Here are the implications of the above configuration:

• The request (1.5) tells Kubernetes that the container needs at least 1.5 CPUs to run.

• The scheduler will only place the Pod on a node that has at least 1.5 CPUs available.

• The limit (3) means that the container can never exceed 3 CPUs.

• If the node only has 2 CPUs (vs. 3 set up in the YAML), the container can still run (since 1.5 fits), but it will never exceed the node’s physical capacity—it can’t use more than what the node has.

• If a container requests more CPU than a node can offer, the Kubernetes scheduler simply avoids that node. For example, if your Pod requests 3 CPUs but a node only has 2, it won’t be scheduled there. The scheduler might place it on a node with 4 CPUs instead, keeping in mind that some CPU is always reserved for system components like the Kubelet and OS processes.

• If no node in the cluster has enough available resources, the Pod remains in the Pending state until one becomes available.

Here is an example of requesting 10 CPU cores (We assume your cluster nodes have fewer than 10 CPU cores each):

kubectl apply -f - << EOF
apiVersion: v1
kind: Namespace
metadata:
  name: resource-management
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: high-cpu-flask
  namespace: resource-management
spec