GitLab Runners sur Kubernetes : scaler son CI/CD automatiquement

Gérer des runners GitLab sur des VMs fixes, c’est payer pour de la capacité idle. Sur Kubernetes, un nouveau pod de CI démarre à chaque job et se termine quand le job est fini — scalabilité automatique, facturation au job réel.

Installer GitLab Runner avec Helm

helm repo add gitlab https://charts.gitlab.io
helm repo update

helm install gitlab-runner gitlab/gitlab-runner   --namespace gitlab-ci   --create-namespace   -f runner-values.yaml

# runner-values.yaml
gitlabUrl: https://gitlab.example.com

runnerToken: "glrt-votre-token-ici"

runners:
  executor: kubernetes

  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "gitlab-ci"
        image = "ubuntu:22.04"
        cpu_request = "100m"
        cpu_limit = "2"
        memory_request = "256Mi"
        memory_limit = "2Gi"
        service_cpu_limit = "1"
        service_memory_limit = "1Gi"

        # Cache dans S3
        [runners.cache]
          Type = "s3"
          Shared = true
          [runners.cache.s3]
            ServerAddress = "s3.amazonaws.com"
            BucketName = "gitlab-ci-cache"
            BucketLocation = "eu-west-1"
            AuthenticationType = "iam"

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "200m"

Cache S3 : partagé entre tous les runners

# Dans .gitlab-ci.yml — utiliser le cache S3
test:
  cache:
    key: "$CI_COMMIT_REF_SLUG-python"
    paths:
      - .cache/pip
    policy: pull-push
  variables:
    PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
  script:
    - pip install -r requirements.txt
    - pytest

Le cache est stocké dans S3 — n’importe quel runner dans n’importe quel pod peut le lire.

Isolation par tags de runner

# Pour les jobs qui nécessitent des ressources spécifiques
build:heavy:
  tags:
    - kubernetes-high-memory   # runner avec limits mémoire élevées
  script:
    - docker build --memory 4g -t myapp .

deploy:prod:
  tags:
    - kubernetes-prod          # runner avec accès réseau prod
  script:
    - kubectl apply -f manifests/

Service containers : base de données pour les tests

test:integration:
  services:
    - name: postgres:16-alpine
      alias: db
      variables:
        POSTGRES_DB: test
        POSTGRES_USER: test
        POSTGRES_PASSWORD: test
    - name: redis:7-alpine
      alias: redis
  variables:
    DATABASE_URL: "postgresql://test:test@db:5432/test"
    REDIS_URL: "redis://redis:6379"
  script:
    - pytest tests/integration/ -v

GitLab démarre ces containers comme des pods Kubernetes aux côtés du job — accessibles par leur alias.

Notre formation CI/CD couvre GitLab Runner et l’infrastructure de CI avec des ateliers pratiques.