Flotte Docker-Swarm, Kubernetes, Mesos et Core-OS
Je suis relativement nouveau dans tous ces domaines, mais j'ai du mal à comprendre les technologies énumérées.
Bien que tous tentent de résoudre différents problèmes, ils ont cependant des points communs. J'aimerais comprendre quelles sont les choses communes et ce qui est différent. Il est probable que la combinaison de quelques-uns serait très utile, si oui de quoi s'agit-il?
J'en énumère quelques-unes avec des questions, mais ce serait bien si quelqu'un les énumère toutes en détail et répond aux questions.
Kubernetes vs Mesos:
Ce lien
Quelle est la différence entre les Mesos d'Apache et les Kubernetes de Google
fournit un bon aperçu des différences, mais je suis incapable de comprendre pourquoi Kubernetes devrait fonctionner au-dessus de Mesos. S'agit-il davantage de la réunion de deux solutions opensource?
Flotte Kubernetes vs Core-OS:
Si j'utilise kubernetes, une flotte est-elle requise?
Comment Docker-Swarm s'intègre-t-il dans tout ce qui précède?
Divulgation: Je suis ingénieur principal sur Kubernetes
Je pense que Mesos et Kubernetes sont largement destinés à résoudre des problèmes similaires liés à l'exécution d'applications en cluster, ils ont des historiques et des approches différentes pour résoudre le problème.
Mesos concentre son énergie sur une planification très générique et sur la connexion de plusieurs ordonnanceurs différents. Cela signifie que des systèmes tels que Hadoop et Marathon peuvent coexister dans le même environnement de planification. Mesos est moins concentré sur les conteneurs en cours d'exécution. Mesos existait avant l'intérêt généralisé pour les conteneurs et a été reconfiguré en pièces pour supporter les conteneurs.
Au contraire, Kubernetes a été conçu dès le départ pour être un environnement permettant de créer des applications distribuées à partir de conteneurs. Il inclut les primitives pour la réplication et la découverte de services en tant que primitives principales, où de telles choses sont ajoutées via des frameworks dans Mesos. Kubernetes a pour objectif principal de créer, d’exécuter et de gérer des systèmes distribués.
Fleet est un distributeur de tâches de niveau inférieur. Il est utile pour amorcer un système de cluster. Par exemple, CoreOS l’utilise pour distribuer les agents kubernetes et les fichiers binaires vers les machines d’un cluster afin d’activer un cluster kubernetes. Il n’est pas vraiment destiné à résoudre les mêmes problèmes de développement d’applications distribuées, pensez plutôt à systemd/init.d/upstart pour votre cluster. Ce n'est pas obligatoire si vous utilisez kubernetes, vous pouvez utiliser d'autres outils (par exemple, Salt, Puppet, Ansible, Chef, ...) pour réaliser la même distribution binaire.
Swarm s'efforce d'étendre l'API Docker existante pour faire en sorte qu'un cluster de machines ressemble à une API Docker unique. Fondamentalement, notre expérience chez Google et ailleurs indique que l'API de nœud est insuffisante pour une API de cluster. Vous pouvez voir de nombreuses discussions à ce sujet ici: https://github.com/docker/docker/pull/8859 et ici: https://github.com/docker/ docker/issues/8781
J'espère que ça t'as aidé! Rejoignez-nous sur IRC @ # google-conteneurs si vous voulez parler davantage.
Je pense que la réponse la plus simple est qu'il n'y a pas de réponse simple. La Swift montée en puissance des conteneurs, et Docker en particulier, a laissé un vide pour la "planification et l'orchestration des conteneurs", quoi que cela puisse signifier. En réalité, cela signifie que vous disposez de plusieurs technologies. cela peut fonctionner en harmonie à certains niveaux, mais avec certains aspects en concurrence, par exemple, Kubernetes peut être utilisé comme un guichet unique pour le déploiement et la gestion de conteneurs sur un cluster de calcul (comme Google l’a initialement conçu), Fleet, utilisant le niveau de résilience fourni par Fleet sous CoreOS.
Comme cette vidéo Google l'indique Kubernetes n'est pas une solution complète de mise à l'échelle du conteneur de boîtes, mais une bonne déclaration pour commencer. De même, vous vous attendriez à un moment donné à Apache Mesos de pouvoir travailler avec Kubernetes, mais pas avec Marathon, dans la mesure où Marathon semble remplir le même rôle que Kubernetes. Quelque part, je pense avoir lu ces textes pourraient faire partie du même effort, mais je peux me tromper à ce sujet. Il s’agit vraiment de l’orientation stratégique de Mésosphère et de l’adoption correspondante des principes de Kubernetes.
Dans le discours liminaire de DockerCon, Solomon Hykes a suggéré que Swarm serait un niveau susceptible de fournir une interface commune aux nombreux cadres d’orchestration et de planification. D'après ce que je peux voir, Swarm est conçu pour fournir un flux de travail de déploiement Docker fluide, fonctionnant avec certains frameworks de flux de travail conteneur tels que Deis, mais suffisamment flexible pour permettre un déploiement et une gestion des ressources "lourds" tels que Mesos.
J'espère que cela aide - cela pourrait être un post énorme. Je pense que l'essentiel est que ce sont des services jeunes et en évolution qui vont probablement fusionner et devenir interopérables, mais nous devons passer en revue les 12 prochains mois pour voir comment cela se passe. Il y a des gens très intelligents sur le problème, donc l'avenir est très prometteur.
Autant que je sache,
Mesos, Kubernetes et Fleet tentent tous de résoudre un problème très similaire. L'idée est que vous retiriez tout votre matériel des développeurs et que "l'outil de gestion de cluster" le trie pour vous. Ensuite, tout ce que vous avez à faire est de donner un conteneur au cluster, de lui donner quelques informations (de le maintenir en fonctionnement en permanence, de le redimensionner si X se produit, etc.) et le gestionnaire de cluster le réalisera.
Avec Mesos, il gère tout le cluster pour vous, mais n'inclut pas le planificateur. Le planificateur est le bit qui dit, ok ce processus nécessite 2 procs et 512 Mo de RAM, et j'ai une machine là-bas avec ce libre, donc je l'exécuterai sur cette machine. Certains programmateurs de plugins sont disponibles pour Mesos: Marathon et Chronos et vous pouvez écrire les vôtres. Cela vous donne beaucoup de puissance pour la distribution des ressources et la mise à l'échelle des clusters, etc.
Fleet et Kubernetes semblent faire abstraction de ce genre de détails (vous n'avez donc pas besoin d'écrire votre propre planificateur). Cela signifie que vous devez définir vos tâches et les soumettre dans le format/la manière défini par Fleet ou Kubernetes, puis elles prennent en charge et planifient les tâches (conteneurs) pour vous.
Donc, je suppose que: l’utilisation de Mesos peut signifier un peu plus de travail pour écrire votre propre planificateur, mais offre potentiellement plus de flexibilité si nécessaire.
Je pense que l'idée d'exécuter Kubernetes sur Mesos signifie que Kubernetes agit en tant que planificateur pour Mesos. Personnellement, je ne suis pas sûr des avantages que cela procure si on gère l'un ou l'autre seul (j'espère que quelqu'un interviendra et expliquera!)
Comme MikeB l'a dit ... nous n'en sommes qu'au début, et tout est à gagner (gardez également un œil sur l'ECS d'Amazon). Il existe donc de nombreuses normes en concurrence et beaucoup de chevauchements!
-edit- Je n'ai pas mentionné l'essaim Docker car je n'ai pas beaucoup d'expérience avec ça.
Pour tous ceux qui s'y rendent après 2017, la flotte est obsolète. Ne l'utilisez plus.
Fleet Docs dire "CoreOS ne développe plus ni ne maintient activement la flotte" et lien vers Orchestration du conteneur: passage de la flotte à Kubernetes . Fleet a été retiré de Container Linux ( anciennement CoreOS Linux ) et remplacé par Kubernetes kubelet (agent). Cela coïncidait avec un pivot d'entreprise qui offrait Tectonic (une distribution de Kubernetes) comme produit principal.