Gitpod décide de quitter Kubernetes et annonce Gitpod Flex

• Depuis 6 ans, Gitpod utilise Kubernetes pour construire une « plateforme d’environnements de développement distants », prenant en charge 1,5 million d’utilisateurs et fournissant chaque jour des milliers d’environnements de développement
• Mais l’entreprise a réalisé que Kubernetes n’est pas adapté à la création d’environnements de développement
• Il ne s’agit pas ici de savoir s’il faut ou non utiliser Kubernetes pour des workloads de production, ni de la manière de concevoir une expérience développeur pour déployer des applications sur K8s
  → Il s’agit de la manière de construire des environnements de développement dans le cloud (ou de ne pas le faire)

[Pourquoi les environnements de développement sont particuliers]

• Ils sont fortement stateful et très interactifs
  • Ils ne peuvent pas être déplacés d’un nœud à l’autre
  • De grandes quantités de code source, de cache de build, de conteneurs Docker, de données de test, etc. changent fréquemment, et le coût de migration est élevé
  • Contrairement aux services de production, la relation entre le développeur et l’environnement est de type 1 pour 1
• Les développeurs sont fortement liés à leur code source et à leurs modifications
  • Ils n’aiment pas perdre leurs changements ni être bloqués par le système
  • Les environnements de développement sont particulièrement sensibles aux défaillances
• Ils présentent des schémas d’utilisation des ressources imprévisibles
  • La plupart du temps, ils n’ont pas besoin de beaucoup de bande passante CPU, mais peuvent soudain nécessiter plusieurs cœurs en quelques centaines de ms
  • Si c’est plus lent, cela se traduit par une latence inacceptable et une absence de réponse
• Ils nécessitent des privilèges et des capacités étendus
  • Contrairement aux workloads de production, ils ont besoin d’un accès root et de la capacité à télécharger/installer des paquets
  • Ce qui est un problème de sécurité pour des workloads de production est un comportement attendu dans un environnement de développement (accès root, capacités réseau étendues, montages de systèmes de fichiers supplémentaires, etc.)
• Ces caractéristiques les distinguent des workloads applicatifs classiques et influencent fortement les décisions d’infrastructure

[Système actuel : Kubernetes]

• Aux débuts de Gitpod, Kubernetes semblait être un choix d’infrastructure idéal
  • Sa scalabilité, l’orchestration de conteneurs et la richesse de son écosystème correspondaient bien à la vision d’environnements de développement cloud
• Mais avec la montée en charge et l’élargissement de la base d’utilisateurs, des difficultés sont apparues en matière de sécurité et de gestion de l’état
  • Kubernetes est conçu pour exécuter des workloads applicatifs bien contrôlés, pas des environnements de développement difficiles à maîtriser
• Gérer Kubernetes à grande échelle est complexe
  • Des services managés comme GKE ou EKS atténuent une partie du problème, mais avec leurs propres contraintes et limites
• De nombreuses équipes qui veulent exploiter des CDE ont tendance à sous-estimer la complexité de Kubernetes
  • Cela a entraîné une charge de support importante sur l’ancien produit Gitpod auto-hébergé

La difficulté de la gestion des ressources

• L’allocation CPU et mémoire est le principal casse-tête
• Le partage d’un nœud entre plusieurs environnements semble séduisant, mais en pratique l’effet de noisy neighbor est important
• Problèmes CPU
  • Les environnements de développement ont peu besoin de CPU la plupart du temps, puis en demandent beaucoup de manière soudaine
  • Des solutions basées sur CFS et des contrôleurs personnalisés ont été testés, mais les besoins restent difficiles à prévoir
  • Même avec des limites CPU statiques, plusieurs processus entrent en concurrence
• Gestion de la mémoire
  • Allouer une quantité fixe de mémoire est simple mais limitant
  • L’overbooking peut conduire à l’arrêt de processus
  • L’introduction du swap a quelque peu réduit la nécessité d’overbooking

Optimisation des performances de stockage

