Kubernetes a-t-il besoin d’une LTS ?

Le cycle de vie de Kubernetes, inadapté à la réalité des déploiements ? Un DevOps l’affirme… et incite le projet à mettre en place une LTS.

À l’heure actuelle, les trois dernières versions mineures reçoivent des correctifs. Il en sort une toutes les 15 semaines environ. Chaque release bénéficie donc d’à peu près un an de support, auquel s’ajoute une période de transition de quelques semaines.

On ne peut raisonnablement pas espérer que les grandes entreprises suivent une telle cadence, affirme l’intéressé. Autant par le manque d’outillage que par le volume de breaking changes. En outre, créer à chaque fois de nouveaux clusters pour pouvoir changer de version engendre la duplication – et donc le gaspillage, même temporaire – de ressources. Il faut aussi changer un certain nombre d’éléments : pipelines CI/CD, DNS, documentation…

Et d’évoquer les CSP, qui ont élargi la fenêtre de support. Azure, par exemple, prend en charge chaque version pendant deux ans à partir de sa sortie. Google Cloud a quant à lui assuré, sur son offre GKE, un support effectif de Kubernetes 1.24 pendant 584 jours, et de la v1.26 pendant 572 jours.

Proposition : que le projet Kubernetes mette en place un canal LTS avec une cadence de 2 ans. Il n’y aurait pas de possibilité d’upgrade entre versions. Cela pousserait à créer régulièrement de nouveaux nœuds, et ainsi à rafraîchir la stack (etcd, contrôleurs ingress, etc.). La communauté disposerait d’une forme de « point focal », tout comme les éditeurs tiers.

Kubernetes et LTS : antinomique ?

Parmi les partisans d’une plus grande stabilité pour Kubernetes, on argumente, entre autres, du fait que :

– Kubernetes n’est pas que dans les datacenters
– Il ne s’améliore plus suffisamment pour justifier tant de breaking changes ; a fortiori quand on a accumulé les dépendances
– Beaucoup d’utilisateurs n’ont pas besoin des « nouvelles fonctionnalités »
– Une telle cadence fait qu’on est systématiquement en phase d’upgrade, d’autant plus que le saut de version n’est pas recommandé

Certains, à l’inverse, estiment que Kubernetes implique la flexibilité. Qu’il est fait pour accompagner les démarches DevOps et qu’il suppose donc un cycle continu de mise à jour. Exit, donc, « les grandes entreprises avec des processus de dev des années 90 », pour reprendre un témoignage. « Ne laissez pas votre stack vieillir ; les upgrades sont plus simples quand on les fait tôt et souvent », lui fait écho un autre.

Entre les deux, il y a ceux qui considèrent qu’il faut surtout améliorer le process d’upgrade, en particulier pour favoriser le saut de version. Il y a aussi ceux qui rappellent que LTS ne signifie pas absence de mises à jour, même si ces dernières sont censées être plus simples à déployer. Et ceux qui se demandent comment faire adopter aux projets amont (cert-manager, cilium…) le même cycle de vie.

Une autre question se pose, notamment eu égard aux pratiques des CSP : est-ce au projet Kubernetes de proposer une LTS ou est-ce aux distributions ? Aucun projet open source ne devrait avoir à s’engager sur cette voie, estime un utilisateur : que ceux qui ont besoin d’une LTS se tournent vers une offre commerciale.

Illustration © LuckyStep – Adobe Stock