Review container CPU requests

Description

CPU requests guide Kubernetes scheduling and CPU allocation under contention. Requests below actual needs can place too many workloads on the same node and increase latency. A request is not a usage ceiling; a container can use additional CPU when capacity is available.

LimitRange can supply a default request. If only a CPU limit is specified and no other default applies, that limit is used as the request. Inspect the effective request on deployed pods.

Potential impact

Underestimating CPU needs can cause node contention and performance degradation.
Excessive requests can increase required node capacity or prevent scheduling.

Remediation

Set resources.requests.cpu according to observed CPU use and latency requirements, and test normal and peak load.
Check LimitRange defaults and the effective CPU limit together with the deployed pod’s request. The example 250m value is not appropriate for every workload.

Examples

These existing examples keep a CPU limit of 0.5 while making the request explicit. Without another default, the before request is also 0.5. Use a maintained image for deployment.

Before

hcl

resource "kubernetes_pod" "pod" {
  metadata {
    name = "terraform-example"
  }

  spec {
    container {
      image = "nginx:1.7.9"
      name  = "example"

      resources {
        limits = {
          cpu    = "0.5"
          memory = "512Mi"
        }
      }
    }
  }
}

After

hcl

resource "kubernetes_pod" "pod" {
  metadata {
    name = "terraform-example"
  }

  spec {
    container {
      image = "nginx:1.7.9"
      name  = "example"

      resources {
        limits = {
          cpu    = "0.5"
          memory = "512Mi"
        }

        requests = {
          cpu    = "250m"
          memory = "50Mi"
        }
      }
    }
  }
}

Explanation:

Before: No request is explicit, but the 0.5 CPU limit can supply the request.
After: The CPU request is explicitly 250m. This can lower the previous effective request, so verify actual needs.