{"id":78321,"date":"2026-03-11T15:20:43","date_gmt":"2026-03-11T09:50:43","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=78321"},"modified":"2026-03-16T15:42:41","modified_gmt":"2026-03-16T10:12:41","slug":"running-gitlab-ci-at-scale-setting-up-kubernetes-based-runners","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/running-gitlab-ci-at-scale-setting-up-kubernetes-based-runners\/","title":{"rendered":"Running GitLab CI at Scale: Setting Up Kubernetes-Based Runners"},"content":{"rendered":"

Introduction<\/span><\/h1>\n

As the project grows and traditional CI runners running on static virtual machines or shared runners often struggle to keep up with increasing workloads. Jobs may queue up, builds start taking longer than expected and developers are left waiting.<\/span><\/p>\n

what’s the solution?<\/strong><\/span>
\nSo, instead of using traditional executioners we can leverage the GitLab Runner Kubernetes Executor<\/strong> for this as it creates new pods for every new jobs and delete’s it as soon as the job’s get completed. Kubernetes Executor dynamically create pods to execute the pipeline jobs. Hence, This approach makes a scalable CI\/CD architecture where compute resources are gets used only when its needed. In this blog, we will explore how Setting Up Kubernetes-Based Runners.<\/span><\/p>\n

Step 1: Create Namespace and Add the Helm Repository<\/span><\/h2>\n

Create a new namespace gitlab for runners and add the helm repository by using below commands-<\/span><\/p>\n

\"cmd\"<\/span><\/p>\n

Step 2: Configure RBAC (Role Based Access Control)<\/span><\/h2>\n

So, The gitlab runners needs the permissions to manage the pods in kubernetes cluster for which we need to create the RBAC.<\/span>
\nRBAC defines what resources a service account can access within that cluster.<\/span><\/p>\n

So, RBAC configuration includes below three main components-<\/span><\/p>\n

1. Service Account<\/strong>: Represents the identity used by the runner.<\/span>
\n2. Cluster Role<\/strong>: Defines the permissions required by the runner.<\/span>
\n3. Cluster Role Binding<\/strong>: Binds the role with the service account.<\/span><\/p>\n

RBAC configuration that we would be using is below –<\/span><\/p>\n

\"RBAC\"

rbac.yaml<\/span><\/p><\/div>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

Lets apply this –<\/span><\/p>\n

\"kubectl\"<\/p>\n

Step 3: Now, Register this Runner in GitLab<\/span><\/h2>\n

Lets, create the new project runner-<\/span><\/p>\n

    \n
  1. Go to GitLab project Settings<\/strong> \u2192 CI\/CD<\/strong> \u2192 Runners<\/strong><\/span><\/li>\n
  2. Click on New project runner<\/span><\/li>\n
  3. Add tags like kubernetes. These tags are how your .gitlab-ci.yml<\/strong> assigns jobs to this runner<\/span><\/li>\n
  4. Give it a description and click Create runner<\/span><\/li>\n
  5. Now, Copy the Gitlab registration token<\/strong> that appears (it starts with glrt<\/strong>-). Make sure you copy that as you won’t seeing it again.<\/span><\/li>\n<\/ol>\n
    \"runner\"

    runner<\/span><\/p><\/div>\n

    Step 4: Let’s Deploy the Runner with Helm<\/span><\/h2>\n

    create a file with name gitlab-runner.yaml, use the below configuration Replace “glrt-REPLACE_ME” with your actual token created in Step 3<\/code><\/span><\/p>\n

    \"Runner

    Runner Configuration<\/span><\/p><\/div>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

     <\/p>\n

    Install the Helm chart with below command –<\/span><\/p>\n

    helm install gitlab-runner \\\r\n--namespace gitlab \\\r\n--version 0.80.0 \\\r\n-f gitlab-runner.yaml \\\r\ngitlab\/gitlab-runner<\/span><\/pre>\n
    check if the pods are up and running –<\/span><\/p>\n
    kubectl get pods -n gitlab --watch<\/span><\/pre>\n
    Step 5: Test Your Runner<\/span><\/h2>\n
    Add the below .gitlab-ci.yml<\/strong> to your repository linked to your GitLab account to check if everything is working as expected.<\/span><\/p>\n
    \"sample<\/span><\/p>\n
    Conclusion-<\/span><\/h2>\n
    So, If we need to scale our CI\/CD then running the GitLab Runner on Kubernetes is an effective way rather than relying on the traditional executioners the GitLab Runner Kubernetes Executor<\/strong>\u00a0provides pipelines execute dynamically, allowing it to significantly optimize infrastructure costs by utilizing cluster resources only when they are truly needed and provides a highly scalable pipeline architecture suitable for modern DevOps teams.<\/span><\/p>\n
    Kubernetes executor – https:\/\/docs.gitlab.com\/runner\/executors\/kubernetes<\/a><\/span>
    \nTroubleshooting the Kubernetes executor –     https:\/\/docs.gitlab.com\/runner\/executors\/kubernetes\/troubleshooting\/<\/a><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
    Introduction As the project grows and traditional CI runners running on static virtual machines or shared runners often struggle to keep up with increasing workloads. Jobs may queue up, builds start taking longer than expected and developers are left waiting. what’s the solution? So, instead of using traditional executioners we can leverage the GitLab Runner […]<\/p>\n","protected":false},"author":1834,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":33},"categories":[5877],"tags":[4252,6073,8461],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78321"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1834"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=78321"}],"version-history":[{"count":4,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78321\/revisions"}],"predecessor-version":[{"id":78536,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78321\/revisions\/78536"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=78321"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=78321"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=78321"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}