Limit ranges for defaults in Kubernetes - Step-by-Step Execution

Process Flow - Limit ranges for defaults

Create LimitRange YAML

↓

Apply LimitRange to Namespace

↓

Pod Created without resource requests

↓

Kubernetes applies default limits

↓

Pod runs with default CPU and Memory limits

This flow shows how Kubernetes applies default resource limits to pods when no explicit requests or limits are set.

Execution Sample

Kubernetes

apiVersion: v1
kind: LimitRange
metadata:
  name: limits
spec:
  limits:
  - default:
      cpu: 500m
      memory: 256Mi
    defaultRequest:
      cpu: 250m
      memory: 128Mi
    type: Container

This YAML defines default CPU and memory limits and requests for containers in a namespace.

Process Table

Step	Action	Pod Resource Spec	Kubernetes Default Applied	Resulting Pod Resources
1	Create LimitRange object	None	N/A	LimitRange with default CPU=500m, Memory=256Mi set
2	Apply LimitRange to namespace	None	N/A	Namespace now has default limits configured
3	Create Pod without resource requests/limits	CPU=None, Memory=None	CPU=250m (request), Memory=128Mi (request), CPU=500m (limit), Memory=256Mi (limit)	Pod containers get CPU=250m request, Memory=128Mi request, CPU=500m limit, Memory=256Mi limit
4	Pod runs	CPU=250m request, Memory=128Mi request, CPU=500m limit, Memory=256Mi limit	N/A	Pod runs with default resource limits
5	Create Pod with explicit limits	CPU=100m, Memory=64Mi	No default applied	Pod uses explicit CPU=100m, Memory=64Mi

💡 Execution stops after pod creation and resource assignment; defaults only apply if pod lacks explicit resource specs.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 5
LimitRange	None	Created with defaults	Applied to namespace	No change	No change
Pod CPU	None	None	None	250m (request), 500m (limit) (default applied)	100m (explicit)
Pod Memory	None	None	None	128Mi (request), 256Mi (limit) (default applied)	64Mi (explicit)

Key Moments - 2 Insights

Why does Kubernetes apply default limits only when pod resource limits are missing?

As shown in execution_table step 3 and 5, Kubernetes applies defaults only if the pod does not specify CPU or memory limits. If explicit values exist (step 5), defaults are ignored.

What happens if LimitRange is not created in the namespace?

Without a LimitRange (before step 1), Kubernetes does not apply any default resource limits, so pods run without resource constraints.

Visual Quiz - 3 Questions

Look at the execution_table at step 3, what CPU limit is applied to the pod?

A 500m

B 250m

C 100m

D None

💡 Hint

Check the 'Kubernetes Default Applied' and 'Resulting Pod Resources' columns at step 3.

At which step does the pod run with explicit CPU and memory limits?

A Step 2

B Step 3

C Step 5

D Step 4

💡 Hint

Look for the row where 'Pod Resource Spec' shows explicit CPU=100m and Memory=64Mi.

If the LimitRange was not applied, what would be the pod's CPU limit at step 3?

A 500m

B None

C 250m

D 100m

💡 Hint

Refer to the 'LimitRange' variable in variable_tracker before step 1 and step 3.

Concept Snapshot

LimitRange sets default CPU and memory limits for containers in a namespace.
If a pod does not specify resource requests or limits, Kubernetes applies these defaults.
Explicit pod resource specs override LimitRange defaults.
Create and apply LimitRange YAML in the target namespace to enforce defaults.
Defaults help prevent resource overuse and improve cluster stability.

Full Transcript

This visual execution shows how Kubernetes LimitRange objects provide default CPU and memory limits for pods. First, a LimitRange YAML is created with default and defaultRequest values. When applied to a namespace, any pod created without explicit resource requests or limits receives these defaults automatically. The execution table traces pod creation steps, showing when defaults apply and when explicit pod specs override them. Variables track LimitRange existence and pod resource values over time. Key moments clarify why defaults only apply if pod specs are missing and what happens without a LimitRange. The quiz tests understanding of default application and pod resource assignment. This helps beginners see how Kubernetes manages resource limits visually and practically.

Practice

1. What is the main purpose of a LimitRange in a Kubernetes namespace?

easy

A. To schedule pods on specific nodes

B. To set default and maximum resource limits for containers in that namespace

C. To create network policies for pods

D. To manage persistent storage volumes

Solution

1. Step 1: Understand LimitRange role

   A LimitRange defines default, minimum, and maximum resource limits for containers in a namespace.

2. Step 2: Compare with other options

   Network policies, scheduling, and storage are managed by other Kubernetes resources, not LimitRange.

3. Final Answer:

   To set default and maximum resource limits for containers in that namespace -> Option B

4. Quick Check:

   LimitRange controls resource limits = C [OK]

Hint: LimitRange controls resource limits, not networking or storage [OK]

Common Mistakes:

• Confusing LimitRange with NetworkPolicy
• Thinking LimitRange schedules pods
• Assuming LimitRange manages storage

2. Which of the following is the correct YAML snippet to set a default CPU request of 100m using a LimitRange?

easy

A. apiVersion: v1\nkind: LimitRange\nmetadata:\n name: cpu-default\nspec:\n limits:\n - default:\n cpu: 100m\n type: Container

B. apiVersion: v1\nkind: LimitRange\nmetadata:\n name: cpu-default\nspec:\n limits:\n - defaultRequest:\n cpu: 100m\n type: Container

