k8s工作负载怎么选？Deployment/StatefulSet/Job对比表与选型口诀

工作负载选型指南

本教程共 65 篇 · 第 24 篇 · 更新于 2026-08-14 · 约 7 分钟阅读

Kubernetes工作负载选型DeploymentStatefulSetDaemonSetJob

本节目标：学完你能面对任意一个部署需求，从这张对比表里直接挑出该用的工作负载，不再纠结。

第 11–23 章我们认识了 Pod 和多种工作负载（Deployment、StatefulSet、DaemonSet、Job、CronJob 等）。东西一多就容易晕：到底什么时候用哪个？这章把它们摆在一张桌子上比一比。

24-1 一张对比表

工作负载	Pod 特征	典型场景	一句话记忆
裸 Pod	临时、无管家	临时调试、一次性实验	别用在生产
Deployment	无状态、多副本、可滚动更新	Web/API 服务	默认首选
StatefulSet	有状态、身份稳定、存储固定	数据库、中间件	在乎”还是不是它”
DaemonSet	每节点一份	日志、监控 Agent	每台机器都要
Job	跑完即退、要成功 N 次	批处理、备份	干完就走
CronJob	按时间表跑 Job	定时任务	带闹钟的 Job
静态 Pod	kubelet 直管、不进 apiserver	托管控制平面	看不见的管家

Note

这表建议收藏。实际选型 90% 的情况，从上往下对一遍就能定。

问自己：“这个应用挂了重建一个，还认识吗？“如果无所谓，就是无状态。Web 前端、REST API、网关，全是这类。

直接上 Deployment。它给你副本管理、滚动更新、回滚，一应俱全。这是大多数人的默认答案。

kubectl create deployment web --image=myapp:1.0 --replicas=3

除非下面几条明确命中，否则别犹豫，用 Deployment。

如果应用”有名字、有自己那块盘、有主从关系”，Deployment 会害了你——它重建 Pod 时身份和盘都变了。

数据库（MySQL、Postgres）、消息队列（Kafka、RabbitMQ）、分布式存储，用 StatefulSet。它保证名字固定、存储跟随、启动有序。

Tip

新手常犯的错：把 MySQL 用 Deployment 跑。结果 Pod 一重建，数据盘对不上，库就空了。有状态，认准 StatefulSet。

问：“这个程序是不是每台机器都得有一份？“日志采集、节点监控、网络插件，答案都是”是”。

这类别用 Deployment 去数节点数硬凑。节点是会增删的，DaemonSet 自动跟着集群规模走。

kubectl get daemonset -A

问：“这个活是常驻的，还是跑完就撤？“备份、算报表、跑测试，都是”跑完就走”。

只跑一次用 Job；要每天/每小时定时跑用 CronJob。它们和前面几个”常驻型”工作负载思路完全不同。

Warning

别拿 Deployment 去跑批处理。Deployment 看到 Pod 退了会当成”崩了”去重启，Job 才认为”退了=完成”。语义反了，资源白白浪费。

裸 Pod（直接 kubectl run 或 apply 一个 Pod）：只用于临时调试、实验。生产里别直接管裸 Pod，它没自愈、没副本。

静态 Pod：几乎只在集群自身用——kubeadm 用它托管控制平面组件。你日常不该手写静态 Pod。记住它的存在和用途即可。

# 临时调试可以这样，但别当正式部署
kubectl run debug --image=busybox --rm -it -- sh

我给自己总结了个顺口溜，供你参考：

Note

这章是 Pod 与工作负载部分的收尾。下一部分（第 25 章起）我们讲怎么让这些 Pod 能被访问到——Service 与网络。那是另一块大拼图。

选型对了，部署就稳了一半。下一部分见。