GitLab Runners sur Kubernetes : optimisation des coûts hyperscale avec l'executor Kubernetes

Plongée technique : GitLab Runners sur Kubernetes, installation Operator, valeurs Helm, autoscaling et modèle de coûts FinOps. Pour la version courte, lisezArrêtez de payer pour le CI inactif.

La plupart des équipes facturent l'intégration continue comme si chaque nuit et chaque week-end étaient encore un lundi matin. Les serveurs restent chauds. Le disque reste alloué. Personne ne fusionne de code — et la facture ne s'en rend pas compte. Cette phrase n'est pas un slogan ; c'est la forme par défaut d'une flotte de runners fixes.

Cet article détaillé est le compagnon technique d'un tutoriel pratique surGitLab Server et GitLab Runner sur Kubernetes: comment l'exécuteur Kubernetes transforme chaque tâche CI en pod éphémère, comment cela permet une provision et une désprovision dynamiques de la capacité, et comment cette conception débloqued'énormes économiesen récupérant CPU, la RAM et le stockage lorsque la demande s'effondre la nuit et le week-end.

Regardez d'abord les deux sessions, puis utilisez cette page comme référence écrite de l'architecture et du modèle de coûts.

1. Runners & pipelines— autoscaling des charges de travail GitLab Runner avec Kubernetes.

Regardez : GitLab Runners complets et CI/CD sur Kubernetes· Version en langage simple :Arrêtez de payer pour le CI inactif

Serveur GitLab en HA Kubernetes— déployez GitLab avec l'Operator en quelques minutes.

Regarder : Déployer GitLab en HA Kubernetes cluster à l'aide de l'Operator· Docs :Installation de GitLab Operator

1. Thèse

GitLab sur Kubernetes + l'executor Kuberneteschange l'unité de capacité CI de « une machine que nous possédons tout le mois » à « des pods (et des nœuds) que nous louons pour le travail ». Le gestionnaire de runner reste petit et toujours actif. Les pods de travail apparaissent pour une construction et disparaissent ensuite. Avec le redimensionnement automatique du cluster, les nœuds de travail suivent la même courbe. C'est ainsi que vous protégez le débit du lundi matin et arrêtez de payer les prix du lundi matin pour le mardi à 03:00 et pour les samedis calmes.

En une ligne — la même ligne que le guide pour les débutants :provisionner pour le pic, dé-provisionner pour le creux.

2. L'habitude coûteuse, énoncée comme une odeur d'architecture

Les CI traditionnels ressemblent souvent à une flotte permanente : un ensemble fixe de machines de build qui restent en place « au cas où ». Cela fonctionne quand le trafic est régulier. Cela gaspille de l'argent quand la demande est ponctuelle.

• En journée :les développeurs poussent des branches, ouvrent des demandes de fusion, exécutent des tests — la demande grimpe.
• Soirs et nuits :l'activité baisse ; les machines continuent de consommer CPU et de la RAM.
• Week-ends :souvent quasi inactifs — pourtant les volumes de stockage et les nœuds cloud peuvent toujours être réservés et facturés.

Vous ne payez pas pour les « builds réalisés ». Vous payez pour la capacité qui existe, qu'on l'utilise ou non. Les flottes fixes accumulent aussi un état collant : « ça marche sur le runner 3 », des paquets dérivés, des caches qui n'expirent jamais. Les pods élastiques ne résolvent pas la discipline par eux-mêmes, mais ils rendent le clean-slate par défaut.

3. Carte système

L'analogie issue du guide de base reste valable à cette couche : GitLab Runner est le worker ; Kubernetes est le dispatcher qui appelle les workers uniquement lorsque les colis (tâches) arrivent, puis les renvoie chez eux.

4. Installation de GitLab sur le cluster (chemin opérateur)

Le chemin de formation Day 1 installe GitLab avec l'opérateur officiel, de sorte que le serveur partage la même fondation Kubernetes que les runners. La vidéo complémentaireDéployer GitLab dans un cluster Kubernetes en HA à l'aide de l'opérateurdécrit cette installation en quelques minutes. Prérequis : un cluster avec ingress, Helm,kubectl, et cert-manager lorsque le chart gère TLS.

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

helm install gitlab-operator gitlab/gitlab-operator \
  --create-namespace \
  --namespace gitlab-system

kubectl -n gitlab-system get deployment gitlab-controller-manager

