AWS环境下Kubernetes部署Python容器出现CrashLoopBackOff问题排查

你当前遇到的CrashLoopBackOff最核心的触发原因如下，按出现概率从高到低排序：

• 直接原因：当前Deployment未配置command/args启动命令，官方python:latest公共镜像默认启动行为是开启交互式Python解释器，Kubernetes运行容器时默认不分配TTY和标准输入，解释器无任务可执行直接正常退出，触发默认的Always重启策略，进入循环重启。
• 其他可能原因：
  • 若你是自定义打包的Python业务镜像，可能存在业务代码启动报错、依赖库缺失、配置文件路径错误、端口绑定失败、进程权限不足等问题
  • 容器申请的CPU/内存资源超出节点可用配额，被系统OOM Kill（退出码通常为137）
  • 镜像拉取失败（该场景通常会先报ImagePullBackOff，可作为排除项）

1. 查看容器运行日志，确认退出前的输出信息：

kubectl logs sbs-python-5d8f87b5c8-xbqd7 -n default

如果日志为空，基本可以确认是默认Python镜像无前台进程导致的正常退出。
2. 查看Pod详情和事件，确认退出码和异常事件：

kubectl describe pod sbs-python-5d8f87b5c8-xbqd7 -n default

查看Status字段下的Last State信息：

• 退出码为0：进程正常执行完毕退出，对应无前台进程的场景
• 退出码为1：业务进程启动报错，需结合日志排查代码/依赖问题
• 退出码为137：进程被系统OOM Kill，需调整容器资源配额

3. 若需要进入容器排查环境问题，可临时修改Deployment配置，增加sleep命令挂住容器进程：

containers:
- name: sbs-python
  image: python:latest
  imagePullPolicy: Always
  ports:
  - containerPort: 5000
  # 新增临时启动命令
  command: ["/bin/sh", "-c", "sleep 3600"]

重新apply后执行kubectl exec -it <pod名称> -- /bin/bash进入容器，手动验证依赖、业务代码启动逻辑是否正常。

场景1：仅测试镜像可用性，不需要运行业务 #

直接给容器配置常驻前台进程，或者开启TTY保留Python交互模式：

containers:
- name: sbs-python
  image: python:latest
  imagePullPolicy: Always
  ports:
  - containerPort: 5000
  # 方案A：配置常驻循环进程
  command: ["/bin/sh", "-c"]
  args: ["while true; do echo 'container running'; sleep 10; done"]
  # 方案B：开启TTY保留Python交互模式
  # tty: true
  # stdin: true

场景2：需要部署自己的Python业务 #

1. 编写Dockerfile打包自定义镜像，安装业务依赖、拷贝代码，指定默认启动命令，示例：

FROM python:latest
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .
# 启动常驻的Web服务进程
CMD ["python", "app.py"]

2. 将Deployment的image字段替换为你自己打包的镜像地址即可，无需额外配置command字段。

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