排查linux容器宿主机问题需以宿主机为原点，同步检查资源状态（cpu、内存、磁盘io）、cgroups/namespace隔离性、网络栈（网桥、iptables、内核参数）及日志事件联动，避免仅依赖容器层命令。
排查Linux容器宿主机问题，关键在于理清容器与宿主机的资源依赖和状态耦合关系。容器不是黑盒，它的运行完全依托于宿主机的内核、cgroups、namespace、存储和网络栈。出问题时，不能只查docker logs或kubectl describe，必须同步观察宿主机层面的实时状态。
看宿主机资源是否被耗尽
容器异常（如频繁重启、OOMKilled、响应延迟）常是宿主机资源瓶颈的外在表现：
-
CPU：用
top或htop看整体负载（Load average），再用pidstat -u 1定位高CPU进程——注意区分是容器内进程（如PID在/proc/[pid]/cgroup中显示docker/或kubepods/）还是宿主机其他服务 -
内存：运行
free -h看可用内存；检查dmesg -T | grep -i "killed process"确认是否触发OOM Killer；用cat /sys/fs/cgroup/memory/docker/*/memory.usage_in_bytes（Docker）或find /sys/fs/cgroup/memory/kubepods/ -name memory.usage_in_bytes -exec sh -c 'echo "{}: $(cat {})"' \;粗略估算容器组内存占用 -
磁盘IO与空间：
iostat -x 1看%util和await；df -h查根分区及/var/lib/docker或/var/lib/containers所在挂载点；du -sh /var/lib/docker/overlay2/* 2>/dev/null | sort -hr | head -5快速定位大镜像层或残留容器数据
查容器隔离机制是否异常
Namespace和cgroups是容器隔离的基础，它们出问题会导致容器行为不可控：
- 用
ls -l /proc/[PID]/ns/（任一容器内进程PID）验证是否所有namespace都带[...]后缀（表示已隔离）；若看到(deleted)或指向/proc/1/ns/...，说明隔离失效 - 检查cgroups路径是否存在且权限正常：
cat /proc/[PID]/cgroup查看容器归属的cgroup路径，再进对应目录（如/sys/fs/cgroup/cpu,cpuacct/docker/xxx/）确认cpu.shares、memory.limit_in_bytes等文件可读，值符合预期 - 若使用systemd管理容器（如podman system service），运行
systemctl --state=running | grep container确认cgroup v2下容器单元状态是否为running，避免因Scope泄漏导致资源统计错乱
验网络链路是否在宿主机侧中断
容器网络不通，80%以上问题根因在宿主机的iptables/nftables规则、网桥配置或内核参数：
- 确认容器使用的网桥（如
docker0、cni0）处于UP状态：ip link show docker0；检查其IP和子网是否与容器IP段匹配（如docker0是172.17.0.1/16，容器却分配到10.244.1.5，说明CNI插件未生效） - 抓包定位断点：
tcpdump -i docker0 port 80看请求是否到达网桥；再在容器内tcpdump -i eth0对比，若前者有包后者无，说明iptables DNAT/SNAT规则丢失或被覆盖 - 检查关键内核参数：
sysctl net.ipv4.ip_forward必须为1；sysctl net.bridge.bridge-nf-call-iptables在使用网桥+iptables时需为1（否则bridge流量不经过iptables）
盯日志与事件联动分析
把容器操作与宿主机系统事件对齐，能快速锁定时间线上的因果关系：
- 容器启动/停止时，宿主机
dmesg可能输出cgroup创建失败、设备节点权限拒绝、overlayfs mount error等底层错误 - 用
journalctl -u docker --since "2024-05-20 14:00:00"查Docker daemon日志，重点关注failed to start container或libcontainer相关报错；若用Podman，查journalctl -u podman - 将容器ID与宿主机进程关联：
docker inspect -f '{{.State.Pid}}' <container_id></container_id>得到PID，再用ps -o pid,ppid,comm -p <pid> --forest</pid>看其父进程是否为containerd-shim或conmon，排除僵尸进程或孤儿容器
容器排错不是单点扫描，而是以宿主机为坐标原点，把容器当作一组受控的进程+配置+资源配额来审视。每次操作容器命令，都要条件反射式同步检查对应宿主机组件的状态。