• Les IOPS et la latence influencent l’expérience des environnements de développement
• Diverses configurations ont été testées afin de trouver un équilibre entre vitesse, stabilité, coût et performance
  • SSD RAID 0
  • Stockage bloc comme EBS ou disque persistant
  • PVC
• Les opérations de sauvegarde/restauration sont coûteuses

Autoscaling et optimisation du temps de démarrage

• Réduire au minimum le temps de démarrage est l’objectif prioritaire
• On pensait qu’exécuter plusieurs workspaces sur un même nœud améliorerait le temps de démarrage grâce au cache partagé, mais ce n’était pas le cas
• Kubernetes impose une borne basse au temps de démarrage
• Évolution de la méthode de scale-out
  • Des expériences de scale-out ont été menées avec des ghost workspaces et des ballast pods
  • L’introduction d’un plugin d’autoscaler a fortement amélioré la stratégie de montée en charge
• Autoscaling proportionnel pour faire face aux pics de charge
  • Démarrer des pods vides permet de réagir rapidement aux hausses soudaines de la demande
• Diverses tentatives d’optimisation du pull d’images
  • Pré-pull via DaemonSet, maximisation de la réutilisation des couches, images préconstruites, Stargazer et lazy pulling, Registry-facade + IPFS

Complexité réseau

• Contrôle d’accès aux environnements de développement
  • Les environnements doivent être totalement isolés les uns des autres
  • Les network policies aident, mais des problèmes de fiabilité apparaissent quand le nombre de services augmente
• Partage de la bande passante réseau
  • Le CNI peut prendre en charge le network shaping, mais cela ajoute encore une couche de contrôle à gérer

Sécurité et isolation : équilibrer flexibilité et protection

• Le plus grand défi est d’offrir un environnement sécurisé tout en donnant de la flexibilité aux utilisateurs
• Donner des privilèges root aux utilisateurs présente de nombreuses failles
• Les user namespaces constituent une solution plus fine
  • Conversion des UID du système de fichiers, montages proc masqués, prise en charge de FUSE, capacités réseau, activation de Docker
• Difficultés de mise en œuvre des user namespaces
  • Impact sur les performances, problèmes de compatibilité, complexité, adaptation aux versions de Kubernetes

[Expérimentations autour des micro-VM]

• Face aux limites de Kubernetes, Gitpod a commencé à explorer les technologies de micro-VM (uVM) comme Firecracker, Cloud Hypervisor et QEMU comme solution intermédiaire
• L’idée était d’améliorer l’isolation des ressources, de conserver la compatibilité avec d’autres workloads (dont Kubernetes) et de renforcer la sécurité, tout en gardant les avantages de la conteneurisation
• Avantages des micro-VM
  • Elles offrent des bénéfices attractifs, bien alignés avec les objectifs des environnements de développement cloud
  • Meilleure isolation des ressources : la capacité d’overbooking diminue, mais l’isolation des ressources est meilleure qu’avec des conteneurs. La disparition de la contention sur les ressources du noyau partagé améliore la prévisibilité des performances par environnement
  • Snapshots mémoire et reprise rapide : la fonctionnalité userfaultfd de Firecracker prend en charge les snapshots mémoire. Elle permet de reprendre presque instantanément l’ensemble d’une machine, y compris les processus en cours. Pour les développeurs, cela signifie un démarrage beaucoup plus rapide et une reprise immédiate là où le travail s’était arrêté
  • Meilleure frontière de sécurité : les uVM peuvent servir de frontière de sécurité robuste, rendant inutiles les mécanismes complexes de user namespaces implémentés sur Kubernetes. Cela peut aussi offrir une compatibilité complète avec une plus grande variété de workloads, y compris la conteneurisation imbriquée (exécuter Docker ou Kubernetes dans l’environnement de développement)
