Consolidez votre pile GitLab avec Gitaly sur Kubernetes

GitLab 18.11 apporte une bonne nouvelle pour les équipes qui exécutent GitLab sur Kubernetes : Gitaly sur Kubernetes est désormais en disponibilité générale. Auparavant, les équipes qui hébergeaient GitLab sur Kubernetes devaient maintenir une configuration hybride, car la plupart des composants GitLab fonctionnaient dans Kubernetes, tandis que Gitaly restait sur des machines virtuelles. Cette architecture hybride compliquait les opérations quotidiennes pour ces équipes. Cette époque est révolue : Gitaly sur Kubernetes est désormais une option de déploiement officiellement prise en charge.

Le chemin vers Kubernetes

Gitaly a des exigences strictes qui ne se transposent pas naturellement dans un environnement Kubernetes.

Les opérations Git peuvent être gourmandes en mémoire, et leurs schémas d'utilisation sont difficiles à prévoir. Pour protéger le processus principal de Gitaly contre les événements de dépassement de mémoire (OOM) et éviter les interruptions de service, Gitaly peut être configuré pour exécuter chaque processus Git dans un cgroup dédié. Dans cette configuration, le processus Gitaly réside dans un cgroup distinct de ceux utilisés par les processus Git. Si un processus Git dépasse la limite de mémoire de son cgroup et est interrompu, le processus principal de Gitaly n'est pas affecté.

La mise en œuvre de cette configuration dans un pod Kubernetes a nécessité un effort supplémentaire. La plupart des clusters Kubernetes utilisent containerd comme environnement d'exécution de conteneurs, et jusqu'à récemment, containerd n'autorisait les conteneurs à écrire dans cgroupfs que s'ils s'exécutaient en mode privilégié. La solution a consisté à monter /sys/fs/cgroup via un conteneur d'initialisation et à rendre le chemin accessible en écriture.

Les redémarrages de pods ont également demandé des ajustements supplémentaires. Sur une machine virtuelle, Omnibus peut mettre à jour le binaire Gitaly en place et recharger gracieusement en maintenant le socket ouvert tout en remplaçant le processus. Sur Kubernetes, en revanche, lorsqu'un pod de StatefulSet est remplacé, que ce soit en raison d'une mise à jour Helm, d'un drainage de nœud ou d'un changement de configuration, les pods Gitaly sont arrêtés puis redémarrés. Il s'agit d'un arrêt brutal, et non d’un redémarrage en douceur. Pour le mode sharded de Gitaly par exemple, qui n'offre pas de haute disponibilité, cela signifie une interruption de service qui peut s’avérer inacceptable pour certains clients.

Notre solution consistait à permettre la configuration des tentatives de reconnexion des clients. En configurant les clients Gitaly, comme Rails, pour qu'ils réessaient les requêtes suffisamment longtemps pour permettre à Gitaly de redémarrer et d’être à nouveau disponible, les utilisateurs peuvent constater une latence légèrement plus élevée pendant cette brève fenêtre, mais les requêtes aboutissent, et les interruptions de service sont évitées.

Pour confirmer que les tentatives de reconnexion des clients éliminaient effectivement les interruptions de service lors des mises à jour, nous avons réalisé une série de benchmarks. Nous avons exécuté des opérations Git courantes sur deux instances GitLab, l'une avec Gitaly sur des machines virtuelles, l'autre sur Kubernetes, puis déclenché une mise à jour en cours de test et suivi les taux de réussite des requêtes. Voici les résultats :

Les chiffres sont quasiment identiques dans les deux environnements. Ces résultats sont particulièrement encourageants en raison de la nature même de Kubernetes : un redémarrage de pod implique un arrêt brutal du processus et une fermeture immédiate du socket, et pourtant les taux de réussite sont restés élevés. Pour atteindre un taux de réussite de 100 % sur toutes les opérations, il faudrait recourir à notre solution de haute disponibilité, Gitaly Cluster (Praefect), qui ne prend pas encore en charge Kubernetes, bien que nous y travaillions activement et que sa mise à disposition générale soit prévue prochainement.

Ce que Gitaly sur Kubernetes signifie pour vous

Si vous utilisez GitLab en mode hybride, avec certains composants sur Kubernetes et Gitaly sur des machines virtuelles, vous pouvez désormais consolider votre infrastructure en déplaçant Gitaly dans le cluster. Vous n'aurez plus besoin de maintenir et de surveiller une flotte de machines virtuelles distincte en parallèle de vos nœuds Kubernetes et pourrez regrouper l'ensemble de votre pile GitLab dans un seul environnement géré par Kubernetes.

Si vous adoptez GitLab pour la première fois et que vous exploitez déjà des logiciels sur Kubernetes, vous bénéficiez maintenant d'un déploiement GitLab entièrement natif sur Kubernetes grâce à notre chart Helm.

Installation de Gitaly sur Kubernetes

La méthode recommandée pour déployer Gitaly sur Kubernetes consiste à utiliser le chart Helm GitLab. Avant de commencer, il est utile de consulter la documentation de Gitaly sur Kubernetes, qui couvre les points de configuration essentiels et vous aide à éviter les pièges courants.

Gitaly peut être déployé soit dans le cadre d'une installation complète de GitLab, soit en tant que composant externe. La documentation de Gitaly sur Kubernetes aborde les deux scénarios.