容器突然崩了，运维兄弟常手忙脚乱：到底该查 Docker 还是调 K8s？这俩都是容器生态的核心工具，但故障恢复时职责总糊在一起，很容易走弯路 —— 比如明明是 Docker 镜像坏了，却死磕 K8s 配置，半天没进展。我结合平时处理故障的经验，把两者的定位、判断方法和分工拆清楚，帮大家快速解决问题。

一、先搞懂：Docker 和 K8s 到底是干啥的，分工才好分

分工乱的根源，其实是没搞透两者的核心定位。先把这点理清，后面判断故障归属就简单了。

1. Docker：管单个容器 “生老病死” 的

Docker 本质是容器引擎，说白了就是帮你管 “单个容器” 的：

把应用和依赖打包成镜像，保证换个环境也能跑；

创建、启动、停止单个容器，还能看这个容器的状态 —— 比如是不是活的、占了多少内存；

处理容器和宿主机的本地交互，比如把宿主机的目录挂到容器里，或者配置容器的网络。

简单说，Docker 只盯着 “单个容器”，不管一堆容器怎么协同，更没能力跨节点调度。

感兴趣可了解>>>Docker容器技术与安装教程视频介绍

2. K8s：管一群容器 “整体稳定” 的

K8s 是容器编排平台，核心是管 “集群里所有容器的整体情况”：

它不直接建容器（底层还是靠 Docker 这类引擎），而是通过 Pod、Deployment 这些东西批量管容器；

能让容器崩了自动恢复、跨节点迁移，还能分配资源 —— 比如哪个容器多给点内存；

保障整个集群的服务能用，比如帮你找到服务在哪、把请求分到不同容器上。

K8s 看的是 “全局”，单个容器的细节它不管。

感兴趣可了解>>>Kubernetes 架构、安装和配置视频介绍

二、快速判断：容器崩了，先找 Docker 还是 K8s？

故障恢复第一步，先定好归谁管。我总结了平时最常见的 4 种场景，大家可以直接对号入座。

1. 就一个容器崩了，其他都正常 —— 找 Docker

如果只有某一个容器启动不了或者崩了，同节点的其他容器都好好的，那基本是 Docker 的问题：

常见原因比如镜像坏了（拉的时候断了、本地镜像文件损坏）、容器配置错了（端口跟别的程序冲突、挂的目录根本不存在），或者宿主机给这个容器的资源不够（比如内存跑满了）；

第一步先查 Docker：敲 docker ps -a 看看容器状态，再用 docker logs 容器ID 读崩溃日志，一般能很快找到问题 —— 比如日志里写 “镜像不存在”，那就是镜像的事。

2. 一个 Pod 里的容器全崩了，或者老重启 —— 找 K8s

K8s 里一个 Pod 会装多个关联的容器，要是这些容器一起崩了，或者重启次数特别多（看 RESTARTS 那列），肯定是 K8s 配置的问题：

常见的比如 Pod 资源给少了（内存不够被系统杀掉，就是常说的 OOM）、健康检查配置错了（比如没响应就重启，结果一直重启），或者依赖的 ConfigMap、Secret 没挂上去 —— 容器启动要的配置找不到，自然崩；

第一步查 K8s：敲 kubectl describe pod Pod名称看事件日志，重点看 “Events” 那块，比如里面写 “Failed to pull configmap”，就是配置没挂对。

3. 容器崩了没日志，同节点容器都不对劲 —— 先查 Docker 引擎

要是容器崩了没任何日志，而且同节点里其他 Docker 管的容器也不正常，别先动 K8s，先查 Docker 引擎：

可能是 Docker 后台进程（daemon）崩了，或者宿主机内核跟 Docker 版本不兼容，也可能是 Docker 的存储驱动出问题；

第一步先看 Docker 状态：敲 systemctl status docker，要是 daemon 没跑，先重启试试 ——systemctl restart docker，重启完再看容器能不能恢复。

4. 节点宕机了，容器没自动迁走 —— 找 K8s

要是宿主机（也就是 K8s 节点）挂了，原本跑在上面的容器没自动移到其他节点，那是 K8s 高可用没配好：

比如没用水 Deployment 管 Pod（裸 Pod 崩了不会自己恢复）、集群节点太少 —— 就一个节点，挂了没地方迁，或者 K8s 控制节点没做高可用（就一个 master 节点，挂了整个集群没法管）；

第一步查节点状态：敲 kubectl get nodes，要是节点显示 “NotReady”，先想办法恢复节点，或者让 K8s 在其他好节点上重新建 Pod。

