工作负载（Workload）指一类 Kubernetes API 对象：描述「希望运行哪些 Pod、如何创建与更新它们」。与生信最贴近的常是 Job / CronJob（批处理、定时批）；长期在线服务多用 Deployment。本篇把资源类型、requests/limits、以及 Pending 排障串成一条线，并与 k8s-01 图 5 步骤 4～5 对齐。
本系列与编号约定
- 调度（步骤 4）与 kubelet 执行（步骤 5）的总览见 k8s-01 图 5 与「步骤 1～5 速查表」。
- 上一篇：k8s-03。
系列导航
| 篇目 | 链接 |
|---|---|
| 上一篇 | pipeline-frameworks-k8s-03.kubectl与日常观测 |
| 下一篇 | pipeline-frameworks-k8s-05.存储网络与权限入门 |
| 相关 | Argo Workflows 入门 |
1. 常见工作负载类型（一句话）
| 资源 | 典型用途 | Pod 生命周期 |
|---|---|---|
| Deployment | 无状态、长期在线、多副本 | 期望副本数由控制器维持；更新时常用滚动 |
| Job | 跑完即成功的批任务 | 完成 completions 后结束；失败可重试（按 spec） |
| CronJob | 定时触发 Job | 按 cron 表达式创建 Job 对象 |
图 1 控制器与 Pod 的关系（示意）
ReplicaSet 常被 Deployment 管理，日常不必单独手写。Argo 多步工作流在底层仍会落成 Pod（有时用 Job 语义封装），因此读 Argo 文档时看到「Pod」应直接对应到上图中的执行单元。
2. requests 与 limits：调度、QoS 与 OOM
在 Pod 的容器 spec 里（resources）：
- requests：调度器认为「该容器至少需要」的 CPU/内存，用于 Predicates（能否放到某节点）与 Priorities（打分）。节点上可调度的新 Pod 的 requests 总和不能超过节点 Allocatable（在资源维度上）。
- limits：运行时上限；内存超过 limit 时，容器可能被 OOMKilled（表现为
CrashLoopBackOff或Reason: OOMKilled）。
图 2 requests 与 limits 在节点上的直觉
与 HPC「申请核数/内存」类比：requests 像申请量（决定你能不能排进队列）；limits 像硬上限（用超了会被杀）。若只设 limits 不设 requests，某些版本/配置下 requests 可能被默认成与 limits 相同，行为因版本与配置而异，生产建议显式写出两者。
3. Pending 与排障顺序（与步骤 4、5 对照）
Pod 处于 Pending 通常表示：尚未调度到节点（spec.nodeName 仍为空）或调度后仍无法进入运行（较少仍显示 Pending，多数会进 Events）。排查时优先用 kubectl describe pod，看 Events 与 Conditions。
图 3 长时间 Pending 时的常见检查方向（示意）
与 图 5 的对应关系：
- 步骤 4：调度器 Bind 之前——资源不足、节点选择器、污点与容忍、亲和性、未绑定的 PVC 等，都会让 Pod 无法完成绑定。
- 步骤 5：绑定之后——镜像拉取（
ImagePullBackOff）、启动命令错误、内存 limit 过小导致 OOM，属于 kubelet/CRI/runtime 阶段。
4. 与 Argo 的关系（点到为止）
- Argo 在 Workflow 里声明步骤镜像与依赖；每个步骤往往对应一个或多个 Pod。
- 你在 Argo UI 里看到的「等待资源」「镜像错误」，落到 K8s 层就是上节的 Pending / ImagePullBackOff 等；用 k8s-03 的
kubectl describe/logs可交叉验证。
细节仍以 Argo 入门 为准；本篇只固定 K8s 侧的资源与调度语义。
5. 小结
- Deployment / Job / CronJob 解决「长期服务 vs 批任务 vs 定时批」的差异；底层都落实到 Pod。
- requests 参与调度与 limits 约束运行时；OOM 与 limits 直接相关。
- Pending 优先看 Events；区分「调度前」（步骤 4）与「节点上」（步骤 5）问题。
- 下一步：k8s-05 介绍卷与 PVC/PV、Service、RBAC——与 Pending 中的 PVC 未绑定、Service 访问、流水线 API 权限直接相关。