Spark是用於分析應用程序的開源，可伸縮，大規模並行，內存中執行引擎。
可以將其視為位於多個數據存儲上方的內存層，在其中可以將數據加載到內存中並在整個集群中並行進行分析。 Spark Core：Spark的基礎，它為調度和基本I / O提供了許多自由，Spark提供了100多個高級操作員，使構建並行應用程序變得容易。
Spark還包括預構建的機器學習算法和圖形分析算法，這些算法專門編寫為在內存中並行執行。 它還支持查詢的交互式SQL處理和實時流分析。 因此，您可以使用Java，Python，R和Scala等編程語言編寫分析應用程序。
您可以在雲，Hadoop YARN，Apache Mesos或Kubernetes上使用其獨立集群模式運行Spark。 訪問HDFS，Cassandra，HBase，Hive，對象存儲和任何Hadoop數據源中的數據。
Spark可以在Kubernetes管理的集群上運行。 此功能利用已添加到Spark的本地Kubernetes調度程序。
怎麼運行的？
> Spark Submit on k8s
spark-submit可以直接用於將Spark應用程序提交到Kubernetes集群。 提交機制的工作方式如下：
· Spark創建一個在Kubernetes容器中運行的Spark驅動程序。
· 驅動程序將創建執行程序，這些執行程序也將在Kubernetes Pod中運行並連接到它們，並執行應用程序代碼。
· 應用程序完成後，執行程序Pod終止並被清理，但驅動程序Pod保留日誌，並在Kubernetes API中保持"完成"狀態，直到最終對其進行垃圾收集或手動清理為止。
但是，為什麼我們應該使用Kubernetes作為集群管理器？
這種集成當然非常有趣，但是應該考慮的一個重要問題是，為什麼組織應該選擇Kubernetes作為集群管理器，為什麼不運行在默認情況下隨Spark附帶的Standalone Scheduler或運行在YARN等生產級集群管理器上。
讓我嘗試用以下幾點來回答這個問題。
· 您是否正在使用容器化的數據分析管道？ 一家典型的公司想要統一數據管道，例如，如果某個典型的數據管道需要Queue，Spark，DB，Visualization應用程序並且所有內容都在容器上運行，那麼在容器上運行Spark並使用Kubernetes來管理整個管道是有意義的。
· 資源共享得到了更好的優化。與其在專用硬件上運行管道，不如在Kubernetes集群上運行它，是非常高效和最佳的，因此，由於管道中的所有組件並非始終都在運行，因此資源共享更好。
· 利用Kubernetes生態系統 Spark工作負載可以直接使用Kubernetes集群通過命名空間和配額以及管理功能（如可插拔授權和日誌記錄）進行多租戶和共享。 最重要的是，它不需要在Kubernetes集群上進行任何更改或進行新安裝。 只需創建一個容器映像併為您的Spark應用程序設置正確的RBAC角色，便一切就緒。 當您使用Kubernetes作為集群管理器時，您將獲得與日誌記錄和監視解決方案的無縫集成。 社區還在探索高級用例，例如管理流工作負載和利用Istio等服務網格。
· 使用獨立調度程序的侷限性。您可以通過啟動以獨立模式運行的Spark集群輕鬆在Kubernetes上運行Spark。這意味著您在Kubernetes上運行Spark Master和worker和完整的Spark集群。這種方法非常可行，並且適用於許多情況。它具有其自身的優點，因為它是在Kubernetes上運行Spark的非常穩定的方式，並且您可以利用kubernetes的所有很酷的功能，例如資源管理，各種持久性存儲及其用於日誌記錄和服務網格（Istio）的集成，但是Spark並不知道它在Kubernetes和Kubernetes上運行並不知道它在運行Spark。這意味著我們需要重複或複製一些配置，例如，如果要運行10 GB的執行器，則需要使用這些設置啟動Kubernetes POD，並相應地指定Spark守護程序內存。請注意，您將需要為Spark Daemon進程提供一些額外的內存，例如Spark Master和Spark worker，並且不能僅將POD的全部內存用於驅動程序或執行程序。因此，如果沒有專家:)，就會浪費資源，並且很容易弄亂配置。獨立方法的另一個侷限性在於它難以管理彈性-默認情況下獨立不提供。
· YARN與Kubernetes的比較：儘管這並不是一個正確的比較，因為kubernetes仍然支持使用YARN作為資源管理器/談判者的所有框架。 YARN用於許多生產工作負載，可用於運行任何應用程序。 Spark將YARN視為容器管理系統，以在其獲取容器後請求具有定義的資源的Spark資源，並在容器之間建立基於RPC的通信以運行驅動程序和執行程序。 YARN不處理服務層，因為Spark需要處理服務層。 YARN可以通過釋放和獲取容器來自動縮放。 使用YARN容器的主要缺點是，它始終在容器中運行JVM，而當您在Kubernetes上運行時，您可以使用自己的映像，該映像非常少。
· Kubernetes社區支持。 如果您是組織機構，需要在容器協調器之間進行選擇，則可以輕鬆選擇Kubernetes，這不僅是因為它具有社區支持，而且還可以在您選擇的" Prem"和" cloud provider"上運行，以及 沒有CLOUD鎖定您需要承受的痛苦。 Kubernetes與容器運行時無關，它具有非常廣泛的功能，例如支持在容器上運行群集應用程序和服務負載平衡，服務升級而不會停止或發生任何中斷以及定義明確的存儲故事。
為什麼您可能要避免使用Kubernetes作為Spark集群管理器？
這仍是一個beta功能，尚未投入生產。 有許多功能，例如動態資源分配，依賴關係的群集內分段，對PySpark和SparkR的支持，對Kerberized HDFS群集的支持以及客戶端模式和流行的筆記本電腦交互式執行環境仍在工作中，並且不可用。
許多需要進一步改進的功能是將Executor日誌，History服務器事件存儲在持久捲上，以便以後可以引用它們。
摘要
Apache Spark是數據科學家必不可少的工具，它為從大規模數據轉換到分析到機器學習的各種應用程序提供了一個強大的平臺。
數據科學家正在採用容器，以通過實現諸如打包依賴項和創建可複製工件之類的好處來改善其工作流程。
鑑於Kubernetes是管理容器化環境的標準，因此自然支持Spark中的Kubernetes API。
(本文翻譯自Rachit Arora的文章《Why run Spark on Kubernetes?》，參考：https://medium.com/@rachit1arora/why-run-spark-on-kubernetes-51c0ccb39c9b)
