spark over kubernetes vs yarn/hadoop生态系统

Question

我看到spark对kubernetes有很大的吸引力。它比在Hadoop上运行spark更好吗？这两种方法都运行在分布式方法中。有人能帮我理解一下在kubernetes上运行spark和在Hadoop生态系统上运行spark之间的区别/比较吗？

谢谢

Answer 1

有人能帮我理解一下在kubernetes上运行spark和在Hadoop生态系统上运行spark之间的区别/比较吗？

需要注意的是，这是一个理论上的答案，因为我不再运行Spark，因此我没有在kubernetes上运行Spark，但我维护了Hadoop集群和现在的kubernetes集群，所以我可以谈谈它们的一些区别。

Kubernetes是一个久经沙场的资源管理器，拥有对其所有组件的api访问权限，这是一个理性的人所希望的。它提供了非常轻松的声明资源限制( cpu和ram，甚至syscall容量)，非常非常轻松的日志输出(通过kubectl返回给用户，以及使用多种日志管理方法从集群中输出)，前所未有的指标收集和输出级别，允许人们关注集群的健康状况和其中的作业，不胜枚举。

但选择在kubernetes上运行Spark的最大原因可能与选择运行kubernetes的原因相同:共享资源，而不是为不同的工作负载创建新的机器(嗯，加上上面的所有好处)。因此，如果你有一个Spark集群，它很可能会在作业不活跃的时候烧毁$$$，而kubernetes会在这些节点上愉快地调度其他作业，而它们不运行Spark作业。是的，我知道Mesos和Yarn是“通用的”集群资源管理器，但根据我的经验，它们并不像kubernetes那样容易或无处不在。

我欢迎有人发布反叙述，或者在kubernetes上贡献更多关于Spark的实践经验，但尽管如此

Answer 2

为了完善Matthew L Daniel的观点，我将重点放在Kubernetes可以为数据管道带来的两个有趣的概念上：-命名空间+资源配额有助于更容易地分离和共享资源，例如，通过将更多的资源预留到数据密集型/更不可预测/业务关键部分，而不一定每次都有新的节点-水平扩展-基本上当Kubernetes调度器不能成功分配可能在未来使用Spark的动态资源分配创建的新pods时(尚未实现)，它能够动态地挂载必要的节点(例如，通过https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#introduction)。也就是说，水平扩展目前在Apache Spark中很难实现，因为它需要保留外部随机服务，即使对于关闭的执行器也是如此。因此，即使我们的负载减少了，我们仍然会保留创建的节点来处理它的增加。但当这个问题得到解决时，Kubernetes自动缩放将是一个有趣的选择，可以降低成本，提高处理性能，并使管道具有弹性。

然而，请注意，所有这些说法仅基于个人观察和对Kubernetes feature (2.3.0)上的早期Spark的一些本地测试。