kubernetes中常见的exited code总结

在Kubernetes运维过程中，容器异常退出时的Exit Code是排查问题的关键线索。以下是经过系统整理的常见退出码及其深度解析，基于Linux标准信号机制和容器运行时实践总结： Exit Code 0 ✅ 含义：正常退出

在Kubernetes运维过程中，容器异常退出时的Exit Code是排查问题的关键线索。以下是经过系统整理的常见退出码及其深度解析，基于Linux标准信号机制和容器运行时实践总结：

Exit Code 0 ✅
- 含义：正常退出
- 场景：容器主进程主动终止（如业务程序执行完成）
- 排查建议：检查容器日志确认是否预期行为，常见于Job/CronJob任务完成
Exit Code 1 ❗
- 通用错误码
- 典型原因：
  - 应用程序未捕获的异常（如Python未处理的Exception）
  - 启动命令参数错误
  - 配置文件语法错误
- 诊断方法：kubectl logs查看应用日志，结合 kubectl describe pod检查启动命令
Exit Code 137 (128+9/SIGKILL) ☠️
- 强制终止信号
- 产生机制：
  - OOM Killer触发（需检查 dmesg日志）
  - 资源限制（kubectl describe pod查看OOMKilled状态）
  - 手动 kill -9操作
- 优化方案：合理设置resources.limits内存值，添加Heap监控
Exit Code 143 (128+15/SIGTERM) ⏳
- 优雅终止信号
- 标准流程：kubelet删除Pod时发送SIGTERM，等待terminationGracePeriodSeconds（默认30秒）
- 常见问题：应用未实现优雅退出逻辑，导致强制终止
Exit Code 126 🔐
- 权限问题
- 具体表现：
  - 容器入口文件无执行权限（chmod +x缺失）
  - 只读文件系统写入操作（readOnlyRootFilesystem: true时）
- 验证方法：kubectl exec检查文件权限
Exit Code 127 🔍
- 命令未找到
- 典型场景：
  - Dockerfile中CMD/ENTRYPOINT路径错误
  - 基础镜像缺少依赖二进制文件
- 快速验证：which <command>确认命令存在性
Exit Code 139 (128+11/SIGSEGV) 💥
- 段错误(Segmentation Fault)
- 深层原因：
  - 空指针解引用（C/C++程序常见）
  - 内存越界访问
- 诊断工具：需结合coredump分析（需提前配置ulimit）
Exit Code 255 ❓
- 非标准错误
- 可能情况：
  - 容器运行时异常（docker/containerd状态异常）
  - 镜像损坏（建议 docker pull重新获取）
  - 节点资源耗尽（检查 df -h和 free -m）

高级排查技巧：

事件追溯：

kubectl get events --sort-by=.metadata.creationTimestamp

退出码转换表：

原始信号计算方式最终Exit Code

SIGTERM 128+15 143

SIGKILL 128+9 137
自定义处理：通过Pod的 lifecycle.preStop钩子实现优雅退出逻辑

原始信号	计算方式	最终Exit Code
SIGTERM	128+15	143
SIGKILL	128+9	137

预防建议：

所有容器进程实现信号处理（SIGTERM/SIGINT）
生产环境必须配置resources.requests/limits
使用livenessProbe避免僵尸进程
重要服务部署PodDisruptionBudget

通过系统理解这些退出码，可以快速定位80%以上的容器异常问题。实际运维中建议结合Prometheus监控指标（如container_last_seen）建立告警体系。

kubernetes中常见的exited code总结

kubernetes中常见的exited code总结

标签: