我看到 Spark 对 kubernetes 有很大的吸引力。它比在Hadoop上运行火花更好吗？这两种方法都以分布式方法运行。有人可以帮助我理解在 kubernetes 上运行 spark 与 Hadoop 生态系统之间的区别/比较吗？
谢谢
有人可以帮助我理解在 kubernetes 上运行 spark 与 Hadoop 生态系统之间的区别/比较吗？
预先警告这是一个理论上的答案，因为我不再运行 Spark，因此我没有在 kubernetes 上运行 Spark，但我维护了一个 Hadoop 集群和一个现在的 kubernetes 集群，所以我可以谈谈它们的一些差异。
Kubernetes 是一个久经沙场的资源管理器，可以像一个理性的人所希望的那样，通过 API 访问其所有组件。它提供了非常无痛的声明性资源限制(CPU 和 RAM，甚至还有系统调用容量(，非常非常无痛的日志出口(通过kubectl返回给用户，并使用多种类型的日志管理方法离开集群(，前所未有的指标收集和出口水平，允许人们密切关注集群及其中作业的运行状况， 这样的例子不胜枚举。
但也许人们选择在 kubernetes 上运行 Spark 的最大原因与选择运行 kubernetes 的原因相同：共享资源，而不必为不同的工作负载创建新机器(好吧，加上上面的所有这些好处(。因此，如果你有一个 Spark 集群，它非常非常有可能在作业没有在其上主动运行时燃烧 $$$，而 kubernetes 会在它们不运行 Spark 作业时愉快地将其他作业调度到这些节点上。是的，我知道 Mesos 和 Yarn 是"通用"集群资源管理器，但根据我的经验，它们并不像 kubernetes 那样无痛或无处不在。
我欢迎有人发布反驳，或者在 kubernetes 上贡献更多 Spark 的实践经验，但
为了完成 Matthew L Daniel 的观点，该矿重点介绍了 Kubernetes 可以为数据管道带来的 2 个有趣的概念： - 命名空间 + 资源配额有助于更轻松地分离和共享资源，例如将更多资源保留给数据密集型/更不可预测/业务关键部分，而不必每次都使用新节点 - 水平扩展 - 基本上，当 Kubernetes 调度程序无法成功分配将来可能使用 Spark 的动态资源分配(尚未实现(创建的新 pod 时，它能够动态挂载必要的节点(例如通过 https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#introduction(。也就是说，水平扩展目前在Apache Spark中很难实现，因为它需要保留外部随机服务，即使对于关闭的执行器也是如此。因此，即使我们的负载减少，我们仍将保留创建的节点来处理其增加。但是，当这个问题得到解决时，Kubernetes 自动缩放将是一个有趣的选择，可以降低成本、提高处理性能和使管道具有弹性。
但是请注意，所有这些说法仅基于个人观察和对早期 Spark on Kubernetes 功能 (2.3.0( 的一些本地测试。