别再把 K8s 当大号 Docker 了：我用 Kubernetes 跑数据任务踩过的那些坑

别再把 K8s 当大号 Docker 了：我用 Kubernetes 跑数据任务踩过的那些坑

一、先说结论：K8s 跑数据任务，不是不能用，是别瞎用

很多人第一次把数据任务搬到 Kubernetes，心态都差不多：

“反正我有 K8s 集群，不跑点 Spark / ETL / Python Job，感觉亏了。”

结果一上来就是三连问：

• 任务怎么调度？
• 失败了怎么重试？
• 跑着跑着怎么把节点打满了？

然后开始怀疑人生。

核心观点我先摆出来：

👉 Kubernetes 非常适合跑「短生命周期、可重试、资源边界清晰」的数据任务
👉 但你得用「数据任务的方式」去用它，而不是 Web 服务那一套

二、一个最常见的错误：用 Deployment 跑离线任务

我见过太多这样的 YAML：

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: etl
        image: my-etl:latest

跑是能跑，但问题一堆：

• 任务跑完了，Pod 还在
• 失败了，不知道是该重启还是该报警
• 多次执行？得手动删 Pod

一句话总结：

Deployment 是给「一直活着的服务」用的，不是给「干完就走的打工人」用的。

三、正确姿势一：数据任务，优先用 Job / CronJob

1️⃣ 用 Job 跑一次性任务（最常见）

apiVersion: batch/v1
kind: Job
spec:
  backoffLimit: 3
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: data-job
        image: my-etl:1.0
        command: ["python", "main.py"]

这个东西有几个优点：

• ✅ 任务成功就结束
• ✅ 失败可以自动重试
• ✅ 状态清晰（Succeeded / Failed）

我个人经验：

80% 的离线数据任务，用 Job 就够了，真没必要一上来就 Spark Operator。

2️⃣ 定时任务？CronJob 别滥用

apiVersion: batch/v1
kind: CronJob
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: daily-etl
            image: my-etl:1.0

CronJob 很香，但也有坑：

• 集群时间漂移 → 任务乱跑
• 上一次没跑完，下一次又启动
• 高峰期同时触发，资源直接爆炸

我自己的建议：

👉 关键链路任务，用调度系统（Airflow / DolphinScheduler）
👉 K8s 负责执行，不负责“聪明地安排人生”

四、第二个大坑：资源不设限，K8s 会很“诚实”

这是很多数据工程师第一次被 K8s 教做人。

resources:
  limits:
    cpu: "2"
    memory: "4Gi"

不设会怎样？

• Python 一不小心 OOM
• JVM 自己膨胀
• 一个任务把 Node 拖死，大家一起陪葬

真实经验：

K8s 不会帮你省资源，它只会在你越界的时候，直接把你干掉（OOMKilled）

我的习惯是：

• requests：真实可用的下限
• limits：最多给到能承受的上限
• JVM / Spark 参数和容器资源 必须对齐

五、日志 & 失败处理：别指望 Pod 活着告诉你真相

数据任务最大的特点是：

你发现它失败的时候，现场已经没了

所以我强烈建议：

1️⃣ 日志必须外部化

• stdout → Loki / ES
• 文件 → 对象存储 / NFS
• 不要指望 kubectl logs 永久有效

2️⃣ 程序层面主动退出码

try:
    run_job()
except Exception as e:
    logger.exception(e)
    sys.exit(1)  # 让 K8s 知道你失败了

退出码 = K8s 的唯一语言

六、K8s + 数据任务，什么时候真的香？

说点真心话，不吹。

适合的场景 ✅

• 多租户数据处理平台
• 临时 / 弹性算力需求
• 任务类型多、生命周期短
• 想统一运维模型（监控 / 权限 / 网络）

不太适合的 ❌

• 超长时间单任务（跑几天）
• 强状态依赖（本地磁盘）
• 极致 IO 敏感（调度抖动很致命）

七、我的一点私货感受

我自己从 Yarn、Mesos，一路折腾到 Kubernetes，说实话：

K8s 并没有让数据处理更简单，它只是让“复杂变得更可控”

你要接受三件事：

1. 任务是“随时会死”的
2. 节点是“不可靠的”
3. 失败是“默认态”

一旦你用这种心态去设计数据任务，Kubernetes 反而会变成一个非常靠谱的打工人。

八、最后一句掏心窝子的总结

Kubernetes 不是银弹，但它是一个非常诚实的系统。
你写得烂，它马上让你知道；
你设计得稳，它能默默扛住一切。