Skip to content

GKE GitLab Runner Platform

This page provides reference information relating to the DevOps team's Google Kubernetes Engine (GKE) GitLab Runner platform.

Platform Description

The GKE GitLab runner platform provides GKE-hosted GitLab Runner resources for DevOps product's to run CI jobs on.

Platform Status

The GKE GitLab runner platform is live and in use by multiple DevOps product teams.

Contact

Technical queries and support should be directed to the Platforms Team MS Teams channel where members of the Platforms Team will be able to assist.

Issues discovered in the service or new feature requests should be reported by creating an issue in the associated GitLab project.

Environments

The GKE GitLab Runner platform is currently deployed to both development and production environments. The GCP console landing page for the environment projects are as follows:

Name Project landing page
Production gitlab-runner-prod-22257483
Development gitlab-runner-devel-72a2b0bc

Source code

Source code for the GKE GitLab Runner platform infrastructure is in the gitlab-runner-platform repository.

Technologies used

The GKE GitLab Runner platform uses the following technologies:

Architecture

GKE cluster configuration

The platform requires a GKE cluster. Unfortunately, due to the GitLab Auto-DevOps Build stage's dependency on Docker in Docker, it's not possible to use GKE AutoPilot as it doesn't support privileged containers. Instead, the cluster is provisioned as a Standard GKE cluster with the following notable configuration:

  • The cluster is deployed to the gitlab-runner-prod-22257483 Google project.
  • It is a regional cluster in europe-west2, with nodes in the europe-west2-a and europe-west2-b zones.
  • The worker node pool runs the CI job pods and is auto-scaling. Each node has 16 vCPU and 12GB of memory, of which about 10.1GB is available to pods, which is the allocatable memory shown in the Google Cloud console.
  • Workload Identity is enabled.

Default job container resources

Each job pod has a build container, a helper container and one container for each service, such as docker:dind. The runners set these defaults. A job can raise them with the KUBERNETES_* variables described in the how-to, up to the ceiling. See the explanation for how requests and limits work.

Container Memory request Memory limit Ceiling for overrides
Build 250Mi 1Gi 8Gi
Service (dind) 512Mi 2Gi 4Gi
Helper 128Mi 1Gi 4Gi

The build container's CPU request is 250m, with a ceiling of 2000m. The devops-general runner has a build memory limit of 1.3Gi. Some product runners override the build values: their memory limit is between 1.3Gi and 2.8Gi, and one has a CPU request of 1. The ceiling for a container applies to both its memory request and its memory limit. These are the production values as of October 2026.

Per-product configuration

Each product has the following resources created by the Terraform configuration (see the how-to for steps on adding a product to the Terraform deployment).

  • A unique Kubernetes namespace for the product's runners.
  • A Kubernetes service account (named gke-ci-run) in the product's namespace.
    • This includes IAM bindings for this service account to impersonate other service accounts using Workload Identity.
  • A GitLab runner pod deployed using the GitLab runner Helm chart.
  • A Kubernetes network policy which blocks ingress for all pods within the namespace and allows egress to any IP on port tcp/443 only. This ensures isolation between different product CI/CD jobs.
  • The following CI/CD variables populated with the relevant values.
    • GKE_RUNNER_TAG
    • ARTIFACT_REGISTRY_DOCKER_REPOSITORY
    • ARTIFACT_REGISTRY_SERVICE_ACCOUNT

Service Management and tech lead

The service owner for the GKE GitLab Runner platform is Abraham Martin.

The service manager and tech lead for the GKE GitLab Runner platform is Adam Deacon.

The following engineers have operational experience with the GKE GitLab Runner platform and are able to respond to support requests or incidents:

See also