Min and max constraints — bounding what containers can request

Min and max constraints in LimitRange bound what containers can request. This lesson walks the constraints, the admission behaviour, the overcommit ratio, and the discipline.

The min and max fields

apiVersion: v1
kind: LimitRange
metadata:
  name: container-limits
  namespace: tenant-a-prod
spec:
  limits:
    - type: Container
      default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      max:
        cpu: 2
        memory: 4Gi
      min:
        cpu: 50m
        memory: 64Mi
      maxLimitRequestRatio:
        cpu: "4"
        memory: "2"

The constraint fields:

• max. Maximum limits a container can specify. A container requesting 4 cores would be rejected if max is 2.
• min. Minimum requests a container must specify. A container requesting 10m CPU would be rejected if min is 50m.
• maxLimitRequestRatio. Maximum ratio of limit to request. A container with limit=4 and request=10m (ratio 400x) would be rejected if maxLimitRequestRatio is 4.

The admission behaviour

flowchart LR
    A[Pod creation request] --> B{Container within min?}
    B -->|No| C["Rejected: below min"]
    B -->|Yes| D{Container within max?}
    D -->|No| E["Rejected: above max"]
    D -->|Yes| F{ratio within maxLimitRequestRatio?}
    F -->|No| G["Rejected: ratio exceeded"]
    F -->|Yes| H[Accepted]

The admission sequence:

1. Each container’s requests are checked against min. Below min → rejected.
2. Each container’s limits are checked against max. Above max → rejected.
3. The ratio of limit to request is checked against maxLimitRequestRatio. Above → rejected.
4. If all checks pass, the Pod is accepted.

The overcommit ratio

flowchart LR
    A[Container] --> B["Request: 100m"]
    A --> C["Limit: 500m"]
    B --> D["Ratio: 5x"]
    D --> E{maxLimitRequestRatio: 4}
    E -->|5 > 4| F[Rejected]
    E -->|4x ratio| G[Accepted]

The ratio prevents extreme overcommit. A container with limit=4 cores and request=10m (ratio 400x) is allowed to burst to 4 cores but reserves almost nothing. The scheduler would overpack the node, and the container would frequently throttle.

A maxLimitRequestRatio of 4 (or 2 for memory) prevents this extreme case.

The min field

min:
  cpu: 50m
  memory: 64Mi

The min field ensures every container declares some resources. A Pod with resources.requests: {} would have zero requests and be invisible to the scheduler (and the quota).

The min field is applied as the floor for any declared request. A container with requests.cpu: 10m would be rejected if min is 50m.

The max field

max:
  cpu: 2
  memory: 4Gi

The max field prevents one container from consuming the entire namespace quota. A 64-core container in a 32-core namespace quota would fail at admission (the quota is checked too).

The max is a per-container limit. A namespace with 10 containers, each at 2 cores, would be within a 20-core quota.

The maxLimitRequestRatio

maxLimitRequestRatio:
  cpu: "4"
  memory: "2"

The ratio is per resource. CPU can typically be overcommitted more aggressively than memory (CPU throttling is graceful; memory OOM is fatal).

A typical configuration:

• CPU: 4. A container with limit=2 cores can have request as low as 500m (4x ratio).
• Memory: 2. A container with limit=2Gi can have request as low as 1Gi (2x ratio).

Quiz

The operational discipline

Min and max constraints in production rest on five non-negotiable elements:

• Set max for every resource. Prevent monopolisation.
• Set min to ensure declarations. Pods without requests are invisible.
• Set maxLimitRequestRatio. Prevent extreme overcommit.
• Tune based on workload characteristics. Memory-constrained workloads need tighter memory ratios.
• Test the constraints. Quarterly: create a Pod that exceeds max; verify rejection.

Constraints are the guardrails. Without them, a single workload can disrupt the entire namespace.