So far, Kubernetes knows:

Run 3 Pods

But Kubernetes also needs to know:

How much CPU and memory does each Pod need?

Without resource requests and limits, one badly behaved application could consume a huge amount of a node's resources and affect other workloads.

The two most important concepts are:

Requests → What the Pod needs
Limits    → Maximum resource usage allowed

1. The Problem#

Imagine one Kubernetes node has:

CPU    = 4 cores
Memory = 8 GB

And we have:

Application A
Application B
Application C

Suppose Application A suddenly consumes:

CPU = 3.8 cores
Memory = 7 GB

Then:

Application B
Application C
        ↓
Could be starved of resources

Kubernetes needs a way to manage this.

That's where:

requests
limits

come in.

2. CPU and Memory#

Kubernetes primarily manages:

CPU
Memory

For containers.

Example:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
 
  limits:
    cpu: "500m"
    memory: "512Mi"

Let's decode this.

3. CPU Units#

CPU can be specified using:

1
500m
250m
100m

m means:

millicpu

So:

1000m = 1 CPU

Therefore:

500m = 0.5 CPU
250m = 0.25 CPU
100m = 0.1 CPU

Think:

1 CPU
│
├──────────── 1000m
│
├──────       500m
│
└──           250m

4. Memory Units#

Memory can use units such as:

Mi
Gi
M
G

For Kubernetes resource quantities, you'll commonly encounter:

128Mi
256Mi
512Mi
1Gi
2Gi

For example:

256Mi ≈ 256 MiB
1Gi ≈ 1 GiB

For practical Kubernetes work, remember:

Mi → mebibytes
Gi → gibibytes

5. What Is a Request?#

A request tells Kubernetes:

"I need at least this much resource for scheduling purposes."

Example:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"

This means Kubernetes considers:

CPU requirement    = 250m
Memory requirement = 256Mi

when deciding where to place the Pod.

6. Scheduling Example#

Suppose:

Node A
CPU available for scheduling = 500m

Your Pod requests:

CPU = 250m

It can potentially fit.

But if:

Node B
CPU available = 100m

then the Pod cannot fit based on its CPU request.

Conceptually:

Pod
Request:
250m CPU
      │
      ▼
Scheduler
      │
      ├── Node A → 500m available ✅
      │
      └── Node B → 100m available ❌

This is one of the most important purposes of requests.

7. What Is a Limit?#

A limit defines the maximum resource usage allowed for a container.

Example:

resources:
  limits:
    cpu: "500m"
    memory: "512Mi"

Meaning:

CPU
↓
Can use up to approximately 0.5 CPU
 
Memory
↓
Can use up to 512Mi

8. Request vs Limit#

Memorize this:

Request
   ↓
Used mainly for scheduling
 
Limit
   ↓
Maximum allowed usage

For example:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
 
  limits:
    cpu: "500m"
    memory: "512Mi"

Conceptually:

CPU:
 
0 ─────── 250m ───────────── 500m
          ↑                    ↑
       Request               Limit

9. Real Example#

Imagine a Node.js API.

Normal usage:

CPU = 150m
Memory = 200Mi

During a traffic spike:

CPU = 400m
Memory = 400Mi

We could configure:

resources:
  requests:
    cpu: "200m"
    memory: "256Mi"
 
  limits:
    cpu: "500m"
    memory: "512Mi"

So Kubernetes knows:

Normal reservation:
200m CPU
256Mi Memory
 
Maximum:
500m CPU
512Mi Memory

10. Why Requests Matter for Scheduling#

Suppose we have:

Node
CPU = 4
Memory = 8Gi

We already run:

Pod A
requests:
  cpu: 1
  memory: 2Gi
 
Pod B
requests:
  cpu: 1
  memory: 2Gi

Then scheduler sees approximately:

Requested CPU = 2
Requested memory = 4Gi

Remaining schedulable capacity is approximately:

CPU = 2
Memory = 4Gi

A new Pod requesting:

CPU = 3

cannot fit on that node.

Even if actual CPU usage happens to be low at that moment.

This is important:

Scheduling is based primarily on resource requests, not current instantaneous usage.

11. Why Limits Matter#

Suppose your application has a memory leak.

Without an appropriate memory limit:

Node
│
├── API
│
├── Redis
│
├── Frontend
│
└── Bad application
        │
        ├── 1GB
        ├── 2GB
        ├── 4GB
        └── 8GB...

It could consume too much node memory.

With a limit:

memory limit = 512Mi

the container can't simply keep consuming memory indefinitely.

12. What Happens When Memory Limit Is Exceeded?#

