Kubernetes Pod启动报CrashLoopBackOff反复重启故障排查

你的初步判断方向有误，问题核心不是容器无持续运行进程——sleep infinity本身是可以长期前台运行的，真正的故障原因是：

你在Deployment配置中自定义的command: [ "sleep" ]和args: [ "infinity" ]字段，完全覆盖了业务镜像内置的Nginx启动命令。容器启动后只会运行sleep进程，根本不会启动Nginx Web服务，你配置的HTTP类型存活、就绪探针在15秒初始延迟结束后，访问80端口的/index.html会直接连接失败，加上你把failureThreshold设为1，单次探测失败就会被kubelet判定为不健康，强制杀死容器重启。反复重启触发退避逻辑，最终呈现CrashLoopBackOff状态。

几个佐证点：

• 镜像本地运行无异常，是因为本地直接启动镜像时会使用镜像内置的CMD ["nginx", "-g", "daemon off;"]命令启动Nginx，没有被外部命令覆盖
• 替换其他镜像可正常部署，是测试时使用了精简配置，没有保留错误的command/args覆盖逻辑
• 这类问题不会在容器事件里报进程主动退出，因为sleep进程不会主动终止，事件只会记录探针失败后容器被kubelet终止重启

你可以通过两个操作快速确认：

• 执行kubectl logs malvacom-frontend-8575c8548b-n959r，看不到任何Nginx启动相关的日志
• 临时注释掉配置里的livenessProbe和readinessProbe段重新部署，Pod会进入Running状态，但此时访问Pod的80端口会直接被拒绝，因为没有Web服务在监听

直接删除容器配置段下的command和args两行配置，让容器使用镜像内置的Nginx启动命令即可，修正后的核心配置片段如下：

containers:
  - name: malvacom-frontend
    image: docker.io/forsrobin/malvacom_frontend
    imagePullPolicy: IfNotPresent
    ports:
      - containerPort: 80
    resources:
      limits:
        memory: "128Mi"
        cpu: "200m"
    livenessProbe:
      httpGet:
        path: /index.html
        port: 80
      initialDelaySeconds: 15
      timeoutSeconds: 2
      periodSeconds: 5
      failureThreshold: 1
    readinessProbe:
      httpGet:
        path: /index.html
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 5
      failureThreshold: 1

修复操作步骤：

1. 保存修改后的frontend.yaml
2. 执行kubectl apply -f frontend.yaml触发滚动更新
3. 等待20秒左右执行kubectl get pods，当对应Pod状态为Running、READY列显示1/1时，即部署正常。

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