三、Docker 管啥：就修单个容器的 “本地问题”

Docker 在故障恢复里，主要就是修单个容器的本地毛病，具体分三类情况。

1. 容器自己的问题：直接修这个容器就行

要是容器进程、配置、网络出问题，用 Docker 命令直接处理就行：

进程崩了：比如日志里写 “Java OutOfMemoryError”，先把应用代码修了，再敲 docker start 容器ID 重启，不行就用 docker run 重新建一个；

资源不够：敲 docker stats 看看这个容器之前占多少资源，要是内存不够，用 docker update --memory 2G 容器ID 加内存，再重启；

网络不通：敲 docker network inspect 网络名看看网络配置，要是容器没加对网络，用 docker network connect 网络名容器ID 把它连进去就行。

2. 镜像和存储的问题：先把基础修好

镜像和存储是容器能跑的基础，这俩出问题得先解决：

镜像有问题：敲 docker images 看看本地有没有这个镜像，要是没了或者坏了，用 docker pull 镜像名:标签重新拉，比如 docker pull nginx:1.24；要是本地镜像坏了，先 docker rmi 损坏镜像ID 删掉再拉；

挂载有问题：敲 docker inspect 容器ID 看看挂了哪个目录，去宿主机确认这个目录存在，权限也对 —— 比如给个 chmod 755 /data，修好再重启容器。

3. Docker 引擎出问题：先把底层弄好

引擎坏了的话，所有容器都得歇菜，得赶紧恢复：

daemon 崩了：先试 systemctl restart docker 重启，要是起不来，去看 /var/log/docker.log 找原因 —— 比如日志里说内核版本不对，那就升级内核；

版本不兼容：要是重启后还是不行，敲 docker version 看看版本，参考 Docker 官方文档换个稳定版，比如 25.0.x 系列，别用太新的测试版。

四、K8s 管啥：管集群里容器的 “全局调度”

K8s 不管单个容器的小毛病，主要是通过调度让整个集群恢复稳定，平时处理最多的是这三类情况。

1. 容器崩了自动恢复：靠控制器 “自愈”

K8s 里的 Deployment、StatefulSet 这些控制器，能让容器崩了自己恢复：

原理很简单：比如你配了 replicas: 3，就是要 3 个容器跑着，要是一个崩了，K8s 会通过健康检查（livenessProbe）发现，然后在好的节点上让 Docker 新建一个；

操作上：先敲 kubectl get deployment 看看控制器状态，要是 “READY” 数不够，比如应该 3 个只 ready 2 个，就用 kubectl describe deployment 名称查原因 —— 比如镜像拉不下来，那就是镜像地址错了。

2. 节点宕机了：让容器迁到其他节点

要是某个节点挂了，K8s 会自动把这个节点上的容器移到其他好节点：

流程大概是这样：kubelet 发现节点状态变成 “NotReady”→ 把这个节点上的 Pod 标成 “不可用”→ 调度器（kube-scheduler）在好节点上重新安排这些 Pod→ 底层 Docker 启动新容器；

这里要注意：集群节点至少 3 个，不然一个挂了没地方迁；Deployment 副本数至少 2 个，避免一个容器崩了服务就停了。

3. 资源不够容器老崩：动态调资源

要是容器因为集群资源不够老崩，K8s 可以通过配置解决：

先设资源限制：在 Deployment 里写 resources.limits.cpu: 1 resources.limits.memory: 2G，别让一个容器占太多资源，影响其他容器；

再开自动扩缩容：用 HPA（Horizontal Pod Autoscaler），比如 CPU 使用率超 70% 就多开几个副本，敲 kubectl autoscale deployment 名称 --min=2 --max=5 就能启用，不用手动加副本。

五、实际案例：电商订单服务容器崩了，怎么配合恢复

我之前处理过电商促销期间的故障：订单服务有 2 个 Pod 崩了，用户下单偶尔超时。当时是这么配合恢复的：

先定归属：敲 kubectl get pods -n order-service，看到 2 个 Pod 状态是 “CrashLoopBackOff”，其他 Pod 正常 —— 初步判断是 K8s 配置的问题；

查 K8s 原因：敲 kubectl describe pod order-pod-xxx，Events 里写着 “OOM killed”—— 原来 Pod 内存给少了，才 1G，促销期间请求多就不够用；

调 K8s 配置：把 Deployment 里的 resources.limits.memory 从 1G 改成 2G，再敲 kubectl apply -f order-deployment.yaml 生效；

等 K8s 调度：K8s 自动把崩了的 Pod 删了，在好的节点上让 Docker 拉镜像、建新 Pod；

