kubectl set resources: Usage, Options & Common CI Errors
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
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=1GiCommon 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.
# 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