# Apply the GitLab custom resource (pin chart version in the manifest)
kubectl -n gitlab-system apply -f deploy_gitlab_server.yaml

Exemple de forme CR (personnalisez le domaine et l'adresse e-mail de l'émetteur pour votre environnement) :

apiVersion: apps.gitlab.com/v1beta1
kind: GitLab
metadata:
  name: gitlab
spec:
  chart:
    version: "9.2.2"
    values:
      global:
        hosts:
          domain: "example.com"
        ingress:
          configureCertmanager: true
      certmanager-issuer:
        email: you@example.com

La première installation prend généralement entre 10 et 15 minutes pendant que le webservice, Sidekiq, les bases de données et les composants connexes se stabilisent. Récupérez le mot de passe racine initial depuis le secret du cluster :

kubectl get secret gitlab-gitlab-initial-root-password -n gitlab-system \
  -o jsonpath='{.data.password}' | base64 -d

Référence :Installation de l'opérateur GitLab(onglet Helm sur cette page). Vue d'ensemble du chart :docs.gitlab.com/charts· guide d'installation :installation du chart.

5. GitLab Runner avec l'exécuteur Kubernetes

Un GitLab Runner est l'application qui travaille avec GitLab CI/CD pour exécuter les jobs dans une pipeline. Avec l'exécuteurKubernetes, le manager ne compile pas sur lui-même. Pour chaque job, il :

1. Crée un pod (plus les conteneurs d'aide / de service configurés).
2. Transmet les logs vers GitLab.
3. Récupère les artefacts et le statut de sortie.
4. Supprime le pod — rendant CPU et la RAM au cluster.

Ce cycle de création/exécution/suppression est le premier levier de coût. Les travaux terminés ne doivent pas laisser une machine chaude dédiée toute la nuit.

5.1 Helm schéma d'installation

Les scripts de formation créent un namespace, transmettent un jeton d'inscription et peuvent installer plus d'une version (par exemple des runners basés sur Alpine et Ubuntu) afin que les jobs puissent sélectionner différents environnements. Procédure officielle :Installer GitLab Runner avec le graphique Helm; référence des valeurs :Configurer le graphique GitLab Runner Helm.

helm upgrade --install --namespace gitlab-runner gitlab-runner-alpine \
  -f config-runner-alpine.yaml \
  --set serviceAccount.create=true \
  gitlab/gitlab-runner \
  --create-namespace

Obtenir des jetons depuis l'interface GitLab (runners d'instance / groupe / projet) ou depuis des secrets gérés par l'opérateur. Privilégier les jetons d'authentification modernes des runners ; les jetons d'inscription sont dépréciés vers GitLab 18.Ne jamais engager des jetons en production— les scripts de lab contiennent parfois des placeholders qui doivent être remplacés localement.

5.2 Valeurs qui comptent pour l'échelle et l'isolation

À partir des modèles Workstation (gitlab-runner-values-template.yaml/ générésconfig-runner-*.yaml):

gitlabUrl: http://gitlab-webservice-default.gitlab-system.svc.cluster.local:8080/
concurrent: 2
rbac:
  create: true
  clusterWideAccess: true
runners:
  privileged: true
  config: |
    [[runners]]
      environment = ["GIT_SSL_NO_VERIFY=1"]
      [runners.kubernetes]
        namespace = "gitlab-runner"
        image = "alpine/git:latest"
        service_account = "gitlab-runner"
        privileged = true

La concurrence sans CPU ne fait que prolonger la file d'attente. Associerconcurrentà une vraie marge de manœuvre sur les nœuds ou un auto-scaling de nœuds.

6. Autoscaling à deux niveaux (vraiment quatre)

« Autoscaling GitLab Runners on Kubernetes » n'est pas un seul interrupteur. Empilez ces leviers :

1. Élasticité des pods de job— intégrée à l'exécuteur Kubernetes. Zéro job → zéro pods de job. Cela seul élimine la plupart des gaspillages par job sur un cluster partagé.
2. Runnerconcurrentet plusieurs Deployments de runners— séparez alpine vs ubuntu (ou CPU vs des constructeurs plus gros) afin que la capacité spécialisée ne reste pas inoccupée pour un mauvais mix.
3. Autoscaling du cluster / des nœuds— les pods en attente ajoutent des nœuds ; les nœuds vides partent après la vague du soir.
4. Politique optionnelle sensible au planning— plafonds de concurrence réduits ou pools de nœuds mis à l'échelle selon un calendrier pour les nuits et week-ends, en complément de la chute naturelle de la demande.

