Spark on Kubernetes 的现状与挑战

资源调度器可以简单分类成集中式资源调度器和两级资源调度器。两级资源调度器有一个中央调度器负责宏观资源调度，对于某个应用的调度则由下面分区资源调度器来做。两级资源调度器对于大规模应用的管理调度往往能有一个良好的支持，比如性能方面，缺点也很明显，实现复杂。其实这种设计思想在很多地方都有应用，比如内存管理里面的 tcmalloc 算法，Go 语言的内存管理实现。大数据的资源调度器 Mesos/Yarn，某种程度上都可以归类为两级资源调度器。

集中式资源调度器对于所有的资源请求进行响应和决策，这在集群规模大了之后难免会导致一个单点瓶颈，毋庸置疑。但是 Kubernetes 的 scheduler 还有一点不同的是，它是一种升级版，一种基于共享状态的集中式资源调度器。Kubernetes 通过将整个集群的资源缓存到 scheduler 本地，在进行资源调度的时候在根据缓存的资源状态来做一个 “乐观” 分配(assume + commit)来实现调度器的高性能。

Kubernetes 的默认调度器在某种程度上并不能很好的 match Spark 的 job 调度需求，对此一种可行的技术方案是再提供一种 custom scheduler，比如 Spark on Kubernetes Native 方式的参与者之一的大数据公司 Palantir 就开源了他们的 custom scheduler，github repo: https://github.com/palantir/k8s-spark-scheduler。

2.集群规模瓶颈。

基本上现在可以确定的是 Kubernetes 会在集群规模达到五千台的时候出现瓶颈，但是在很早期的时候 Spark 发表论文的时候就声称 Spark Standalone 模式可以支持一万台规模。Kubernetes 的瓶颈主要体现在 master 上，比如用来做元数据存储的基于 raft 一致性协议的 etcd 和 apiserver 等。对此在刚过去的 2019 上海 KubeCon 大会上，阿里巴巴做了一个关于提高 master 性能的 session: 了解 Kubernetes Master 的可扩展性和性能，感兴趣的可以自行了解。

3.Pod 驱逐(Eviction)问题。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!