Schwarm, Kubernetes oder Mesos für Stapelverarbeitungsjobs

Question

Meine Anwendung muss viele Container als Worker Nodes ausführen (um verschiedene Stapelverarbeitungsjobs auszuführen), und ich bin nicht wirklich daran interessiert, Webserver oder Datenbanken zu verwalten - nur kurze Jobs das kann irgendwo zwischen 1 Sekunde bis 1 Stunde dauern. Meine Idee ist, gegen eine Wolke von Knoten zu arbeiten, ohne dass ich mich darum kümmern muss, welche Maschine von diesen Knoten die verfügbaren Ressourcen hat, um meinen Job zu verarbeiten (Mesos sind ziemlich gut darin - wie angekündigt).

Ich spiele gerade mit DC/OS und ich frage mich, ob eine der anderen Clustering-Technologien diese Funktion bieten: given I need 1CPU, 2GB RAM and 2GB of disk - run X docker container against my nodes.

Ich mag die Idee von Schwarm aufgrund der Tatsache, dass ich sehr gut mit docker selbst vertraut bin und ich glaube, es ist am einfachsten zu installieren und zu automatisieren (Scale Up oder Down). Ich mag kubernetes (keine Erfahrung), weil es kostenlos ist und ich bin mir ziemlich sicher, dass es lange so bleiben wird. Ich mag DC/OS, weil es viel bündelt, aber ich bin mir ihrer zukünftigen Pläne nicht sicher, und ich bin es gewohnt, dass Projekte Funktionen abschneiden, um sie in einen Plan einzubeziehen, der deine Seele für x Knoten auflädt.

Was sind Ihre Gedanken?

Answer 1

Kubernetes, Swarm und Mesos können alle Jobs technisch für Sie planen und mit einschränkenden Ressourcen umgehen.

Im Gegensatz zu den anderen beiden wurde Mesos in erster Linie entworfen, um Verteilung, Aufgabe und Ressourcen-Management auf einer niedrigeren Ebene zu behandeln. Die Fokussierung auf diese Bits führte zu mehr Leistung und Flexibilität, aber auch zu mehr Komplexität auf einer niedrigeren Ebene. Deshalb gibt es DC/OS, um Ihnen ein Paket von Microservice-Tools zu bieten, die als Plattform auf höherer Ebene gut funktionieren.

Mesos wurde auch entwickelt, damit Sie Ihren eigenen Scheduler mitbringen können, um Aufgabenlebenszyklusanforderungen zu erfüllen, die normalerweise für stateful Aufgaben benötigt werden. Kubernetes und Swarm wurden in erster Linie entwickelt, um den statusfreien Service-Use-Case zu behandeln und später angepasst, um Stateful Services und Jobs mit dem enthaltenen Scheduler zu verarbeiten.

DC/OS baut auf Mesos auf und verfügt über integrierte Scheduler für Jobs und Services, während Sie bei Bedarf weiterhin Ihren eigenen benutzerdefinierten Scheduler erstellen können.

Kubernetes hat kürzlich die Unterstützung für benutzerdefinierte Disponenten als gut, aber die deutlich weniger ausgereift als die Mesos Implementierung und Ökosystem und auch dreht immer noch um die Kernhülsen & Replikatssatz Primitiven verwendet, die Ermächtigung werden kann oder zu begrenzen, je nach Ihren Bedürfnissen .

Vor kurzem hat Mesosphere ein neues dcos-commons-Framework entwickelt, um auch JVM-basierte Mesos-Scheduler trivial zu machen. Dies kann Ihre Produktivität auf DC/OS steigern. https://github.com/mesosphere/dcos-commons

Mesos & DC/OS bietet Ihnen auch mehr Optionen für die Containerisierung. Sie können Docker-Images und Docker-Container verwenden, wenn Sie möchten. Oder Sie können die Laufzeitumgebung des Mesos-Containers mit oder ohne Docker-Images verwenden, was Ihnen mehr Flexibilität hinsichtlich Workloads und Packaging bietet.

DC/OS und Kubernetes haben beide auch Paketmanager, die nützlich sein können, um Abhängigkeiten wie Spark, Kafka oder Cassandra zu installieren. Aber DC/OS hat tendenziell robustere Datendienste, da sie mit eigenen benutzerdefinierten Schedulern erstellt werden, während das Kubernetes-Ökosystem dazu neigt, komplexe Docker-Container-Wrapper rund um ihre Systeme zu verwalten, da benutzerdefinierte Scheduler erst spät eintreffen. Docker schließt auch die Paketverwaltung ein, wenn Sie Docker-Images als "Pakete" betrachten. Der Unterschied besteht darin, dass DC/OS und Kubernetes Abstraktionen höherer Ebenen (Apps & Pods) verpacken, die mehrere Container enthalten können.In jüngerer Zeit hat Docker "Stacks" hinzugefügt, die Abstraktionen höherer Ebenen sind, aber ich glaube nicht, dass es einen externen Repository-Mechanismus oder viel Paketmanagement gibt.

Swarm ist definitiv die einfachste, aber seine ursprüngliche API wurde entwickelt, um die gleiche wie die Knoten-API zu sein, die großartig für Vertrautheit und Onboarding war, sondern eher als Abstraktion auf höherer Ebene. Sie haben die Schwarm-API neu geschrieben und als "Schwarm-Modus" in Docker-Engine gebündelt. Diese Bündelung der Orchestrierungs-Engine und der Container-Laufzeit erleichtert dem Benutzer die Installation und Verwaltung, kombiniert aber auch die bisher zwei verschiedenen Abstraktionsebenen. Anstatt also nur eine Abhängigkeit von Orchestrierungs-Engines zu sein, konkurriert die Docker Engine nun auch mit ihnen und widerspricht der Unix-Philosophie, eine Sache gut zu machen und für ein gewisses politisches Durcheinander in den jeweiligen Open-Source-Communities zu sorgen. Twitter, Hacker-Nachrichten und Chat-Gespräche eskalierten in das Gespräch von forking docker, die zu K8s experimenting on alternatives, DC/OS supporting Docker images without using Docker engine und Docker extracting containerd führen.

Sie alle funktionieren gut. Die Auswahl einer Art hängt von Ihren Bedürfnissen ab. Ich empfehle generell DC/OS, weil es eine größere Anzahl von Problemen anpackt und aus vielen verschiedenen Microservice-Tools und Layern besteht. Dadurch können Sie mehrere Anwendungsfälle unterstützen, indem Sie gegen die Ebene programmieren, was am sinnvollsten ist. Offenlegung tho, ich arbeite für Mesosphäre! ;)