Mehr als ein Update

Mesos 1.0: Was die aktuelle Version zum Meilenstein macht

Marc Zimmermann

Nachdem in diesem und im letzten Jahr viele Projekte aus dem Container-Umfeld ihr 1.0-Release veröffentlicht hatten, war es vor kurzem auch bei Apache Mesos soweit. Man hat sich viel Zeit gelassen, obwohl die Software als stabil gilt und längst bei den ganz Großen wie Twitter, Airbnb, Netflix, Samsung und Apple im Einsatz ist.

Mesos 1.0: API, Upgrades, Storage-Features – und mehr

Zu den wichtigsten Ergänzungen des 1.0-Releases zählen ein versioniertes und dokumentiertes API, eine formelle Release- und Upgrade-Policy sowie verbesserte Security-Features. Aber auch einige Neuerungen im Bereich des Containerizers, beim Networking sowie den Storage-Features machen die aktuelle Version interessant. Eine Übersicht aller Änderungen ist unter [1] und [2] zu finden. Wir schauen ins im Folgendem an, was die Neuerungen für Entwickler bedeuten.

Zwei alte Nachteile sind behoben

Vor dem neuen Mesos-Meilenstein gab es bereits zwei Arten von APIs: ein „Driver-Based“ Framework-API für die Schedulers und Executors, sowie ein HTTP-API für Administratoren und Tools. In Version 1.0 wurde stattdessen ein einziges, RPC-basiertes HTTP-API für alle eingeführt. Damit werden zwei Nachteile der alten Architektur behoben: die Abhängigkeit von limitierten Programmbibliotheken (C++, Java, Python) sowie die benötigte bidirektionale Kommunikation zwischen Client und Server.

Unkomplizierte Clients

Neue API-Clients können in allen Programmiersprachen geschrieben werden, die HTTP können. Zudem erfordert die Kommunikation nun keinen Rückkanal mehr, was das Betreiben von Clients in Containern in der Cloud stark vereinfacht. Die folgende Abbildung zeigt eine Übersicht über die neuen Endpoints des API.

Mesos 1.0

Einheitlichere Endpoints für das API

Ein Highlight des neuen API ist der Support von Eventstreams für die Operator-HTTP-API, der allerdings noch als experimentell gekennzeichnet ist. Dabei können sich Clients an dem Eventbus anmelden und erhalten dann alle Events des Mesos-Clusters. Dies verhindert ein unnötiges Pollen des API. In naher Zukunft ist eine weitere Vereinheitlichung der Endpoints geplant.

Entwickeln wird deutlich leichter

Auch vor dem neuen Release war es unter Mesos bereits möglich, unterschiedliche Container-Formate wie Docker und Appc zu starten. Allerdings benötigte man dafür noch externe Ressourcen wie den Docker-Dämon für docker- oder rkt für appc-Container. Der Unified Containerizer ermöglicht jetzt mithilfe einer Container-Runtime-Engine – dem Mesos Containerizer – unterschiedliche Container-Image-Formate zu starten.

Aktuell können Docker- und Appc-Container gestartet werden, in Zukunft sogar alle Container, die OCI-konform [3] sind. Für Developer wird es so deutlich einfacher, Features wie persistente Volumes, neue Cgroups usw. zu entwickeln, da nun immer nur ein Containerizer geändert werden muss. Dabei besteht die Architektur des Containerizers aus drei Komponenten:

  1. Der Launcher ist zuständig für das „Prozessmanagement“ der Container. Typische Aufgaben sind zum Beispiel das Starten und Stoppen von Containern. Dabei unterstützt der Launcher aktuell Posix, Linux und künftig auch systemd.
  2. Der Isolator stellt eine Schnittstelle für Erweiterungen zur Laufzeit des Containers zur Verfügung. Dabei ist eine Vielzahl von Isolatoren bei dem Unified Container von Haus aus dabei. Einige Beispiele für Isolatoren, die von Mesos mitgeliefert werden, sind:
    • Cgroups Isolator: cgroups/cpu, cgroups/mem
    • Disk Isolator: disk/du, disk/xfs
    • Filesystem Isolator: filesytem/linux
    • Volume Isolator: docker/volume
    • Network Isolator: network/cni
    •  GPU Isolator: gpu/nvidia
  3. Der Provisioner ist für das Management der Container-Images zuständig: Die Images werden gepullt, bei Bedarf gecached und daraus das rootfs des Containers erstellt. Der Provisioner unterstützt aktuell die Image-Fomate Docker und Appc, Support für CVMFS [4] ist ebenfalls geplant.

Ein paar Einschränkungen lassen sich momentan beim Unified Container noch nicht vermeiden: So wird zum Beispiel für den Docker-Container nur der Host-Network-Modus unterstützt. Es ist aber davon auszugehen, dass diese „Kinderkrankheiten“ zeitnah von der Community behoben werden. Mehr dazu unter [5]