This is extremely important.

Suppose:

limits:
  memory: "512Mi"

Application tries to consume:

700Mi

The container may be terminated due to an out-of-memory condition.

You may see:

OOMKilled

Check:

kubectl describe pod <pod-name>

You may find:

Reason: OOMKilled

Then:

kubectl get pod <pod-name>

could show restart behavior.

13. Memory vs CPU Behavior#

CPU and memory behave differently.

CPU#

CPU is generally compressible.

If the container tries to exceed its CPU limit, it can be throttled.

Conceptually:

CPU limit = 500m
 
Application wants:
800m
 
Kubernetes:
"You're limited to approximately 500m."

The application may become slower.

Memory#

Memory is not compressible in the same way.

If a container exceeds its memory limit:

Memory limit = 512Mi
 
Application wants:
700Mi

the container can be terminated with:

OOMKilled

So:

CPU → throttling
Memory → potential OOM kill

is a useful interview-level mental model.

14. Requests and Limits Example#

A realistic Deployment:

apiVersion: apps/v1
kind: Deployment
 
metadata:
  name: node-api
 
spec:
  replicas: 3
 
  selector:
    matchLabels:
      app: node-api
 
  template:
    metadata:
      labels:
        app: node-api
 
    spec:
      containers:
        - name: node-api
          image: my-node-api:1.0
 
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
 
            limits:
              cpu: "500m"
              memory: "512Mi"

Now each Pod requests:

250m CPU
256Mi memory

and can use up to:

500m CPU
512Mi memory

subject to Kubernetes/runtime behavior and node capacity.

15. Three Important Scenarios#

Scenario A#

Request = 250m
Limit = 500m
 
Actual CPU = 150m

Everything is fine.

Scenario B#

Request = 250m
Limit = 500m
 
Actual CPU = 450m

Still within the limit.

Scenario C#

Request = 250m
Limit = 500m
 
Application wants >500m

CPU can be throttled.

16. What If Request = Limit?#

You can do:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
 
  limits:
    cpu: "500m"
    memory: "512Mi"

This has consequences for the Pod's QoS classification, which we'll discuss shortly.

17. What If You Don't Specify Resources?#

You might write:

containers:
  - name: app
    image: my-app

with no:

resources:

Then your workload may have no explicit resource requests/limits.

This can create problems:

❌ Scheduling becomes less predictable
❌ One workload may consume excessive resources
❌ HPA behavior can be affected
❌ Cluster capacity planning becomes harder
❌ Troubleshooting becomes harder

In production, explicitly defining resource requirements is generally a good practice.

18. QoS Classes#

Kubernetes assigns Pods a Quality of Service class.

There are three:

Guaranteed
Burstable
BestEffort

These affect how Kubernetes treats Pods under resource pressure.

19. BestEffort#

If containers have:

No CPU requests
No CPU limits
No memory requests
No memory limits

the Pod can be classified as:

BestEffort

Example:

containers:
  - name: app
    image: nginx

No resources specified.

20. Burstable#

A Pod is generally Burstable when it has some resource requests/limits but doesn't meet the conditions for Guaranteed QoS.

Example:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
 
  limits:
    cpu: "1"
    memory: "1Gi"

Request and limit are different.

This is common for many applications.

21. Guaranteed#

A Pod is generally Guaranteed when every container has CPU and memory requests and limits specified, and for each resource:

request = limit

Example:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
 
  limits:
    cpu: "500m"
    memory: "512Mi"

for each container in the Pod.

22. QoS Summary#

                 QoS
                  │
       ┌──────────┼──────────┐
       │          │          │
 Guaranteed   Burstable   BestEffort
       │          │          │
 request=      Some         Nothing
 limit         resources    specified

Under node resource pressure, QoS affects eviction behavior, but don't think of QoS as a simple "priority" system. Actual eviction decisions also consider resource pressure and Pod-level signals such as priority.

23. ResourceQuota#

We briefly saw this in Chapter 8.

Now it makes more sense.

Suppose namespace:

development

should have a maximum:

CPU requests = 4
Memory requests = 8Gi
Pods = 20

You can use:

apiVersion: v1
kind: ResourceQuota
 
metadata:
  name: dev-quota
  namespace: development
 
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    pods: "20"

Now Kubernetes can enforce namespace-level resource consumption limits.

24. ResourceQuota vs Resource Limits#

Don't confuse them.

Container resource limit#

Pod/container level

Example:

Container max memory = 512Mi

ResourceQuota#

Namespace level

Example:

Namespace total memory requests <= 8Gi

Think:

