批处理任务和常驻服务在容器编排上天然不同一个追求”跑完就走”的干净利落，另一个追求”永不掉线”的稳定持久，两者的调度策略、资源模型和生命周期管理逻辑几乎完全相反。
搞混这两类工作负载，是很多Kubernetes集群资源利用率上不去的根本原因，批处理任务就像临时工，干完活就结账走人；常驻服务是正式员工，得一直扎根在岗位上，后者只要重启一次，用户就会感知到抖动，而前者重启十次都没人关心，下面从调度逻辑、资源配额、故障恢复和成本控制四个维度拆开聊。
批处理任务和常驻服务的调度逻辑差异在哪
批处理任务看”完成度”，常驻服务看”可用副本数”
批处理任务（Job）的调度目标是终态，它要的是”这100万条数据有没有算完”，Pod退出码为0就算成功，非0就是失败，所以编排系统对它的考核指标是完成率,不是存活率。
常驻服务（Deployment/StatefulSet）的调度目标是稳态，它要的是”任何时候都有3个副本在同时响应请求”，Pod挂了就要立刻拉起新的顶上，KPI永远盯着Ready副本数,而不是任务进度。
两者的调度器行为差异在实际故障场景里非常明显，比如节点宕机，对于常驻服务，控制器会立刻在别的节点补副本；对于批处理任务，控制器会等Pod的优雅退出超时（默认30秒）后，才决定是重建还是标记失败，这个差异导致不少团队把Job当成Deployment跑，结果Pod反复重启,任务永远完不成。
资源请求模型不同：批处理任务要”整块”，常驻服务要”碎票”
批处理任务里的Pod经常是短生命周期、高资源消耗，比如大数据清洗任务，一个Pod可能需要8核16G，跑10分钟就结束，这种特性要求调度器能容忍碎片化的资源分配集群里哪怕只有一台机器能塞下这个任务,也得能调度过去。
常驻服务则完全相反，微服务Pod通常只申请1核2G这种小规格，调度器要做的是把这些Pod像碎票一样均匀撒到各个节点上，避免单点过热，行业共识认为，节点资源水位超过80%时，常驻服务的响应延迟会出现明显拐点，而批处理任务反而希望集群水位越高越好反正跑完就释放。
容器编排时批处理任务和常驻服务的资源配额怎么配
请求值和限制值的配比策略完全相反
常驻服务的资源配比有标准答案：request值要稳，limit值要松，比如Java服务，request给1核2G，limit给2核4G，留出GC抖动和流量高峰的余量，业内专家指出，limit设置过紧是Pod被OOM Kill的头号原因。
批处理任务则相反：request值要符合真实使用量，limit值尽量不要设，数据密集型任务对内存的需求曲线波动极大，处理到某个分区时可能内存暴涨，如果limit卡死，任务直接被杀；如果不设limit，任务能借到集群空闲内存，跑完就还，不影响别人,很多团队在跑Spark任务时都会刻意把limit调大或者去掉。
队列和优先级才是批处理任务的灵魂
常驻服务靠HPA（水平自动扩缩）应对流量，批处理任务靠排队机制控制并发，Kubernetes原生的Job不支持优先级队列，这也是为什么Kueue、Volcano这类批量调度组件会火。
实操中建议给批处理任务单独建一个资源池，用ResourceQuota限制最大并发Pod数，比如数据平台每天凌晨跑300个ETL任务，但只允许同时跑20个Pod，剩下的排队，这样做的好处是防止任务雪崩所有任务同时启动，每个都在抢内存,最终全部失败。
故障恢复策略：批处理任务和常驻服务的重启哲学
常驻服务”死得快”，批处理任务”慢半拍”
常驻服务的readinessProbe失败3次就会摘流量，livenessProbe失败就重启，这套机制对批处理任务根本不适用批处理任务经常是跑几分钟后才开始干重活，前面的初始化阶段探针全绿，一旦进入计算密集区，CPU飙升，livenessProbe连续超时，Pod被强制重启,任务从零开始。
正确做法是批处理任务不配livenessProbe，只配startupProbe，startupProbe的failureThreshold设大一点，比如30次，每10秒探一次，给任务5分钟冷启动时间，启动完成后探针自动失效，任务进入无人监管的”闷头跑”模式。
失败重试策略：backoffLimit比restartPolicy更重要
批处理任务的Pod重启策略只能设Never或OnFailure，设了Always会被API Server拒绝，真正控制重试次数的是Job的backoffLimit参数，默认值是6这意味着最坏情况下任务会跑7次尝试。
实际场景里要根据任务幂等性调整这个值，如果任务支持断点续传，backoffLimit可以设成20甚至更高；如果任务每次重跑都会产生脏数据，backoffLimit应该设为0，失败立即告警人工介入，这里容易踩坑的是parallelism和completions搭配错误，比如并行任务里单个Pod失败，Job会整体重启所有并行Pod,造成大面积资源浪费。
成本控制：批处理任务和常驻服务的计费逻辑
常驻服务看”占用时长”，批处理任务看”计算消耗量”
公有云容器编排场景下，常驻服务是按小时计费的，哪怕流量为零，Pod空转也烧钱，批处理任务适合用Spot实例（竞价实例），价格通常是按量付费的10%-20%，任务跑完即释放,不用担心被回收影响可用性。
很多团队省钱的核心操作就是把无状态批处理任务迁到Spot资源池，比如离线数据同步任务，允许中断重跑，用Spot实例跑成本直接打一折，但要注意，StatefulSet类任务（比如数据库备份）不适合上一台Spot实例节点被回收时数据没落盘就全没了。
集群自治与弹性伸缩的差异化配置
集群节点级自动伸缩（Cluster Autoscaler）对两类工作负载的行为也应该不同，常驻服务所在的节点池，缩容阈值建议设高一些，比如利用率低于50%持续10分钟才缩容，防止流量毛刺导致频繁扩缩容，批处理任务所在的节点池，缩容阈值设宽一些，利用率低于20%持续5分钟就缩,反正任务本来就是一杆子买卖。
关于容器编排工具选型，如果集群里同时混跑这两类负载，建议不要只用原生调度器，批处理任务占比较大时，引入Volcano这类批量调度组件做任务排队、优先级抢占；常驻服务为主要负载时，保持默认调度器即可，维护成本最低，日常排查问题时，可以用kubectl get job和kubectl get deploy快速区分状态视图一个看完成数/总数，一个看Ready/Desired,一眼就能知道是哪类负载出了问题。
批处理任务和常驻服务的编排选型避坑指南
| 对比维度 | 批处理任务 | 常驻服务 |
|---|---|---|
| 核心指标 | 完成率、平均完成时间 | 可用性、P99延迟 |
| 资源策略 | request贴近实际，limit放宽 | request留余量，limit控制上限 |
| 探针配置 | 只配startupProbe | 三探针齐全 |
| 故障处理 | backoffLimit控制重试 | readiness/liveness驱动重启 |
| 成本优化 | Spot实例+弹性伸缩 | 按量付费+HPA自动缩容 |
容器编排的最大陷阱就是试图用一套模板打天下，批处理任务和常驻服务的部署YAML除了Pod模板是通用的，控制器、调度策略、资源配额、探针配置、重试逻辑全部应该是两套独立配置，建议在CI/CD流程里区分两个目录结构，比如deploy/services/和deploy/jobs/,避免开发同学把Job误提交成Deployment导致任务永远在重启。
批处理任务和常驻服务容器编排常见问题解答
Q：批处理任务和常驻服务能放在同一个Kubernetes集群里跑吗？
A：可以，但强烈建议用命名空间隔离，并且对每个命名空间设置ResourceQuota，比如default命名空间跑Web服务，batch命名空间跑定时任务，两者限制CPU和内存总量，还需要关注优先级类（PriorityClass），让常驻服务的优先级高于批处理任务，这样集群资源不足以支撑全部负载时，调度器会优先挤掉批处理任务的Pod,保常驻服务不挂。
Q：定时清理日志的CronJob算批处理任务还是常驻服务？
A：按批处理任务的规则治理，CronJob创建的每个Job，都要设置正确的startingDeadlineSeconds，防止任务堆积，日志清理这类任务会大量消耗磁盘IO，建议把这类批量操作Pod单独调度到独立节点池，或者使用本地SSD的节点，同时给Job设置Pod级反亲和性，避免多个清理任务在同一节点同时跑导致IO争抢，清理任务一般时长远低于调度周期，很难出现任务堆积，但磁盘写满的场景往往比预想来得更快,所以磁盘水位监控和任务是连贯动作。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/639942.html
