🤼‍♂️ Debat Kubernetes et LTS | Actus DevOps decembre 2023

cchaudier · Décembre 21, 2023, 9:05

Quelles sont les dernières nouveautés dans le monde du Cloud et du devops ?

Comme à notre habitude nous voilà de retour avec l’Actus DevOps mensuel, pour t’aider dans ta veille.

Aujourd’hui, je suis avec @erwan, @DamyR et @Uggla ensemble on parle de :
Faille de sécurité chez Okta - le retour
Rapport de la CNCF sur les tendances
Nouveautés chez nos fournisseurs cloud
Kube a-t-il besoin d’une LTS ?

#RadioDevOps est le podcast dédié à notre mouvement issu de la communauté des #CompagnonsDuDevOps. Radio DevOps est disponible dans toutes les applications de podcast.

Et pour toi c’était quoi les nouvelles marquantes DevOps ou cloud de ce mois ?

cchaudier · Décembre 21, 2023, 9:05

JeromeB · Décembre 21, 2023, 12:44

Dire, “prenez Kubernete en managé si vous n’avez pas les moyens de gérer les updates et maintenir un cluster”, je trouve que ce n’est pas une vraie réponse à la question de la LTS.

Une petite équipe peut avoir envie d’avoir la maîtrise de sa stack, la LTS est une très bonne réponse à ce besoin. Les LTS sont mises à jour régulièrement (et elles sont souvent maintenue par les équipes produit pour beaucoup de technos d’ailleurs), car on sait qu’il n’y aura pas rupture de compatibilité, normalement, on y retrouve que de la correction de bug et de faille de sécurité. Le passage à la nouvelle LTS étant fait avec plus de vigilance et de tests en amont.

olivierM · Décembre 21, 2023, 3:09

Et c’est quoi ce backstage ? Un developer portal ? Comprend pas.

DamyR · Décembre 23, 2023, 1:52

Comme j’ai dis, mon expérience malheureusement montre que quand l’équipe est trop petite les LTS finissent juste par repousser tellement les updates que plus personnes les fait. Je suis pas foncièrement contre les LTS, mais contre la vision que je voie de la LTS va permettre d’avoir un système qu’on update pas.

Pour le coup, j’ai vécu ça dans une petite boite, passage de Debian à Ubuntu car LTS plus longue à cette époque. Résultat, les trucs n’était plus jamais mis à jour.

Il me semble que je le dis à la fin, why not tant que ça ralentis pas le reste. Mais personnellement j’ai plus peur de voir des gens plus update. Je préfère avoir une solution d’auto-update, quitte à conserver plus longtemps certains chemin d’API.

JeromeB · Décembre 23, 2023, 4:41

Ne pas mettre à jour son applicatif est une mauvaise pratique, ce n’est pas une question de LTS ou de rolling release. J’ai vécu ça dans une expérience ancienne : des outils utilisés par tout le monde mais jamais mis à jour, les outils n’étaient pas maintenus par faignantise rien à voir avec la dispo de LTS ou non.

Pour ma part, j’ai arrêté les autoupdate sur la prod, car j’ai eu des mauvaises surprises (ie. arrêt de service). Ca impose une certaine rigueur de suivre ses updates manuellement. Sauf CVE grave nécessitant un update immédiat, pour gérer cela dans l’équipe, on utilise l’outil Kanboard, on peut y créer des taches périodiques, les déplacer automatiquement de colonne selon la proximité de la “due date”, les attribuer.

Comme on gère manuellement les updates, mais que c’est que 5% (au doigt mouillé) de notre temps dans une équipe de 3 personnes, nous sommes très friand de version sur branches maintenue en long terme, car ça permet de faire de l’update régulier et sans stress. A tel point que ne pas avoir de LTS est un gros red flag lors d’un choix de techno.

DamyR · Décembre 26, 2023, 8:24

Ne pas mettre à jour son applicatif est une mauvaise pratique,

Je pense qu’on est tous d’accord là dessus.

les outils n’étaient pas maintenus par faignantise rien à voir avec la dispo de LTS ou non

