Docker 容器运行时故障排除实战指南

场景

在生产环境中，Docker 容器可能出现启动失败、意外退出、性能下降或网络异常等问题。本文以典型场景为例：某微服务容器在 Kubernetes 集群中反复 CrashLoopBackOff，日志无明确错误，需系统排查。

症状

• 容器启动后立即退出，状态为 Exited (1) 或 Exited (137)
• docker logs 无输出或仅有少量泛泛信息
• kubectl describe pod 显示 CrashLoopBackOff
• 主机 dmesg 出现 OOM 或内核错误
• 容器内进程无响应或响应超时

诊断

1. 检查容器日志

docker logs --tail 100 <container_id>
docker logs --since 5m <container_id>

若日志无帮助，尝试附加标准输入/输出：

docker attach --sig-proxy=false <container_id>

2. 检查容器状态与退出码

docker inspect <container_id> --format '{{.State.ExitCode}}'
docker inspect <container_id> | jq '.[0].State'

• 退出码 137：SIGKILL，通常因 OOM 或被 docker stop 杀死
• 退出码 1：应用错误，需检查应用日志
• 退出码 0：正常退出，但可能被 init 进程接管

3. 检查资源限制与 OOM

docker stats --no-stream <container_id>
cat /sys/fs/cgroup/memory/docker/<container_id>/memory.oom_control

查看 oom_kill 计数是否增加。

4. 检查文件系统与存储驱动

docker info | grep -i "Storage Driver"
df -h /var/lib/docker

存储驱动（如 overlay2）满或 inode 耗尽会导致容器无法写入。

5. 检查网络与 DNS

docker exec <container_id> ping -c 3 google.com
docker exec <container_id> nslookup <service_name>

若容器内 DNS 解析失败，检查 /etc/resolv.conf 或 Docker 网络模式。

6. 检查内核与 cgroup 版本

uname -r
cat /sys/fs/cgroup/unified/

Docker 20.10+ 默认使用 cgroup v2，某些旧应用可能不兼容。

7. 使用 docker events 实时监控

docker events --filter 'container=<container_id>'

观察容器生命周期事件。

命令

# 查看进程树
docker top <container_id>

# 进入命名空间调试
docker run --rm -it --pid=container:<container_id> --net=container:<container_id> --cap-add SYS_PTRACE nicolaka/netshoot

# 导出容器文件系统
docker export <container_id> -o container.tar

# 检查镜像层
docker history <image_name>

风险控制

• 切勿在生产环境下直接执行 docker restart 或 docker rm -f 而不先执行 docker pause 或健康检查
• 在诊断阶段，使用 docker logs 和 docker inspect 等只读命令，避免修改容器状态
• 如需重启，先创建快照或执行 docker commit 保存当前状态
• 涉及内核参数调整时，先在测试环境验证

回滚

1. 记录当前容器配置：docker inspect <container_id> > container_config.json
2. 停止异常容器：docker stop <container_id>
3. 恢复至上一版本镜像：docker pull <image_name>:<previous_tag>
4. 使用原参数重新启动：docker run --name <container_name> ... <image_name>:<previous_tag>
5. 若容器由编排工具管理，更新配置并重新部署：kubectl rollout undo deployment/<deployment_name>

验证

• 确认容器运行状态：docker ps -a | grep <container_name>，Status 应为“Up”
• 检查应用健康端点：curl -f http://localhost:<port>/health
• 监控日志无错误：docker logs --tail 50 <container_id> 无异常堆栈
• 确认资源正常：docker stats --no-stream <container_id> 显示 CPU/内存使用在预期范围内
• 测试网络连通性：从其他服务访问容器无误

何时提交 OpsGlobal 工单

当出现以下情况时，应立即联系 OpsGlobal 专家团队：

• 容器崩溃涉及内核 panic、不可恢复的文件系统损坏或硬件故障
• 诊断命令报错“权限不足”或“系统调用受限”，且无法通过 --privileged 安全提升
• 容器运行时行为与官方文档严重不符，疑似 Docker 或 containerd 自身 bug
• 故障影响多个节点或整个集群，需协调多维度资源排查
• 自行尝试所有上述步骤后，容器仍无法恢复，且业务中断时间超过 RTO

提交工单时请附上：docker info、docker version、syslog 片段、问题容器 ID 及诊断命令输出。