Limit ranges for defaults in Kubernetes - Commands & Configuration

Introduction

Sometimes containers in Kubernetes use too much or too little CPU and memory. Limit ranges let you set default resource limits and requests so containers have balanced resources without manual setup.

When you want every container in a namespace to have a default CPU and memory limit to avoid resource hogging.

When you want to ensure containers request a minimum amount of CPU and memory to run properly.

When you want to prevent users from accidentally creating containers that use too many resources.

When you want to enforce consistent resource usage policies across all pods in a namespace.

When you want to avoid pods being killed or throttled because they exceed cluster resource limits.

Config File - limitrange.yaml

limitrange.yaml

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

This file creates a LimitRange named default-limits in the example-namespace.

The default section sets default CPU and memory limits for containers that do not specify them.

The defaultRequest section sets default CPU and memory requests, which is the minimum guaranteed resource.

The type: Container means these limits apply to individual containers inside pods.

Commands

This command creates the LimitRange resource in the example-namespace to set default CPU and memory limits and requests for containers.

Terminal

kubectl apply -f limitrange.yaml

Expected Output

limitrange/default-limits created

This command lists all LimitRanges in the example-namespace to verify that the default limits were created.

Terminal

kubectl get limitrange -n example-namespace

Expected Output

NAME             CREATED AT

default-limits   2024-06-01T12:00:00Z

→

-n - Specifies the namespace to look in

This command generates a pod manifest named test-pod.yaml in example-namespace without creating it, so you can inspect resource defaults applied by LimitRange.

Terminal

kubectl run test-pod --image=nginx --restart=Never -n example-namespace --dry-run=client -o yaml > test-pod.yaml

Expected Output

No output (command runs silently)

→

--dry-run=client - Generates the manifest without creating the pod

→

-o yaml - Outputs the manifest in YAML format

This command creates the test-pod in example-namespace. Since the pod does not specify resources, the LimitRange defaults apply automatically.

Terminal

kubectl apply -f test-pod.yaml

Expected Output

pod/test-pod created

This command shows detailed information about test-pod, including the CPU and memory limits and requests applied by the LimitRange.

Terminal

kubectl describe pod test-pod -n example-namespace

Expected Output

Name:         test-pod

Namespace:    example-namespace

Containers:

  nginx:

    Image:      nginx

    Limits:

      cpu:     500m

      memory:  256Mi

    Requests:

      cpu:     250m

      memory:  128Mi

Status:       Pending

→

-n - Specifies the namespace of the pod

Key Concept

If you remember nothing else from this pattern, remember: LimitRanges set default resource limits and requests so containers have balanced CPU and memory without manual setup.

Common Mistakes

Not specifying the namespace when applying or checking LimitRanges.

LimitRanges are namespace-scoped, so commands without the correct namespace won't find or apply them.

Always use the -n flag with the correct namespace when working with LimitRanges.

Expecting LimitRanges to apply to pods that already specify resource limits.

LimitRanges only apply defaults when containers do not specify resource requests or limits.

Set resource requests and limits in pod specs if you want to override LimitRange defaults.

Creating LimitRanges without the type: Container field.

Without specifying type, the LimitRange may not apply to containers as expected.

Always include type: Container to apply limits to container resources.

Summary

Create a LimitRange resource to set default CPU and memory limits and requests for containers in a namespace.

Apply the LimitRange with kubectl apply and verify it exists with kubectl get limitrange.

Create pods without resource specs to see LimitRange defaults applied automatically.

Use kubectl describe pod to confirm the resource limits and requests on containers.

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