Je suis relativement nouveau dans tous ces domaines, mais j'ai du mal à avoir une idée claire des technologies répertoriées.
Cependant, tous ces éléments essaient de résoudre différents problèmes, mais ils ont également des points communs. Je voudrais comprendre quelles sont les choses qui sont communes et ce qui est différent. Il est probable que la combinaison de quelques-uns conviendrait parfaitement, si oui, quels sont-ils?
J'en énumère quelques-uns avec des questions, mais ce serait formidable que quelqu'un les énumère tous en détail et réponde aux questions.
Kubernetes vs Mesos:
Ce lien
Quelle est la différence entre Apache Mesos et Kubernetes de Google
fournit un bon aperçu des différences, mais je ne peux pas comprendre pourquoi Kubernetes devrait fonctionner au-dessus de Mesos. Est-ce plus à voir avec le rapprochement de deux solutions open source?
Kubernetes vs Flotte Core-OS:
Si j'utilise Kubernetes, une flotte est-elle nécessaire?
Comment Docker-Swarm s'intègre-t-il dans tout ce qui précède?
Réponses:
Divulgation: je suis ingénieur principal sur Kubernetes
Je pense que Mesos et Kubernetes visent en grande partie à résoudre des problèmes similaires liés à l'exécution d'applications en cluster, ils ont des histoires différentes 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 programmateurs différents. Cela signifie qu'il permet à des systèmes comme Hadoop et Marathon de coexister dans le même environnement de planification. Mesos se concentre moins sur l'exécution de conteneurs. Les mésos existaient avant un intérêt généralisé pour les conteneurs et ont été re-factorisés en parties pour soutenir les conteneurs.
En revanche, 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 des primitives pour la réplication et la découverte de services en tant que primitives de base, où en tant que tel des éléments sont ajoutés via des frameworks dans Mesos. L'objectif principal de Kubernetes est un système permettant 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 et les binaires kubernetes aux 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-y plutôt à systemd / init.d / upstart pour votre cluster. Ce n'est pas nécessaire si vous exécutez kubernetes, vous pouvez utiliser d'autres outils (par exemple Salt, Puppet, Ansible, Chef, ...) pour réaliser la même distribution binaire.
Swarm est un effort de Docker pour étendre l'API Docker existante pour faire ressembler un cluster de machines à une seule API Docker. 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 un tas de discussions à ce sujet ici: https://github.com/docker/docker/pull/8859 et ici: https://github.com/docker/docker/issues/8781
J'espère que cela pourra aider! Rejoignez-nous sur IRC @ # google-containers si vous souhaitez en parler davantage.
la source
Je pense que la réponse la plus simple est qu'il n'y a pas de réponse simple. La montée en puissance rapide des conteneurs, et de Docker en particulier, a laissé un vide de pouvoir pour «la planification et l'orchestration des conteneurs», quoi que cela puisse signifier. En réalité, cela signifie que vous disposez d'un certain nombre de technologies qui peuvent fonctionner en harmonie à certains niveaux, mais avec certains aspects en compétition. Par exemple, Kubernetes peut être utilisé comme un guichet unique pour déployer et gérer des conteneurs sur un cluster de calcul (comme Google l'a conçu à l'origine), mais pourrait également être placé au sommet de Fleet, en utilisant le niveau de résilience fourni par Fleet sur CoreOS.
Comme l'indique cette vidéo Google, Kubernetes n'est pas une solution complète de mise à l'échelle des conteneurs, mais c'est une bonne déclaration pour commencer. De la même manière, vous vous attendriez à un moment donné à ce qu'Apache Mesos puisse 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 que j'ai lu cela pourrait faire partie du même effort, mais je peux me tromper à ce sujet - il s'agit vraiment de la direction stratégique de la mésosphère et de l'adoption correspondante des principes de Kubernetes.
Dans le discours d'ouverture de DockerCon, Solomon Hykes a suggéré que Swarm serait un niveau qui pourrait fournir une interface commune sur les 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 de Docker fluide, fonctionnant avec certains cadres de flux de travail de conteneur existants tels que Deis, mais suffisamment flexible pour céder la place à un déploiement et à une gestion des ressources «lourds» tels que Mesos.
J'espère que cela aide - cela pourrait être un énorme message. Je pense que la clé est que ce sont des services jeunes et en évolution qui vont probablement fusionner et devenir interopérables, mais nous devons passer les 12 prochains mois pour voir comment cela se déroulera. Il y a des gens très intelligents sur le problème, donc l'avenir s'annonce très prometteur.
la source
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 soustrayez tout votre matériel aux développeurs et que «l'outil de gestion de cluster» trie tout pour vous. Ensuite, tout ce que vous avez à faire est de donner un conteneur au cluster, de lui donner des informations (le maintenir en marche en permanence, augmenter si X se produit, etc.) et le gestionnaire de cluster le fera.
Avec Mesos, il s'occupe de toute la gestion du cluster pour vous, mais il n'inclut pas le planificateur. Le planificateur est le bit qui dit, ok ce processus a besoin de 2 procs et 512 Mo de RAM, et j'ai une machine là-bas avec cela gratuit, donc je vais l'exécuter sur cette machine. Il existe des programmateurs de plugins disponibles pour Mesos: Marathon et Chronos et vous pouvez écrire le vôtre. Cela vous donne une grande puissance de distribution des ressources et de mise à l'échelle du cluster, etc.
Fleet et Kubernetes semblent faire abstraction de ce genre de détails (vous n'avez donc pas à écrire votre propre planificateur). Cela signifie que vous devez définir vos tâches et les soumettre dans le format / la manière définie par Fleet ou Kubernetes, puis ils prennent le relais et planifient les tâches (conteneurs) pour vous.
Donc je suppose que l'utilisation de Mesos peut signifier un peu plus de travail dans l'écriture de votre propre planificateur, mais offre potentiellement plus de flexibilité si nécessaire.
Je pense que l'idée d'exécuter Kubernetes sur Mesos est que Kubernetes agit en tant que planificateur pour Mesos. Personnellement, je ne suis pas sûr des avantages que cela apporte sur l'exécution de l'un ou de l'autre seul (j'espère que quelqu'un interviendra et expliquera!)
Comme MikeB l'a dit ... c'est le début, et tout est à gagner (gardez un œil sur l'ECS d'Amazon également) donc il y a beaucoup de normes concurrentes et beaucoup de chevauchements!
-edit- Je n'ai pas mentionné l'essaim Docker car je n'ai pas vraiment beaucoup d'expérience avec.
la source
Pour quiconque vient à ce après 2017, la flotte est obsolète. Ne l'utilisez plus.
Les documents de flotte indiquent que "la flotte n'est plus activement développée ou maintenue par CoreOS" et un lien vers l' orchestration de conteneurs: passage de la flotte à Kubernetes . Fleet a été supprimé de Container Linux ( anciennement connu sous le nom de CoreOS Linux ) et remplacé par Kubernetes kubelet (agent). Cela a coïncidé avec un pivot d'entreprise pour proposer Tectonic (une distribution Kubernetes) comme produit principal.
la source