我看到 Kubernetes 对 Spark 有很大的吸引力。它比在 Hadoop 上运行 spark 更好吗？这两种方法都以分布式方法运行。有人可以帮助我了解在 kubernetes 与 Hadoop 生态系统上运行 spark 之间的区别/比较吗？
谢谢
【问题讨论】：
标签： apache-spark hadoop kubernetes
有人可以帮助我了解在 kubernetes 与 Hadoop 生态系统上运行 spark 之间的区别/比较吗？
预先警告这是一个理论上的答案，因为我不再运行 Spark，因此我没有在 kubernetes 上运行 Spark，但是我已经维护了 Hadoop 集群和现在的 kubernetes 集群，所以我可以说他们的一些差异。
Kubernetes 是一个久经沙场的资源管理器，可以通过 api 访问其所有组件，这是一个理性的人所希望的。它提供了非常轻松的声明性资源限制（cpu 和 ram，甚至还有系统调用容量），非常、very 无痛的日志出口（都通过 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 中很难实现水平扩展，因为它需要保留外部 shuffle 服务，即使是关闭的执行程序也是如此。所以即使我们的负载减少，我们仍然会保留创建的节点来处理它的增加。但是，当这个问题得到解决时，Kubernetes 自动缩放将成为降低成本、提高处理性能和使管道具有弹性的有趣选择。
但请注意，所有这些说法仅基于个人观察和对早期 Spark on Kubernetes 功能 (2.3.0) 的一些本地测试。
【讨论】：