ITPub博客

首页 > 大数据 > 数据分析 > Spark in action on Kubernetes - Spark Operator的原理解析

Spark in action on Kubernetes - Spark Operator的原理解析

数据分析 作者:吐泡泡ooO 时间:2019-04-03 15:56:12 0 删除 编辑

前言

在上篇文章中,向大家介绍了如何使用Spark Operator在kubernetes集群上面提交一个计算作业。今天我们会继续使用上篇文章中搭建的Playground进行调试与解析,帮助大家更深入的理解Spark Operator的工作原理。所以如果没有浏览过上篇文章的同学,可以通过传送门直达,先配置好Playground的环境。

Spark Operator的内部实现

在深入解析Spark Operator之前,我们先补充一些关于kubernetes operator的知识。2018年可以说是kubernetes operator泛滥的一年,各种operator如雨后春笋般出现。operator是扩展kubernetes以及与kubernetes集成的最佳方式之一。在kubernetes的设计理念中,有很重要的一条就是进行了抽象,比如对存储进行抽象、对应用负载进行抽象、对接入层进行抽象等等。每个抽象又对应了各自生命周期管理的controller,开发者提交的Yaml实际上是对抽象终态的描述,而controller会监听抽象的变化、解析并进行处理,最终尝试将状态修正到终态。

那么对于在kubernetes中未定义的抽象该如何处理呢,答案就是operator。一个标准operator通常包含如下几个部分:1. CRD抽象的定义,负责描述抽象所能包含的功能。 2.CRD Controller ,负责解析CRD定义的内容以及生命周期的管理。3.clent-go的SDK,负责提供代码集成时使用的SDK。

有了这个知识储备,那么我们回过头来看Spark Operator的代码,结构基本就比较明晰了。核心的代码逻辑都在pkg下,其中apis下面主要是定义了不同版本的API;client目录下主要是自动生成的client-go的SDK;crd目录下主要是定义的两个自定义资源sparkapplication和scheduledsparkapplication的结构。controller目录下主要定义的就是这个operator的生命周期管理的逻辑;config目录下主要处理spark config的转换。了解一个Operator能力最快捷的方式,就是查看CRD的定义。在Spark Operator中定义了sparkapplication和scheduledsparkapplication两个CRD,他们之间有什么区别呢?

sparkapplication 是对常规spark任务的抽象,作业是单次运行的,作业运行完毕后,所有的Pod会进入Succeed或者Failed的状态。而scheduledsparkapplication是对离线定时任务的一种抽象,开发者可以在scheduledsparkapplication中定义类似crontab的任务,实现spark离线任务的周期性定时调度。

上面这张图是Spark中kubernetes的集成图,也就是说当我们通过spark-submit提交作业的时候,会自动生成driver pod与exector pods。那么引入了Spark Operator后,这个流程变成了什么呢?

其实到此,我们就已经基本了解Spark Operator做的事情了,首先定义了两种不同的CRD对象,分别对应普通的计算任务与定时周期性的计算任务,然后解析CRD的配置文件,拼装成为spark-submit的命令,通过prometheus暴露监控数据采集接口,创建Service提供spark-ui的访问。然后通过监听Pod的状态,不断回写更新CRD对象,实现了spark作业任务的生命周期管理。

Spark Operator的任务状态机

当我们了解了Spark Operator的设计思路和基本流程后,还需要深入了解的就是sparkapplication的状态都包含哪些,他们之间是如何进行转换的,因为这是Spark Operator对于生命周期管理增强最重要的部分。

一个Spark的作业任务可以通过上述的状态机转换图进行表示,一个正常的作业任务经历如下几个状态:

而当任务失败的时候会进行重试,若重试超过最大重试次数则会失败。也就是说如果在任务的执行过程中,由于资源、调度等因素造成Pod被驱逐或者移除,Spark Operator都会通过自身的状态机状态转换进行重试。

Spark Operator的状态排查

我们已经知道了Spark Operator最核心的功能就是将CRD的配置转换为spark-submit的命令,那么当一个作业运行不预期的时候,我们该如何判断是哪一层出现的问题呢?首先我们要判断的就是spark-submit时所生成的参数是否是预期的,因为CRD的Yaml配置虽然可以增强表达能力,但是提高了配置的难度与出错的可能性。

默认情况下Spark Operator会通过glog level=2等级对外输出每次作业提交后转换的提交命令。而默认情况下,glog的level即为2,因此通过检查Spark Operator的Pod日志可以协助开发者快速排查问题。此外在sparkapplication上面也会通过event的方式进行状态的记录,上述状态机之间的转换都会通过event的方式体现在sparkapplication的对象上。掌握这两种方式进行问题排查,可以节省大量排错时间。

最后

使用Spark Operator是在kubernetes上实践spark的最佳方式,和传统的spark-submit相比提供了更多的故障恢复与可靠性保障,并且提供了监控、日志、UI等能力的集成与支持。在下一篇中,会为大家介绍在kubernetes集群中,提交spark作业时的如何使用外部存储存储的最佳实践。


本文作者:莫源

本文为云栖社区原创内容,未经允许不得转载。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/69915408/viewspace-2640278/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2019-04-03

  • 博文量
    728
  • 访问量
    414762