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碰巧又是可以完成這一使命的有力候選人。可以參見 《ofollow,noindex">京東如何基於容器技術打造高效能及效率的大資料平臺 》
-
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