Container die ML-Funken sprühen

Kubernetes & Apache Spark: Das perfekte Duo für Data Science & Machine Learning

Terry Shea

© Shutterstock.com / anekoho

Irgendwann mussten sich die Bereiche Kubernetes bzw. Container und Machine Learning ja treffen. In seinem Artikel erklärt Terry Shea, Chief Revenue Officer bei Kublr, wie man beim Maschinellen Lernen und im Internet of Things von Kubernetes profitieren kann. Schlüsselelement ist dabei die neueste Version von Apache Spark (2.3), die den nativen Support für die Orchestrierungsplattform bereitstellt.

Bei Kublr halten wir konstant Rücksprache mit der Community und unseren Kunden darüber, welche Workloads sie mit Containern und Kubernetes ausführen wollen. Wir haben festgestellt, dass das Interesse, Kubernetes für Data Science- und Machine-Learning-Anwendungen zu verwenden, immer mehr zunimmt.

Von MapReduce über Hadoop bis hin zu Spark wurden für Frameworks Funktionen erschaffen, die für die parallele Verarbeitung von Daten bzw. dessen Beschleunigung Cluster nutzen. Bislang wurden diese Cluster über eigene Cluster-Management-Lösungen (also Spark) verwaltet. Alternativen gab es hier in Form von Apache Yarn oder Mesos Marathon.

Nicht nur in Apache Spark: Die native Kubernetes-Integration

Seit dem Release von Apache Spark 2.3 gibt es gute Neuigkeiten für alle, die Kubernetes in Data-Science- oder Machine-Learning-Projekten nutzen: den nativen Support für die Orchestrierungsplattform in Spark. Bereits Ende des vergangenen Jahres kündigte Mesosphere, das Unternehmen hinter Mesos Marathon, die Unterstützung für Kubernetes an. Auch bei Google scheint man den Trend ernst zu nehmen, Kubernetes im Machine-Learning-Umfeld einzusetzen: Mit Kubeflow stellt der Suchmaschinenriese für das hauseigene ML-Framework TensorFlow einen „zusammensetzbaren, portierbaren und skalierbaren Machine Learning Stack für Kubernetes“ (natürlich Open Source) bereit. Zudem gibt es Tutorials und GitHub Repositories in denen erklärt wird, wie man Hadoop auf Kubernetes laufen lassen kann.

Und auch in der Community zeichnet sich der Trend deutlich ab. So gibt es zum Beispiel eine Special Interest Group (SIG), die sich mit dem Thema Big Data auseinandersetzt und auf der KubeCon in Kopenhagen gab es einen Hackathon zum Verwalten von Daten in Cloud-native- und Data-Science-Bereich. Das Interesse und die Aktivitäten der Community gehen natürlich noch viel weiter.

Die zunehmende Aktivität in Sachen Kubernetes für Data Science und Machine Learning lässt sich in unseren Augen damit erklären, dass Anwendungen aus diesen Bereichen so von der IT besser unterstützt werden können. Eine Orchestrierungsebene für alle containerisierten Anwendungen zu haben, hat einige Vorteile:

  • Eine bessere Verwendbarkeit von Ressourcen durch das zentralisierte Scheduling von Data-Science- und anderen Container-Anwendungen,
  • die (potentielle) Portabilität für Workloads,
  • eine einzige Scheduling-Lösung für lokale oder Multi-Cloud-Umgebungen und
  • die Möglichkeit für die IT, sogenannte Self-Service Environments für Datenwissenschaftler und andere Nutzer der Daten zu erstellen.

Mit der Power der GPU

Kubernetes kann auch die Power von Grafikkarten nutzen, um das parallele Verarbeiten von Daten zu beschleunigen. In Umgebungen, die so etwas unterstützen, wird sogar automatisch skaliert. Tatsächlich stellt Kubernetes sogar zwei Arten der automatischen Skalierung bereit: das Pod Auto-Scaling und das Cluster Auto-Scaling. Bei ersterem werden mehr Pods basierend auf festgelegten Regeln zur Skalierung automatisch im Cluster erstellt, bei letzterem werden mehr Nodes basierend auf flexiblen Regeln zur Skalierung dem Cluster hinzugefügt. Die genannten Regeln zur Skalierung können in Kubernetes seit der Einführung der individuellen Metriken noch feingranulierter eingestellt werden, etwa über Tasks in einer Warteschlange. Früher drehte sich bei den Metriken der Skalierung alles um CPU und Arbeitsspeicher.

Native Kubernetes-Integration in Apache Spark

Die „native“ Integration in Spark ist wirklich etwas Neues. Apache Spark geht nun davon aus, dass ein Kubernetes-Cluster bereits existiert und stellt eine Methode zur Verfügung, um Container Images zu erstellen, die dann ihrerseits in Kubernetes deployt werden können. Für die Übermittlung der Anwendung zu Kubernetes kann Spark-submit genutzt werden, in Kubernetes werden dann einer oder mehrere Container in einem Pod untergebracht. Mehrere Pods werden pro Node terminiert, wobei es zwei Arten von Nodes gibt: Master Nodes und Worker Nodes.

Apache Spark + Kubernetes: Die Architektur / Quelle: Apache Spark

Die native Integration macht es Spark möglich, einen Spark-Treiber in einem Kubernetes Pod zu erstellen, der dann seinerseits Executors erstellt. Diese laufen ebenfalls in Kubernetes Pods und der Spark-Treiber verbindet sich zu ihnen und führt Anwendungen aus. Auf der Projektseite von Apache Spark gibt es eine genaue Anleitung für dieses Szenario.

Auf der Anwendungsebene bleibt Spark als Scheduling-Mechanismus im Einsatz, während man von den Ressourcenmanagementkapazitäten von Kubernetes profitiert. Für die Zukunft ist bereits geplant, fortgeschrittene Kubernetes-Funktionen zu integrieren, etwa affinity/anti-affinity-Pod-Scheduling-Parameter. Weitere Informationen dazu gibt es hier und im Video.

Wo geht die Reise hin?

In Zukunft wird es vor allem darum gehen, neue Use Cases zu unterstützen, die von der starken Erweiterbarkeit der Kubernetes-Plattform profitieren. Anwendungsfälle aus dem IoT-Bereich stehen oft in Verbindung mit Data Science, gerade im Backend. Im Edge-Bereich könnten IoT-Projekte das Pre-Processing von Daten gebrauchen. Auch die Möglichkeit, Nodes auf ARM-Prozessoren ausführen zu können, sowie mit niedriger Bandbreite und eingeschränkter Konnektivität umgehen zu können, wären wünschenswerte Verbesserungen. Und natürlich wäre es auch gut, automatische Deployments durchführen zu können. In Sachen Kommunikation kann zwischen Sensoren oder Geräten zum Edge Node ein Protokoll wie MQTT verwenden. Andersherum aber, also vom Edge Node wieder zum Datenzentrum oder dem Cloud IoT, wird eher eine Streaming-Anwendung benötigt.

Kubernetes hat das Potential, Anwendungsabstraktionen, die eine große Anzahl von Use Cases vereinfachen, und gleichzeitig ein selbstheilendes Infrastrukturmanagement bereitzustellen. Bei Kublr arbeiten wir an Architekturen, die diese Use Cases unterstützen. Wer gerne einmal Spark in Verbindung mit Kubernetes testen möchte, der kann sich Kublr-in-a-Box herunterladen und einfach einen Kubernetes Cluster aufsetzen.

Geschrieben von
Terry Shea

Terry Shea is the Chief Revenue Officer for Kublr, a comprehensive Kubernetes platform for the enterprise.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.