C. apiVersion: v1\nkind: LimitRange\nmetadata:\n name: cpu-default\nspec:\n limits:\n - defaultLimit:\n cpu: 100m\n type: Container

D. apiVersion: v1\nkind: LimitRange\nmetadata:\n name: cpu-default\nspec:\n limits:\n - defaultCpu:\n cpu: 100m\n type: Container

Solution

1. Step 1: Check LimitRange syntax for default

   The correct key to set default resource requests or limits is default under limits.

2. Step 2: Validate the YAML snippet

   apiVersion: v1\nkind: LimitRange\nmetadata:\n name: cpu-default\nspec:\n limits:\n - default:\n cpu: 100m\n type: Container uses default: with cpu: 100m correctly under limits and type: Container.

3. Final Answer:

   Option A is the correct YAML snippet -> Option A

4. Quick Check:

   Use default key for defaults in LimitRange [OK]

Hint: Use 'default' key under limits to set default resources [OK]

Common Mistakes:

• Using incorrect keys like defaultRequest or defaultLimit
• Misplacing keys outside limits array
• Wrong indentation in YAML

3. Given this LimitRange YAML applied in a namespace:

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-default
spec:
  limits:
  - default:
      memory: 256Mi
    type: Container

What will be the memory request for a container without any memory request specified?

medium

A. No memory request will be set

B. Pod creation will fail due to missing memory request

C. Memory request will be unlimited

D. 256Mi memory request will be applied by default

Solution

1. Step 1: Understand default in LimitRange

   The default memory value sets the memory request if the container does not specify one.

2. Step 2: Apply to container without memory request

   Since the container has no memory request, Kubernetes applies the default 256Mi memory request from LimitRange.

3. Final Answer:

   256Mi memory request will be applied by default -> Option D

4. Quick Check:

   Default resource applies if container omits it [OK]

Hint: Default applies only if container omits resource request [OK]

Common Mistakes:

• Assuming no default means no request
• Thinking pod creation fails without explicit request
• Confusing default with max or min limits

4. You applied this LimitRange YAML:

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-limit
spec:
  limits:
  - max:
      cpu: 500m
    type: Container

Your pod container requests 600m CPU. What will happen?

medium

A. Pod will be created with 600m CPU request

B. Pod will ignore LimitRange and use 600m CPU

C. Pod creation will fail due to exceeding max CPU limit

D. Pod CPU request will be automatically reduced to 500m

Solution

1. Step 1: Understand max limit enforcement

   LimitRange max limits set the maximum allowed resource request or limit for containers.

2. Step 2: Check pod CPU request against max

   The pod requests 600m CPU, which exceeds the max 500m CPU set by LimitRange.

3. Step 3: Kubernetes behavior on violation

   Kubernetes rejects pod creation if resource requests exceed LimitRange max limits.

4. Final Answer:

   Pod creation will fail due to exceeding max CPU limit -> Option C

5. Quick Check:

   Exceeding max limit causes pod creation failure [OK]

Hint: Requests above max limit cause pod creation failure [OK]

Common Mistakes:

• Assuming Kubernetes auto-adjusts resource requests
• Thinking pod ignores LimitRange max limits
• Confusing max limit with default value

5. You want all containers in a namespace to have a default CPU request of 200m and a default memory request of 512Mi, but also want to ensure no container can request more than 1 CPU or 1Gi memory. Which LimitRange YAML snippet correctly enforces this?

hard

A. apiVersion: v1\nkind: LimitRange\nmetadata:\n name: resource-limits\nspec:\n limits:\n - default:\n cpu: 200m\n memory: 512Mi\n max:\n cpu: 1\n memory: 1Gi\n type: Container

B. apiVersion: v1\nkind: LimitRange\nmetadata:\n name: resource-limits\nspec:\n limits:\n - defaultRequest:\n cpu: 200m\n memory: 512Mi\n maxLimit:\n cpu: 1\n memory: 1Gi\n type: Container

C. apiVersion: v1\nkind: LimitRange\nmetadata:\n name: resource-limits\nspec:\n limits:\n - defaultCpu:\n cpu: 200m\n memory: 512Mi\n maxCpu:\n cpu: 1\n memory: 1Gi\n type: Container

D. apiVersion: v1\nkind: LimitRange\nmetadata:\n name: resource-limits\nspec:\n limits:\n - default:\n cpu: 200m\n memory: 512Mi\n maxRequest:\n cpu: 1\n memory: 1Gi\n type: Container

Solution

1. Step 1: Identify correct keys for defaults and max

   The correct keys are default for default requests and max for maximum allowed resources under limits.

2. Step 2: Validate YAML structure

   apiVersion: v1\nkind: LimitRange\nmetadata:\n name: resource-limits\nspec:\n limits:\n - default:\n cpu: 200m\n memory: 512Mi\n max:\n cpu: 1\n memory: 1Gi\n type: Container correctly uses default and max keys with proper resource names and type: Container.

3. Step 3: Check other options for invalid keys

   Options B, C, and D use invalid keys like defaultRequest, maxLimit, defaultCpu, or maxRequest which are not valid in LimitRange spec.

4. Final Answer:

   Option A correctly enforces default and max resource limits -> Option A

5. Quick Check:

   Use 'default' and 'max' keys for defaults and max limits [OK]

Hint: Use 'default' and 'max' keys under limits for defaults and max limits [OK]

Common Mistakes:

• Using invalid keys like defaultRequest or maxLimit
• Mixing up default and max keys
• Incorrect YAML indentation or structure