Container
   ↓
resources.requests / limits
 
Namespace
   ↓
ResourceQuota

25. LimitRange#

A LimitRange can define defaults and constraints for resources inside a namespace.

Example:

apiVersion: v1
kind: LimitRange
 
metadata:
  name: default-limits
  namespace: development
 
spec:
  limits:
    - type: Container
      default:
        cpu: "500m"
        memory: "512Mi"
 
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"

Now if developers forget to specify resources, Kubernetes can apply configured defaults.

This is useful for enforcing consistency.

26. ResourceQuota + LimitRange#

A mature namespace can use both:

                  Namespace
                      │
          ┌───────────┴───────────┐
          │                       │
    ResourceQuota             LimitRange
          │                       │
   Total namespace          Per-container
      capacity               defaults/limits

Example:

Namespace
│
├── Maximum 20 Pods
├── Maximum 8Gi memory requests
│
└── Each container:
    default request = 128Mi
    default limit = 512Mi

27. How Scheduler Uses Requests#

This is worth understanding deeply.

Suppose:

Node A
CPU capacity = 4

Existing Pods request:

Pod 1 → 1 CPU
Pod 2 → 1 CPU
Pod 3 → 500m

Total:

2.5 CPU

New Pod requests:

1.5 CPU

Then:

2.5 + 1.5 = 4 CPU

It can potentially fit.

But if the new Pod requests:

2 CPU

then:

2.5 + 2 = 4.5 CPU

It doesn't fit on that node based on CPU requests.

The scheduler may try another node.

28. Pending Due to Insufficient Resources#

Imagine you deploy:

resources:
  requests:
    cpu: "8"
    memory: "32Gi"

but your cluster has no node capable of satisfying that request.

The Pod can remain:

Pending

Check:

kubectl get pods

Then:

kubectl describe pod <pod-name>

You might see an event such as:

Insufficient cpu

or:

Insufficient memory

This is a very common Kubernetes troubleshooting scenario.

29. Requests Are Not Guaranteed Actual Usage#

Suppose:

requests:
  cpu: "500m"

This does not mean your application continuously consumes exactly 500m CPU.

It means:

Kubernetes uses that value as the requested resource amount for scheduling and capacity management.

Actual usage could be:

100m
200m
450m

etc.

30. Why This Matters for HPA#

This becomes especially important in the next chapter.

Suppose HPA is configured based on CPU utilization.

It may calculate utilization relative to the container's CPU request.

For example:

CPU request = 250m
Actual usage = 200m

Utilization:

200 / 250 = 80%

So a good CPU request matters not only for scheduling but also for autoscaling behavior.

We'll cover HPA in Chapter 15.

31. Node Capacity vs Pod Requests#

Suppose:

Node:
4 CPU
8Gi memory

You might think:

Pod requests:
4 CPU
8Gi memory

means the Pod can definitely consume everything.

Not exactly.

Requests are used for scheduling; limits determine maximum usage at the container level.

Also, Kubernetes nodes need resources for system components and other overhead.

So actual allocatable capacity is not simply identical to the raw hardware capacity.

32. CPU Request Example for Node.js#

Suppose your Node.js API normally needs:

100–200m CPU

You might start with:

requests:
  cpu: "200m"

and allow bursts:

limits:
  cpu: "1"

So:

Normal reservation:
200m
 
Burst:
up to 1 CPU

But don't blindly copy these values into production.

You should measure actual workload behavior.

33. Memory Is More Dangerous#

Node.js applications can consume substantial memory depending on:

Traffic
Heap size
Caching
Large JSON processing
File processing
LLM workloads

For example:

requests:
  memory: "512Mi"
 
limits:
  memory: "1Gi"

If your application genuinely needs more than 1Gi under normal workload, setting the limit too low can cause:

OOMKilled

Therefore:

Resource limits should be based on observed application behavior, not arbitrary numbers.

34. Your AI Workloads#

This is especially relevant for AI workloads.

Suppose you eventually run a model-serving container:

LLM server

and it needs:

CPU
RAM
GPU

CPU/memory resource configuration alone isn't enough for GPUs.

Kubernetes supports GPU resources through device plugins and vendor integrations, with resources such as:

nvidia.com/gpu

For example, conceptually:

resources:
  limits:
    nvidia.com/gpu: 1

GPU scheduling is a more advanced topic, but remember:

Kubernetes can schedule specialized resources in addition to CPU and memory.

35. Debugging Resource Problems#

Check Pod resources#

kubectl describe pod <pod>

Check node resources#

kubectl describe node <node>

See resource usage#

