本文向您展示了如何实现kubernetes scheduler后端调度。内容简洁易懂,一定会让你大放异彩。希望通过这篇文章的详细介绍,你能有所收获。
背景
随着k8s的普及,以及自动部署和自动扩展的优势,今天我们来讨论一下如何基于k8s后端实现
组件图
。
00-1010整个数据流是消费者-生产者模型。
说明kubernetesClient与k8s的交互,如:任务的提交,killing任务podsPollingSnapshotSource从k8s中拉出pod的任务状态,并存储在podsPollingSnapshotSource监控任务的观察器中获取任务状态。将podsSnapshotpod存储到podsSnapshotpod状态podsSnapshotpod状态镜像的内部状态转换taskpodsLifecycleManager从podSnapshotStore中消耗Pod的状态,以便根据任务的状态进行后续操作。
对于podsWatchSnapshotSource的实现,我们是基于k8s的守望机制,但是有一个问题:
如果在某个时候,podsWatchSnapshotSource失败,组件重新启动,那么问题就来了,事件将在重新启动期间丢失。
这里我们采用k8s的resourceVersion机制。如果我们定期存储resourceVersion并在重启时读取,就可以实现断点续传的功能。
需要注意的一点是,这个资源版本在Kubernetes服务器中的保留是有限的。使用etcd2的旧集群最多可以保留1000个更改。
默认情况下,如果资源版本超过服务器的资源版本值,使用etcd3的较新群集将保留最近5分钟的更改。
会报告错误。
组件说明
数据流程图
后端通过名为reviveOffer的获取可用的后端资源。
获取资源后,通过kubernetesClient将任务提交给k8s。
减少与提交给k8s的任务相对应的资源量。
将后端内部相应的作业状态更新为运行状态;如果现有作业状态是运行状态,则将相应的作业状态更新为更新状态。
PodsWatchSnapshotSource监视刚刚提交的任务,获取任务的更新状态,并将其存储在podSnapshotStore中,用于后续的任务处理。
PodsPollingSnapshotSource会定期提取应用程序提交的所有任务,并将其存储在podSnapshotStore中,以清理最终任务。
Podshotstore将任务状态更新为内部状态,并对订阅该Podshotstore的快照进行函数回调。
TaskPodsLifecycleManager订阅上述快照并对其进行处理:1。如果任务状态为podFailed或PodSucceeded,更新后端作业的内部pig状态,如果有对应的Running作业,调用k8s api删除pod,并删除资源(CPU、mem等)。)被吊舱占据。如果有相应的更新作业状态,将更新后的状态更新为运行状态,防止外部任务的更新导致任务的资源更新不一致。2.调用kubernetesTaskSchedulerBackend的statusUpdate方法来更新任务。
流程说明
00-1010因为公司有自己的调度平台,所以主要比较调度粒度:
k8s上的Spark调度是执行器级的,是粗粒度调度。
K8s后端调度是作业级的,每个作业都有一个pod容器,属于细粒度的精准调度。
以上内容就是如何实现kubernetes scheduler后端调度。你学到什么知识或技能了吗?如果你想学习更多的技能或丰富你的知识,请关注行业信息渠道。
内容来源网络,如有侵权,联系删除,本文地址:https://www.230890.com/zhan/147380.html