• Difficultés des micro-VM
  • Mais ces expérimentations ont aussi révélé plusieurs défis majeurs
  • Overhead : même légères, les uVM entraînent plus d’overhead que les conteneurs. Cela affecte à la fois les performances et l’utilisation des ressources, ce qui est critique pour une plateforme d’environnements de développement cloud
  • Conversion d’images : transformer des images OCI en systèmes de fichiers utilisables dans des uVM nécessite des solutions personnalisées. Cela complexifie le pipeline de gestion des images et peut affecter le temps de démarrage
  • Limitations propres à certaines technologies
    • Firecracker : absence de prise en charge du GPU (de plus en plus important pour certains workflows de développement), absence de prise en charge de virtiofs (ce qui limite les options efficaces de partage de système de fichiers)
    • Cloud Hypervisor : absence de prise en charge de userfaultfd, ce qui ralentit les processus de snapshot et de restauration (et annule un avantage clé des uVM)
  • Problèmes de déplacement des données : les uVM impliquent de manipuler de gros snapshots mémoire, ce qui complique davantage les transferts de données. Cela affecte à la fois l’ordonnancement et le temps de démarrage, deux éléments centraux de l’expérience utilisateur
  • Considérations sur le stockage : les essais de connexion de volumes EBS à des micro-VM ont ouvert de nouvelles possibilités, mais aussi de nouvelles questions
    • Stockage persistant : conserver le contenu des workspaces sur des volumes attachés éviterait de récupérer à répétition les données depuis S3, ce qui pourrait améliorer le temps de démarrage et réduire l’utilisation réseau
    • Considérations de performance : partager des volumes à haut débit entre workspaces pourrait améliorer les performances d’E/S, mais soulève aussi des inquiétudes sur l’implémentation efficace de quotas, la gestion de la latence et la garantie de la scalabilité
• Enseignements tirés des expérimentations sur les micro-VM
  • Même si les micro-VM ne sont finalement pas devenues la solution d’infrastructure principale, ces essais ont apporté des enseignements précieux
  • Gitpod a particulièrement apprécié l’expérience de sauvegarde complète des workspaces et de suspension/reprise de l’état d’exécution
  • Pour la première fois, l’équipe a commencé à envisager de sortir de Kubernetes. Après des efforts pour intégrer KVM et des uVM dans des pods, elle s’est mise à explorer des options hors de Kubernetes
  • Le stockage a été réidentifié comme un élément clé pour offrir en même temps trois objectifs : des performances de démarrage stables, des workspaces fiables (prévention des pertes de données) et une utilisation optimale des machines

Kubernetes est extrêmement difficile comme plateforme d’environnements de développement

• Comme indiqué plus haut, les environnements de développement exigent un système qui respecte leur nature stateful particulière
• Il faut garantir des frontières de sécurité sûres tout en accordant aux développeurs les privilèges nécessaires à leur productivité
• Et il faut accomplir tout cela avec un overhead opérationnel limité, sans compromettre la sécurité
• Aujourd’hui, il est possible d’atteindre tout cela avec Kubernetes, mais à un coût considérable
• Gitpod a appris à la dure la différence entre workloads applicatifs et workloads système
• Kubernetes est incroyablement remarquable
• Il s’appuie sur une communauté passionnée et a construit un écosystème réellement riche
• Si vous exécutez des workloads applicatifs, Kubernetes reste un bon choix
• Mais pour des workloads système comme les environnements de développement, Kubernetes apporte d’énormes défis en matière de sécurité et d’overhead opérationnel
• Les micro-VM et des budgets de ressources clairs aident, mais le coût devient alors un facteur encore plus déterminant
• C’est pourquoi, après des années à rétroconcevoir et forcer les environnements de développement à entrer dans une plateforme Kubernetes, l’équipe a pris du recul pour réfléchir à ce que devrait être l’architecture de développement du futur
• En janvier 2024, elle a commencé à la construire, puis a lancé Gitpod Flex en octobre
• Plus de six années d’enseignements durement acquis sur l’exécution sécurisée d’environnements de développement à l’échelle d’Internet sont désormais intégrées aux fondations de cette architecture

