Memory requests and limits in Kubernetes - Time & Space Complexity
We want to understand how the time to schedule and run pods changes as we increase memory requests and limits in Kubernetes.
How does setting memory requests and limits affect the system's work as more pods are added?
Analyze the time complexity of the following Kubernetes pod spec snippet.
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: nginx
resources:
requests:
memory: "256Mi"
limits:
memory: "512Mi"
This snippet sets memory requests and limits for a container inside a pod, guiding how the scheduler allocates resources.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The Kubernetes scheduler checks each pod's memory requests against available nodes.
- How many times: For each pod, the scheduler compares memory requests with nodes, repeating this for all pods and nodes.
As the number of pods increases, the scheduler must check more memory requests against nodes.
| Input Size (n pods) | Approx. Operations (pod-node checks) |
|---|---|
| 10 | ~10 x number_of_nodes |
| 100 | ~100 x number_of_nodes |
| 1000 | ~1000 x number_of_nodes |
Pattern observation: The work grows linearly with the number of pods, as each pod's memory request is checked against nodes.
Time Complexity: O(n)
This means the scheduling time grows roughly in direct proportion to the number of pods requesting memory.
[X] Wrong: "Setting higher memory limits makes scheduling time grow exponentially."
[OK] Correct: The scheduler checks requests linearly per pod; limits affect runtime but not the scheduling checks count.
Understanding how resource requests affect scheduling helps you explain system behavior clearly and shows you grasp how Kubernetes manages resources efficiently.
"What if we added node selectors to pods? How would that change the time complexity of scheduling with memory requests?"
Practice
memory request specify in a Kubernetes pod configuration?Solution
Step 1: Understand memory request meaning
Memory request is the minimum memory Kubernetes guarantees to a container so it can run without being killed due to lack of memory.Step 2: Differentiate from memory limit
Memory limit is the max memory allowed, not the minimum guaranteed.Final Answer:
The minimum amount of memory guaranteed for the container -> Option DQuick Check:
Memory request = minimum guaranteed memory [OK]
- Confusing memory request with memory limit
- Thinking request is the max memory
- Assuming request is current usage
Solution
Step 1: Recall correct YAML structure for resources
In Kubernetes, memory requests and limits are underresources.requests.memoryandresources.limits.memorywith values as strings including units like "Mi".Step 2: Check each option for syntax correctness
resources: requests: memory: "256Mi" limits: memory: "512Mi" matches the correct syntax. Options A, B, and C use wrong keys or structure.Final Answer:
resources: requests: memory: "256Mi" limits: memory: "512Mi" -> Option AQuick Check:
Correct YAML keys and units = resources: requests: memory: "256Mi" limits: memory: "512Mi" [OK]
- Using wrong keys like 'mem' or 'memory' outside resources
- Omitting quotes or units for memory values
- Swapping 'request' and 'requests'
resources:
requests:
memory: "128Mi"
limits:
memory: "256Mi"
What happens if the container tries to use 300Mi of memory?Solution
Step 1: Understand memory limit enforcement
Memory limit is the maximum memory a container can use. If it exceeds this, Kubernetes kills the container.Step 2: Apply to given values
The limit is 256Mi. Using 300Mi exceeds this limit, so the container will be terminated.Final Answer:
The container is killed by Kubernetes for exceeding the memory limit -> Option CQuick Check:
Memory usage > limit = container killed [OK]
- Thinking container is throttled instead of killed
- Confusing requests with limits
- Assuming container can burst beyond limit safely
Solution
Step 1: Recall relationship between requests and limits
Memory requests must be less than or equal to memory limits. Requests are minimum guaranteed, limits are max allowed.Step 2: Analyze given values
Requests = 512Mi, Limits = 256Mi. Requests are higher than limits, which is invalid and causes an error.Final Answer:
Memory requests cannot be higher than memory limits -> Option BQuick Check:
Requests ≤ Limits rule violated [OK]
- Setting requests higher than limits
- Assuming limits can be lower than requests
- Thinking requests and limits can be any values
Solution
Step 1: Identify minimum guaranteed memory
Minimum memory guaranteed is set by requests.memory, so set it to 200Mi.Step 2: Identify maximum allowed memory
Maximum memory allowed is set by limits.memory, so set it to 400Mi.Step 3: Verify correct order
Requests must be ≤ limits, so 200Mi ≤ 400Mi is valid.Final Answer:
requests.memory: "200Mi" and limits.memory: "400Mi" -> Option AQuick Check:
Requests = 200Mi, Limits = 400Mi [OK]
- Swapping requests and limits values
- Setting only requests or only limits
- Setting requests higher than limits
Ready to prove it?
Pass the test and this pattern moves unknown
