Kube-scheduler decides which pods go to which node. The scheduler takes into consideration the amount of resources required by a pod and those available on the nodes and identifies the best nodes to place the pod on.
The pods go into the pending state if no node with sufficient resources is available for the placement.
Resource Request
apiVersion: v1
kind: Pod
metadata:
name: simple-app
labels:
name: simple-app
spec:
containers:
- name: simple-app
image: simple-app
ports:
- containerPort: 8080
resources:
requests:
memory: "4Gi"
cpu: 2
CPU can be from 1m 1 CPU = 1 AWS vCPU 1 GCP Core 1 Azure Core 1 Hyperthread
Memory 256Mi(MebiByte) A mebibyte equals 220 or 1,048,576 bytes. G 1000 Megabytes Gi 1024 Mebibyte
Limits can be specified in pod yaml file under resources:
...
resources:
requests:
memory: "4Gi"
cpu: 2
limits:
memory: "8Gi"
cpu: 4
When a pod requests more than the limits. A Pod can use more memory than under limit but not cpu. If the entire memory is consumed, the pod is terminated with an oom (out of memory) error
Default behavior
Any pod can consume as many resources as the node has
To set the default limit on pod resource requests, the limit range can be set. This is applied at the namespace level
apiVersion: v1
kind: LimitRange
metadata:
name: cpu0resource-constraint
spec:
limits:
- default:
cpu: 500m
defaultRequest:
cpu: 500m
max:
cpu: "1"
min:
cpu: 100m
type: Container
apiVersion: v1
kind: LimitRange
metadata:
name: memory-resource-constraint
spec:
limits:
- default:
memory: 1Gi
defaultRequest:
memory: 1Gi
max:
memory: 1Gi
min:
memory: 500Mi
type: Container
Resource Quota: sets limit at nameserver level on all the pods the workload is shared on
apiVersion: v1
kind: ResourceQuota
metadata:
name: my-resource-quota
spec:
hard:
requests.cpu: 4
requests.memory: 4Gi
limits.cpu: 10
limits.memory: 10Gi