图解kubernetes批处理Job控制器的关键设计

K8s中的批处理任务模块主要是由Job控制器完成,今天我们就来关注下其底层的关键设计,包括完成状态、并行模式、并行策略等关键机制

1. 基础概念

在聊k8s的任务模块的实现的时候,我们先看一下传统的任务系统的设计与实现,然后聊下基于k8s的基础的概念

1.1 传统的任务系统设计

传统的任务系统设计主要可以分为master(任务分配/故障感知/负载均衡)、Worker(任务执行/任务监控/任务管理)、分布式协调(etcd等存储元数据)、任务仓库(存储任务的实现比如类或者接口)等几部分, 从大的部分又可以切分为两个部分管控端(分布式协调/master/仓库)、执行端(Worker),传统的任务系统大概就是这样

通常复杂的就是如何在master如何做任务的负载均衡、任务的快速完成、依赖等管控功能,其次就是如何在worker端实现一个牛x的引擎,可以支持各种不同任务的执行环境和类型的执行

1.2 基于Pod的任务载体

k8s中的最小单元调度是Pod,同样的job控制器调度的最小单元也是Pod, Pod里面包含容器,以容器为载体k8s屏蔽了传统worker模块的任务执行环境与实现两个部分,只需要添加一些配置数据,对应的Pod就可以完成对应的任务的执行

1.3 简化的调度层

在k8s中Pod通常被定义为一个不稳定的单元,即k8s并不保证你的pod在被调度到某一台机器后就会一直的稳定运行,直到这台机器下线,这与传统的系统都不太一样,基于该特点,Job调度器的调度层其实也是一种面向于终态的设计。

大概就先介绍这些,接下来我们去分析k8s中job的核心实现机制

2. 核心实现

Job控制器的核心实现有几个关键点:并行粒度、完成状态、并行策略、并行模式、删除策略,记住这些关键点,我们来一一剖析

2.1 并行粒度

并行的粒度是指的针对同一任务可以同时有多少个并行的Pod即同时运行的Pod,Job控制器会根据用户设定的并行粒度确定需要同时运行的Pod

2.2 完成状态

在一些批处理调度的系统里面可能会通过数据分片后,等待所有分片的任务都完成后,来确定任务的完成状态,但是在k8s中Job控制器是一个通用的实现, 而且调度层本身也并不关注调度任务的具体数据

所以在k8s中里面其实是通过Completion的和backoffLimit来完成状态转移的,即通过Completion来确定需要等待的Pod的完成的数量,而通过backoffLimit确定到底可以允许失败重试的次数,确定重试多少次就认为任务失败了

2.3 并行模式

在k8s的job控制器模式介绍中提到四种并发模式, 那实现上是不是真的有四种模式呢,答案是否定的。可以说k8s的job控制器根本也就不关注是那种模式,模式是应用层自己的设计,而job控制器只负责并行粒度、当前状态、完成状态

这里我们主要分析下Parallel JOb with a fix completion count和Parallel Job with a work queue的实现来聊聊Job控制器是如何实现的,两者很大的一个区别就是后者不能设置Completions,即不需要设置需要等待多少个Pod完成,为什么一个参数的设定就可以实现两者模式呢?

答案就是期望的完成数量不同,如果Completions不设定,则实际上Job控制器发现有任一一个Pod成功并且当前活跃的Pod的数量为0,则表示当前任务完成, 该模式主要适用于单次的批任务,即本次批任务的所有Pod任务都完成,通常也意味着本次批任务是有限的集合

而Completions设定为数量则意味着只需要完成指定数量的批任务,即任务可能类似于流处理模式,本次只期望完成一部分即可,即Completions设定数量的任务

2.4 并行策略

并行策略主要是指的如果我们指定的Parallelism的数量过大,为了避免单个任务同时创建大量的Job任务对集群带来的影响则采用分批逐次递增的策略,逐步完成并行所需要的Pod的更新

2.5 期望计数

期望计数是k8s中控制器常见的机制,即当控制器进行Pod操作完成后,会设定当前期望的Pod的增加或者删除的计数,通过期望计数的统计来确定当前是否需要继续更新对应的pod, 期望的满足主要来源于两个地方:informer和当前控制流,informer通过监听apiserver来感知事件,而当前控制流则主要是在操作Pod失败的时候,直接更新期望,因为这些操作失败的Pod并不会从后续的informer中感知到

2.6 删除策略

我们提到过期望计数来决定是否更新状态,但这个并不保证一致性,很有可能因为事件的延迟导致控制器创建了大量的Pod此时就需要基于终态的继续调整,即需要根据当前的数量来删除部分的Pod, 删除策略主要是包含六点:1)未分配优先 2)未运行优先 3)未就绪优先 4)运行时间最短优先 5)重启次数多优先 6)创建时间较短优先

3. 总结

Job控制器的实现设计上还是很好玩的,主要是是面向常见的批处理场景,但本身并没有考虑优先级、关系、效率、分片等功能,只是一个通用的基础的任务调度的实现, 当前k8s中还有很多针对不同场景的专用任务调度实现,但基于k8s的任务系统设计本身就给我们降低了很多的复杂度,这也就是云原生带来的好处,今天就到这里,谢谢大家

kubernetes学习笔记地址: https://www.yuque.com/baxiaoshi/tyado3

微信号:baxiaoshi2020

