Review Kubernetes container CPU requests

Description

Kubernetes uses CPU requests for node placement and allocation under CPU contention. Requests below actual needs can place too many workloads on the same node and increase latency. A request is not a CPU cap; a container can use more when capacity is available.

LimitRange can provide default requests. If only a CPU limit is specified and no separate default applies, that limit is used as the request. Check the effective requests on deployed Pods.

Potential impact

• Underestimated CPU needs can cause node contention and reduced performance.
• Excessive requests can increase required capacity or prevent Pods from being scheduled.

Remediation

• Set resources.requests.cpu according to measured usage and latency requirements, and test normal and peak load.
• Check LimitRange defaults, the effective CPU limit and actual Pod requests. The example value of 250m is not suitable for every workload.

Examples

Replace the image address with an actual verified image. These examples make the request explicit while retaining a 500m CPU limit. Without another default, the original request is also 500m.

Before

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

No CPU request is explicit, but the 500m limit can become the request.

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"

The CPU request is explicitly 250m. This can reduce the previous effective request, so verify the workload’s needs.

References

• CWE-400
• Kubernetes reference documentation