L’avenir des environnements de développement

• Avec Gitpod Flex, Gitpod conserve certains aspects fondamentaux de Kubernetes — l’application libre de la théorie du contrôle et les API déclaratives — tout en simplifiant l’architecture et en améliorant les fondations de sécurité
• Les environnements de développement sont orchestrés via un control plane fortement inspiré de Kubernetes
• La plateforme introduit les couches d’abstraction nécessaires, spécifiques aux environnements de développement, et supprime l’essentiel de la complexité d’infrastructure superflue
• Le tout avec la sécurité zero trust comme priorité absolue
• Cette nouvelle architecture permet aussi une intégration fluide des dev containers
• Elle ouvre également la possibilité d’exécuter des environnements de développement sur desktop
• Comme il n’est plus nécessaire de supporter tout le poids d’une plateforme Kubernetes, Gitpod Flex peut désormais être déployé en auto-hébergé en moins de 3 minutes, et sur autant de régions que souhaité
• Cela offre un contrôle plus fin sur la conformité et davantage de flexibilité pour modéliser les frontières organisationnelles et les domaines

(C’était à l’origine un autre article, mais il semblait pertinent de les regrouper.)

Gitpod Flex

• Première plateforme d’automatisation pour des environnements de développement zero trust
• Conçue pour fonctionner sur laptop, dans le cloud et on-premise, tout en gardant le code source, les données et la propriété intellectuelle dans un réseau privé
• Fournit des briques de base pour automatiser le cycle de vie du développement logiciel, en commençant par les environnements de développement
• Automations
  • Tâches et services programmables définis via des dépôts ou des API
  • Aident les développeurs à résoudre eux-mêmes leurs problèmes, tout en permettant aux équipes de productivité développeur de centraliser l’amélioration des environnements de développement
  • Offrent davantage qu’une simple exécution de scripts
  • Peuvent servir au provisioning et au seeding de bases de données, à la personnalisation des workflows développeur, à l’exécution de clusters temporaires, à la mise en place de workflows d’agents basés sur des LLM, ou encore à l’application centralisée de politiques globales/locales de sécurité et de conformité
• Environnements zero trust
  • Tous les acteurs et services sont traités selon le principe « ne jamais faire confiance, toujours vérifier »
  • Blocage complet des acteurs malveillants, forte réduction de la surface d’attaque, diminution des risques de malware ou d’exfiltration de code
  • Inclut une évaluation continue et une vérification explicite, un chiffrement de niveau entreprise validé, un contrôle d’accès granulaire, un contrôle complet du réseau et un journal d’audit exhaustif
  • Le point le plus important est de conserver le code source, les données et la propriété intellectuelle au sein d’un réseau privé
• Gitpod Desktop
  • Permet de standardiser et d’automatiser les environnements de développement locaux
  • Prise en charge initiale d’Apple Silicon
  • Propose une latence nulle, une alternative plus rapide, plus légère et plus simple à Docker Desktop pour le développement, une optimisation des coûts via l’exploitation du calcul local, et une reprise après incident en cas d’interruption du cloud ou des endpoints
• Prise en charge des Development Containers
  • Intégration complète de la spécification Dev Container
  • Les configurations Dev Container existantes peuvent être utilisées sans modification
  • Compatibilité avec VS Code et d’autres outils pris en charge
  • Travail cohérent aussi bien en local que dans le cloud
  • L’adoption du standard Dev Container facilite la définition, le partage et la gestion des environnements de développement

Une base pour les 10 prochaines années d’automatisation du développement logiciel

• Nous avons pensé les environnements de développement de manière trop étroite
• Un environnement de développement est plus qu’un IDE, des dépendances et des outils : c’est l’espace fondamental dans lequel le logiciel est créé
• C’est là que s’effectuent le prototypage du code, la mise en forme par les humains et les machines, les tests, le refactoring, la compilation, le packaging, la signature et le déploiement
• Il offre un accès inégalé au contexte de développement, aux workflows et aux insights, permettant des fonctionnalités qui distinguent la plateforme des autres plateformes de développement
• Vision produit
  • L’intégration continue (CI) fusionne avec l’environnement de développement
  • Il joue le rôle de System of record du développement logiciel
  • Il devient une plateforme pour la prochaine génération d’outils développeur
