Apache Spark on K8s的安全性和性能優化

• 前言

    Apache Spark是目前最爲流行的大數據計算框架，與Hadoop相比，它是替換MapReduce組件的不二選擇，愈來愈多的企業正在從傳統的MapReduce做業調度遷移到Spark上來，Spark的生態圈支持者愈來愈多，固然它出衆的內部API設計，讓它也很是容易和現有既成事實的Hadoop組件（YARN/HDFS）集成。

    容器技術的興起，各類分佈式的容器編排技術也應運而生，其中的佼佼者包括Apache Mesos和Google發起的Kubernetes，雖然Mesos系出名門（UC Berkely），可是K8s最近1-2年逐漸有拉大領先差距的趨勢。

    大數據計算框架，存儲框架和雲計算容器技術，這二者在數據中心的技術棧中，早期都是各自獨立發展，並沒有太大關聯關係，伴隨各自技術生態圈日益成熟，幾個大的技術框架各自領地劃分也很是清楚，大數據計算服務與其餘雲計算服務並沒有二致，須要統一的資源調度與協調框架，讓它的部署更加方便，資源利用率更加高效；從Mesos或者K8S的角度，做爲致力於成爲數據中心的OS（操做系統）的資源調度框架，放棄掉數據中心最大的應用場景之一的大數據計算服務，貌似也說不過去，因而，這二者慢慢也走在了一塊兒。這篇文章，咱們來探討它們的重要表明，Apache Spark和K8s，當它們走在一塊兒的時候，會碰到什麼樣的問題，以及社區的最新進展。

• Apache Spark的分佈式調度框架

回顧歷史，Spark的資源調度器有這麼幾個實現：

• • Local模式，主要用於Spark應用程序開發調試使用，畢竟是單機單進程，設置斷點，單步跟蹤都十分方便；
  • Standalone模式，獨佔模式，啓動應用程序時告訴調度器須要多少資源（多少CPU線程，多少內存），在應用程序的完整生命週期內，獨享資源，哪怕資源閒置也沒法分配給其餘用戶使用；
  • Yarn模式，Yarn模式本質功能和Standalone沒有太大差異，只不過YARN是Hadoop生態系統中的重要組件，有着更好的多租戶的概念，且有不少其餘組件對於YARN的支持很完備，Spark爲了和其餘Hadoop生態組件共存，支持YARN模式也是大勢所趨；好在YARN發展出了Dynamic Resource Allocation（動態資源分配），讓相似Spark這種大數據計算框架，在部分計算任務結束時就能提早釋放資源，讓給同一集羣中的其它用戶或者程序使用，極大提升了系統資源利用率。
  • Mesos模式，因爲和Spark師出同門，Spark在很早期就已經支持它了，固然Mesos在動態資源分配上也作得比YARN要早，而且支持容器技術，當初的理念是很先進的。
  • K8s模式，確實Mesos當初的理念是很先進的，可是架不住Google力推Kubernetes，K8s在容器編排和軟件生態建設上，充分發揮了google工程師團隊強大的工程能力，Mesos能提供的功能，基本K8s都能給。

• 爲何容器技術（和K8s）對於Spark很重要？

  • 在共享雲計算平臺多租戶的應用場景下，每一個用戶都但願有獨立的，隔離的應用環境，減小彼此調用都干擾，好比作Python調用時，不一樣用戶對於Python的版本可能都會有不一樣要求。容器技術能夠爲不一樣用戶和應用構建徹底隔離，獨立，可簡單維護的運行環境。這是Hadoop時代的YARN，利用虛擬的資源分配技術所知足不了的。
  • YARN是大數據資源調度框架，而數據中心軟件系統每每還包括數據庫服務，web服務，消息服務等等其它應用程序，讓這些徹底不相干的應用友好共存，最大化資源利用率，是數據中心維護者的最大心願，K8s碰巧又是能夠完成這一使命的有力候選人。能夠參見 《京東如何基於容器技術打造高性能及效率的大數據平臺》

• Spark on K8S面臨的問題和調整

    做爲最爲流行的大數據計算框架Apache Spark，與Kubernetes的集成是成爲當前比較熱門的話題，這個工做目前是有Google的工程師在力推。除了計算需求之外，大數據還會有大量的數據存儲在HDFS之上，當Kubernetes能夠輕易調度Apache Spark，爲它提供一個安全可靠的運行隔離環境時，數據在多用戶之間的安全性又變得很是棘手，本文正是探討了兩個話題：如何利用Kerboros這樣的認證體系，打通HDFS和Spark的做業執行的權限控制；出於性能的考慮，在Spark的Executor Pod如何仍然保持數據本地性調度優化。

具體細節能夠參見示說網上的ppt文檔： apache_spark_on_k8s_and_hdfs_security