背景

  随着k8s快来越火热，以及自动部署，自动伸缩等优点，我们今天来探讨一下，基于k8s的backend的调度怎么来实现

组件图

组件说明

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

组件	解释
kubernetesClient	跟k8s进行交互，如:任务的提交,杀任务
podsPollingSnapshotSource	从k8s中拉取pod的任务状态,存储到podSnapshotStore
podsWatchSnapshotSource	监控任务的watcher，以获取任务状态，存储到podSnapshotStore
podSnapshotStore	pod状态的存储
podState	pod内部状态转换
podsSnapshot	pod 的状态镜像
taskPodsLifecycleManager	从podSnapshotStore消费pod的状态,以便根据任务的状态进行后续操作

• 特别说明
  对于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,属于细粒度的精准调度