Depuis quelques années, je joue régulièrement avec un mixe de services Azure et on-premise sous Hyper-V. Dernièrement, je suis tombé sur un problème de stabilité qui m’a dérouté.

Le problème

Un cluster Kubernetes bâti sur RKE2 perdait régulièrement des nœuds (freeze, ou reboot qui n’aboutit pas et qui oblige l’arrêt brutal de la VM). Malheureusement, les logs de mes VM ne contenaient aucune erreur.

La solution

Ce cas de figure ne m’était jamais arrivé avec les clusters que j’avais installés avec kubeadm ou kubic. J’ai donc cherché l’élément qui différait. Je me suis rendu compte que la documentation de RKE2 manquait d’une recommandation que j’ai pu trouver sur tous les cluster Kuberntes que j’avais testés. Celle-ci conseille de désactiver le SWAP.

Après désactivation du SWAP sur l’ensemble des VM constituant mon cluster, celui-ci est devenu stable (plus aucun freeze ou problème de reboot).

Oui, j’ai bien conscience que le fait d’utiliser le mot "toujours" dans ce titre va m’attirer des problèmes. S‘il vous plait, prenez bien le temps de lire l'article en entier afin de comprendre le raisonnement qui m’a conduit à choisir ce titre.

J’ai beau être développeur .net depuis longtemps, je n’ai pas toujours utilisé Azure DevOps et ses prédécesseurs. Durant les années où je faisais du consulting, ceci était une véritable force.

Au fil du temps, j’ai été amené à faire un constat que je n’attendais pas. Il y a un problème qui finit toujours par se produire une fois la migration terminée : Azure DevOps s’adapte plus rapidement aux tendances du marché. Il intègre rapidement de nouveaux produits tiers, de nouvelles méthodes de travail, et de nouvelles fonctionnalités.

La belle plateforme que l’on a choisie devient alors un frein. Il faut savoir rester lucide et honnête. J’ai rencontré des décideurs qui ne voulaient pas admettre que leur solution d’ALM, DevOps, ou gestion de projet / ticketing était dépassée. Bien souvent, ce sont les mêmes qui ne voient pas l’intérêt de déployer les mises à jour, ou d’effectuer les migrations des produits qu’ils ont eu même choisis (qui a dit Log4J?).

Pendant de nombreuses années, le marché de la virtualisation a été considéré comme étant stable.

Et puis patatras :

• Broadcom rachète VMware. Ce qui fait peur à beaucoup de monde.
• Après des années d’immobilisme, Oracle change le modèle de licence du pack d’extension (celui-ci devient payant pour les usages professionnels).

Dans ce contexte, nombre d’entreprises se posent la question de trouver une solution alternative viable.

Ces dernières années, le DevOps est monté en puissance. Nombre d’éditeurs l’on comprit, et tentent de s’octroyer une part du gâteau en ajoutant des fonctionnalités de déploiement continu dans leurs produits.

Pour illustrer cet article, j’ai choisi deux produits qui illustrent bien les tendances du marché :

• Rancher : un outil d’administration de clusters Kuberntes.
• Keel : un orchestrateur de mises à jour de conteneurs.

Ces deux outils offrent la possibilité d’automatiser le déploiement d’application dans Kubernetes :

• Rancher : via les composants GitOps de Fleet.
• Keel : via des Webhooks sur les registres d'images.

L’un va donc s’intéresser à notre code, l’autre au produit de celui-ci. Les deux approches sont donc bien différentes. Partir sur un produit ou l’autre pour installer des conteneurs en continu n’est pas un choix à faire à la légère.

Voici un message d’erreur des plus insupportables :

Error CS0433

The type 'ServiceCollection' exists in both 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=6.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' and 'Microsoft.Extensions.DependencyInjection, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'

Une classe est présente dans deux DLL. Souvent, celles-ci ne sont pas référencées directement par le projet.

Pour résoudre le problème, il suffit de modifier le projet (fichier csproj ou vbproj). Il faut y ajouter les références aux packages incriminés, et fixer la version désirée.

Exemple :

<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="6.0.0" />
<PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="6.0.0" />

Conclusion

Même si PackageReference est pratique, il faut toujours rester vigilant concernant les références indirectes.