背景
随着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,属于细粒度的精准调度
本文由博客群发一文多发等经营工具平台 OpenWrite 公布