Hyperscale raconte la même histoire avec une amplitude plus marquée : éparpillez-vous pour les files profondes, puis dé-provisionnez agressivement afin que la moitié calme de la semaine ne ressemble pas à la moitié occupée sur la facture.

6.1 Une note sur « inactif » dans le sens GitLab Runner

Certains exécuteurs maintiennent un petit nombre de machines inactives en veille pour absorber le prochain job sans latence de démarrage à froid. Sur Kubernetes, le démarrage à froid consiste généralement à créer un pod (secondes), pas à démarrer une VM (minutes). Préférez laisser les pods descendre à zéro et accepter un léger retard de planification plutôt que de maintenir une garde-nuit de nœuds vides « au cas où ». Si vous devez maintenir un plancher minimal, dimensionnez ce plancher pour la réalité de la garde — pas pour la tempête de merges du lundi.

6.2 Provisionnement et déprovisionnement dynamiques de bout en bout

Suivre un pipeline de job :

1. Le développeur pousse ; GitLab crée un job dans la file d'attente en attente.
2. Le gestionnaire de runner récupère le job et demande un pod à API.
3. Si le cluster manque de CPU/RAM, l'autoscaler ajoute un nœud (provisionnement).
4. Le pod exécute le script, télécharge les artefacts, se termine.
5. Le pod est supprimé ; les ressources retournent au pool (déprovisionnement au niveau du job).
6. Lorsque de nombreux nœuds restent vides au-delà du seuil de réduction d'échelle — typiquement après le soir et tout le week-end — les nœuds partent (déprovisionnement au niveau infrastructure).

C'est ce cycle complet que la vidéo entend par GitLab Runners à l'échelle hyperscale pour l'optimisation des coûts : pas un seul drapeau sophistiqué, mais le cycle de vie des jobs et l'élasticité du cluster qui travaillent ensemble.

7. Modèle de coûts : où apparaissent les économies massives

Soyez précis. L'autoscaling ne rend pas les builds gratuits. Il vous évite de payer les tarifs de pointe pendant les heures creuses. Les économies proviennent de l'alignement de la dépense sur la demande réelle — les quatre points du guide simplifié, développés pour les opérateurs.

7.1 Échelonner à la hausse uniquement quand des personnes (ou des bots) travaillent

Lorsqu'une matinée chargée engendre des dizaines de pipelines, Kubernetes planifie de nombreux pods de jobs en parallèle jusqu'aux limites de concurrence et de cluster. La productivité apparaît quand la pression de fusion est réelle.

7.2 Réduisez drastiquement les coûts lorsque la demande disparaît

Lorsque les tâches se terminent, les pods disparaissent. Avec le redimensionnement automatique du cluster (ou un pool de nœuds correctement dimensionné), les nœuds cloud inutilisés quittent le pool. Les nuits et les week-ends — généralement les fenêtres les plus calmes pour les équipes produits — sont la première capacité que vous devriez cesser de payer.

7.3 Arrêtez de gaspiller CPU, la RAM et le stockage

Au fil d'un mois, les heures calmes dominent l'horloge. Récupérer les nuits et les week-ends est là où leséconomies en dollars s'accumulent.

7.4 Payez pour les résultats, pas pour le mobilier

Vous payez toujours pour GitLab et pour un plan de contrôle mince (gestionnaire de runners + essentiels du cluster). Ce que vous cessez de payer, c'est un entrepôt de chaises vides.

7.5 Intuition travaillée (pas un benchmark fabriqué)

Supposons que le jour nécessite de manière durable l'équivalent de 20 slots d'exécuteur occupés, tandis que les nuits et les week-ends en nécessitent 2. Une flotte fixe dimensionnée pour 20 paie pour 20 24 heures sur 24. Un pool élastique paie ~20 pendant la journée et ~2 (plus le plan de contrôle) quand tout est calme. Pour de nombreuses équipes produits, les heures calmes constituent une grande fraction du mois — donc les récupérer est ce qui rend les économiesénormessans inventer un pourcentage marketing. La finance multiplie les prix locaux par heure-nœud ; le travail de l'architecture est de rendre les heures vides réellement vides sur le compte de facturation.

De grandes économies apparaissent quand le pic du lundi ne dicte plus la facture du mardi à 3h du matin — et quand le silence du samedi finit par paraître calme sur la facture aussi.

