首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

Spark Scheduler在K8s环境下是如何工作的?

Spark Scheduler在K8s环境下的工作方式如下:

Spark Scheduler是Apache Spark中的一个组件,用于在集群上调度和管理Spark应用程序的任务。在Kubernetes(K8s)环境下,Spark Scheduler与Kubernetes调度器(Kubernetes Scheduler)进行交互,以实现任务的调度和资源管理。

具体工作流程如下:

  1. 提交Spark应用程序:用户通过Spark提交器将Spark应用程序提交到Kubernetes集群中。
  2. 创建Spark Driver Pod:Kubernetes根据用户提交的应用程序规格创建一个Spark Driver Pod。Spark Driver是Spark应用程序的主进程,负责与Spark集群进行通信和协调。
  3. 分配资源:Kubernetes调度器为Spark Driver Pod分配资源,包括CPU、内存和其他所需的资源。
  4. 启动Spark Driver:Kubernetes启动Spark Driver Pod,并运行Spark Driver进程。
  5. Spark Driver与Scheduler通信:Spark Driver与Spark Scheduler进行通信,向其发送任务请求和资源需求。
  6. 调度任务:Spark Scheduler根据可用资源和任务需求,将任务分配给可用的Executor Pod。Executor Pod是运行Spark任务的工作单元。
  7. 创建Executor Pod:Kubernetes根据Spark Scheduler的任务分配,创建相应数量的Executor Pod,并为其分配资源。
  8. 运行任务:Executor Pod启动后,运行Spark任务的Executor进程。Executor进程接收Spark任务的任务描述,并在分配的资源上执行任务。
  9. 监控和管理:Spark Scheduler和Kubernetes调度器持续监控任务的执行情况和资源使用情况。如果有Executor Pod失败或资源不足,Spark Scheduler会重新调度任务或请求更多资源。

总结: Spark Scheduler在K8s环境下通过与Kubernetes调度器的交互,实现了Spark应用程序的任务调度和资源管理。它负责将任务分配给可用的Executor Pod,并监控任务的执行情况。通过与Kubernetes的集成,Spark Scheduler能够充分利用Kubernetes的弹性和资源管理能力,提高Spark应用程序的性能和可靠性。

腾讯云相关产品推荐:

  • 腾讯云容器服务(Tencent Kubernetes Engine,TKE):提供了托管的Kubernetes集群,可用于部署和管理Spark应用程序。详情请参考:https://cloud.tencent.com/product/tke
  • 腾讯云弹性MapReduce(EMR):提供了基于Spark的大数据处理服务,可在云端快速搭建和管理Spark集群。详情请参考:https://cloud.tencent.com/product/emr
页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • 【Spark on K8S】Spark里的k8s client

    目前在我们的应用下,会有这样的一种特殊的场景。比如说 Driver 创建在 A 集群,但是需要 Driver 将 Executor Pod 创建到 B 集群去。所以我们这里会有两个集群的 master url,分别是集群 A 和集群 B。那么创建任务的模式就是 spark-subtit 的 master url 指向集群 A,然后给 Driver 的 k8s client 设置其创建 Executor Pod 的 master url 指向 B,那么在现有 Spark 的参数下,能否直接通过 SparkConf 或者环境变量来实现这一点呢?我们看看源码。 对于这样的需求,我们首先需要去了解 Spark 是如何跟 k8s 集群打交道的。Spark on K8S 在 submit 的时候默认是直接在 K8S Master 节点提交,通过 --master 或者 SparkConf 中的 spark.master 来指定。

    02

    「走进k8s」Kubernetes基本概念和组件(13)

    k8s为每个pod分配了唯一的IP地址,一个pod里的多个容器共享pod IP。 pod其实有两种类型:普通的pod和静态pod,后者比较特殊,它并不存放在etcd存储中,而是存放在某个具体的Node上的一个具体文件中,并且只在此Node上启动运行。而普通的pod一旦被创建,就会被放入etcd中存储。随后被master调度到某个具体的Node上并进行绑定,随后该pod被对应的Node上的kubelet进程实例化成一组相关的docker容器并启动起来。 每个pod都可以对其使用的服务器上的计算资源设置限额,当前可以设置限额的源有CPU和memory两种。其中CPU的资源单位为CPU的数量。 一般而言,一个CPU的配额已经算是相当大的一个资源配额,所以在k8s中,通常以千分之一的CPU配额为最小单位,以m来表示,通常一个容器的CPU配额为100-300m,即占用0.1-0.3个CPU。这个配额是个绝对值,不是占比。 在k8s中,一个计算资源进行配额限定需要设定两个参数: requests,资源的最小申请量,系统必须满足要求 limits,资源最大允许使用的量。

    01

    软件测试|K8S 容器编排

    初学者容易误以为容器的任务只在于部署行为--将软件在容器中部署以提供持续的服务。但其实容器也同样大量的被应用于批处理程序的运行上。比如测试行为是典型的批处理任务范畴, 它不提供持续稳定的服务, 它只是一段特定的程序,而一但这段测试程序结束后就应该销毁一切,包括执行环境和所占用的资源,容器对比于传统的虚拟机的优势也在于除了容器更加的轻量级外, 容器的创建和销毁都很方便,通过 K8S 的能力可以很方便的在需要时创建,结束时销毁回收资源以达到更好的资源利用率(就如上篇文章中介绍的 Jenkins 与 K8S 打通后的运作模式)。而现在准备的测试案例会更加特殊, 它需要重复运行 N 次,因为本次执行的是稳定性测试(也有人叫它浸泡测试或者长期高压测试),这种测试类型的特殊之处就在于它的目的是验证被测系统在长期的高压下是否仍能够提供稳定的服务。所以它的测试方式是长期的(1 天,1 周甚至更长时间)不间断的运行自动化测试。而自动化测试的数量是有限的,它不可能持续的运行那么长时间,所以才需要重复运行。在不改造测试框架的前提下 K8S 能通过什么样的方式来帮助完成这个测试需求。首先看一段 K8S 提交任务的配置文件。

    01

    一文带你了解K8S 容器编排(下)

    初学者容易误以为容器的任务只在于部署行为--将软件在容器中部署以提供持续的服务。但其实容器也同样大量的被应用于批处理程序的运行上。比如测试行为是典型的批处理任务范畴, 它不提供持续稳定的服务, 它只是一段特定的程序,而一但这段测试程序结束后就应该销毁一切,包括执行环境和所占用的资源,容器对比于传统的虚拟机的优势也在于除了容器更加的轻量级外, 容器的创建和销毁都很方便,通过 K8S 的能力可以很方便的在需要时创建,结束时销毁回收资源以达到更好的资源利用率(就如上篇文章中介绍的 Jenkins 与 K8S 打通后的运作模式)。而现在准备的测试案例会更加特殊, 它需要重复运行 N 次,因为本次执行的是稳定性测试(也有人叫它浸泡测试或者长期高压测试),这种测试类型的特殊之处就在于它的目的是验证被测系统在长期的高压下是否仍能够提供稳定的服务。所以它的测试方式是长期的(1 天,1 周甚至更长时间)不间断的运行自动化测试。而自动化测试的数量是有限的,它不可能持续的运行那么长时间,所以才需要重复运行。在不改造测试框架的前提下 K8S 能通过什么样的方式来帮助完成这个测试需求。首先看一段 K8S 提交任务的配置文件。

    01
    领券