Limit ranges for defaults in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Default CPU limit from LimitRange

Given this LimitRange YAML applied in a namespace, what is the default CPU limit for a pod container without explicit limits?

Kubernetes

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-limit-range
spec:
  limits:
  - default:
      cpu: 500m
    defaultRequest:
      cpu: 250m
    type: Container

A 500m

B 250m

C No default CPU limit is set

D 1000m

💡 Hint

Look at the 'default' field under 'limits' for CPU.

The 'default' field under 'limits' sets the default CPU limit applied to containers without explicit limits. Here it is 500m (0.5 CPU).

❓ Configuration

intermediate

Set default memory request and limit

Which YAML snippet correctly sets a default memory request of 128Mi and a default memory limit of 256Mi for containers in a namespace?

A

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

B

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

C

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

D

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

💡 Hint

Remember defaultRequest is the minimum guaranteed, default is the max limit.

Option D correctly sets defaultRequest to 128Mi and default to 256Mi for containers. The type must be 'Container' to apply to container resources.

❓ Troubleshoot

advanced

Pod creation fails due to LimitRange defaults

A pod without resource limits fails to create in a namespace with this LimitRange: apiVersion: v1 kind: LimitRange metadata: name: limit-range spec: limits: - default: cpu: 200m memory: 256Mi max: cpu: 100m memory: 128Mi type: Container What is the reason for the failure?

A The default max CPU and memory exceed the max allowed, causing a conflict.

B The pod lacks explicit resource requests, which are mandatory despite defaults.

C The LimitRange type should be 'Pod' not 'Container'.

D The default values are lower than the minimum required, causing rejection.

💡 Hint

Check if default values are within max limits.

The default CPU (200m) and memory (256Mi) exceed the max CPU (100m) and max memory (128Mi), causing the pod creation to fail due to invalid resource limits.

🔀 Workflow

advanced

Applying LimitRange to enforce defaults

You want to enforce default CPU and memory limits on all containers in a namespace without requiring users to specify them. Which workflow step is correct?

A Modify the pod spec to include default resource limits in the cluster configuration file.

B Create a LimitRange with 'default' values for CPU and memory, then apply it to the namespace with kubectl apply.

C Use a PodSecurityPolicy to enforce default CPU and memory limits.

D Set resource quotas with default CPU and memory limits in the namespace.

💡 Hint

LimitRange is designed to set default resource limits.

LimitRange objects define default resource requests and limits for containers in a namespace. Applying a LimitRange with default values enforces these defaults automatically.

✅ Best Practice

expert

Best practice for setting LimitRange defaults

Which is the best practice when setting default resource limits in a LimitRange to avoid pod failures and resource starvation?

A Set default limits very high to avoid pod failures due to limit exceeded errors.

B Set default requests equal to default limits to prevent any resource bursting.

C Set default requests lower than expected usage and default limits slightly above typical usage to allow burst.

D Do not set default requests or limits; let users specify all resource values explicitly.

💡 Hint

Think about balancing resource guarantees and flexibility.

Setting default requests lower than expected usage ensures pods get guaranteed resources without overcommitting, while default limits slightly above typical usage allow pods to burst when needed without causing failures.