7.6 Ce que vous payez volontairement

• Composants GitLab Server — dimensionnés pour les utilisateurs et la coordination CI, pas pour la ferme de compilation.
• Runner manager Déploiement(s) — petit par rapport aux fermes de jobs.
• Caches délibérés (proxy de dépendances, PVCs) — utiles, mais dimensionnés ; les caches ne sont pas un stockage gratuit.
• DinD privilégié — pratique et plus lourd ; envisagez Kaniko/BuildKit quand la densité et l'isolation comptent plus que la familiarité.

8. CI/CD pipelines en pratique

Avec des runners en ligne,.gitlab-ci.ymldéfinit les étapes et les tâches. GitLab planifie ; l'exécuteur Kubernetes matérialise les pods. Gardez les pipelines honnêtes sur les coûts :

• Échouez rapidement sur lint/unit avant les lourdes constructions d'images.
• Utilisezrules/workflowafin que les branches de brouillon ne diffusent pas de matrices complètes.
• Privilégiez les caches partagés avec des clés claires plutôt qu'une croissance disque illimitée par VM.
• Étiquetez les tâches au bon pool de runners (alpine vs ubuntu, petits vs gros constructeurs).

stages: [lint, test, build]

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

lint:
  stage: lint
  image: alpine:3.19
  script:
    - echo "cheap checks first"

test:
  stage: test
  tags: [kubernetes, alpine]
  script:
    - echo "unit tests"

build:
  stage: build
  tags: [kubernetes, dind]
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script:
    - echo "heavy image build only on default branch"

L'idée économique est la même que l'idée de plateforme : ne planifiez pas de travail coûteux quand un contrôle peu onéreux aurait échoué, et ne gardez pas des runners spécialisés chauds pour des tâches qui n'arrivent jamais le samedi.

9. Notes de sécurité et de location

Les pods éphémères améliorent l'hygiène (moins d'état collant) mais DinD privilégié et RBAC à l'échelle du cluster peuvent élargir le rayon d'explosion. Defaults pratiques pour la plupart des équipes :

• Exécutez les pods de tâches dans un namespace dédié avec ResourceQuotas et LimitRanges.
• Privilégiez les constructions non privilégiées whenever possible ; isolez les runners DinD derrière des tags spécifiques.
• Évitez de monter des identifiants cloud à longue durée de vie dans chaque tâche ; injectez des jetons à courte durée de vie par pipeline.
• Traitez les jetons d'inscription de runner comme des secrets — faites-les tourner quand les personnes partent ou quand les laboratoires sont partagés.
• Si plusieurs équipes partagent un cluster, séparez les gestionnaires de runners (et éventuellement les pools de nœuds) afin qu'un voisin bruyant ne puisse pas maintenir toute la ferme chaude — et gardez l'histoire des coûts imputable par équipe.

10. Une observabilité qui prouve les économies

Vous ne pouvez pas affirmer des économies de nuit et de week-end sans regarder. Suivez au moins :

Si le nombre de pods baisse la nuit mais que la facture des nœuds ne baisse pas, ce sont les paramètres de mise à l'échelle — pas GitLab — qui sont le prochain levier.

11. VMs fixes vs Kubernetes exécuteurs (tableau de décision)

Choisissez les VMs fixes uniquement lorsque vous avez vraiment une demande plate 24×7 ou des contraintes qui interdisent un cluster. Tout le monde d'autre avec des pipelines pilotés par des humains en pointes paie la taxe meuble.

12. Ce que vous ne perdez pas

L'autoscaling ne signifie pas « pas de contrôle ». Vous définissez toujours la concurrence, les images autorisées, les privilèges DinD, la politique réseau et la portée d'enregistrement. Le but est de conserver ces contrôles tout en laissant la capacité inutilisée s'évaporer — la même réassurance que dans le texte en langage simple, maintenant appliquée avec RBAC, les namespaces et les releases de runners séparés.

13. Liste de vérification opérationnelle

1. Versions du pin et du chart de l'opérateur ; mise à niveau intentionnelle.
2. Rotation des jetons de runner ; purgez les jetons de lab de tout script avant publication.
3. Noms de domaine séparés : système GitLab vs tâches de runner.
4. Surveillezles podsen attente — une hausse des en attente signifie que la concurrence ou la capacité des nœuds est insuffisante au pic.
5. Surveillezles heures de nœuds vides— des nœuds restant vides la nuit indiquent un retard de réduction d'échelle ou un besoin d'ajustement de la politique de pool.
6. Limitez les runners privilégiés aux tâches qui en ont besoin.
7. Sauvegardez GitLab indépendamment de l'élasticité du runner.
8. Examinez la facture par heure de la semaine une fois le CI élastique en service — les nuits et les week-ends devraient chuter visiblement.