If Metrics Server is installed:

kubectl top pods

and:

kubectl top nodes

Example:

NAME       CPU(cores)   MEMORY(bytes)
node-api   180m         220Mi

This shows current usage, not requests/limits.

36. kubectl top vs Requests#

Don't confuse:

kubectl top pods

with:

resources.requests

kubectl top:

Actual observed usage

Requests:

Declared scheduling requirement

Limits:

Declared maximum

So:

Usage ≠ Request ≠ Limit

This is an excellent interview concept.

37. A Production-Style Deployment#

Here's a reasonable example:

apiVersion: apps/v1
kind: Deployment
 
metadata:
  name: node-api
 
spec:
  replicas: 3
 
  selector:
    matchLabels:
      app: node-api
 
  template:
    metadata:
      labels:
        app: node-api
 
    spec:
      containers:
        - name: node-api
          image: my-node-api:1.0
 
          ports:
            - containerPort: 3000
 
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
 
            limits:
              cpu: "1"
              memory: "512Mi"

With three replicas, the scheduler considers approximately:

CPU requests:
3 × 250m = 750m
 
Memory requests:
3 × 256Mi = 768Mi

That's the requested capacity for the three containers, not necessarily their actual usage.

38. Common Mistakes#

❌ Mistake 1#

limits:
  memory: "128Mi"

for an application that normally requires 300Mi.

Result:

OOMKilled

❌ Mistake 2#

Huge requests:

requests:
  cpu: "8"

for a small application.

Result:

Pod may remain Pending

because Kubernetes cannot find a node with enough allocatable CPU.

❌ Mistake 3#

No requests/limits for production workloads.

This makes capacity planning and scheduling less predictable.

❌ Mistake 4#

Copying resource values from another application.

Your:

Node.js API

doesn't necessarily have the same requirements as:

PostgreSQL

or:

Next.js

Measure your workload.

39. Interview Questions#

Q1. What is a resource request?#

The amount of CPU or memory a container requests for scheduling and resource planning.

Q2. What is a resource limit?#

The maximum CPU or memory usage configured for a container.

Q3. What happens if CPU exceeds the limit?#

Generally, CPU usage can be throttled.

Q4. What happens if memory exceeds the limit?#

The container can be terminated with an out-of-memory condition, commonly observed as OOMKilled.

Q5. Does the scheduler use limits or requests?#

Primarily requests when deciding whether a Pod fits on a node.

Q6. What is BestEffort?#

A Pod with no CPU/memory requests or limits.

Q7. What is Burstable?#

A Pod that has some resource requests/limits but doesn't meet the Guaranteed QoS criteria.

Q8. What is Guaranteed?#

Generally, every container has CPU and memory requests and limits, with requests equal to limits for those resources.

Q9. What is ResourceQuota?#

A namespace-level mechanism for limiting aggregate resource consumption.

Q10. What is LimitRange?#

A namespace-level mechanism for defining default and/or minimum/maximum resource settings for containers or Pods.

🧠 Chapter 13 Cheat Sheet#

The four most important things:

REQUEST
   ↓
Used for scheduling
 
LIMIT
   ↓
Maximum configured usage
 
CPU
   ↓
Can be throttled
 
MEMORY
   ↓
Can result in OOMKilled

Remember:

Actual Usage
     ≠
Request
     ≠
Limit

And:

Pod
 │
 ├── requests → Scheduler
 │
 └── limits   → Runtime enforcement

🎯 Complete Kubernetes Picture#

You now have:

                       INTERNET
                           │
                           ▼
                       Ingress
                           │
                           ▼
                        Service
                           │
                    ┌──────┼──────┐
                    ▼      ▼      ▼
                   Pod    Pod    Pod
                    │
             ┌──────┴──────┐
             │             │
         ConfigMap       Secret
             │             │
             └──────┬──────┘
                    │
                 Container
                    │
              ┌─────┴─────┐
              │           │
            CPU         Memory
          Request       Request
          Limit         Limit

And if the application needs persistent data:

Container
    │
    ▼
   Volume
    │
    ▼
   PVC
    │
    ▼
   PV
    │
    ▼
Persistent Storage

Next → Chapter 14: Health Checks#

This chapter is extremely important for zero-downtime production systems.

You'll learn:

Liveness Probe
Readiness Probe
Startup Probe
HTTP Probe
TCP Probe
Command Probe
initialDelaySeconds
periodSeconds
timeoutSeconds
failureThreshold

And we'll answer the critical question:

How does Kubernetes know whether your Node.js application is alive, ready to receive traffic, or still starting?