CPU and memory for workers and Jobs
Plan agent requests and limits, optional database-container resources, and BestEffort restore Jobs.
Loading documentation…
Powered by heyo
A project worker uses one long-running agent Pod and creates a separate restore Job for each check. They have different resource settings. Max parallel jobs limits how many checks a worker can run at once; it does not reserve CPU or memory for those Jobs.
The generated agent Deployment always contains CPU, memory, and ephemeral-storage requests and limits. RestoreTrust chooses a profile from Max parallel jobs:
| Max parallel jobs | CPU request / limit | Memory request / limit | Ephemeral-storage request / limit |
|---|---|---|---|
| 1 | 150m / 400m | 192Mi / 384Mi | 256Mi / 512Mi |
| 2–4 | 400m / 1000m | 384Mi / 768Mi | 512Mi / 1Gi |
| 5–16 | 1200m / 3000m | 1Gi / 2Gi | 1Gi / 2Gi |
| 17–64 | 4000m / 8000m | 3Gi / 6Gi | 2Gi / 4Gi |
These values are for the agent, not a shared pool for restore Jobs. When you change Max parallel jobs, save the worker record and apply its newly generated Agent deployment patch so the stored and advertised capacities match. The profile is selected by range: changing from two to four parallel Jobs keeps the same agent profile, but still requires enough cluster capacity for two additional restore Jobs and scratch volumes.
By default, RestoreTrust sets no CPU or memory requests or limits on any restore-Job container. Without cluster admission defaults, Kubernetes then gives the Pod BestEffort quality of service. It does not reserve CPU or memory for the restore and can evict the Pod early under node pressure. There is no separate BestEffort switch: leaving all four database-resource fields empty keeps this behavior. File checks do not offer database-resource fields. A namespace LimitRange can add defaults, so inspect the actual Pod if its quality-of-service class matters to you.
For a database schedule, set any of these fields under Database container resources when creating the schedule or on its Project worker tab:
| Field | What Kubernetes uses it for | Allowed value |
|---|---|---|
| CPU request | CPU considered when placing the Pod | Whole millicores, 1–1,000,000; 1000m is one CPU |
| CPU limit | Upper CPU usage of the database container | Whole millicores, 1–1,000,000 |
| Memory request | Memory considered when placing the Pod | Whole MiB, 1–16,777,216 |
| Memory limit | Upper memory usage of the database container | Whole MiB, 1–16,777,216 |
All four are independent and optional. RestoreTrust does not infer a request, limit, or default from another field or from the worker. A request cannot exceed the corresponding limit. If you provide a limit without a request, Kubernetes itself uses that limit as the request. Only the temporary database container, which imports the dump and answers health probes, receives these values. Download and validator containers remain without CPU or memory requests or limits. With database resources set, the Pod normally has Burstable quality of service: the other containers do not have matching requests and limits, so the Pod is not Guaranteed.
For example, a CPU request of 500 and limit of 2000, plus a memory request of 2048 and limit of 4096, asks Kubernetes to place the database container with 0.5 CPU and 2 GiB available, and caps it at 2 CPUs and 4 GiB. These settings do not tune the database process itself. Leave fields empty to avoid a constraint, or clear all four to return future Jobs to BestEffort.
The schedule saves the values for future checks. Each check keeps the values from its dispatch snapshot, so editing the schedule does not change a check already queued or running. An older agent may ignore this newer setting; upgrade the worker before relying on the limits.
For automation, use the schedule API's database_resources fields. A PATCH replaces the whole object; send null to clear it.
Plan node capacity for the agent plus every concurrent Job, scratch PVC, and image pull. A CPU or memory request can leave a Job Pending when no node has enough free capacity. If Kubernetes reports Insufficient cpu or Insufficient memory for five minutes by default, the agent stops the Job and the check ends as Infrastructure error with exit code 49. Lower the request, reduce parallel restores, or add node capacity. A database container that exceeds its memory limit can be OOMKilled; inspect its Pod events and the check error before increasing the limit.
Scratch storage is a separate PVC request for every Job. Its size and quota are independent of the CPU and memory fields above.