Apache Spark™ auf der
Stackable Data Platform

Zunächst dem Getting-Started-Guide in der Operator-Dokumentation folgen. Eine SparkApplication-CRD anlegen, die das Container-Image, die Hauptanwendungsdatei, die Executor- und Driver-Ressourcen sowie alle nötigen Umgebungsvariablen angibt, und sie dann mit kubectl apply anwenden. Der Operator stellt automatisch alle benötigten Kubernetes-Ressourcen bereit, plant den Job und verwaltet seinen Lifecycle, inklusive Log-Sammlung und Event-Tracking.

Die unterstützten Apache-Spark-Versionen stehen in der Stackable-Dokumentation. Eine passende Version wählen, die zu einem kompatiblen Spark-Image für das Deployment passt, oder ein eigenes Image aus einer eigenen Registry mitbringen – für gepatchte Versionen oder zusätzliche Bibliotheken. Der Operator betreibt mehrere Versionen parallel, sodass sich neue Releases im eigenen Tempo einführen lassen.
Aktuelle Liste.

Ja, indem für jede SparkApplication ein anderes Container-Image angegeben wird. Jede Anwendung läuft unabhängig, sodass mehrere Spark-Versionen konfliktfrei im selben Kubernetes-Cluster koexistieren. Das ist nützlich, um neue Versionen zu testen, Workloads schrittweise zu migrieren oder Teams mit unterschiedlichen Dependency-Anforderungen zu unterstützen.

Abhängigkeiten lassen sich auf mehrere Arten hinzufügen: Custom Container Images, die Bibliotheken oder Pakete enthalten; gemountete Volumes mit JARs oder Konfigurationsdateien; Maven-Koordinaten für Java-/Scala-Bibliotheken (Iceberg, Hadoop-Connectoren usw.); und Python-Pakete über pip für PySpark-Jobs. Die Operator-Dokumentation liefert Beispiele für jede Methode und stellt Reproduzierbarkeit und Versionskontrolle der Abhängigkeiten sicher.

Jeder Driver- und Executor-Pod enthält einen Vector-Sidecar, der Logs in einem strukturierten, zentralisierten Format sammelt. Logs lassen sich zusätzlich zur Langzeitspeicherung nach S3 schreiben. Der Spark History Server kann Event-Logs aus S3 lesen, sodass sich abgeschlossene Anwendungen durchsehen, Metriken einsehen und vergangene Läufe leicht debuggen lassen – das sorgt für operative Transparenz und vereinfacht Monitoring und Troubleshooting.

Ja. S3 lässt sich über die CRD als Datenquelle konfigurieren, wobei Credentials über Secrets und SecretClasses angegeben werden. Spark kann direkt aus diesen Object Stores lesen und in sie schreiben – das ermöglicht die Integration mit Data Lakes und cloud-nativen Storage-Systemen ohne zusätzliche ETL-Schichten.

Ja. Die Operator-Dokumentation liefert Anleitungen zum Konfigurieren der Kerberos-Authentifizierung für HDFS-Zugriff. Der Secret Operator von Stackable kann Keytabs generieren und Credentials sicher verwalten. TLS- und RBAC-Konfigurationen stellen sicher, dass Workloads sicher in Multi-Tenant-Clustern laufen.

Ja. Spark lässt sich mit anderen Stackable-Operatoren zu End-to-End-Workflows kombinieren: Spark-Jobs aus Airflow für orchestrierte ETL-Pipelines auslösen, Lakehouse-Tabellen nach Spark-Transformationen mit Trino abfragen und aggregierte Ergebnisse mit Superset visualisieren. Integrationsmuster sind in den Stackable-Plattform-Guides dokumentiert – für zuverlässige, skalierbare und wartbare Analytics-Pipelines.

Ja. Resource Requests und Limits lassen sich pro Rolle definieren, etwa für Driver- oder Executor-Pods, und sogar pro Role-Group. So lässt sich die Zuteilung von CPU, Memory und Storage für jeden Workload-Typ optimieren – hohe Auslastung ohne Over-Provisioning. Das Ressourcen-Tuning hilft außerdem, die Cluster-Stabilität bei gemischten Workloads und hoher Last zu wahren.

Der Operator wurde auf den wichtigsten managed und selbst gehosteten Kubernetes-Plattformen getestet: EKS, AKS, GKE, OpenShift, IONOS und K3s. Diese Flexibilität ermöglicht es, Spark zuverlässig über Cloud-Anbieter oder On-Premise-Infrastruktur hinweg zu deployen – bei gleichzeitigem Vorteil von deklarativem Management und Operator-Automatisierung.