Spark On K8s实战教程

landmandw · · 112 次点击 · 开始浏览    置顶

学习地址1:https://pan.baidu.com/s/1lAtGozCTJdzGkNBATFCSRA 提取码:n37l 学习地址2:https://share.weiyun.com/Y7rFNJ8j 密码:8j8gae 一、k8s的优点 k8s是一个开源的容器集群管理系统,可以实现容器集群的自动化部署、自动扩缩容、维护等功能。 1、故障迁移 2、资源调度 3、资源隔离 4、负载均衡 5、跨平台部署 二、Spark on K8s工作原理 具体流程,包括以下几步: ①:用户使用kubectl 创建 SparkApplication 对象,提交sparkApplication的请求到api-server,并把sparkApplication的CRD持久化到etcd; ②:SparkApplication controller 从 kube-api server 接收到有对象请求,创建 submission (实际上就是 参数化以后的 spark-submit 命令),然后发送给 submission runner。 ③:Submission runner 提交 app 到 k8s 集群,并创建 driver pod。一旦 driver pod 正常运行,则由 driver pod 创建 executor pod。 当应用正常运行时,spark pod monitor 监听 application 的 pod 状态,(通过kubectl可以通过list、status看到)并将pod 状态的更新发送给 controller,由 controller 负责调用 kube-api 更新 spark application 的状态(实际上是更新 SparkApplication CRD 的状态字段)。 ④:mutating adminission webhook创建svc,可以查看spark web ui 三、Spark on K8s 的优势 优势1: 它的部署环境非常简单,我们现在使用的是云上托管的 K8s 服务,我们不需要去维护它的控制节点,当然每个云服务的 EMR 都有自己的产品,如 AWS 的 EKS,华为云的 CCE,谷歌的 GKE。这种类似的产品,我们不需要维护它的控制节点,也不需要在上面常驻任何 Spark 的服务就可以运行 Spark 作业。另外它也没有环境依赖,因为运行时所有的大数据作业都是容器化的,不需要节点上有一些提前预置好的环境,也就决定了运行的时候多版本可以共存。 优势2: 是其弹性优势。无论我们使用涉及开源的 K8s 的 cluster-auto scaler 插件,还是某些云商自己实现的基于 K8s 的更高效的扩缩容机制,都可以保证集群能够极快地自动扩缩容。这个时候,因为可以快速的把不用的节点关闭,也就相应地节约了计算的成本。 优势3: 它没有按节点来收取服务费用,只需要收取一个控制面的服务费用,这个服务费用是非常低的,在公司级的资源使用下,这部分的费用几乎是可以忽略不计的。 优势4: 它有更高的资源使用率。它是使用 go 语言编写的 kubelet 服务,它所需要预留的资源会远远低于 JVM 上所需要的,其节点利用率可以达到 90% 甚至更高。 四、spark app 开发 对于spark app 开发,实际上核心还是对于以来管理的处理解决方法比较多 all in one spark 直接打包到spark 应用中,可能需要频繁修改spark app 使用fat jar 在打包的时候包含以来到jar 中,比较方便,但是可能会造成jar 太大 通过pacakges 坐标模式(运行时自动下载依赖) in spark + fat jar 混合模式 将部分常用,同时比较重要的放到spark 中,fat jar 只存储应用自己需要的领域特定的 五、SparkSQL迁移到K8s的收益 1、可以将计算和存储进行解耦,即存算分离。在存储和计算耦合的架构中,由于各业务场景对存储和计算的需求不平衡,绑定两者同步进行伸缩,会出现其中一种资源浪费的情况;将计算和存储解耦后则可以根据需要分别进行弹性伸缩,系统在负载均衡调度方面可以更加灵活。 2、统一算力资源池实现统筹调度,SparkSQL可以作为离线业务与其它在线业务进行混混部达到峰谷互补的效果,有助于提升服务器资源利用率和管理运维效率,节约总成本。 六、Spark on k8s的挑战 挑战1: 我个人认为最重要的,就是Shuffle的流程,按照目前的Shuffle方式,我们是没办法打开动态资源特性的。而且还需要挂载云盘,云盘面临着Shuffle数据量的问题,挂的比较大会很浪费,挂的比较小又支持不了Shuffle Heavy的任务。 挑战2: 调度和队列管理问题,调度性能的衡量指标是,要确保当大量作业同时启动时,不应该有性能瓶颈。作业队列这一概念对于大数据领域的同学应该非常熟悉,他提供了一种管理资源的视图,有助于我们在队列之间控制资源和共享资源。 跳转3: 读写数据湖相比较HDFS,在大量的Rename,List等场景下性能会有所下降,同时OSS带宽也是一个不可避免的问题。 七、Spark on k8s的解决方案 1、如果用是Docker的文件系统,问题是显而易见的,因为性能慢不说,容量也是极其有限,对于Shuffle过程是十分不友好的。 2、如果用Hostpath,熟悉Spark的同学应该知道,是不能够启动动态资源特性的,这个对于Spark资源是一个很大的浪费,而且如果考虑到后续迁移到Serverless K8s,那么从架构上本身就是不支持Hostpath的。 4、如果是Executor挂云盘的PV,同样道理,也是不支持动态资源的,而且需要提前知道每个Executor的Shuffle数据量,挂的大比较浪费空间,挂的小Shuffle数据又不一定能够容纳下。

有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

112 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传