Kubernetes与纱线/ Hadoop生态系统之间的火花

Question

我看到在kubernetes上产生火花的吸引力很大。在Hadoop上运行Spark是否更好？两种方法都以分布式方法运行。有人可以帮助我了解在kubernetes上运行Spark与Hadoop生态系统之间的区别/比较吗？

谢谢

Answer 1

  

有人可以帮助我了解在kubernetes和Hadoop生态系统上运行spark的区别/比较吗？

请注意，这是一个理论上的答案，因为我不再运行Spark，因此也没有在kubernetes上运行Spark，但是我既维护了Hadoop集群，又维护了kubernetes集群，所以我可以说他们之间的某些差异。

Kubernetes就像是一个经过艰苦奋斗的资源管理器，具有对api的访问权，这是一个合理的人所希望的。它提供了非常轻松的声明性资源限制（cpu和ram甚至系统调用能力），非常非常非常方便的日志输出（都通过kubectl返回用户，并使用多种日志管理方法），前所未有的指标收集和输出级别，使人们可以密切关注集群的健康状况以及其中的工作，而且清单还在不断增加。

但是也许一个人选择在kubernetes上运行Spark的最大原因就是一个人选择完全在kubernetes上运行的相同原因：共享资源，而不必为不同的工作负载创建新机器（当然，还有上述所有这些好处） ）。因此，如果您有一个Spark集群，则很可能在没有积极运行作业的情况下烧掉$$$，而kubernetes会在其他节点未运行Spark的情况下乐意将其他作业调度到这些节点上工作。是的，我知道Mesos和Yarn是“通用的”集群资源管理器，但是根据我的经验，它们没有像kubernetes一样痛苦或无处不在。

我欢迎有人发表反叙述，或在kubernetes上贡献Spark的更多动手经验，但是

Answer 2

为了完善Matthew L Daniel的意见，该矿山集中在Kubernetes可以带给数据管道的2个有趣概念上： -名称空间+资源配额有助于例如通过将更多资源保留给数据密集型/更多不可预测/关键业务部分而不必每次都具有新节点，从而更轻松地分离和共享资源 -水平扩展-基本上，当Kubernetes调度程序无法成功分配将来可能由Spark的动态资源分配创建的新Pod（尚未实现）时，它就能够动态挂载必要的节点（例如，通过https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#introduction） 。那就是说，目前在Apache Spark中很难实现水平缩放，因为即使对于关闭的执行程序，它也需要保留外部洗牌服务。因此，即使我们的负载减少，我们仍将保留创建的节点来处理其增加。但是，当解决此问题时，Kubernetes自动缩放将成为降低成本，提高处理性能和使管道具有弹性的有趣选择。

但是请注意，所有这些说法仅基于个人观察和Kubernetes功能（2.3.0）上早期Spark的一些本地测试。