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.
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.
Regardez les vidéos
1. Runners & pipelines— autoscaling des charges de travail GitLab Runner sur Kubernetes.
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
- 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.
- Réduire fortementquand la demande disparaît — les pods disparaissent ; avec le redimensionnement automatique du cluster, les nœuds vides quittent le pool.
- Arrêter de gaspiller CPU, la RAM et le stockagesur des flottes de runners toujours actifs pendant les heures calmes.
- 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.