用 Docker 验证：去新 Pod 所在的节点，敲 docker ps 看容器是不是在跑，再用 docker logs 容器ID 确认应用没报错；

最后查服务：敲 kubectl get svc order-service，用 Service 地址测了下，订单能正常下了，故障就解决了。

六、避坑提醒：这 3 个错别犯，不然越修越乱

别用 Docker 命令改 K8s 管的容器：之前见过有人容器崩了，直接用 docker stop 停了再建，结果 K8s 以为容器又崩了，不停重建，越改越乱 ——K8s 管的容器，就用 K8s 命令调；

Docker 底层坏了，K8s 也没办法：要是 Docker 引擎崩了，K8s 只能看到 Pod 异常，没法自己修 Docker，得先把 Docker 修好，K8s 才能接着调度；

不配高可用，K8s 救不了你：要是用裸 Pod（没 Deployment）、副本数就 1 个，或者集群就一个节点，K8s 想自动恢复也没辙 —— 生产环境一定要配 Deployment、多副本、多节点。

七、Docker 和 K8s 配合好，故障恢复才快

其实一句话就能说清：Docker 是 “修单个容器的维修工”，解决本地的小问题；K8s 是 “管集群的指挥官”，负责全局调度和恢复。把两者的分工理清，处理故障时就不用瞎忙，能省不少时间 —— 这也是咱们运维提升效率的关键。

附录：Docker 故障排查常用命令汇总

Docker 故障排查常用命令汇总

开设课程开班时间在线报名

OCP

2025.04.26

在线报名

HCIP-AI Solution

2025.04.26

在线报名

HCIE-openEuler

2025.05.03

在线报名

RHCA-CL260

2025.05.04

在线报名

HCIP-Cloud

2025.05.10

在线报名

PGCM直通车

2025.05.10

在线报名

HCIA-Datacom(晚班)

2025.05.19

在线报名

HCIA-Sec

2025.06.07

在线报名

RHCA-RH442

2025.06.07

在线报名

PMP

2025.06.10

在线报名

HCIA-Datacom

2025.06.14

在线报名

HCIE-AI Solution

2025.06.14

在线报名

HCIE-Datacom

2025.06.14

在线报名

HCIP-Datacom(晚班)

2025.06.16

在线报名

OCM

2025.06.21

在线报名

HCIE-Cloud

2025.06.21

在线报名

HCIP-Sec

2025.06.21

在线报名

HCIE-Bigdata

2025.06.28

在线报名

RHCE

2025.06.28

在线报名

HCIE-Datacom考前辅导

2025.07.05

在线报名

HCIP-Datacom深圳

2025.07.19

在线报名

CISP

2025.07.19

在线报名

HCIA-Datacom(晚班)

2025.07.21

在线报名

RHCA-RH436

2025.07.26

在线报名

OCP

2025.07.26

在线报名

HCIE-Sec

2025.08.09

在线报名

HCIA-AI Solution

2025.08.16

在线报名

HCIP-Datacom(晚班)

2025.08.25

在线报名

RHCA-RH358

2025.09.06

在线报名

PMP

2025.09.16

在线报名

HCIE-Datacom

2025.09.06

在线报名

HCIA-AI Solution

2025.09.27

在线报名

HCIA-Datacom

2025.09.27

在线报名

PGCM直通车

2025.10.11

在线报名

RHCA-DO374

2025.10.11

在线报名

HCIA-Sec

2025.10.11

在线报名

RHCE

2025.10.18

在线报名

HCIP-Datacom

2025.11.08

在线报名

HCIP-Sec

2025.11.08

在线报名

RHCA-CL260

2025.11.15

在线报名

OCP

2025.11.15

在线报名

HCIE-Sec

2025.12.13

在线报名

HCIE-Datacom

2026.01.10

在线报名

在线精品

华为数通初级 | HCIA-Datacom在线课程

1027人在学

鸿蒙应用开发：图片组件与插值

330人在学

HarmonyOS 系统简介：鸿蒙入门核心课

275人在学

Wireshark 与 HTTP/HTTPS 协议数据包学习

412人在学

课程商城

华为 HCIP-Datacom 考试服务

10课时

【直播课】华为HCIA-Datacom数通认证课程

36课时

华为云计算认证 HCIA HCIP-Cloud HCIE 培训课程

48课时

华为数通HCIE-Datacom培训认证数据通信路由交换

40课时

在线报名

报名已确认!

我们已收到您的信息
相关老师将尽快与您联系

友情链接

IT培训| 企业招聘| 大学生就业|