Resource allocation
This topic describes container resource allocation logic, how you can configure resource limits (if possible for your build infrastructure), and troubleshooting issues related to resource allocation.
Build pod resource allocation
By default, resource requests are always set to the minimum, and additional resources are requested only as needed during build execution, depending on the resource request logic. Resources are not consumed after a step's execution is done.
- What are Kubernetes container requests? Containers are guaranteed to get requests. If a container requests a resource, Kubernetes only schedules it on a node that can give the container the requested resource.
- What are Kubernetes container limits? This defines the upper limit for resource consumption by a Kubernetes container. When the container uses more than the defined limit, Kubernetes evicts the pod.
For more information, go to the Kubernetes documentation on Kubernetes best practices: Resource requests and limits.
Default resource minimums (requests) and maximums (limits) are as follows:
Component | Minimum CPU | Maximum CPU | Minimum memory | Maximum memory |
---|---|---|---|---|
Steps | 10m | 400m | 10Mi | 500Mi |
Add on (execution-related steps on containers in Kubernetes pods) | 100m | 100m | 100Mi | 100Mi |
Override resource limits
For an individual step, you can use the Set Container Resources settings to override the maximum resources limits:
- Limit Memory: Maximum memory that the container can use. You can express memory as a plain integer or as a fixed-point number with the suffixes
G
orM
. You can also use the power-of-two equivalents,Gi
orMi
. Do not include spaces when entering a fixed value. The default is500Mi
. - Limit CPU: The maximum number of cores that the container can use. CPU limits are measured in CPU units. Fractional requests are allowed. For example, you can specify one hundred millicpu as
0.1
or100m
. The default is400m
. For more information, go to Resource units in Kubernetes.
Set Container Resources settings aren't available for self-hosted VM or Harness Cloud build infrastructures.
To increase default resource limits across the board, you can contact Harness Support to enable the feature flag CI_INCREASE_DEFAULT_RESOURCES
. This feature flag increases maximum CPU to 1000m and maximum memory to 3000Mi.
Resource request logic and calculations
Limit and request values are based on steps being parallel or sequential. Parallel steps sum the resources for each parallel step, and sequential steps take the maximum resources needed amongst the sequential steps.
The total computed resource requirements are set as the limit and request values for the stage container (also referred to as the Lite-Engine). For example, if total CPU is 600m, then the stage container's memory limit and request values are both set to 600m. This ensures selection of appropriately-sized pods, and it avoids over- or under-utilization of resources.
Resource calculation examples
Calculation example #1: Sequential steps
Calculation example #2: Parallel steps
Calculation example #3: Sequential and parallel steps
Calculation example #4: Sequential and parallel steps with overrides
Calculation example #5: Step groups
Calculation example #6: Background steps
Troubleshoot resource limits
Go to the CI Knowledge Base for questions and issues related to resource allocation and build infrastructure, such as:
- CI pods appear to be evicted by Kubernetes autoscaling
- Docker Hub rate limiting
- Use a parallel step to monitor failures
- Can I change the CPU/memory allocation for steps running on Harness cloud?
- Can I prioritize my build pod if there are resource shortages on the host node?
- Experiencing OOM on java heap for the delegate
- Out of memory errors with Gradle
- DinD Background step fails when Docker daemon disconnects or hit quota limit after some time