Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[SPARK-47475][CORE][K8S] Support `spark.kubernetes.jars.avoidDownload…
…Schemes` for K8s Cluster Mode ### What changes were proposed in this pull request? During spark submit, for K8s cluster mode driver, instead of always downloading jars and serving it to executors, avoid the download if the url matches `spark.kubernetes.jars.avoidDownloadSchemes` in the configuration. ### Why are the changes needed? For K8s cluster mode driver, `SparkSubmit` will download all the jars in the `spark.jars` to driver and then those jars' urls in `spark.jars` will be replaced by the driver local paths. Later when driver starts the `SparkContext`, it will copy all the `spark.jars` to `spark.app.initial.jar.urls`, start a file server and replace the jars with driver local paths in `spark.app.initial.jar.urls` with file service urls. When the executors start, they will download those driver local jars by `spark.app.initial.jar.urls`. When jars are big and the spark application requests a lot of executors, the executors' massive concurrent download of the jars from the driver will cause network saturation. In this case, the executors jar download will timeout, causing executors to be terminated. From user point of view, the application is trapped in the loop of massive executor loss and re-provision, but never gets enough live executors as requested, leads to SLA breach or sometimes failure. So instead of letting driver to download the jars and then serve them to executors, if we just avoid driver from downloading the jars and keeping the urls in `spark.jars` as they were, the executor will try to directly download the jars from the urls provided by user. This will avoid the driver download bottleneck mentioned above, especially when jar urls are with scalable storage schemes, like s3 or hdfs. Meanwhile, there are cases jar urls are with schemes of less scalable than driver file server, e.g. http, ftp, etc, or when the jars are small, or executor count is small - user may still want to fall back to current solution and use driver file server to serve the jars. So in this case, make the driver jars downloading and serving optional by scheme (similar idea to `FORCE_DOWNLOAD_SCHEMES` in YARN) is a good approach for the solution. ### Does this PR introduce _any_ user-facing change? A configuration `spark.kubernetes.jars.avoidDownloadSchemes` is added ### How was this patch tested? - Unit tests added - Tested with an application running on AWS EKS submitted with a 1GB jar on s3. - Before the fix, the application could not scale to 1k live executors. - After the fix, the application had no problem to scale beyond 12k live executors. ### Was this patch authored or co-authored using generative AI tooling? No Closes #45715 from leletan/allow_k8s_executor_to_download_remote_jar. Authored-by: jiale_tan <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]>
- Loading branch information