# kubectl set resources: Usage, Options & Common CI Errors

> kubectl set resources patches CPU and memory requests and limits on a workload. Right-sizing in CI, the unschedulable-Pending trap, and LimitRange conflicts.

Source: https://latchkey.dev/learn/command-reference/kubectl-set-resources  
Updated: 2026-06-25

Adjust CPU and memory requests and limits without editing YAML.

kubectl set resources patches the requests and limits on a container, triggering a rolling update. It is used in CI to right-size a workload or to bump limits before a load test.

## What it does

kubectl set resources deploy/NAME --requests=cpu=200m,memory=256Mi --limits=cpu=500m,memory=512Mi patches the container's resource block. -c selects a container; --limits and --requests can be set independently. CPU is in cores or millicores (500m), memory in Ki/Mi/Gi.

## Common usage

```Terminal
kubectl set resources deploy/web -c=web --limits=cpu=500m,memory=512Mi
kubectl set resources deploy/web --requests=cpu=200m,memory=256Mi
kubectl set resources deploy/web -c=web \
  --requests=cpu=200m,memory=256Mi --limits=cpu=1,memory=1Gi
```

## Common errors in CI

The classic trap is requesting more than any node can offer: the new pods sit Pending with "0/N nodes are available: N Insufficient cpu/memory" and the rollout stalls until its deadline - describe the pod to see it, and lower the request or add capacity. A namespace LimitRange or ResourceQuota can reject the patch outright ("must be less than or equal to ...max" or "exceeded quota"). Setting a memory limit below actual usage gets the container OOMKilled on the next spike. Always follow set resources with kubectl rollout status so a bad sizing fails the deploy.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl set resources: Usage, Options & Common CI Errors?

kubectl set resources patches the requests and limits on a container, triggering a rolling update. It is used in CI to right-size a workload or to bump limits before a load test.

### What it does?

kubectl set resources deploy/NAME --requests=cpu=200m,memory=256Mi --limits=cpu=500m,memory=512Mi patches the container's resource block. -c selects a container; --limits and --requests can be set independently. CPU is in cores or millicores (500m), memory in Ki/Mi/Gi.

### Common errors in CI?

The classic trap is requesting more than any node can offer: the new pods sit Pending with "0/N nodes are available: N Insufficient cpu/memory" and the rollout stalls until its deadline - describe the pod to see it, and lower the request or add capacity.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt