Aller au contenu

Blog

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 Walia
  • 2 min de lecture
  • Updated

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

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 TenthMatrix (remplace le lien devops.git retiré).

Publié parTenthMatrix.