-
前言
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文档：