containerd base_runtime_spec

下面给你做一次 **完整、收敛、结构化、专业级别的知识汇总**，把你这两天追问的所有内容（containerd 的 base_runtime_spec、挂载 CA、kube-proxy 启动失败 `/proc/thread-self/fd`、/etc 自动挂载机制、runc 初始化原理……）全部打通成一个体系，同时给出可直接落地的例子与根因剖析。---# 🚀 **一份文档掌握：containerd 全局挂载 CA + kube-proxy 启动失败原因 + /etc 自动挂载原理**---# 目录1. **containerd base_runtime_spec —— 作用、原理与示例**
2. **runc 初始化流程原理（重点：`/proc/thread-self/fd` 为什么必须存在）**
3. **为什么 kube-proxy 启动失败？完整链路分析**
4. **containerd 默认挂载 `/etc/hosts` `/etc/hostname` `/etc/resolv.conf` 的机制**
5. **base_runtime_spec 正确写法 + 错误写法对比**
6. **完整示例：如何全局挂载宿主机 CA**
7. **总结：一个节点上容器创建时实际发生的事情（时序图）**---# 1️⃣ containerd **base_runtime_spec** —— 作用、原理与示例## ✨ **作用**base_runtime_spec = “全局模板 OCI spec”。对所有通过 **Kubernetes / CRI（kubelet）** 创建的容器 **自动附加配置**，包括：* 默认环境变量
* bind mount
* cgroups
* seccomp
* namespace
* default capabilities✔ **这是 containerd 官方推荐的全局默认 spec 扩展方式。**---## ✨ 适用场景| 场景                 | 是否适合用 base_runtime_spec |
| ------------------ | ----------------------- |
| 全节点需要挂载 CA         | ✔ 强烈推荐                  |
| 全节点默认添加 env、ulimit | ✔                       |
| 全局 seccomp 修改      | ✔                       |
| 全局覆盖 /proc、/sys    | ❌ 高危（会导致 kube-proxy 失败） |---## ✨ containerd 1.x / 2.x 的差别（非常重要）| containerd 版本 | config version | CRI 插件路径                                 |
| ------------- | -------------- | ---------------------------------------- |
| 1.x           | version = 2    | `plugins."io.containerd.grpc.v1.cri"`    |
| 2.x           | version = 3    | `plugins."io.containerd.cri.v1.runtime"` |---# 2️⃣ **runc 初始化流程原理剖析**要理解 kube-proxy 为啥报：```
open /proc/thread-self/fd: no such file or directory
```必须理解 **runc 创建容器时到底做了什么**。---## runc 创建容器流程（极精简的核心）1. **准备 OCI spec（由 containerd 传入）**
2. 创建 **namespaces（pid/net/mnt/uts/ipc/user）**
3. 处理 **mounts 列表**
4. 进入 `pivot_root`（如果需要）
5. **初始化 console/stdio → 必须操作 /proc/thread-self/fd**
6. 执行容器进程（如 /pause 或 kube-proxy）---## 为什么必须访问 `/proc/thread-self/fd`？因为 runc 要绑定：* 容器 stdio（stdin/stdout/stderr）
* console socket（terminal = true）
* 额外的 exec fds（containerd-shim 用）Linux 标准流程是：```
/proc/thread-self/fd/X
```对应当前 runc 线程的 fd。➡ 只要**/proc 没正确挂载**，runc 就必定直接失败。---# 3️⃣ kube-proxy 启动失败的根因分析错误：```
open /proc/thread-self/fd: no such file or directory
```最常见根因：---## ❌ **1. base_runtime_spec 覆盖了 /proc**（最常见破坏原因）如果你写了类似：```json
{"destination": "/proc","type": "bind","source": "/proc","options": ["rbind"]
}
```那么：* containerd 还未完成默认 mount
* runc 使用的 /proc thread-self 还没就绪
* 立即失败✔ 这是 containerd 官方文档明确禁止的。---## ❌ **2. DaemonSet 没有 hostPID=true**kube-proxy 使用 hostPID 访问：* 宿主机 /proc/sys/net
* conntrack
* iptables 结构如果 kube-proxy 在自己的 PID namespace：* /proc 中不包含宿主机的内容
* `/proc/thread-self/fd` 不稳定
* runc 初始化容易失败---## ❌ **3. 使用老旧 runc（v1.0.0 边缘版本） + terminal=false bug**这类 runc 在 terminal=false 时，在关闭 fd 期间使用 thread-self/fd，会因为挂载时序导致找不到。---# 4️⃣ containerd 默认挂载 `/etc` 系列的原理你问：> base_runtime_spec 里没有写 /etc/hosts、/etc/resolv.conf，它们如何出现？下面是完整原理。---## 🔧 containerd（CRI）会自动追加 **三个挂载**：| 文件                 | 由谁生成       | 作用                       |
| ------------------ | ---------- | ------------------------ |
| `/etc/hosts`       | kubelet    | 注入 Pod hostname / svc 域名 |
| `/etc/hostname`    | containerd | 用 Pod 名作为 hostname       |
| `/etc/resolv.conf` | kubelet    | 为 Pod 设置集群 DNS           |---## ⚠ 什么时候会被破坏？**只要你把 `/etc` 或子文件覆盖为 RO 或直接 bind mount：**错误示例：```json
{"destination": "/etc","type": "bind","source": "/etc","options": ["bind", "ro"]
}
```➡ kubelete 无法写 `/etc/hosts` → Pod DNS 坏了➡ containerd 无法写 `/etc/hostname`➡ kube-proxy/containerd 无法启动---# 5️⃣ base_runtime_spec 正确写法 vs 错误写法## ✔ 正确挂 CA（推荐）```json
{"destination": "/etc/ssl/host-certs","type": "bind","source": "/etc/ssl/certs","options": ["rbind", "ro", "rprivate"]
}
```不会影响 containerd 默认挂载。---## ❌ 错误：覆盖整个 /etc```json
{"destination": "/etc","type": "bind","source": "/mnt/etc","options": ["rbind", "ro"]
}
```➡ DNS / hostname / hosts 全坏。---## ❌ 错误：挂载 /proc（必定破坏 runc）```json
{"destination": "/proc","type": "bind","source": "/proc","options": ["rbind"]
}
```➡ runc 初始阶段无法访问 thread-self➡ kube-proxy 等关键容器启动失败---# 6️⃣ 完整示例：全局挂宿主机 CA## step1: 生成基础 spec```
ctr oci spec > /etc/containerd/cri-base.json
```---## step2: 加入 CA mount```json
{"destination": "/etc/ssl/host-certs","type": "bind","source": "/etc/ssl/certs","options": ["rbind", "ro", "rprivate"]
}
```---## step3: 在 containerd 配置中启用### containerd 1.x```
version = 2
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]base_runtime_spec = "/etc/containerd/cri-base.json"
```### containerd 2.x```
version = 3
[plugins."io.containerd.cri.v1.runtime".containerd.runtimes.runc]base_runtime_spec = "/etc/containerd/cri-base.json"
```---## step4: 重启 containerd（必须）```
systemctl restart containerd
```---# 7️⃣ 一张时序图：容器创建时到底发生什么？```
Kubelet│├─ 创建 /etc/hosts、/etc/resolv.conf│▼
Containerd(CRI)│├─ 合并 base_runtime_spec + PodSpec → 生成最终 OCI spec│├─ 追加默认挂载（/etc/hosts、/etc/hostname）│▼
runc│├─ 创建 namespace├─ mount rootfs├─ mount /proc├─ mount /sys├─ mount 你的 CA├─ 打开 /proc/thread-self/fd （初始化 stdio）│▼
容器进程启动（pause / kube-proxy / app)
```如果 **任意人破坏了 /proc 挂载流程** → 失败。---# 📌 总结（最精华部分）### ✔ containerd base_runtime_spec 最适合干的是：* 全局挂载 CA
* 全局 env
* 全局 seccomp/capabilities 轻量扩展### ❌ base_runtime_spec 绝对不能做：* 覆盖 /proc
* 覆盖 /sys
* 覆盖 /dev
* 覆盖 /etc（影响 hosts/resolv.conf）
* 绑定需要写入的路径为只读➡ 会导致 runc 初始化失败，报 `/proc/thread-self/fd` 错误。---如果你需要：✔ 我可以帮你补：* 一个“正确规范的 containerd 全局 spec 模板（可直接用）”
* kube-proxy 最推荐的 DaemonSet 配置（hostPID/hostNetwork）
* 一键检测节点是否存在危险性挂载的脚本告诉我你要哪部分，我按“可直接落地”的标准给你输出。

[root@styxtikvk8s01v es-ops]# cat /etc/crictl.yaml
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: false[root@styxtikvk8s01v es-ops]# cat /etc/containerd/cri-base.json 
{"ociVersion": "1.0.2","process": {"terminal": false,"user": {"uid": 0,"gid": 0},"args": ["sh"],"env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","SSL_CERT_DIR=/etc/ssl/host-certs","SSL_CERT_FILE=/etc/ssl/host-certs/ca-certificates.crt"]},"root": {"path": "rootfs","readonly": false},"mounts": [{"destination": "/proc","type": "proc","source": "proc","options": ["nosuid", "noexec", "nodev"]},{"destination": "/sys","type": "bind","source": "/sys","options": ["rbind", "ro", "rprivate"]},{"destination": "/dev","type": "tmpfs","source": "tmpfs","options": ["nosuid", "strictatime", "mode=755", "size=65536k"]},{"destination": "/dev/pts","type": "devpts","source": "devpts","options": ["nosuid", "noexec", "newinstance", "ptmxmode=0666", "mode=0620", "gid=5"]},{"destination": "/dev/shm","type": "tmpfs","source": "shm","options": ["nosuid", "noexec", "nodev", "mode=1777", "size=65536k"]},{"destination": "/etc/ssl/host-certs","type": "bind","source": "/etc/ssl/certs","options": ["rbind", "ro", "rprivate"]}]
}