Review Kubernetes container CPU limits

Description

Without an effective CPU limit, a container can use spare CPU on the node. This can support bursts, but contention and predictable performance still need consideration. CPU requests guide scheduling and allocation under contention; they are different from limits.

A CPU limit can cause throttling at the cap. Choose limits according to performance requirements and resource policy rather than applying the same cap to every workload.

Potential impact

• Uncontrolled CPU contention can increase latency for other workloads.
• An overly low CPU limit can delay legitimate work and increase timeouts.

Remediation

• Set resources.limits.cpu where a cap is required and review it together with the request and actual usage.
• Check LimitRange defaults and effective values, and measure throttling and latency under normal and peak load. Maintain appropriate requests and capacity planning even when no CPU cap is used.

Examples

The image address and resource values are illustrative. Use an available, verified image and values suited to the workload.

Before

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
    - name: app
      image: images.my-company.example/app:v4
      resources:
        limits:
          memory: "64Mi"

Only a memory limit is explicit. Without a separate CPU default, the container can use spare CPU.

After

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
    - name: app
      image: images.my-company.example/app:v4
      resources:
        requests:
          cpu: "250m"
          memory: "64Mi"
        limits:
          cpu: "500m"
          memory: "128Mi"

A CPU request of 250m and limit of 500m are specified. Throttling can occur at the limit.

References

• CWE-400
• Kubernetes reference documentation