工作负载¶

业务一般不直接创建 Pod，而使用控制器保证期望副本数和发布策略。

对象	适用场景
Deployment	无状态应用，支持滚动更新和回滚。
StatefulSet	有稳定名称、网络标识或持久卷的有状态服务。
DaemonSet	每个（或部分）节点运行一个 Pod，如日志/监控 Agent。
Job / CronJob	一次性任务与定时批处理。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi

kubectl apply -f deployment.yaml
kubectl rollout status deployment/web
kubectl rollout history deployment/web
kubectl rollout undo deployment/web

设置合理的 requests 和 limits，并为业务配置就绪/存活探针；不要将单个 Pod 当作长期可靠实体。

Deployment：无状态服务¶

Deployment 通过 ReplicaSet 管理 Pod，适合任意副本都能处理请求、状态保存在外部数据库或存储中的服务。

kubectl set image deployment/web web=nginx:1.28-alpine
kubectl rollout status deployment/web --timeout=5m
kubectl rollout history deployment/web
kubectl rollout undo deployment/web
kubectl scale deployment/web --replicas=5

RollingUpdate 的 maxUnavailable 决定发布期间最多缺少多少副本，maxSurge 决定最多额外创建多少副本。只有 Readiness 成功的 Pod 才应承接 Service 流量。单副本应用即使滚动策略正确，也可能在更新或节点故障时中断。

StatefulSet：有状态副本¶

StatefulSet 提供稳定的 Pod 名称、启动/终止顺序，以及配合 volumeClaimTemplates 的独立 PVC。例如 mysql-0 重建后仍使用对应的数据卷。

它适合数据库、消息队列和需要稳定成员身份的集群，但只负责 Kubernetes 层面的身份和编排，不自动实现主从选举、数据复制、备份和故障切换。这些仍由应用、Operator 或运维方案负责。

kubectl get statefulset,pod,pvc -n data
kubectl rollout status statefulset/mysql -n data
kubectl scale statefulset/mysql -n data --replicas=3

扩缩容前必须了解应用的成员加入/退出流程。不要把“Pod Ready”当成“数据副本已经同步完成”。

DaemonSet：每节点 Agent¶

DaemonSet 常用于 CNI、CSI Node Plugin、日志采集、节点监控和安全 Agent。新节点加入后会自动创建 Pod，可通过 nodeSelector、亲和性和 tolerations 限定运行节点。

kubectl get daemonset -A
kubectl get pod -n monitoring -o wide
kubectl rollout status daemonset/node-exporter -n monitoring

如果期望数与就绪数不一致，检查节点标签、污点/容忍、资源不足和宿主机端口冲突。

Job 与 CronJob：批处理¶

Job 运行到成功完成，CronJob 按计划创建 Job。它们适合数据库维护、报表、同步和备份触发任务，不适合常驻服务。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cleanup
spec:
  schedule: "0 3 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 1800
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: cleanup
              image: registry.example.com/ops/cleanup:1.2.0

重点设置：

concurrencyPolicy: Forbid 防止上次未结束时重复运行。
backoffLimit 限制失败重试，避免持续打垮依赖。
activeDeadlineSeconds 限制最长运行时间。
历史保留数量防止 Job/Pod 长期堆积。
任务逻辑尽量幂等，重复执行不会破坏数据。

kubectl get cronjob,job -n ops
kubectl create job --from=cronjob/cleanup cleanup-manual -n ops
kubectl logs job/cleanup-manual -n ops

怎样选择控制器¶

持续运行、无稳定身份要求 → Deployment
持续运行、每副本需稳定身份/独立卷 → StatefulSet
每个节点都要运行 → DaemonSet
运行一次直到完成 → Job
按时间周期运行 → CronJob

无论选择哪种控制器，上线都要同时考虑资源、探针、配置、存储、权限、网络策略、可观测性和退出流程。工作负载对象解决“如何保持运行”，不代表应用已经具备高可用。

官方参考：Workloads。