"Nous avons quitté Kubernetes" : l'expérience d'un éditeur logiciel

En abandonnant Kubernetes, Gitpod s'est-il libéré d'un poids ? C'est tout comme, à en juger le bilan que l'éditeur américain tire de cette décision.

En 2019, il avait fait de Kubernetes le socle de son offre, qui consiste en une plateforme d'environnements de développement. Ces derniers ont des traits caractéristiques. Dont l'interactivité (composantes sujettes à de nombreux changements), l'usage imprévisible des ressources et le besoin de permissions étendues (accès root, gestion des paquets, montage de systèmes de fichiers...).

De l'avis de Gitpod, gérer ces éléments tout en assurant la sécurité et en optimisant l'usage des ressources présente des "défis immenses" avec Kubernetes.

Sur la gestion des ressources

L'exécution de plusieurs environnements sur un même noeud entraîne des effets de voisinage indésirables.

Gitpod a expérimenté la gestion CPU à travers des schémas basés sur le CFS (ordonnanceur de tâches de Linux). Mais le contrôleur implémenté dans ce cadre - sous forme de DaemonSet - ne permettait qu'une analyse après coup (valeur nr_throttled dans cpu_stats) ; pas l'anticipation.

Le mécanisme de priorisation des processus au sein des conteneurs de développement a aussi révélé des limites. Plus précisément, le fait que ce mécanisme s'appliquait au niveau des groupes de processus. Prioriser le serveur VS Code impliquait ainsi de prioriser également ses compilateurs... gourmands en ressources.

Pour ce qui est de la gestion mémoire, l'overbooking fut compliqué à mettre en place jusqu'en 2021 et l'intégration du swap dans Kubernetes.

Au niveau du stockage, la solution des SSD en RAID 0 fut retenue aux dépens des PVC (Persistent Volume Claims). Ceux-ci procurent de la flexibilité, mais engendrent divers problèmes : délai d'attachement imprévisible, soucis de fiabilité (en particulier chez Google Cloud en 2022, selon Gitpod), nombre limité de disques par instance...

Sur l'optimisation du temps de démarrage

L'optimisation de l'usage des ressources entre souvent en conflit avec la réduction du temps de démarrage des environnements. Pour tenter de trouver un équilibre, Gitpod a expérimenté des pods préemptibles (dits "workspaces fantômes"), qu'il a fini par faire évoluer afin qu'ils occupent un noeud complet - ce qui facilitait leur remplacement. La solution finalement retenue fut le plug-in cluster-autoscaler, introduit dans Kubernetes en 2022.

Fut par ailleurs mis en place un système d'autoscaling fonction du nombre d'environnements lancés. Il instancie des pods vides en utilisant l'image pause.

Non compressées, les images des workspaces peuvent dépasser 10 Go. Gitpod a donc testé, entre autres techniques :

• Prétirage des images communes
  Une solution qui s'est révélée inefficace lors de la mise à l'échelle. Au démarrage des workspaces sur un noeud nouvellement instancié, l'image n'était pas encore disponible. Le processus de prétirage entrait par ailleurs en concurrence avec les workspaces.
• Réutilisation des couches
  Gitpod a construit ses images avec un outil maison capable de gérer indépendamment les couches. La réutilisation est néanmoins restée difficile à observer, à cause notamment de la haute cardinalité.
• Lazy pulling
  Cette technique exige une conversion des images et certains registres n'étaient pas compatibles lorsque Gitpod l'expérimenta en 2022.
• Registry-facade + IPFS
  Une solution efficace, mais complexe...
• Intégration des images de workspaces dans les images disque des noeuds
  Le temps de démarrage s'améliore, mais les images deviennent vite obsolètes. Et ce mécanisme n'est pas compatible avec les installations autohébergées.

Sur la sécurité

Pour donner aux développeurs des privilèges "de type root" dans le conteneur sans compromettre la sécurité de l'hôte, Gitpod a exploité une fonctionnalité du noyau Linux : les namespaces d'utilisateurs. Il a toutefois fallu attendre Kubernetes 1.25 pour en bénéficier. La solution précédemment mise en place impliquait shiftfs pour basculer les UID des systèmes de fichiers. Fuse-overlayfs fut expérimenté en alternative, mais les performances s'avérèrent limitées. Quant aux montages idmapped, ils ont soulevé des problèmes de compatibilité et d'implémentation.

La solution impliquait aussi seccomp notify (interception et modification d'appels système) pour permettre le montage de /proc, dont le modèle de sécurité de Gitpod impose le masquage. Gitpod a par ailleurs dû, pour assurer le support de FUSE (Filesystem in Userspace), implémenter des politiques spécifiques, en particulier pour modifier le filtre eBPF du conteneur.

Il a également fallu créer un namespace réseau dans le conteneur (connecté vers l'extérieur d'abord via slirp4netns, puis via veth), afin d'éviter de lui accorder directement les privilèges CAPT_NET_ADMIN et CAP_NET_RAW.

Les micro-VM, un déclencheur

En 2023, Gitpod a expérimenté les micro-VM. Sur le papier, cette méthode améliore l'isolation et rend les performances plus prévisibles (pas de notion de ressources noyau partagées). Elle apporte aussi un système de snapshots mémoire avec restauration instantanée. Et rend potentiellement inutiles les mécanismes de namespace utilisateur, permettant une compatibilité avec davantage de workloads, dont la conteneurisation imbriquée.

Les micro-VM sont néanmoins plus lourdes que les conteneurs. En outre, la conversion des images OCI a exigé des outils spécifiques. Gitpod a aussi fait face à des limites techniques. Par exemple, sur Firecracker, la non-prise en charge des GPU. Et, au moment des expérimentations, l'absence de support de vitriofs, limitant les options de partage de système de fichiers. Sur Cloud Hypervisor, le processus de snapshot était plus lent, faute de prise en charge de userfaultd.

Gitpod n'a pas retenu l'approche micro-VM, mais celle-ci l'a convaincu, affirme-t-il, de se distancer de Kubernetes. Pas forcément, cependant, d'aspects fondamentaux comme les API déclaratives, que la nouvelle version de la plate-forme reprend. Le plan de contrôle est, lui aussi, largement inspiré de celui de Kubernetes. L'architecture a toutefois été améliorée, comme le socle de sécurité (modèle zero trust). Entre autres apports, la possibilité d'exécuter les environnements de développement sur desktop.

Illustration générée par IA