K8s不同容器运行时下containerd-shim父进程差异及相关问题咨询

二者核心功能完全一致，都是作为containerd和容器进程的中间层，负责传递容器生命周期指令、托管容器运行、收割进程状态，避免containerd崩溃导致所有容器异常退出，差异仅在适配的标准和定位：

• containerd-shim-runc-v2 是专门对接runc runtime、符合OCI runtime spec v2标准的官方实现，是containerd 1.4+版本的默认runc shim
• containerd-shim 要么是旧版本遗留的v1标准shim，要么是当前环境下默认runtime shim的软链接（比如默认用runc v2时，containerd-shim会软链接到containerd-shim-runc-v2），这也是你看到二者启动参数高度相似的核心原因

两种场景的配置逻辑不同导致父进程不一样：

• 使用--container-runtime=docker时，minikube内置的dockerd + containerd组合默认开启了shim的daemonize配置：shim启动后会主动调用setsid等系统调用脱离父进程组，最终被系统PID 1进程收养，所以父进程显示为1
• 使用--container-runtime=containerd时，minikube的原生containerd配置关闭了shim自动脱离逻辑，shim不需要脱离父进程即可完成容器托管功能，所以父进程保持为containerd本身

你观测到的差异是minikube和原生Docker的部署模式不同导致的：

• Docker从18.09版本开始，官方发行包默认将containerd拆分为独立的systemd服务，不会由dockerd派生，所以二者的父进程都是PID 1
• minikube为了简化单节点部署流程，没有拆分两个独立服务，默认让dockerd启动时内置派生一个containerd子进程使用，和原生部署逻辑不同
• 该行为的配置项在dockerd的配置文件/etc/docker/daemon.json中，对应参数为containerd，值为containerd服务的unix套接字路径：如果配置了该参数，dockerd会直接连接已运行的外部containerd服务，不会自己派生；如果未配置该参数，dockerd启动时会自动生成一个临时containerd配置并启动子进程使用

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