精通Docker容器运行时故障排查：SRE实用指南

场景

某微服务在Kubernetes集群中突然进入CrashLoopBackOff状态。检查Docker日志发现错误：container_linux.go:367: starting container process caused: process_linux.go:578: executing setns process caused: exit status 1: unexpected EOF。容器无法正常启动，影响服务可用性。

症状

• 容器状态反复CrashLoopBackOff。
• docker logs输出为空或仅有错误信息。
• 主机上dockerd日志显示runtime错误。
• 系统资源使用率正常，无OOM。

诊断

1. 检查容器日志

运行docker logs <container-id>查看标准输出/错误。如果为空，说明容器在初始化阶段即失败。

2. 检查容器状态与配置

docker inspect <container-id> --format '{{.State.Status}} {{.State.ExitCode}}'

ExitCode非零（常见如139=段错误，137=OOM，但此处127表示命令不存在）。

3. 分析OCI运行时错误

错误来自runc（默认OCI运行时）。检查/var/log/syslog或journalctl -u docker获取更详细堆栈。

journalctl -u docker -n 100 --no-pager | grep -i error

常见原因： - cgroups版本不兼容（某些应用需要cgroup v1，而系统使用v2）。 - 挂载点问题（如/proc、/sys未正确挂载）。 - 内核安全策略（AppArmor/SELinux阻止操作）。

4. 测试runc单独运行

runc exec <container-id> /bin/sh

若失败，则确认runtime本身有问题。

5. 检查cgroups配置

cat /proc/self/cgroup
mount | grep cgroup

若为cgroup v2，检查/sys/fs/cgroup下是否存在对应控制器。

6. 使用strace跟踪

strace -f -e trace=process docker run --rm alpine echo hello

定位系统调用失败点。

风险控制

• 不要在生产环境直接运行诊断命令，尤其是runc exec和strace，可能影响容器状态。
• 使用--memory和--cpu限制资源，避免因资源耗尽诱发其他问题。
• 在测试环境复现问题。
• 启用Docker debug模式（dockerd --debug）获取详细日志，但注意数据量。

回滚

1. 恢复上一版本的容器镜像： bash kubectl set image deployment/<name> <container>=<image>:<previous-tag>
2. 如果Kubernetes节点Docker守护进程异常，重启Docker： bash systemctl restart docker 注意重启会停止所有容器，需评估影响。
3. 若怀疑runc版本问题，降级或重新安装runc： bash apt-get install --reinstall runc=1.0.0-1

验证

• 部署回滚后，等待Pod启动并检查状态： bash kubectl rollout status deployment/<name> kubectl logs -f <pod-name>
• 运行健康检查端点（如/healthz）。
• 监控Docker daemon日志无新错误。

何时提交OpsGlobal工单

• 错误涉及内核模块或cgroups版本冲突，需升级内核或修改系统配置。
• OCI runtime需要定制或升级，但影响多服务。
• 问题持续出现且影响多个节点，需要全面runtime审计。
• 内部团队无权限修改主机级别设置（如Kubernetes节点由供应商管理）。