Eigene IPs für jeden Container

Mit Version 1.0 unterstützt Mesos nun das Container Network Interface, kurz: CNI [6]. Mit der Einführung von CNI erhält jeder Container seinen eigenen Netzwerk-Namespace. Dieser stellt die Isolation von anderen Netzwerken sicher. Es ist nun möglich, jedem Container über CNI eine eigene IP zu geben. Dank CNI können Container „Mitglied“ in einer Vielzahl von IP-Netzwerken sein. Neben den traditionellen VLans unterstützt CNI auch extra für den Container-Betrieb entwickelte Netzwerke wie Weave, Flannel oder Calico.

Auch hier muss man derzeit noch mit ein paar Einschränkungen leben. So unterstützt der network/cni-Isolator noch nicht das Mapping von Ports nach außen. Dafür muss ein weitere Proxy/Gateway auf dem Agent installiert werden. Alles weitere unter [6].

DevOpsCon Whitepaper 2018

Free: 40+ pages of DevOps expert knowledge

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Kai Tödter (Siemens), Nicki Watt (OpenCredo), Tobias Gesellchen (Europace AG) and many more.

Storage: „Wandern“ mit dem Container

Der Universal Containerizer unterstützt darüber hinaus den docker/volume-Isolator. So lassen sich auch nicht lokale Storage-Volumes problemlos nutzen. Bekannte docker-volume-Treiber sind flocker oder rexray, welche wiederum verschiedene Storage-Typen wie ScaleIO, Ceph, Amazon EBS usw. unterstützen. Der Unified Containerizer setzt dafür das dvdcli-Kommando ein, welches von EMC entwickelt wurde. [8] Mithilfe des dvdcli-Kommandos lassen sich Storage-Volumes mounten, unmounten, erzeugen und löschen. Ein Beispiel für ein Mount-Kommando sähe wie folgt aus:

dvdcli mount –volumedriver=rexray –volumename=test123456789

Dabei wird mit Hilfe von rexray ein Volume names test123456789 gemountet. Der Vorteil gegenüber dem bekannten persistenten und lokalen Storage-Prinzip ist, dass der Storage mit dem Container „wandert“. Fällt ein Agent aus, wird der Container auf einen anderen Agent verschoben und dort das Volume automatisch wieder eingebunden. Zum jetzigen Zeitpunkt ist der Storage Support allerdings noch experimentell.

Jeder sieht nur, was er soll

Nachdem SSL/TLS-Verschlüsselung für Frameworks und REST-Endpoints schon länger unterstützt wird, bieten alle kritischen Endpoints ab Mesos 1.0 auch Support bei der Authentifizierung und Autorisierung an. Des Weiteren wurde eine Autorisierung eingeführt, die auch einen Betrieb mit mehreren Mandanten erlaubt. So lässt sich zum Beispiel der Zugriff auf die Tasks innerhalb des Web-UI so beschränken, dass der Nutzer nur seine eigenen Tasks sieht. Bis dato wurden dem User stets alle Tasks angezeigt.

Praktisch: GPU- und Windows-Support

Mit dem 1.0-Release kann man Mesos-Jobs nun direkt auf der GPU ausführen. Und nicht nur das: Der Mesos Agent kann inzwischen auch auf einem Windows Client installiert werden. Beide Features sind aber noch als experimentell gekennzeichnet.

Ab jetzt geht es regelmäßig weiter

Nach der vorliegenden 1.0-Version können sich Interessierte alle 2 Monate auf ein neues Release freuen. Die Community supported alle Minor-Versionen über 6 Monate. Danach werden keine Security-Fixes mehr in die Version übernommen. Kritische Fixes werden in monatlichen Patch-Releases veröffentlicht.

Lesen Sie auch: Interview mit Michael Hausenblas: Mesos 1.0, Unterschiede zu Kubernetes und Docker Swarm, Pläne für DC/OS

Fazit

Mit Version 1.0 kommt Mesos dem Ziel, „die“ universelle Clustering-Plattform zu werden, einen großen Schritt näher. Vor allem das neue Release-Management bietet echten Mehrwert: Administratoren und andere IT-Verantwortliche sind so in der Lage, einen Update-Plan für die eigene Umgebung zu entwickeln. Bei einigen neuen Features fehlen allerdings noch elementare Funktionen, so dass es hier durchaus sinnvoll sein kann, diese erst mit dem nächsten Release produktiv zu nutzen.

Verwandte Themen:

Geschrieben von
Marc Zimmermann
Marc Zimmermann
Marc Zimmermann ist COO bei der sloppy.io GmbH und seit mehr als 15 Jahren begeisterter Linux Engineer. Zusammen mit seinem Team hilft er Entwicklern und Firmen, die vielen Möglichkeiten, die Mesos und Container bieten, zu nutzen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: