宿主机内核升级后容器崩溃，主因是运行时与新内核兼容性断层；需检查崩溃时间是否紧贴升级窗口、dmesg中runc/overlay/cgroup/oom报错、docker info中内核与runc版本匹配性，并通过grub回退旧内核验证，重点排查cgroups v1/v2切换影响。
宿主机内核升级后，docker 容器在 running 状态下突然崩溃，通常不是容器自身代码问题，而是底层运行时环境与新内核的兼容性断层所致。这类崩溃往往表现为：容器进程无声退出（docker ps 中状态短暂变为 exited (137) 或 exited (1)）、docker logs 无有效错误、docker inspect 显示 "status": "exited" 但无明确原因，甚至出现 kernel oops 或 segfault in runc 等内核级报错。
确认是否为内核升级引发的兼容性问题
先排除其他干扰因素，聚焦内核关联性：
- 检查崩溃时间是否紧贴内核升级窗口：
last reboot和uname -r对比升级前后的版本 - 查看系统日志中是否有内核不兼容提示：
dmesg -T | grep -i "runc\|overlay\|cgroup\|oom" - 运行
docker info | grep "Kernel Version\|Runc Version"，确认当前 Docker 和 runc 是否支持该新内核（尤其注意 cgroups v1/v2 切换） - 临时回退到旧内核启动（通过 GRUB 选择），验证容器是否稳定——这是最直接的因果验证
重点检查 cgroups 版本切换影响
Linux 5.8+ 默认启用 cgroups v2，而旧版 Docker（
- 执行
stat /sys/fs/cgroup -c "%t:%T"：若输出为63677263:2，说明已启用 cgroups v2 - 检查 Docker 是否以 cgroups v2 模式运行：
docker info | grep "Cgroup Driver"，应为systemd或cgroupfs，且需与内核一致 - 若不匹配，可临时切回 cgroups v1：在 GRUB 配置中添加内核参数
systemd.unified_cgroup_hierarchy=0，然后sudo update-grub && reboot
更新容器运行时组件
内核升级后，旧版 runc、containerd 或 Docker Engine 可能缺失对新内核特性的适配（如新的 seccomp 规则、memcg 改动、overlayfs 行为变更）：
- 升级到官方支持当前内核的最新稳定版：
sudo apt-get update && sudo apt-get install docker-ce docker-ce-cli containerd.io（Ubuntu/Debian） - 单独升级 runc（推荐使用静态二进制）：https://www.php.cn/link/51d81424aa2d36bf4248ae8a4a3cc885，替换
/usr/bin/runc - 重启 containerd 和 Docker：
sudo systemctl restart containerd docker
调整容器启动参数规避内核敏感行为
某些新内核会更严格校验容器配置，可临时绕过潜在冲突点：
- 禁用 seccomp 沙箱（仅调试用）：
docker run --security-opt seccomp=unconfined ... - 显式指定 cgroup 驱动：
docker run --cgroup-parent=docker.slice ...（配合 systemd） - 避免使用
--privileged或--cap-add=ALL，改用最小权限模型 - 若使用 overlay2 存储驱动，检查
/var/lib/docker/overlay2下是否有损坏层：sudo docker system prune -a（慎用，会清空镜像）
本质上，这不是容器“应用层”问题，而是运行时与内核契约的再对齐过程。核心动作是：确认内核变更事实 → 排查 cgroups 兼容性 → 升级运行时组件 → 微调容器参数。只要版本链（内核 ↔ runc ↔ containerd ↔ Docker）保持官方推荐组合，绝大多数崩溃都能收敛。
