本文向您展示了如何实现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
