docker run启动自定义镜像时出现Kernel panic错误如何排查

首先明确基础逻辑：容器共享宿主机内核，不存在跨Ubuntu版本容器镜像不兼容直接导致内核panic的可能，hello-world镜像正常运行已经证明Docker引擎核心的namespace、cgroup隔离功能无故障，触发问题的高概率原因按优先级排序如下：

• 镜像构建方式存在缺陷：你是通过docker commit从正在运行的旧容器直接制作镜像，这种方式会将旧容器运行时的所有临时状态一并打包，包括旧实例4.15内核环境下生成的cgroup统计缓存、挂载点残留、运行锁文件、临时系统目录下的状态文件。这些残留内容在Ubuntu20.04默认的5.4+内核环境下，会在Jenkins启动读取系统资源信息、挂载文件系统时触发内核态中断异常，直接导致panic。
• 新实例cgroup版本不兼容：Ubuntu20.04部分EC2 AMI默认开启cgroupv2，而旧Ubuntu18.04环境默认使用cgroupv1，你commit的镜像中残留的旧cgroup挂载规则、Jenkins内置的Java版本对cgroupv2的资源读取逻辑存在已知兼容问题，会触发内核中断错误。
• 新实例内核版本存在已知bug：Ubuntu20.04早期5.4.0-10xx系列AWS定制内核，存在处理overlayfs挂载下cgroup资源统计的中断异常bug，特定挂载参数下会直接触发kernel panic。
• 实例类型驱动冲突：如果新EC2实例选用了Graviton（ARM架构）或新一代x86实例类型，默认内核的存储驱动与你commit镜像中残留的旧aufs挂载标记冲突，也会触发内核级错误。

• 第一步先排除镜像本身问题：直接拉取官方Jenkins LTS镜像执行启动命令docker run -p 8080:8080 jenkins/jenkins:lts，如果容器正常启动无panic，可直接确认问题出在你自行commit的镜像上，和宿主机Docker、内核基础能力无关。
• 检查cgroup版本：执行stat -fc %T /sys/fs/cgroup，输出为cgroup2fs即代表当前启用cgroupv2。
• 检查内核版本：执行uname -r确认当前运行的内核小版本，对照内核更新日志确认是否存在已知的cgroup/overlayfs panic问题。

• 长期最优方案：废弃docker commit制作的镜像，改用Dockerfile构建可复现的无状态镜像。以官方jenkins/jenkins:lts镜像为基础，将旧容器中安装的插件、配置文件、自定义脚本通过COPY、RUN指令写入镜像，完全剔除运行时产生的临时状态文件，从根源避免残留状态触发的兼容问题。
• 临时可用方案：启动现有镜像时添加参数跳过残留挂载，命令如下：

docker run -p 8080:8080 --tmpfs /run --tmpfs /tmp --cgroupns=host e0f499cc9f6e

• cgroupv2兼容修复：如果确认是cgroupv2导致的问题，编辑/etc/default/grub文件，在GRUB_CMDLINE_LINUX配置项中添加systemd.unified_cgroup_hierarchy=0，执行update-grub后重启实例即可切回cgroupv1兼容模式。
• 内核bug修复：执行apt update && apt install -y linux-image-aws升级到最新版AWS定制内核，重启实例后再测试容器启动。

内容的提问来源于stack exchange，提问作者ahkam