14. À qui s'adresse cela

• Ingénieurs plateforme et SREs implémentant GitLab CI sur Kubernetes.
• Chefs DevOps remplaçant les VM de runner par des pods d'exécuteur.
• Partenaires ingénierie et finance qui ont besoin que le CI se comporte comme une utilité basée sur l'usage, pas comme du mobilier.

15. Documentation officielle GitLab

Ces pages sont les références canoniques pour les déploiements Helm et les comportements de mise à l'échelle décrits ci-dessus. Préférez-les aux articles de blog lorsque les versions changent.

Serveur GitLab sur Kubernetes

• Installer l'opérateur GitLab— chemin d'installation de l'opérateur + Helm utilisé dans la démo de formation.
• Diagrammes GitLab Helm— documentation du diagramme parapluie.
• Installer GitLab avec le diagramme Helm— lorsque vous déployez GitLab via des diagrammes plutôt qu'un opérateur.
• sous-diagramme gitlab-runner (diagramme GitLab)— runner intégré à côté de GitLab dans le diagramme principal (distinct du diagramme de runner autonome).

Diagramme GitLab Runner Helm

• Installer GitLab Runner avec le diagramme Helm—helm repo add gitlab, installation/mise à niveau, notes sur le diagramme OCI.
• Configurer le diagramme GitLab Runner Helm—concurrent, modèles de configuration, RBAC, caches, choix d'images.
• diagramme gitlab-runnervalues.yaml— valeurs par défaut complètes (y compris les stubs HPA optionnels).

Kubernetes executor et autoscaling

• Kubernetes executor— job pods, helpers, services (par exemple DinD), demandes de ressources, verbes RBAC.
• Configurer l'autoscaling (Kubernetes executor / chart)— pause des pods,[runners.kubernetes.autoscaler], politiques de période (inactif la nuit/le week-end).
• Autoscaling GitLab Runner— modèle d'autoscaling général (couvre également le cache distribué).
• Planifier et gérer une flotte GitLab Runner— mise à l'échelle et opérations au niveau de la flotte.
• Configuration avancée (config.toml)— sections globalesconcurrentet executor intégrées dans Helmrunners.config.

Jobs CI, builds et paramètres du runner dans GitLab

• Configurer les runners dans GitLab— inscription, tags, run-untagged, runners protégés.
• Utiliser Docker pour construire des images en CI— DinD et alternatives (pertinent lorsqueprivileged/ service Docker est activé dans les valeurs du runner).

Pour le contrôle des coûts la nuit et le week-end, combiner : (1) les job pods de l'executor Kubernetes qui descendent à zéro, (2) les politiques du chartconcurrentet de l'autoscaleravechors pointeidle_count = 0, et (3) l'autoscaling cluster/nœud pour que les nœuds vides quittent le pool — comme décrit dans les sections 6–7.

16. Retour vers la vidéo et le repo

La session YouTube —GitLab complet en ~20 minutes. Autoscaling des workloads GitLab Runner sur Kubernetes— démontre GitLab sur Kubernetes, les runners via Helm, et le récit de coûts hyperscale : provisionner et déprovisionner dynamiquement l'infrastructure pour ne pas payer les tarifs de pointe pendant les nuits et week-ends inactifs. Utilisez le prompt de construction du coursgitlab-runners-k3s-hyperscale-course.prompt.mddans ce repo, avec les docs officiels ci-dessus comme source de vérité versionnée. Pour le cadrage non technique des mêmes idées, voirStop paying for idle CI.

Conclusion

Kubernetes ne se contente pas d'héberger les GitLab Runners. Utilisé correctement, il change l'économie du CI :provisionner à la demande, déprovisionner en cas d'inactivité, récupérer CPU/RAM/storage quand les humains rentrent. C'est le pattern hyperscale — accessible à toute équipe prête à échanger une flotte permanente contre une file de pods.

Commencez par la vidéo, mettez en place l'opérateur + runner Helm dans un labo, activez l'autoscaling des nœuds, puis vérifiez si le samedi finit par paraître calme sur la facture.

Publié parWorkstation.