• 前言

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

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