HorizontalPodAutoscaler扩容Pod后立即终止问题排查

1. 容器进程启动即崩溃，未进入Running阶段 #

这是最高发的原因，你提供的Deployment配置中未定义健康检查、启动校验逻辑，新Pod拉起后容器进程直接退出就会被立即终止。

• 排查操作：
  • 执行kubectl describe pod <被终止的新Pod名称> -n <业务命名空间>，重点查看Events事件流、Container Statuses下的Last State字段，确认退出码和终止原因
  • 如果是OOMKilled，说明resources.requests配置的内存小于FPM+Laravel启动所需的最小内存；如果是Error退出，执行kubectl logs <被终止的Pod名> -c fpm -n <命名空间> --previous查看启动报错日志
• 常见根因：
  • Laravel目录权限错误：storage、bootstrap/cache目录没有容器运行用户的写入权限，是Laravel场景下最常见的启动失败原因
  • 环境变量/密钥配置错误：比如数据库连接信息错误、APP_KEY缺失，导致FPM启动加载框架时报错
  • FPM服务配置异常：比如容器内FPM实际监听端口不是配置的9000，或者进程启动参数错误
• 解决方案：根据日志报错修复对应配置，可临时启动一个同镜像的调试Pod，手动执行FPM启动命令验证可用性，调整资源requests值匹配启动需求。

2. 旧版HPA逻辑缺陷导致扩缩容抖动 #

你使用的autoscaling/v2beta1是已废弃的旧版本HPA API，该版本默认没有扩缩容稳定窗口，且会将未就绪的新Pod纳入指标平均值计算：刚启动的Pod业务流量还没接入，CPU/内存占用远低于运行中的Pod，会瞬间拉低整体平均利用率，触发HPA判定负载已达标，刚扩容完就立刻执行缩容删除新Pod。同HPA配置下前端服务正常，是因为前端Nginx服务启动速度极快，启动后资源占用很快达到运行水平，不会触发该逻辑缺陷，而后端FPM启动需要加载Laravel框架、初始化业务依赖，启动耗时久，刚拉起时资源占用极低，很容易触发抖动。

• 排查操作：
  • 执行kubectl describe hpa fpm-server-hpa -n <命名空间>查看事件流，确认是否存在刚触发ScalingUp扩容事件后1-2分钟内立刻触发ScalingDown缩容事件的情况
  • 执行kubectl get hpa fpm-server-hpa -w持续观察指标变化，确认扩容瞬间的平均利用率是否直接跌到目标阈值以下
• 解决方案：
  • 将HPA API版本升级为稳定版autoscaling/v2
  • 给HPA配置扩缩容行为规则，增加缩容稳定窗口避免抖动，参考配置：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: fpm-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: fpm-server
  minReplicas: 2
  maxReplicas: 20
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15
      - type: Pods
        value: 4
        periodSeconds: 15
      selectPolicy: Max
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

• 给FPM容器配置就绪探针，只有服务正常可接收流量时才将Pod标记为Ready，未就绪Pod不会纳入HPA指标计算。

3. 多控制器冲突修改Deployment副本数 #

如果集群内有其他组件也在操作该Deployment的replicas字段，会出现HPA刚扩容就被其他组件改回低副本数、删除新Pod的情况。

• 排查操作：
  • 执行kubectl describe deployment fpm-server -n <命名空间>，查看副本数变更事件的发起组件
  • 排查是否存在冲突的控制逻辑：比如重复创建的HPA资源、KEDA等其他扩缩容组件的绑定规则、ArgoCD/Flux等GitOps工具的同步逻辑（如果GitOps工具配置了强制同步副本数，而Git仓库中存的replicas是固定低值，会直接删除HPA扩容出的Pod）
• 解决方案：删除冲突的扩缩容配置，GitOps场景下配置忽略Deployment的replicas字段差异，将副本数控制权完全交给HPA。

4. 新节点初始化异常导致Pod被驱逐 #

虽然集群开启了Cluster Autoscaler，但如果新扩容的Pod被调度到CA刚拉起的新节点上，节点初始化失败（比如CNI网络插件未就绪、kubelet异常、存在未被容忍的污点）会导致Pod还没启动就被驱逐终止。

• 排查操作：查看被终止Pod的事件流，确认是否存在调度到新节点后立刻出现Evicted、NodeNotReady、TaintToleration相关报错，登录对应节点检查组件运行状态
• 解决方案：修复节点组件故障，给工作负载配置对应污点容忍，调整CA的节点就绪等待配置。

内容的提问来源于stack exchange，提问作者Alexandru Constantin Arvinte