Feedback

Chat Icon

Cloud Native CI/CD with GitLab

From Commit to Production Ready

Cloud Native, Scalable and Observable GitLab Runner on Kubernetes
85%

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

Cloud Native CI/CD with GitLab

From Commit to Production Ready

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