Nomad : choisir la simplicité et flexibilité

J’ai découvert Nomad, il y a trois ans. L’équipe cloud était contrainte et pas forcément bien valorisé. De plus on leur demandait une forte productivité pour aider l’efficience des équipes. De plus ils étaient aussi en charge de la gestion de matériel (ordi, souris, téléphones, etc). Lors de la recherche pour voir vers quoi on pourrait migrer, on a découvert Nomad.

J’avais surtout utilisé K8 jusque là. Et même si la compléxité de la chose (ou le surchoût lorsqu’il est exposé en PaaS) étaient pénibles, c’étaient malgré tout bien mieux que de faire du ansible ou du chef. Et lorsque j’ai dû me palucher les sources et l’architecture pour vraiment maîtriser la technologie a pu me donner envie de la jouer à la flamme bien moyenâgeuse !

Alors la découverte de Nomad, sa simplicité, son empreinte, et ses sources ce fût un coup de coeur presque immédiat. Et j’ai migré tout mon HomeLab dans l’année.

Lexique

Commençons par définir quelques termes qu’on va utiliser tout du long, et qui pourraient ếtre ambigues. C’est là mes définitions et si elles vous déplaisent, cassez-vous je suis pas là pour discuter lexique.

• K8: Kubernetes.
• HomeLab: Ma stack perso.
• Obfuscation: ction qui consiste, de manière intentionnelle, à rendre une information difficile à comprendre ou percevoir.

La simplicité opérationnelle

Là où Kubernetes implique une myriade de composants à maintenir et comprendre (etcd, kubelet, kube-apiserver, kube-controller-manager, kube-scheduler, CoreDNS, CNI, CSI, etc.), pour espérer survivre s’il arrive un vrai problème, Nomad reste incroyablement minimaliste : un binaire unique, facile à déployer, facile à mettre à jour. Que demande le peuple!

Mon home lab est fait d’une main-frame principal et d’un cluster de quelques dizaines de Pi. J’ai mis 3 semaines à lire les sources et comprendre l’architecture, et une demi-journée à installer mes bécannes, faire le hardening, et migrer mes services.

Quand j’ai déployé K8, j’ai passé 3 mois à lire toutes les sources et comprendre l’architecture. Et j’ai passé une semaine à le faire fonctionner chez moi de manière stable.

Les fichier de config font en tout moins de 100 lignes (même en prenant en compte le CoreDNS).

Cette simplicité le rend just un Must-Have pour les équipes petites Cloud, où on ne peut avoir des spécialistes devant uniquement (ou presque) intervenir sur K8, voir qu’ils soient certifiés. Et même pour les plus grandes, si on veut augmenter leur efficacité.

Moins d’abstractions, plus de contrôle

K8 introduit tellement de concepts abstraits (Pods, Deployments, ReplicaSets, Services, Ingress, CRDs, Operators…) que cela devient de l’obfuscation. C’est à ce demander si c’est pas fait exprès pour vendre de la certification… Et la plus part du temps, cela n’est en aucun cas nécessaire. En toute cas, tant que vous devez pas gérer une infrastructure complexe (si vous avez plus de 15 personnes dans l’équipe cloud, elle l’est), soit la majorité des entreprises.

Avec Nomad, la courbe d’apprentissage est beaucoup plus douce. Le job file (au format HCL) est lisible, explicite et facilement versionnable. Cela permet d’intégrer rapidement Nomad dans des pipelines GitOps sans dépendre d’autres outils ou descriptions comme Helm.

Polyvalence des workloads

Kubernetes est centré sur les conteneurs, ce qui est une bonne chose. Nomad orchestre les conteneurs, certes, mais aussi les binaires natifs, les VM, les fonctions, et même les workloads batch.

Cela me permet de : * Gérer des services en conteneur via Podman * Lancer des batchs en rust/go/python * Orchestrer des services qui se déploient mal sur containeur

Cette flexibilité s’est avérée précieuse dans une organisation où tout ne tourne pas encore sur conteneur. Je dirai même d’avoir un seul orchestrateur pour toutes les tâches, quels soient dans des conteneurs ou que ce soit des batch machine. Et oui, mes backup sont orchestrés par Nomad.

Faibles dépendences externes et intégration avec l’écosystème HashiCorp

Nomad s’intègre naturellement avec Consul pour la découverte de services, et Vault pour la gestion des secrets.

Je dois avouer que j’ai opinion forte, et pas positive, sur Consul et Vault. Même s’ils sont des standards de l’industrie… Malgré tout cela s’intégre très facilement avec! Et permet de faire presque faire du zero-trust sans rajouter de compléxité (est-ce que faire du zero-trust avec Vault peut être simple?, c’est un autre sujet… Spoileur: Non!).

J’utilise pour ma part CoreDNS, et grâcce à la facilité de CoreDNS utiliser le Service Discovery de Nomad pour exposer les machines/services est d’une simplicité enfantine! Et j’ai malheureusement Vault (mais je rêve d’un outil simple pour faire la gestion des secrets).

Malgré tout pour faire pareil que pour K8, j’ai seulement 2 outils à déployer. Et l’intégration/communication avec nomad est d’une facilité déconcertante. Ce qui est loin d’être le cas de K8… Très loin!

Moins de coûts cachés

Le coût d’exploitation d’un cluster K8 est souvent sous-estimé. Entre le temps de formation, le tuning, la maintenance des CRDs, les upgrades majeures de version (qui cassent parfois des APIs), et la surveillance de la couche réseau, K8s devient vite une plateforme à part entière. Et si on utilise le format PaaS d’un cloud public, on fait fois 3 minimum sur le coût d’infrastructure!

Pas besoin de certification, pas besoin d’un “spécialiste” en interne qui ne fait que ça ou presque, et surtout si un truc plante avec nomad, débugger c’est simple, même si les logs sont parfois pas très explicites. Enfin, ai-je parlé des coûts relié aux meurtre-suicide des équipes qui doivent upgrade/debug un K8?

Et c’est quoi le coût à payer?

• Moins d’écosystème communautaire
• Un pool de talent peut-être plus petit, si on enlève les gens voulant rester sur du K8
• Moins de plugins/CRDs que Kubernetes

Mais pour la plus part des cas d’usage, ce compromis est largement acceptable. Je préfére un outil simple et adaptable à un framework puissant mais trop complexe et coûteux à maintenir. Il faut se rappeler que K8 a été fait en se basant de l’outil de Google, si vous avez pas une complexité proche de la leur, il est fort à parier qu’il est pas pensé pour vous!

Conclusion

K8 est omniprésent. Même si c’est plus relié à un historique, et à sa masse critique. Du coup Nomad n’était pas forcément attendu. Pour ma part, ayant du gérer des emmerdes de K8, j’ai rapidement vue le merdier que c’est. Et la complexité qu’il inject, le tout seulement pour utiliser des conteneurs…

Si vous avez un niveau de compléxité de Google, fait du K8. Sinon, checkez Nomad. Il se focus sur l’essentiel: orchestrer des workloads de manière fiable, simple et fléxible.

Et dans un monde où les coûts d’infrastructure partent en vrille et où l’efficacté opérationnelle est nécessaire, c’est un avantage indéniable.