Page MenuHomePhabricator

[Infra] Carry out end-user testing of spark on kubernetes
Open, MediumPublic

Description

We now have the ability to create spark-enabled namespaces in Kubernetes.
This is achieved in two ways:

  1. Add this namespace to the list of jobNamespaces that are monitored by the spark-operator.
  2. Deploy an instance of the spark-support chart to this namespace.

What this means in practice is:

  • The spark-operator is watching this namespace and will handle any SparkApplication or SheduledSparkApplication objects that are created.
  • A spark serviceaccount exists, which has elevated privileges within the namespace.
    • Full access to manage pods, services, configmaps, secrets, and persistent volume claims
  • We can permit serviceaccounts in other namespaces to create pods etc.
    • Typically, this will be an airflow serviceaccount in an airflow instance namespace.
  • Firewall rules are in place, permitting spark pods access to Kerberos, Hive, HDFS, and other services, as required.
  • A kerberos keytab has been deployed as a secret, which can be used to authenticate to Hive and HDFS.

We currently have the analytics-test namespace fully enabled in this way and it would be helpful for end users to start using spark and providing feedback to help guide the next steps on configuration.

In order to gain access to the namespace, users will want to run the following from a deployment server.

kube-env analytics-test-deploy dse-k8s-eqiad

These credentials are only accessible to members of the analytics-deployers group, which is effectively an alias for the analytics-admins group. See this page for more information on the shell groups.

