Skip to content

gitlab: Rely on gitlab-runner concurrency for scaling

Dduvall requested to merge review/simplify-gitlab-runner-scaling into main

Using an HPA to scale the main gitlab-runner pods has proven a bit finicky. 1) It slows the scaling response of the cluster, as the main gitlab-runner pods must initialize prior to them in turn providing more actual runner-* pods. 2) There have been a few instances now where for some reason the HPA value is not updating properly (either the custom Prometheus metric is wrong or there is some breakage in the Prometheus adapter) and the replicas have been maxed out while doing nothing.

Let's try simplifying this setup again, removing the HPA for main gitlab-runner scaling and relying on 2 statically scaled gitlab-runner replicas, each with a concurrency of 20 to provide a total capacity of 40 (actual) runner pods.

Bug: T327416

Edited by Dduvall

Merge request reports