Fille sur un scooter. Illustration freepik, logo Nomad de HashiCorp

Kubernetes est un gorille de 300 kilos pour l'orchestration des conteneurs. Il fonctionne dans certains des plus grands systèmes de conteneurs au monde, mais cela coûte cher.

Surtout cher pour les petites équipes, qui devront passer beaucoup de temps à le maintenir et à faire face à une lourde courbe d'apprentissage. Pour notre équipe de quatre personnes, c'est trop de frais généraux. Nous avons donc commencé à rechercher des alternatives et sommes tombés amoureux de Nomad.

Ce dont nous avons besoin

Notre équipe prend en charge divers services typiques pour la surveillance et l'analyse des performances : points de terminaison API pour les métriques écrites en Go, exportation Prometheus, parseurs de journaux comme Logstash et Gollum, ainsi que des bases de données comme InfluxDB ou Elasticsearch. Chacune de ces services fonctionne dans son propre conteneur. Nous avons besoin d'un système simple pour maintenir tout cela opérationnel.

Nous avons commencé par une liste de critères pour l'orchestration des conteneurs :

• Lancement d'un ensemble de services sur plusieurs machines.
• Vue d'ensemble des services en cours d'exécution.
• Liens entre les services.
• Redémarrage automatique en cas de panne de service.
• Maintenance de l'infrastructure par une petite équipe.

De plus, les éléments suivants seraient agréables, mais non obligatoires :

• Étiquetage des machines par leurs capacités (par exemple, étiquetage des machines avec des disques rapides pour les services lourds en E/S).
• Capacité à lancer des services indépendamment de l'orchestrateur (par exemple, lors du développement).
• Endroit commun pour partager des configurations et des secrets.
• Point de terminaison pour les métriques et les journaux.

Pourquoi Kubernetes ne nous convient pas

Lors de la création d'un prototype avec Kubernetes, nous avons remarqué que nous commencions à ajouter des couches de logique de plus en plus complexes, sur lesquelles nous comptions irrévocablement.

Par exemple, Kubernetes prend en charge des configurations de services intégrées à travers ConfigMaps. Vous pouvez rapidement vous perdre, en particulier lors de la fusion de plusieurs fichiers de configuration ou de l'ajout de services supplémentaires dans un pod. Kubernetes (ou helm Dans ce cas, cela permet d'intégrer dynamiquement des configurations externes pour séparer les intérêts. Cependant, cela crée un lien rigide et caché entre votre projet et Kubernetes. Cela dit, Helm et ConfigMaps sont des options supplémentaires, donc vous n'êtes pas obligé de les utiliser. Vous pouvez simplement copier la configuration dans l'image Docker. Néanmoins, il est tentant de suivre cette voie et de créer des abstractions inutiles, ce dont vous pourriez regretter par la suite.

De plus, l'écosystème Kubernetes évolue rapidement. Il faut beaucoup de temps et d'énergie pour se tenir au courant des meilleures pratiques et des outils les plus récents. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - la liste continue et continue. Au début, tous ces outils ne sont pas nécessaires, mais vous ne savez pas ce dont vous aurez besoin, donc il faut être au courant de tout. Cela rend la courbe d'apprentissage assez raide.

Quand utiliser Kubernetes

Dans notre entreprise, beaucoup utilisent Kubernetes et en sont tout à fait satisfaits. Ces instances sont gérées par Google ou Amazon, qui ont les ressources nécessaires pour les soutenir.

Kubernetes est livré avec des fonctionnalités surprenantes, qui rendent l'orchestration à grande échelle des conteneurs plus gérable :

• Gestion détaillée des permissions.
• Des contrôleurs personnalisés ajoutent de la logique au cluster. Ce sont simplement des programmes qui communiquent avec l'API Kubernetes.
• Mise à l'échelle automatique! Kubernetes peut faire évoluer des services à la demande, en utilisant des métriques de service et sans avoir besoin d'intervention manuelle.

La question est de savoir si vous avez vraiment besoin de toutes ces fonctionnalités. Vous ne pouvez pas simplement compter sur les abstractions ; vous devrez découvrir ce qui se passe sous le capot..

Notre équipe fournit la plupart des services à distance (en raison d'un lien étroit avec l'infrastructure sous-jacente), donc nous ne voulions pas mettre en place notre propre cluster Kubernetes. Nous voulions simplement fournir des services.

Piles non incluses