• Au-delà d’une simple amélioration des pratiques de codage, l’objectif est de bâtir, pour les 10 prochaines années, le moyen le plus rapide et le plus sûr pour les entreprises — des startups aux sociétés du Fortune 50 — de passer à l’échelle et de réussir

[ahwjdekf]

Des entreprises coréennes qui, sous prétexte de sécurité, imposent l’usage forcé de bureaux virtuels avec seulement 8 Go de mémoire. C’est amer.

[bus710]

Il est déjà difficile de trouver des personnes qui maîtrisent bien Kubernetes, alors j’ai l’impression qu’il sera encore plus difficile de trouver des gens capables de comprendre et d’essayer les alternatives proposées ici.

[xguru]

Avis Hacker News

• Les développeurs devraient posséder l’outil de développement qu’ils utilisent. Si un environnement cohérent est nécessaire, le développeur doit posséder sa propre machine et recevoir une image VM stable. Les tentatives de déplacer l’environnement de développement vers un hôte distant échouent le plus souvent. Fournir un matériel adapté aux développeurs est plus rentable que des ressources distantes. Il faut prendre en charge l’exécution de la stack en local, ce qui aide à maintenir la cohérence via des conteneurs. Des outils sont nécessaires pour générer des données dans l’environnement local, et cela peut être automatisé. Il y a des inconvénients liés à la gestion des données, mais dans la plupart des entreprises, la capacité d’exécution de l’équipe compte davantage que le code source.

• Utiliser Kubernetes pour des workloads de production est une question distincte ; ici, il s’agit de la manière de construire des environnements de développement dans le cloud. Article intéressant sur les compromis d’ingénierie liés à la complexité de Kubernetes

• L’article explique les problèmes de Kubernetes et les solutions essayées, mais manque d’explications sur l’alternative finalement choisie. Une nouvelle solution appelée Gitpod Flex est mentionnée, mais il y a très peu d’informations à son sujet

• Kubernetes convient aux workloads stateless, mais lorsqu’il y a de l’état, LXC est plus adapté. LXC peut être clusterisé de manière similaire à K8S et expose des outils au data plane. Il fournit des instances système comparables à des VM, avec des performances proches des conteneurs Docker. Il utilise une syntaxe déclarative et peut servir de couche de base à un cluster Kubernetes.

• En construisant une solution de CI, choisir Kubernetes montre qu’on n’a pas bien compris le problème. Il faudrait utiliser des outils comme Firecracker à des fins de sécurité.

• Kubernetes ne convient pas aux environnements de développement. Un environnement de développement est toujours dans un état changeant. Je ne comprends pas la nécessité d’un environnement de développement cloud. Le but d’une application conteneurisée est d’éviter de devoir synchroniser les environnements de développement entre équipes.

• L’article sur Kubernetes ne mentionne comme cas d’usage unique qu’une combinaison de workflows à faible latence et à forte latence. Il est difficile de justifier l’usage de Kubernetes pour le problème de Gitpod.

• J’ai travaillé sur un projet similaire à Gitpod, et je ne comprends pas l’idée d’utiliser des micro-VM pour remplacer Kubernetes. Kubernetes peut orchestrer des conteneurs externes et peut être utilisé pour exécuter des micro-VM. Le plus gros problème concerne le stockage.

• Construire des environnements de développement sur Kubernetes est du gaspillage. Lorsque le produit est auto-hébergé sur l’infrastructure du client, le débogage et le support deviennent difficiles. Il est efficace d’exposer aux ingénieurs les problèmes de réseau, de mémoire, de calcul et de stockage. Kubernetes est une montée en gamme pour les grandes équipes.