共计 1562 个字符，预计需要花费 4 分钟才能阅读完成。
背景
随着 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 公布
正文完