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 Kubernetes Executor 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.

Step 1: Create Namespace and Add the Helm Repository

Create a new namespace gitlab for runners and add the helm repository by using below commands-

Step 2: Configure RBAC (Role Based Access Control)

So, The gitlab runners needs the permissions to manage the pods in kubernetes cluster for which we need to create the RBAC.
RBAC defines what resources a service account can access within that cluster.

So, RBAC configuration includes below three main components-

1. Service Account: Represents the identity used by the runner.
2. Cluster Role: Defines the permissions required by the runner.
3. Cluster Role Binding: Binds the role with the service account.

RBAC configuration that we would be using is below –

rbac.yaml

Lets apply this –

Step 3: Now, Register this Runner in GitLab

Lets, create the new project runner-

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

runner

Step 4: Let’s Deploy the Runner with Helm

create a file with name gitlab-runner.yaml, use the below configuration Replace “glrt-REPLACE_ME” with your actual token created in Step 3

Runner Configuration

Install the Helm chart with below command –

helm install gitlab-runner \
--namespace gitlab \
--version 0.80.0 \
-f gitlab-runner.yaml \
gitlab/gitlab-runner

check if the pods are up and running –

kubectl get pods -n gitlab --watch

Step 5: Test Your Runner

Add the below .gitlab-ci.yml to your repository linked to your GitLab account to check if everything is working as expected.

Conclusion-

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 provides 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.

Kubernetes executor – https://docs.gitlab.com/runner/executors/kubernetes
Troubleshooting the Kubernetes executor – https://docs.gitlab.com/runner/executors/kubernetes/troubleshooting/