Feedback

Chat Icon

Cloud Native CI/CD with GitLab

From Commit to Production Ready

Cloud Native GitLab Runners on Kubernetes: Scalability and Caching
86%

Deploying GitLab Runner on Kubernetes

Repeat the same procedure to create a Kubernetes runner. Use kubernetes as the tag. Save the token in an environment variable. Example:

export GITLAB_RUNNER_TOKEN=glrt-xxxxxxxxxxxxxx

To use a Kubernetes runner, you need to have a Kubernetes cluster set up. You can use a managed Kubernetes service like Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) or DigitalOcean Kubernetes (DOKS). You can also set up a Kubernetes cluster on your own using tools like Minikube, k3s, or kubeadm. The fastest way is to use a K3s cluster. Being lightweight and scalable, K3s is an excellent choice for running GitLab Runner.

ℹ️ K3s is a lightweight Kubernetes distribution that is easy to install and manage. It is designed for edge computing and IoT devices, but it is also suitable for development, testing, CI/CD, and other use cases.

To set up a K3s cluster, you can use the following steps:

# Install K3s
curl -sfL https://get.k3s.io | \
  INSTALL_K3S_VERSION=v1.35.0+k3s1 sh -s -

Check the status of the K3s service:

systemctl status k3s --no-pager

Create a kubeconfig file:

mkdir -p $HOME/.kube

Copy the kubeconfig file generated by K3s to the $HOME/.kube directory:

cp /etc/rancher/k3s/k3s.yaml $HOME/.kube/config

Change the ownership of the kubeconfig file:

chown $(id -u):$(id -g) $HOME/.kube/config

Check the nodes in the cluster:

kubectl get nodes

This is the most straightforward way to set up a K3s cluster. You can also customize the installation by passing additional options to the curl command like: curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s - --flannel-backend none --token 12345

More details are available in the K3s documentation. For our purposes, the default installation is sufficient. We can now move to creating a Kubernetes runner.

Before moving on, I recommend enabling the autocomplete feature for kubectl. This will make it easier to work with Kubernetes commands:

source /usr/share/bash-completion/bash_completion
echo 'source <(kubectl completion bash)' >>~/.bashrc
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc
source ~/.bashrc

The first step in setting up a Kubernetes runner is installing Helm since we are going to use a Helm chart to install the runner.

ℹ️ Helm is a package manager for Kubernetes that allows you to define, install, and manage applications on Kubernetes. Helm charts are packages of pre-configured Kubernetes resources that can be deployed to a Kubernetes cluster.

You can proceed with installing Helm by running the following commands:

# Download the Helm binary
curl -fsSL -o get_helm.sh \
  https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4

# Give execution permissions to the script
chmod 700 get_helm.sh

# Run the installation script
./get_helm.sh

# Remove the Helm installation script
rm get_helm.sh

Next, you need to add the GitLab Helm repository to Helm:

# Add the GitLab Helm repository
helm repo add gitlab https://charts.gitlab.io

# Update the Helm repositories
helm repo update

Let's see the default configuration values for the GitLab runner:

# Create a folder to store the Helm values file
mkdir -p $HOME/todo/gitlab-runner/helm

# Get the default values file
helm show values gitlab/gitlab-runner --version 0.85.0 \
  > $HOME/todo/gitlab-runner/helm/values.yaml

Open the file $HOME/todo/gitlab-runner/helm/values.yaml in your favorite text editor and make the necessary changes.

In our case, we can start with this initial configuration that includes the necessary settings, run the command below to create the values file:

cat < $HOME/todo/gitlab-runner/helm/values.yaml
# The URL of the GitLab instance where
# the runner should register.
gitlabUrl: https://gitlab.com/

# The registration token used to register the runner
# with your GitLab instance.
# This token should be obtained from your GitLab project
# or group under CI/CD settings.
runnerRegistrationToken: "$GITLAB_RUNNER_TOKEN"

# RBAC (Role-Based Access Control) settings
# to create roles and role bindings.
# Enabling this allows the runner
# to have the necessary permissions in Kubernetes.
rbac:
  # Set to true to create the necessary RBAC roles
  # and bindings for the runner.
  create: true

# Service account configuration to specify
# which service account the runner should use.
# Creating a service account ensures the runner
# has its own identity in the cluster.
serviceAccount:
  # Set to true to create a dedicated service account for the runner.
  create: true

# Metrics configuration.
# Disabling metrics if you do not need Prometheus
# to scrape metrics from the runner pods.
metrics:
  # Set to false to disable Prometheus metrics.
  enabled

Cloud Native CI/CD with GitLab

From Commit to Production Ready

Enroll now to unlock all content and receive all future updates for free.