Produits IA
Labs IAAgents OpenAIAgents ClaudeGrok BotWorkstation CRM (WSL CRM)MarketingTous les produits
Solutions IA
Applied AIAI AgentsGenerative AIStartupAI UpskillingAutomatisation d'Entreprise IALaboratoire IA d'entrepriseStations de travail IAIA privéeClusters GPUIA en périphérieIA par secteur
Services IA
Modernisation de plateformeIngénierie numériqueDonnées et activation IAOpérations autonomesConseil IAAutomatisation DevOpsCybersécuritéDéveloppement logicielCréation d'agentsMise en place MLOps
À propos
PartenairesTémoignages clients
AI InsightsJev seriesBenchmark LabModel selection
Articles
Documentation
OutilsWSL ProxyRing PromoterWSL VaultJobshoutSysOps 24/7
Actualités
Blog
Nous contacterConnexion

Stations de travail IA, logiciels multi-agents IA, infrastructure GPU et solutions d'agents intelligents pour les entreprises modernes.

Nous contacter

Solutions IA

Applied AIAI AgentsGenerative AIStartupAI UpskillingAutomatisation d'Entreprise IALaboratoire IA d'entrepriseIA par secteur

Produits

Tous les produitsWSL CRM & ERPMarketingAgents OpenAIWSL ProxyRing PromoterWSL VaultJobshoutSysOps 24/7

Entreprise

À proposPourquoi WorkstationPartenairesTémoignages clientsTarifsContact

Ressources

AI InsightsArticlesDocumentationBlogRechercherPlan du site
Bureau du Royaume-Uni
77-79 Marlowes, Hemel Hempstead HP1 1LFItinéraire : prenez la sortie 20 de la M25, Outer LondonN° d'entreprise: 11641870Lun - Ven : 9h00 - 18h00 GMT
+44 7515 356 146
Bureau de Belgique
Workstation SRL, Rue Vanderkindere 34, 1180 Uccle, BrusselsBE 0751.518.683Lun - Ven : 9h00 - 18h00 CET
+32 492 45 67 46
Bureau de l'Inde
#159 Sector 9, Pocket 1, DDA Flats, 110077 Dwarka, New Delhi
+91 98881 98841

© 2026 Workstation AI. Tous droits réservés.

ConfidentialitéCookiesConditions d'utilisationPlan du site web

Loading blog...

Accueil / Blogs
GitlabKubernetesDevOpsCicdFinOpsPlatform Engineering

Arrêtez de payer pour des CI inactifs : GitLab Runners sur Kubernetes

Échellez CI pour les pics du lundi, puis réduisez la capacité la nuit et le week-end — le guide en cinq minutes avec les deux vidéos de démo.

Balinder Walia29 septembre 20262 min read

La plupart des équipes paient pour l'intégration continue comme si chaque nuit et chaque week-end étaient encore le lundi matin.GitLab Runners sur Kubernetesrenversent ce modèle : augmenter la capacité au fur et à mesure que les pipelines arrivent, puis la réduire lorsque le bureau se calme. Consultez leapprofondissement techniquepour Helm valeurs, paramètres d'exécuteur et modèle de coûts.

GitLab Runners on Kubernetes — scale up by day, down at night

En résumé.Prévoyez pour le pic, désallouez pour la creux. Les pods de tâches éphémères récupèrent CPU, la RAM et le stockage lorsque la demande baisse — surtout la nuit et le week-end — afin que la ferme du lundi ne facture pas le samedi.

Regardez les vidéos

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

youtu.be/vURXfbvWK_0

2. GitLab Server sur HA Kubernetes— déployez avec l'Opérateur en quelques minutes.

youtu.be/fu82hENYNEs· Docs :GitLab Operator

La habitude coûteuse

  • Jour :les demandes de fusion et les tests font grimper la demande.
  • Nuits :l'activité baisse ; les VM fixes continuent de consommer CPU et la RAM.
  • Week-ends :souvent quasi inactifs — mais les disques et les nœuds peuvent toujours être facturés.

Vous ne payez pas pour les builds effectués. Vous payez pour la capacité qui existe, qu'on l'utilise ou non.

Une image plus simple

LeRunnerde GitLabKubernetesexécute les tâches de pipeline.

Kubernetes peut créer ces workers sous forme de pods éphémères et les supprimer une fois la tâche terminée. À l'échelle hyperscale, la même idée s'applique aux nœuds : plus quand la file d'attente est profonde ; moins — idéalement presque aucun — la nuit et le week-end.

D'où viennent les économies massives

  1. Monter en puissancequand des personnes (ou des bots) travaillent — pods de tâches en parallèle jusqu'aux limites de votre concurrence et de votre cluster.
  2. Réduire fortementquand la demande disparaît — les pods disparaissent ; avec le redimensionnement automatique du cluster, les nœuds vides quittent le pool.
  3. Arrêter de gaspiller CPU, la RAM et le stockagesur des flottes de runners toujours actifs pendant les heures calmes.
  4. Payer pour les résultats, pas pour le mobilier— gardez GitLab et un gestionnaire de runners léger ; laissez la ferme s'évaporer quand elle est inactif.

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.

Documentation officielle

  • Installer GitLab Runner avec le graphique Helm
  • Configurer le graphique Helm Runner
  • Exécuteur Kubernetes
  • Redimensionnement automatique de GitLab Runner
  • Installation de GitLab Operator

Lire la suite :l'article techniquehyperscaletraite des pistes Operator vs Helm, de la concurrence, de DinD, de l'observabilité et d'une liste de vérification FinOps. Prompt de construction du cours :gitlab-runners-k3s-hyperscale-course.prompt.mddans le dépôt du site Workstation (remplace le lien devops.git retiré).

Publié parWorkstation.