Cloud Native, Scalable and Observable GitLab Runner on Kubernetes
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 | sh -
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. For example:
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 GitLab runners are deployed using Helm charts when using Kubernetes.
ℹ️ 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.
Before moving on, make sure that the Kubernetes version is at least 1.4 - this is the minimum version required to run GitLab runners. You can check the Kubernetes version by running the following command:
kubectl version
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-3
# Give it permission to execute
chmod 700 get_helm.sh
# Install Helm
./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:
mkdir -p $HOME/todo/gitlab-runner/helm
helm show values gitlab/gitlab-runner > $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. Most configurations are well documented in the values file. Here is what we need for now to use as a configuration:
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.
serviceAccountCloud Native CI/CD with GitLab
From Commit to Production ReadyEnroll now to unlock all content and receive all future updates for free.
