如何在kubernetes上運行apache spark

這篇文章主要介紹“如何在kubernetes上運行apache spark”，在日常操作中，相信很多人在如何在kubernetes上運行apache spark問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何在kubernetes上運行apache spark”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

一、Data Mechanic平臺介紹

這塊是data mechanics平臺的一個介紹。首先，它是一個serverless的平臺，即一個全托管的平臺，用戶不用去關心自己的機器。所有的應用的啟動和擴容都是在這種秒級的。然后，對于這種本地的開發轉到這種線上的部署，它是一種無縫的轉換。然后，它還能提供這種配置自動的spark的一些參數調優，整個這條pipeline都會做得非常的快，已經非常地穩定。

然后他們相當于是把整個的平臺部署在用戶的賬號里邊的K8S集群。這樣的話，對整個的安全是一個非常大的保證。然后數據權限，包括運行權限，都在統一的賬號里面。

二、Spark on k8s

（一）核心概念

首先，k8s和spark的結合是出現在spark 2.3版本以后的事情，在此之前有幾種方式。第一種就是Standalone，大家使用的并不是非常的多。第二種是Apache mesos，在國外用的比較多，但是市場規模也在逐漸縮小。第三種是Yarn，我們現在絕大多數的企業都是跑在Yarn的集群里面了。第四種是Kubernetes，現在大家也逐漸的把spark跑在k8s上面。

Spark on k8s的架構如下圖所示：

提交應用的方式有兩種。一種是Spark submit，另一種是Spark-on-k8s operator。它們各自的特點如下圖所示：

然后我們再對比一下Yarn和k8s的依賴的管理。這塊是區分點比較大的一個地方。Yarn提供一個全局的spark版本，包括python的版本，全局的包的依賴，缺少環境隔離。而k8s是完全的環境隔離，每一個應用可以跑在完全不同的環境、版本等。Yarn的包管理方案是上傳依賴包到HDFS。K8s的包管理方案是自己管理鏡像倉庫，將依賴包打入image中，支持包依賴管理，將包上傳到 OSS/HDFS，區分不同級別任務，混合使用以上兩種模式。

（二）配置和性能

然后我們說一下配置spark executors的小坑。舉個例子，假設k8s node為16G-RAM，4-core的ECS，下面的配置會一個executor都申請不到！如下圖所示。

原因是什么，就是說Spark pod只能按照node資源的一定比例來申請資源，而spark.executor.cores=4占用了node cores全部資源。如下圖所示，假設我們計算得到的可用資源是85%，那么我們應該這樣配置資源，spark.kubernetes.executor.request.cores=3400m。

然后這塊是一個比較重要的特點，就是動態資源。動態資源的完整支持目前做不到。比如說，Kill一個pod，shuffle file會丟失， 會帶來重算。

這一塊是Cluster autoscaling和dynamic allocation。上文中，我們看到PPT的某一頁，它有一個實線框，還有一個虛線框。實際上說的是，k8s cluster autoscaler：當pod處于pending狀態不能被分配資源時，擴展node節點。然后， Autoscaling和動態資源配合起來工作，就是說，當有資源時，executor會在10s內注冊到driver。而當沒有資源時，先通過autoscaling添加ECS資源，再申請executors。大約在1min~2min內完成executor申請過程。

這個實際上也是更好的保證了我們運行時的彈性，還有一個我自己的理解，比較有意思的一個玩法，就是說更加省成本。Spot instance會使得成本降低75%，它是可以被搶占的一種資源方式，跑一些SLA不高、價格敏感的應用。它在架構上整體設計，使得成本最低。如果executor被kill，會recover。如果driver被kill，就會很危險。配置node selector和affinities來控制Driver調度在非搶占的node，executor調度在spot instance。

然后，下一個就是對象存儲的IO問題。Sparkonk8s通常都是針對對象存儲，rename，list，commit task/job會非常費時。如果沒有S3A committers，Jindofs JobCommitter，應該設置 spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2。

還有Shuffle性能。I/O性能是shuffle bound workload的關鍵點，spark2.x版本用docker file system。而Docker file system是非常慢的，需要用volume來代替。

（三）未來工作

未來的工作，我認為比較重要的就是shuffle的提升，中間數據的存儲與計算分離。這塊是一個比較大的工作。另外，還有Node decommission，支持上傳python依賴文件等等。

我們選擇k8s的優缺點，如下圖所示：

部署spark on k8s的具體步驟，如下圖所示：

三、EMR團隊云原生的思考和實踐

（一）整體架構

這塊是我們的一個整體架構，如下圖所示：

（二）動態資源&shuffle提升

Shuffle service解決核心問題：
? 解決動態資源問題
? 解決掛載云盤貴，事前不確定大小的痛點
? 解決NAS作為中心存儲的擴展性以及性能問題
? 避免task由于fetch失敗重新計算的問題，提升中大作業的穩定性
? 通過Tiered存儲提升作業性能

（三）EMR Spark云原生規劃

EMR產品體系，創建EMR集群類型為ON ACK：
? JindoSpark鏡像
? JindoFSService/JindoFSSDK提升訪問OSS數據湖能力
? JindoJobCommitter增強提交OSS作業能力
? JindoShuffleService&動態資源能力增強
? ACK集群打通EMR原有集群，可以互訪老集群表和HDFS數據
? Operator增強，Dependency管理，提供一站式管控命令
? 云原生日志、監控一站式平臺

關鍵詞：kubernetes，apache spark，云原生，data mechanics，spark on k8s

到此，關于“如何在kubernetes上運行apache spark”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！