Flink/Spark on K8s 实战

最新推荐文章于 2024-11-02 15:20:05 发布

wespten

最新推荐文章于 2024-11-02 15:20:05 发布

阅读量770

点赞数

分类专栏： Hadoop Hive Spark 大数据安全文章标签： flink spark 大数据

本文链接：https://blog.csdn.net/qq_35029061/article/details/127157054

版权

Hadoop Hive Spark 大数据安全专栏收录该内容

130 篇文章 43 订阅 ¥19.90 ¥99.00

订阅专栏

超级会员免费看

本文深入探讨了Flink和Spark在Kubernetes（K8s）上的原生支持，涵盖从提交作业到资源管理的全过程。文章详细介绍了Spark和Flink在K8s上的部署模式，如Spark的cluster和client模式，以及Flink的Standalone和原生模式。内容包括作业提交、资源清理、Pod模板、RBAC权限管理等，并分析了两种框架在K8s上的实现细节和trouble-shooting策略，如日志收集和监控方案。此外，文章还讨论了K8s实现的不足之处，如Spark的Pod容错性和Flink的Deployment语义问题。

摘要由CSDN通过智能技术生成

一、Native 简介

现在，Docker、Kubernetes等容器技术已发展为一项通用技术。

Kubernetes 的核心难点无外乎这几个方面：

容器内抓包定位网络问题
容器进程主动退出、只能运行一个参数
JVM 参数在容器中突然失效

说白了， Kubernetes 的核心理念并不复杂，但涉及的维度的确很多。比如，微服务架构理念、分布式原理、网络、存储等各个层级的知识体系都会覆盖，非运维出身理解起来会比较困难。

以 Flink 和 Spark 为代表的分布式流批计算框架的下层资源管理平台逐渐从 Hadoop 生态的 YARN 转向 Kubernetes生态的K8s原生scheduler以及周边资源调度器，比如 Volcano 和 Yunikorn 等。

这篇文章简单比较一下两种计算框架在 Native Kubernetes 的支持和实现上的异同，以及对于应用到生产环境我们还需要做些什么。

这里的 native 其实就是计算框架直接向 Kubernetes 申请资源。比如很多跑在 YARN 上面的计算框架，需要自己实现一个 AppMaster 来想 YARN 的 ResourceManager 来申请资源。Native K8s 相当于计算框架自己实现一个类似 AppMaster 的角色向 k8s 去申请资源，当然和 AppMaster 还是有差异的（AppMaster 需要按 YARN 的标准进行实现）。