Nomad est 20 % d'orchestration, qui fournit 80 % du nécessaire. Tout ce qu'il fait, c'est gérer les déploiements. Nomad s'occupe des déploiements, redémarre les conteneurs en cas de problèmes... et c'est tout.

Le sens de Nomad réside dans ce qu'il fait : pas de gestion détaillée des permissions ou minimumde politiques réseau avancées , c'est fait intentionnellement. Ces composants sont fournis de manière externe ou pas du tout., c'est intentionnel. Ces composants sont fournis par des tiers ou ne sont pas fournis du tout.

Je pense que Nomad a trouvé le compromis parfait entre simplicité d'utilisation et utilité. Il est idéal pour de petits services indépendants. Si vous avez besoin de plus de contrôle, vous devrez les gérer vous-même ou adopter une autre approche. Nomad est tout simplement un orchestrateur.

Ce qui est le meilleur dans Nomad, c'est sa facilité remplacer. La dépendance à un fournisseur est pratiquement inexistante, car ses fonctionnalités s'intègrent facilement dans tout autre système de gestion des services. Il fonctionne simplement comme un binaire ordinaire sur chaque machine du cluster, c'est tout !

L'écosystème de Nomad est constitué de composants faiblement couplés

La véritable force de Nomad réside dans son écosystème. Il s'intègre très bien avec d'autres produits — totalement optionnels — tels que Consul (stockage clé-valeur) ou Vault (gestion des secrets). Dans le fichier Nomad, il y a des sections pour extraire des données de ces services :

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

Ici, nous lisons la clé service/geo-api/log-verbosity de Consul et, pendant l'exécution, nous la présentons comme une variable d'environnement LOG_LEVEL. Nous présentons également la clé secret/geo-api-key de Vault comme API_KEY. Simple, mais puissant !

Grâce à sa simplicité, Nomad peut facilement être étendu avec d'autres services via l'API. Par exemple, des balises sont supportées pour les tâches. Nous étiquetons tous les services avec des métriques avec la balise trv-metrics. Ainsi, Prometheus peut facilement trouver ces services via Consul et vérifier périodiquement le point de terminaison /metrics pour de nouvelles données. Il en va de même, par exemple, pour les journaux, en utilisant Loki.

Il y a de nombreux autres exemples d'extensibilité :

• Lancer une tâche Jenkins à l'aide d'un hook, et Consul surveille le redéploiement de la tâche Nomad lors de changements de configuration du service.
• Ceph ajoute à Nomad un système de fichiers distribué.
• fabio pour la répartition de charge.

Tout cela permet de faire évoluer l'infrastructure sans lien particulier avec un fournisseur.

Avertissement honnête

Aucun système n'est parfait. Je ne recommande pas d'implémenter immédiatement les fonctionnalités les plus récentes en production. Bien sûr, il existe des bogues et des fonctionnalités manquantes, mais il en va de même pour Kubernetes.

Comparé à Kubernetes, la communauté de Nomad n'est pas aussi grande. Kubernetes a déjà près de 75 000 commits et 2000 contributeurs, tandis que Nomad en a environ 14 000 et 300. Il sera difficile pour Nomad de suivre le rythme de Kubernetes, mais peut-être que cela n'est pas nécessaire ! C'est un système plus spécialisé, et une communauté plus petite signifie aussi que votre pull request sera probablement remarquée et acceptée plus rapidement qu'avec Kubernetes.

Résumé

Conclusion : n'utilisez pas Kubernetes simplement parce que tout le monde le fait. Évaluez soigneusement vos besoins et vérifiez quel outil est le plus avantageux.

Si vous prévoyez de déployer un grand nombre de services homogènes sur une infrastructure à grande échelle, Kubernetes est une bonne option. Gardez simplement à l'esprit la complexité supplémentaire et les coûts d'exploitation. Certains frais peuvent être évités en utilisant un environnement Kubernetes géré, comme Google Kubernetes Engine ou Amazon EKS.

Si vous cherchez simplement un orchestrateur fiable, facile à maintenir et évolutif, pourquoi ne pas essayer Nomad ? Vous pourriez être surpris de l'ampleur de ce que cela peut vous apporter.

Si l'on compare Kubernetes à une voiture, Nomad serait un scooter. Parfois, vous avez besoin de l'un, et parfois de l'autre. Les deux ont leur raison d'être.

Source : habr.com