C’est justement tout mon point, j’aimerais qu’on mettent plus d’effort sur le process d’upgrade, car peu de gens l’automatise et ça c’est un gros soucis. Encore une fois je ne suis pas contre les LTS, mais ça ne va pas résoudre le problème de font des clusters pas upgrade. Je pense sérieusement qu’investir dans un système plus complet pour faire les upgrades facilement serait bien plus efficace.

Pour ma part, j’ai arrêté les autoupdate sur la prod, car j’ai eu des mauvaises surprises (ie. arrêt de service).

Personnellement pas le choix que de les faire en automatique. Quand on commence à avoir plus d’un millier de serveurs, c’est compliqué (on est 4 après, mais beaucoup d’autre choses à gérer). Globalement on a deux solutions pour gérer ça :

Upgrade des préprods la nuit à N-1 et alerte en cas de soucis si pas de contre indication ou remonté négatif upgrade auto en prod.
Build des images la nuit application en rollout, le rollout stop en cas de soucis

Pour moi les updates doivent être gérer en automatique, la balance de risque avec un minimum de test penche souvent de ce côté.

Encore une fois, c’est pas une mauvaise chose les LTS, mais je préfererais une solution d’upgrade en continue. Dans l’idéal les deux. Surtout que les composants de Kubernetes font que l’upgrade en continue est possible, juste que toutes les boites n’ont pas les moyens de la mettre en place.

jderrien · Décembre 26, 2023, 2:26

Voilà la page du projet : https://backstage.spotify.com/

Il y a une vidéo de présentation et une démo

JeromeB · Décembre 27, 2023, 9:31

Je n’ai malheureusement pas la chance d’avoir une preprod équivalente en terme de sollicitation à la prod. Il y a toujours un “gap” de test (surtout du point de vue monté en charge) lors des déploiements en prod.

C’est un autre sujet (qui semble lié), mais je suis preneur de retour sur ce qui permet d’avoir un environnement de test suffisamment sûr pour permettre des changements en prod “automatique”.

damien.vergnaud · Décembre 30, 2023, 1:35

Salut,

Je passe pour dire que je partage l’avis de Damyr exprimé dans le podcast et sur le forum et rajouter de l’eau au moulin.

Côté organisation de la team qui gère l’installation K8S :

Le LTS force la mauvaise fainéantise, celle qui vous pousse à attendre le dernier moment pour faire vos mises à jour, je constate les mêmes choses que Damyr avec les versions d’OS.
La plupart des K8S managés (Vu pour AKS et EKS) proposent des procédures de mises à jour propres et simplifiées à mon sens, si vous suivez les docs scrupuleusement, et que vous posez les bonnes questions, vous ne pouvez pas vous faire piéger.
Si vous maintenez un K8S home-made et que les mises à jours vous font peur, vous avez d’autres problèmes avec votre installation K8S qui vont au delà des mises à jour et qui devraient vous inquiéter d’avantage.

Côté Projet K8S :

Cela retarde la boucle de feedback sur les nouvelles fonctionnalités auprès des éditeurs, ceux sur LTS ne battle test pas les nouvelles fonctionnalités.
Cela complique la vie des contributeurs OpenSource de K8S pour qui, le cahier de charge, devras aussi prendre en compte le passé, c’est à votre pipeline de CI/CD ou à un humain de valider la bonne intégration des futures versions de K8S et de prendre en charge les dépréciations d’API / compatibilité avec vos applications.

Dans la mesure ou la LTS est un “à côté” de la méthode de mise à disposition actuelle de K8S, et que c’est juste les cloud providers qui vont devoir intégrer les version LTS en plus, je ne m’y oppose pas, mais franchement, je vois pas ou est le problème avec la manière de faire actuelle.

tristan · Janvier 2, 2024, 2:00

Hello!

J’ai enfin pris le temps d’écouter l’épisode hier dans le train sur le retour des vacances. Très sympa de vous écouter comme d’habitude. Je réagis sur les outils et notamment MetalLB que j’avais considéré un moment pour finir par me tourner vers KubeVIP. Ça me permet de gérer un fail over des IPs que j’utilise pour mes Ingress. Ça peut également fonctionner en mode BGP mais j’utilise le mode ARP.

D’ailleurs, pour les amateurs de Cilium, je n’ai pas encore testé mais la même fonctionnalité est déjà implémentée (toujours en béta) : L2 Announcements / L2 Aware LB (Beta) — Cilium 1.14.5 documentation