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

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

Particulièrement cher pour les petites équipes qui doivent consacrer beaucoup de temps au support et à une courbe d'apprentissage abrupte. Pour notre équipe de quatre, c'est trop de frais généraux. Nous avons donc commencé à chercher des alternatives - et sommes tombés amoureux de Nomad .

Que veux tu

Notre équipe prend en charge un certain nombre de services typiques de surveillance et d'analyse des performances: points de terminaison API pour les mesures Go, exportation de Prometheus, analyseurs de journaux tels que Logstash et Gollum , ainsi que des bases de données telles que InfluxDB ou Elasticsearch. Chacun de ces services s'exécute dans son propre conteneur. Nous avons besoin d'un système simple pour maintenir tout cela opérationnel.

Nous avons commencé avec une liste d'exigences pour l'orchestration de conteneurs:

• Lancer un ensemble de services sur de nombreuses machines.
  
• Présentation des services en cours d'exécution.
  
• Communication entre services.
  
• Redémarrage automatique en cas de panne du service.
  
• Maintenance des infrastructures par une petite équipe.

De plus, les éléments suivants seront intéressants, mais pas obligatoires:

• Marquage des machines en fonction de leurs capacités (par exemple, marquage des machines à disques rapides pour les services d'E / S lourds).
  
• La capacité d'exécuter des services indépendamment de l'orchestre (par exemple, pendant le développement)
  
• Un lieu 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 nous appuyions inconditionnellement.

Par exemple, Kubernetes prend en charge les configurations de service intégrées via ConfigMaps . Vous pouvez vous perdre rapidement, en particulier lors de la fusion de plusieurs fichiers de configuration ou de l'ajout de services supplémentaires au module. Kubernetes (ou barre dans ce cas) vous permet d'implémenter dynamiquement des configurations externes pour séparer les intérêts. Mais cela conduit à une connexion secrète entre votre projet et Kubernetes. Cependant, Helm et ConfigMaps sont des options supplémentaires, vous n'avez donc pas à les utiliser. Vous pouvez simplement copier la configuration dans l'image Docker. Néanmoins, il est tentant de suivre cette voie et de construire des abstractions inutiles, que vous pouvez regretter plus tard.

De plus, l'écosystème Kubernetes se développe rapidement. Il faut beaucoup de temps et d'énergie pour rester à jour avec les meilleures pratiques et les derniers outils. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - la liste s'allonge encore et encore. Au début du travail, tous ces outils ne sont pas nécessaires, mais vous ne savez pas ce qui est nécessaire, vous devez donc être au courant de tout. Pour cette raison, la courbe d'apprentissage est assez abrupte.

Quand utiliser Kubernetes

Dans notre entreprise, beaucoup utilisent Kubernetes et en sont très satisfaits. Ces instances sont gérées par Google ou Amazon, qui disposent de ressources d'assistance suffisantes.

Kubernetes est livré avec des fonctionnalités incroyables qui le rendent plus gérable et une orchestration de conteneurs à grande échelle:

• Gestion détaillée des droits .
  
• Les contrôleurs personnalisés ajoutent une logique au cluster. Ce ne sont que des programmes qui communiquent avec l'API Kubernetes.
  
• Autoscaling ! Kubernetes peut faire évoluer les services à la demande à l'aide de mesures de service sans nécessiter 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 l’abstraction; vous devez savoir ce qui se passe sous le capot .

Notre équipe fournit la plupart des services à distance (en raison de la connexion étroite avec l'infrastructure principale), nous ne voulions donc pas développer notre propre cluster Kubernetes. Nous voulions simplement fournir des services.

Piles non incluses

Nomad représente 20% de l'orchestration, ce qui donne 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 d'erreur ... et c'est tout.

L'intérêt de Nomad est qu'il fait un minimum : aucune gestion détaillée des droits ou politiques réseau avancées n'est conçue de manière si spéciale. Ces composants sont fournis par ou pas du tout fournis.

Je pense que Nomad a trouvé le compromis parfait entre facilité d'utilisation et utilité. Il convient aux petits services indépendants. Si vous avez besoin de plus de contrôle, vous devrez les augmenter vous-même ou utiliser une approche différente. Nomad n'est qu'un orchestre.

La meilleure chose à propos de Nomad est qu'il est facile à remplacer . Il n'y a pratiquement pas de lien avec le fournisseur, car ses fonctions sont facilement intégrées dans tout autre système qui gère les services. Cela fonctionne comme un binaire ordinaire sur chaque machine d'un cluster, c'est tout!

Écosystème nomade de composants faiblement couplés

La vraie puissance de Nomad dans son écosystème. Il s'intègre très bien avec d'autres produits - complètement facultatifs - tels que Consul (stockage de valeurs-clés) ou Vault (traitement des secrets). À l'intérieur du fichier Nomad, il existe 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é de service/geo-api/log-verbosity de Consul et dans le processus, nous la représentons avec la variable d'environnement LOG_LEVEL . Nous représentons également la secret/geo-api-key de Vault en tant que API_KEY . Simple mais puissant!

En raison de sa simplicité, Nomad est facilement extensible via d'autres services via l'API. Par exemple, les balises des tâches sont prises en charge. Nous marquons tous les services avec des métriques avec la trv-metrics . Ainsi, Prometheus trouve facilement ces services via Consul et vérifie périodiquement le point final /metrics pour de nouvelles données. La même chose peut être faite, par exemple, pour les journaux utilisant Loki .

Il existe de nombreux autres exemples d'extensibilité:

• Exécution du travail Jenkins avec un hook, et Consul suit le redéploiement du travail Nomad lorsque la configuration du service change.
  
• Ceph ajoute un système de fichiers distribué à Nomad.
  
• fabio pour l'équilibrage de charge.

Tout cela vous permet de développer organiquement l'infrastructure sans aucune obligation particulière pour le vendeur.

Avertissement honnête

Aucun système n'est parfait. Je ne recommande pas d'introduire immédiatement les dernières fonctionnalités en production. Bien sûr, il y a des bugs et des fonctionnalités manquantes, mais il en va de même pour Kubernetes.

Comparée à Kubernetes, la communauté Nomade n'est pas si grande. Kubernetes compte déjà environ 75 000 commits et 2 000 contributeurs, tandis que Nomad a environ 14 000 commits et 300 contributeurs. Nomad aura du mal à suivre la vitesse de Kubernetes, mais ce n'est peut-être pas nécessaire! Il s'agit d'un système plus spécialisé, et une communauté plus petite signifie également que votre demande d'extraction est plus susceptible d'être remarquée et acceptée que 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 rentable.

Si vous prévoyez de déployer une tonne de services homogènes sur une infrastructure à grande échelle, alors Kubernetes est une bonne option. N'oubliez pas la complexité et les coûts de maintenance supplémentaires. Certains coûts peuvent être évités en utilisant un environnement Kubernetes géré tel que Google Kubernetes Engine ou Amazon EKS .

Si vous cherchez juste un orchestrateur fiable, facile à prendre en charge et extensible, pourquoi ne pas essayer Nomad? Vous vous demandez peut-être jusqu'où cela vous mènera.

Si vous comparez Kubernetes avec une voiture, Nomad sera un scooter. Parfois, vous en avez besoin, et parfois un autre. Les deux ont le droit d'exister.