Fille sur un scooter. Illustration , Logo Nomade de
Kubernetes est le gorille de 300 livres de l'orchestration de conteneurs. Cela fonctionne dans certains des plus grands systèmes de conteneurs au monde, mais cela coûte cher.
Particulièrement coûteux pour les petites équipes, qui nécessiteront beaucoup de temps d’assistance et une courbe d’apprentissage abrupte. C'est trop de frais généraux pour notre équipe de quatre personnes. Nous avons donc commencé à chercher des alternatives et sommes tombés amoureux de .
Que veux-tu
Notre équipe prend en charge un certain nombre de services courants de surveillance et d'analyse des performances : points de terminaison d'API pour les métriques écrites en Go, exportations Prometheus, analyseurs de journaux tels que Logstash et , 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 que tout fonctionne.
Nous avons commencé par une liste d'exigences pour l'orchestration de conteneurs :
- Exécuter un ensemble de services sur de nombreuses machines.
- Présentation des services en cours d'exécution.
- Liens entre services.
- Redémarrage automatique si le service tombe en panne.
- Maintenance des infrastructures par une petite équipe.
De plus, les éléments suivants seront utiles, mais ne seront pas des ajouts obligatoires :
- Balisage des machines en fonction de leurs capacités (par exemple, marquage des machines avec des disques rapides pour les services d'E/S lourds).
- Possibilité d'exécuter des services indépendamment de l'orchestrateur (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 du prototypage avec Kubernetes, nous avons remarqué que nous ajoutions des couches logiques de plus en plus complexes sur lesquelles nous nous appuyions fortement.
À titre d'exemple, Kubernetes prend en charge les configurations de services intégrées via . Vous pouvez rapidement vous perdre, notamment lors de la fusion de plusieurs fichiers de configuration ou de l'ajout de services supplémentaires à un pod. Kubernetes (ou dans ce cas) vous permet d'implémenter dynamiquement des configurations externes pour séparer les préoccupations. Mais cela se traduit par un couplage étroit et caché entre votre projet et Kubernetes. Cependant, Helm et ConfigMaps sont des options supplémentaires, vous n'avez donc pas besoin de les utiliser. Vous pouvez simplement copier la configuration dans l'image Docker. Cependant, il est tentant de s’engager dans cette voie et de construire des abstractions inutiles que vous pourriez regretter plus tard.
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 derniers outils. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - la liste est longue. Tous ces outils ne sont pas nécessaires lorsque vous débutez, mais vous ne savez pas de quoi vous aurez besoin, vous devez donc être au courant de tout. Pour cette raison, la courbe d’apprentissage est assez abrupte.
Quand utiliser Kubernetes
Dans notre entreprise, de nombreuses personnes utilisent Kubernetes et en sont très satisfaites. Ces instances sont gérées par Google ou Amazon, qui disposent des ressources pour les prendre en charge.
Kubernetes est livré avec , qui rendent l'orchestration des conteneurs à grande échelle plus gérable :
- Détaillé .
- ajouter de la logique au cluster. Ce sont simplement des programmes qui communiquent avec l'API Kubernetes.
- ! Kubernetes peut faire évoluer les services à la demande à l'aide de métriques de service et 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 vous fier uniquement aux abstractions ; .
Notre équipe fournit la plupart des services à distance (en raison de la connexion étroite avec l'infrastructure principale), nous ne souhaitions donc pas créer notre propre cluster Kubernetes. Nous voulions simplement fournir des services.
Piles non incluses
Nomad représente 20 % de l'orchestration qui fournit 80 % de ce qui est 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'erreurs... et c'est tout.
Tout l’intérêt de Nomad réside dans ce qu’il fait minimum: pas de gestion granulaire des droits ou , ceci est spécialement conçu. Ces composants sont fournis en externe ou pas du tout.
Je pense que Nomad a trouvé le compromis parfait entre simplicité d'utilisation et utilité. C'est bon pour les 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. Nomade est juste orchestrateur.
La meilleure chose à propos de Nomad est que c'est facile remplacer. Il n'y a pratiquement aucun lien avec le fournisseur, puisque ses fonctions s'intègrent facilement dans tout autre système gérant les services. Il fonctionne comme un binaire normal sur chaque machine du cluster, c'est tout !
Écosystème nomade de composants faiblement couplés
La véritable force de Nomad, c'est son écosystème. Il s'intègre très bien avec d'autres produits - totalement optionnels - tels que (magasin clé-valeur) ou (secrets de traitement). À l'intérieur du fichier Nomad, il y a des sections pour extraire les 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 depuis Consul et pendant que nous travaillons nous l'exposons à une variable d'environnement LOG_LEVEL. Nous présentons également la clé secret/geo-api-key depuis Vault en tant que API_KEY. Simple mais puissant !
De par sa simplicité, Nomad est facilement extensible avec d'autres services via API. Par exemple, les balises pour les tâches sont prises en charge. Nous étiquetons tous les services avec des métriques trv-metrics. De cette façon, Prometheus peut facilement trouver ces services via Consul et vérifier périodiquement le point final /metrics pour les nouvelles données. La même chose peut être faite, par exemple, pour les journaux, en utilisant .
Il existe de nombreux autres exemples d’extensibilité :
- Exécutez un travail Jenkins à l'aide d'un hook et Consul surveille le redéploiement du travail Nomad lorsque la configuration du service change.
- Ceph ajoute un système de fichiers distribué à Nomad.
- pour l'équilibrage de charge.
Tout cela permet sans aucun lien particulier avec le vendeur.
Avertissement juste
Aucun système n'est parfait. Je ne recommande pas d'introduire immédiatement les fonctionnalités les plus récentes 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é Nomad n’est pas si grande. Kubernetes compte déjà environ 75 000 commits et 2000 14 contributeurs, tandis que Nomad compte environ 000 300 commits et XNUMX contributeurs. Nomad aura du mal à suivre la vitesse de Kubernetes, mais ce n'est peut-être pas obligatoire ! Il s'agit d'un système plus spécialisé, et la 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 avantageux.
Si vous envisagez de déployer une tonne de services homogènes sur une infrastructure à grande échelle, alors Kubernetes est une bonne option. Soyez simplement conscient de la complexité et des coûts d’exploitation supplémentaires. Certains coûts peuvent être évités en utilisant un environnement Kubernetes géré tel que ou .
Si vous recherchez simplement un orchestrateur fiable, facile à entretenir et extensible, pourquoi ne pas essayer Nomad ? Vous pourriez être surpris de voir jusqu’où cela vous mènera.
Si Kubernetes est comparé à une voiture, Nomad serait un scooter. Parfois, vous avez besoin d’une chose et parfois d’une autre. Les deux ont le droit d’exister.
Source: habr.com