Yes. Set CPU and memory requests and limits on every CI job pod. Limits stop a runaway build, or a hijacked job mining or flooding, from starving other jobs and nodes. They also make job cost and capacity predictable, which matters once many ephemeral pods start at the same time.
How Kubernetes enforces them
The Kubernetes documentation explains the difference. A CPU limit is a hard limit enforced by the kernel through throttling: a container cannot use more CPU than its limit. A memory limit is enforced reactively by out of memory kills. If a container uses more memory than its limit, the kernel may terminate it, but only when it detects memory pressure, so a container can briefly exceed the limit before it is killed.
Requests are what the scheduler reserves. If you set a limit but no request, and nothing applies a default request, Kubernetes uses the limit as the request.
Why CI needs this more than most workloads
Job pods run code you did not write: dependencies, test scripts, pull request changes. Even without malice, a bad test can eat all memory on a shared node. With malice, an abused job can burn compute. On a monolith, one agent was a natural boundary. In a shared cluster, the pod limit is the boundary.
Setting reasonable values
- Measure a sample of real jobs. Record peak memory and typical CPU for each pipeline type.
- Set the memory request near typical peak and the limit with some headroom. Avoid limits so tight that normal builds are killed.
- Set a CPU limit that lets builds finish in acceptable time while capping a runaway.
- Use a few size classes, such as small, medium and large, and let pipelines pick one instead of inventing their own.
- Apply a namespace level default and a maximum so a pod with no values cannot be unbounded.
- Pair limits with a job timeout so a stuck job is ended, not just throttled. See CI job timeouts stop runaway and hijacked jobs.
What limits do not do
Limits do not stop data theft or network abuse. They are one control in a set that also includes network policy, short-lived credentials and a locked down service account. A pod that stays under its limits can still read a secret you mounted.
Reading failures correctly
An out of memory kill in CI looks like a mysterious job failure. Teach people to check for it before assuming flakiness, and alert on a spike in kills, since a sudden change can mean a dependency update or a hijacked job.
Quick check
Do limits matter if my cluster is dedicated to CI?
Yes. Jobs from different teams and trust levels still compete, and a runaway job can slow every pipeline.
Should the memory limit equal the request?
It can. Equal values give more predictable scheduling. Leaving headroom between them allows bursts but risks node pressure.
Sources
Last reviewed: 19 October 2026.