关注公告号阅读更多源码分析文章

原文地址:https://www.cnblogs.com/buyicoding/p/12603909.html

时间: 2024-07-31 08:46:36

图解kubernetes批处理Job控制器的关键设计的相关文章

Kubernetes之StatefulSet控制器

目录 Kubernetes之StatefulSet控制器 简介 StatefulSet使用 滚动更新 扩展伸缩 更新策略和版本升级 Kubernetes之StatefulSet控制器 简介 StatefulSet 作为 Controller 为 Pod 提供唯?的标识. 它可以保证部署和 scale 的顺序. StatefulSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为?状态服务?设计) , 其应?场景包括: 稳定的持久化存储, 即Pod重新调度后还是

Kubernetes之Pod控制器,ReplicaSet,Deployment,DaemonSet

目录 Kubernetes之Pod控制器,ReplicaSet,Deployment,DaemonSet ReplicaSet Deployment控制器 创建Deployment Deployment更新 Deployment扩容 金丝雀发布 Deployment回滚 DaemonSet 定义 DaemonSet演示 redis-filebeat DaemonSet的滚动更新 Kubernetes之Pod控制器,ReplicaSet,Deployment,DaemonSet Kubernete

Kubernetes之Pod控制器应用进阶

目录 Kubernetes之Pod控制器应用进阶 Pod控制器下spec常用字段 标签(Labels)和标签选择器(LabelSelector) 标签 标签选择器 Kubernetes之Pod控制器应用进阶 Pod控制器下spec常用字段 #containers [[email protected] ~]# kubectl explain pods.spec.containers. name <string> -required- #容器名,必选字段 image <string>

图解kubernetes控制器StatefulSet核心实现原理

StatefulSet是k8s中有状态应用管理的标准实现,今天就一起来了解下其背后设计的场景与原理,从而了解其适用范围与场景 1. 基础概念 首先介绍有状态应用里面的需要考虑的一些基础的事情,然后在下一章我们再去看statefulSet的关键实现 1.1 有状态与无状态 在日常开发的应用中,通常可以分为两大类:有状态与无状态,比如web服务通常都是无状态的,web应用数据主要来自后端存储.缓存等中间件,而本身并不保存数; 而诸如redis.es等其数据也是应用自身的一部分,由此可以看出有状态应用

图解kubernetes调度器预选设计实现学习

Scheduler中在进行node选举的时候会首先进行一轮预选流程,即从当前集群中选择一批node节点,本文主要分析k8s在预选流程上一些优秀的筛选设计思想,欢迎大佬们指正 1. 基础设计 1.1 预选场景 预选顾名思义就是从当前集群中的所有的node中,选择出满足当前pod资源和亲和性等需求的node节点,如何在集群中快速选择这样的节点,是个复杂的问题 1.2 平均分布 平均分布主要是通过让一个分配索引来进行即只有当所有的node都在本轮分配周期内分配一次后,才开始从头进行分配,从而保证集群的

图解kubernetes调度器ScheduleAlgorithm核心实现学习框架设计

ScheduleAlgorithm是一个接口负责为pod选择一个合适的node节点,本节主要解析如何实现一个可扩展.可配置的通用算法框架来实现通用调度,如何进行算法的统一注册和构建,如何进行metadata和调度流程上下文数据的传递 1. 设计思考 1.1 调度设计 1.1.1 调度与抢占 当接收到pod需要被调度后,默认首先调用schedule来进行正常的业务调度尝试从当前集群中选择一个合适的node 如果调度失败则尝试抢占调度,根据优先级抢占低优先级的pod运行高优先级pod 1.1.2 调

一篇文章为你图解Kubernetes网络通信原理

本文来自51cto因出现文章被删除提示,为避免丢失将其复制备查 Kubernetes对集群内部的网络进行了重新抽象,以实现整个集群网络扁平化.我们可以理解网络模型时,可以完全抽离物理节点去理解,我们用图说话,先有基本印象. 名词解释 1.网络的命名空间:Linux在网络栈中引入网络命名空间,将独立的网络协议栈隔离到不同的命令空间中,彼此间无法通信;docker利用这一特性,实现不容器间的网络隔离. 2.Veth设备对:也叫虚拟网络接口对.Veth设备对的引入是为了实现在不同网络命名空间的通信.

kubernetes(三)--资源控制器

一.控制器简介 1.1.什么是控制器 Kubernetes 中内建了很多 controller(控制器),这些相当于一个状态机,用来控制 Pod 的具体状态和行为 1.2.控制器类型 1)ReplicationController 和 ReplicaSet 2)Deployment 3)DaemonSet 4)StateFulSet 5)Job/CronJob 6)Horizontal Pod Autoscaling 二.控制器详解 2.1.ReplicationController和Repli

图解kubernetes命令执行核心实现

K8s中的命令执行由apiserver.kubelet.cri.docker等组件共同完成, 其中最复杂的就是协议切换以及各种流拷贝相关,让我们一起来看下关键实现,虽然代码比较多,但是不会开发应该也能看懂,祝你好运 1. 基础概念 K8s中的命令执行中有很多协议相关的处理, 我们先一起看下这些协议处理相关的基础概念 1.1 Http协议中的Connection与Upgrade HTTP/1.1中允许在同一个链接上通过Header头中的Connection配合Upgrade来实现协议的转换,简单来