The simplest way to get started testing is to make use of the spark-toolbox deployment that is defined within the `spark-support chart.

btullis@deploy2002:~$ kubectl get deployments spark-toolbox
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
spark-toolbox   3/3     3            3           42h

This is a container that uses the spark image and has all of the correct config files, secrets, environment variables etc. but is just running a sleep infinity command, ready for a user to start a shell and run interactive commands.

We can launch a shell in this toolbox like this:

kubectl exec -it spark-toolbox-6fcf874549-n4dff -- /entrypoint.sh bash

The first suffix for the pod will change on each deployment, and the second will be unique to each of the toolbox replicas.

Once inside the toolbox pod, we can start to launch spark sessions in both client and cluster mode.

Client mode sessions include the use of: spark-sql, spark-shell, and pyspark, as well as spark-submit.
Cluster mode sessions just use spark-submit.

When running a client mode setting, there is only one required command-line option, which is spark.driver.host.
In our case, we want to set this value to either the IPv4 or the IPv6 address of the pod.

So the following should all work for starting a spark cluster in client mode.

spark-sql --conf spark.driver.host=[$(hostname -i|awk '{print $1}')]

spark-shell --conf spark.driver.host=[$(hostname -i|awk '{print $1}')]

pyspark --conf spark.driver.host=[$(hostname -i|awk '{print $1}')]

In cluster mode, we do not have to override this value.

We have seen the following sparkPi job succeed from a toolbox pod.

spark-submit --verbose --deploy-mode cluster --class org.apache.spark.examples.SparkPi --name "Spark Pi" local:///opt/spark/examples/jars/spark-examples_2.12-3.5.7.jar

The executor pods are created and deleted dynamically, but the driver pod remains in a completed state, so we can check the logs.

btullis@deploy2002:~$ kubectl logs spark-pi-a6237b9b2bcbf64a-driver | tail -n 1
Pi is roughly 3.1441357206786034

There are certain things that we will want to be aware of and to carry on configuring, including:

If we find that there are additional options that we wish to add to the spark or hadoop config files, these will be made to the spark-support chart and the values.yaml file specific to each namespace.

Any feedback on the functionality and testing is welcome.

Event Timeline

BTullis renamed this task from Start testing spark on kubernetes to Carry out end-user testing of spark on kubernetes.Dec 17 2025, 12:17 PM
BTullis triaged this task as Medium priority.
BTullis updated the task description. (Show Details)

Tests completed today:

  • Launch and execute a spark command from spark-sql, spark-shell and pyspark. I also tested spark-submit but all my commands were buggy (see below) :)
  • Spark connects successfully to the Hive Metastore
  • Spark connects successfully to HDFS (with the correct principal, rights enforcement ok)
  • Spark works in dynamic-allocation mode by default, but doesn't specify a max number of executors by default. Someone could overwhelm the cluster with those settings - we should put a default value for maxExecutors
  • When a value is set for maxExecutors, spark abides and creates up to the expected number of executors (same for other basic config about memory and cores)
  • For dynamic allocation to be more efficient with k8s, we should set the spark.dynamicAllocation.shuffleTracking.enabled=true parameter by default. This allows spark to remove executors not handling shuffle files only.

Things that don't work:

  • Running our current jars with the new spark version - Different java and scala versions between the spark code and our compiled code

I have spent time reading about details for spark on k8s, and the temporary files management (shuffling and spilling) will be a real subject.

Change #1226261 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/deployment-charts@master] Update the image used for the spark-toolbox

https://gerrit.wikimedia.org/r/1226261

Change #1226261 merged by jenkins-bot:

[operations/deployment-charts@master] Update the image used for the spark-toolbox

https://gerrit.wikimedia.org/r/1226261

  • Spark works in dynamic-allocation mode by default, but doesn't specify a max number of executors by default. Someone could overwhelm the cluster with those settings - we should put a default value for maxExecutors

What default value do you think that we should set for this? How about 50?

  • For dynamic allocation to be more efficient with k8s, we should set the spark.dynamicAllocation.shuffleTracking.enabled=true parameter by default. This allows spark to remove executors not handling shuffle files only.

I'll make a patch to set this now.

Things that don't work:

  • Running our current jars with the new spark version - Different java and scala versions between the spark code and our compiled code

I'm pretty sure that the scala version should still be 2.12.

You can see it being downloaded here, during the spark 3.5.7 distribution compilation stage.

The Java version has definietly changed, since we build spark with openjdk-11-jdk and run it with openjdk-11-jre.

I have spent time reading about details for spark on k8s, and the temporary files management (shuffling and spilling) will be a real subject.

I agree. There will be lots of options to look at, here.
These docs are useful: https://spark.apache.org/docs/3.5.7/running-on-kubernetes.html#local-storage

If we do want to think about using ceph devices for temporary storage, we could think about using a replication factor of 1. That would cut down the write amplification for network traffic, compared with having three copies of temporary data. It's just a thought.

  • Spark works in dynamic-allocation mode by default, but doesn't specify a max number of executors by default. Someone could overwhelm the cluster with those settings - we should put a default value for maxExecutors

What default value do you think that we should set for this? How about 50?

The default on for airflow on yarn is 16, I think we should keep it that way :)

Change #1242514 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/puppet@production] Add the configuration for the new dse-k8s worker nodes that were an-worker

https://gerrit.wikimedia.org/r/1242514

Change #1242514 merged by Btullis:

[operations/puppet@production] Add the configuration for the new dse-k8s worker nodes that were an-worker

https://gerrit.wikimedia.org/r/1242514

Change #1245367 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/deployment-charts@master] Add an analytics PSP permitting access to certain hostPaths

https://gerrit.wikimedia.org/r/1245367

Change #1245369 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/deployment-charts@master] Apply the analytics pod security profile to several namespaces in eqiad

https://gerrit.wikimedia.org/r/1245369

Change #1245403 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/deployment-charts@master] Add a ValidatingAdmissionPolicy permitting access to /srv/spark

https://gerrit.wikimedia.org/r/1245403

Change #1245413 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/puppet@production] Add a /srv/spark managed directory on dse-k8s-worker nodes

https://gerrit.wikimedia.org/r/1245413

Change #1245367 abandoned by Btullis:

[operations/deployment-charts@master] Add an analytics PSP permitting access to certain hostPaths

Reason:

PSPs are already disabled.

https://gerrit.wikimedia.org/r/1245367

Change #1245413 merged by Btullis:

[operations/puppet@production] Add a /srv/spark managed directory on dse-k8s-worker nodes

https://gerrit.wikimedia.org/r/1245413

Change #1245403 merged by jenkins-bot:

[operations/deployment-charts@master] Add a ValidatingAdmissionPolicy for use with analytics workloads

https://gerrit.wikimedia.org/r/1245403

Change #1245369 merged by jenkins-bot:

[operations/deployment-charts@master] Apply the new VAP to several namespaces

https://gerrit.wikimedia.org/r/1245369

Change #1265434 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/deployment-charts@master] Update pod security standards for dse-k8s namespaces

https://gerrit.wikimedia.org/r/1265434

Change #1265434 merged by jenkins-bot:

[operations/deployment-charts@master] Update pod security standards for dse-k8s namespaces

https://gerrit.wikimedia.org/r/1265434

JAllemandou renamed this task from Carry out end-user testing of spark on kubernetes to [Infra] Carry out end-user testing of spark on kubernetes.Jul 8 2026, 7:47 AM

Change #1312514 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/puppet@production] kubernetes: stop managing /srv/spark on the dse-k8s workers

https://gerrit.wikimedia.org/r/1312514

Change #1312540 had a related patch set uploaded (by Btullis; author: Btullis):

[operations/deployment-charts@master] validating-admission-policies: remove /srv/spark from allowed hostPaths

https://gerrit.wikimedia.org/r/1312540

Change #1312514 merged by Btullis:

[operations/puppet@production] kubernetes: stop managing /srv/spark on the dse-k8s workers

https://gerrit.wikimedia.org/r/1312514

Change #1312540 merged by jenkins-bot:

[operations/deployment-charts@master] validating-admission-policies: remove /srv/spark from allowed hostPaths

https://gerrit.wikimedia.org/r/1312540