关于spark:kubernetesk8s-scheduler-backend调度的实现

背景

  随着 k8s 快来越炽热，以及主动部署，主动伸缩等长处，咱们明天来探讨一下，基于 k8s 的 backend 的调度怎么来实现 

组件图

组件阐明

整个数据流就是消费者 - 生产者模型

• 特地阐明
  对于 podsWatchSnapshotSource 的实现，咱们是基于 k8s watch 机制实现的，然而存在一个问题:
  如果某一时刻，podsWatchSnapshotSource 产生了故障导致了该组件产生了重启，那么问题来了，重启这段时间就会失落 event，
  这里咱们采纳 k8s 的 resourceVersion 机制，如果咱们定时存储 resourceVersion，且在重启的时候读取，就能做到断点续传的作用
  留神一点的是：该 resourceVersion 在 Kubernetes 服务器的保留是有限度的。应用 etcd2 的旧集群最多可保留 1000 次更改。
  默认状况下，应用 etcd3 的较新集群会在最近 5 分钟内保留更改，如果超过了该 resourceVersion 超过了服务器的 resourceVersion 的值
  则会报错

数据流程图

流程阐明

• backend 通过被调用 reviveOffer 获取能获取到的 backend 资源.
• 获取到资源后，通过 kubernetesClient 向 k8s 提交工作
• 缩小对应向 k8s 提交工作的资源量
• 更新 backend 外部的对应 job 状态为 Running 状态，如果该存在 job 状态为 Runnnig 状态，则更新对应的 job 状态为 updated 状态
• podsWatchSnapshotSource 监控方才提交的工作，获取工作更新的状态，存储到 podSnapshotStore 中，以便后续工作的解决
• podsPollingSnapshotSource 定时拉取利用提交的所有工作，存储到 podSnapshotStore 中，以便进行 final 工作的清理
• podSnapshotStore 对工作状态更新为外部状态，并对订阅此 podSnapshotStore 的 snapshot 进行函数回调
• taskPodsLifecycleManager 订阅了上述的 snapshot，对该 snapshot 进行解决：
  1. 如果工作状态为 podFailed 或者 PodSucceeded 时，更新 backend job 的内猪状态, 如果存在对应的 Running 的 job，调用 k8s api 删除该 pod，以及删除该 pod 所占用的资源（cpus，mem 等），如果存在对应 updated 的 job 状态，则把 updated 的状态更新为 Running 状态，避免外界工作的更新，导致工作的资源量更新不统一
2. 调用 kubernetesTaskSchedulerBackend 的 statusUpdate 办法进行工作的更新进行解决

UML 类继承图

和 spark on k8s 的区别

因为公司有本人的调度平台，所以次要从调度的粒度来进行比照：
spark on k8s 调度的是 executor 级别的，是粗粒度调度
k8s backend 调度的是 job 级别，每个 job 一个 pod container, 属于细粒度的精准调度

本文由博客群发一文多发等经营工具平台 OpenWrite 公布