如何避免K8s杀死启动时运行长时迁移脚本的后端Pod？

好问题！这种启动阶段需要跑长时间初始化任务的场景在K8s里太常见了，我给你几个实用的解决方案，按推荐程度排序：

1. 配置启动探针（Startup Probe）—— 最优解 #

K8s 1.18及以后版本引入了启动探针，专门用来处理慢启动的应用。它会在应用完全启动前持续探测，直到成功为止，之后才会切换到存活探针和就绪探针的检测逻辑。

你只需要在Pod的探针配置里加上启动探针，把最大等待时间设置得足够覆盖你的迁移脚本时长（比如1分钟）：

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod
spec:
  containers:
  - name: backend-app
    image: your-backend-image:latest
    ports:
    - containerPort: 8080
    # 存活探针——迁移完成后正常检测应用状态
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
    # 启动探针——专门处理慢启动的迁移脚本
    startupProbe:
      httpGet:
        path: /healthz # 这里要和应用启动后的健康检查路径一致，迁移完成后才会返回正常状态
        port: 8080
      failureThreshold: 60 # 允许探测失败的次数
      periodSeconds: 1 # 每次探测的间隔时间

这里的最大等待时间是 failureThreshold * periodSeconds，也就是60*1=60秒，刚好覆盖你的1分钟迁移脚本。如果脚本耗时更长，直接调整这两个参数就行。

2. 用Init Container分离迁移脚本——进阶方案 #

如果你的迁移脚本和应用进程可以完全分离，推荐用Init Container来执行迁移。Init Container会在主容器启动前运行，K8s会等待Init Container成功退出后才启动主容器，这样主容器启动后就可以正常用探针检测，不用担心慢启动问题。

示例配置：

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod
spec:
  # 初始化容器：先跑迁移脚本
  initContainers:
  - name: migration-job
    image: your-backend-image:latest
    command: ["/bin/sh", "-c", "./run-migration.sh"] # 你的迁移脚本命令
    resources:
      requests:
        cpu: "100m"
        memory: "256Mi"
  # 主应用容器
  containers:
  - name: backend-app
    image: your-backend-image:latest
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5

⚠️ 注意：Init Container会在Pod重启时重新执行，所以你的迁移脚本必须是幂等的（重复执行不会导致数据异常）。

3. 调整存活探针的初始延迟——旧版本兼容方案 #

如果你的K8s版本低于1.18（没有启动探针），可以临时调整存活探针的initialDelaySeconds参数，把它设得足够大，让K8s在迁移脚本完成后再开始检测存活状态：

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 120 # 给迁移脚本留2分钟时间
  periodSeconds: 5

这种方法的缺点是：如果应用在initialDelaySeconds期间真的崩溃了，K8s不会及时重启它，所以只适合临时过渡，不推荐长期使用。

4. 调整Pod的重启策略——不推荐（应急用） #

极端情况下，你可以把Pod的restartPolicy设为OnFailure或者Never，但这会导致如果应用真的启动失败，K8s不会自动重启它，风险极高，只适合测试环境临时用，生产环境绝对不要这么做。

内容的提问来源于stack exchange，提问作者pditommaso