容器 E02：checkpoint 和 restore 能保存哪些进程状态
保存对象必须与外部世界对齐
一个进程的内存映射、寄存器、打开 FD、namespace 关系和网络连接可能都参与恢复；磁盘卷的内容、对端 TCP 状态、文件路径与宿主内核功能却未必随检查点一起搬迁。因此先固定 kernel/CRIU 版本、进程树、挂载和网络，记录快照时刻的业务状态。恢复时检查 PID 对照、应用计数、FD 指向的文件和 /ready，不是仅看 CRIU 返回 0。
正常实验在专用 VM 中对自编简单循环进程做 checkpoint/restore，比较恢复前后的进度；边界例增加打开的自有文件或连接到自建 HTTP 端点，记录不支持的对象和精确失败条件，避免把尝试失败硬写为“透明迁移”。恢复前提和清理入口、自编探针源码可独立取得。本云端未安装 CRIU、无恢复环境，正反案例和跨主机迁移全部 NOT_RUN。
| 现象 | 查什么 | 不可推出 |
|---|---|---|
| 恢复命令成功 | 进度/FD/请求及数据 | 原 TCP 对端也恢复 |
| FD 恢复失败 | 路径、权限与挂载 | checkpoint 文件坏 |
| PID 数字改变 | namespace 和进程关系 | 业务状态必丢 |
练习
- 先预测简单计数进程与持有网络连接的进程恢复条件有什么不同，在专用 VM 分两轮实测并保存错误信息。
- 预测只拷贝 checkpoint 文件、不搬移卷中状态会产生什么后果，比较恢复后文件内容与应用状态。
先修：16：数据写入、21：停止。下一篇：E03：事件归属。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-06-20
调度器深入：打分、抢占与拓扑约束
调度器（kube-scheduler）是 Kubernetes 控制平面里最容易被低估的组件。它做的事情看起来简单：把没有 nodeName 的 Pod 绑定到某个节点。但"选哪个节点"这个问题背后，隐藏着资源感知、亲和性约束、拓扑分散、优先级抢占等多维度的决策过程。 从 Kubernetes 1.19 起，调度器的内部逻辑通过 Scheduling Framework 对外暴露为一组扩展点。原来散落在代码各处的调度逻辑被重新组织成插件，每个插件只负责一个扩展点。这让调度行为既可预测，又可扩展。 本文的核心问题是：Kubernetes 调度器用什么框架选节点，当资源不足时如何通过抢占让高优先级 Pod 运行？ 调度框架全景图 1234567891011121314151617181920212223242526Pod pending (no nodeName) │ ▼ Scheduler（from ActiveQ by priority） ┌──────────────────────────────────────────────────...
2026-10-01
容器 04：换了根目录，为什么仍能看到旧文件
/ 是进程解析路径的起点，不是磁盘的物理边界。仅改变根目录无法证明进程已失去对旧文件系统的引用；父进程打开的文件描述符、当前工作目录和挂载传播均可能影响结果。此前02只改变 UTS/IPC 视图，这一篇把根、挂载树与已打开 FD 分开。 三种不同操作 mount namespace 让进程拥有自己的挂载点集合；新建它时通常复制原先的挂载列表，不能说新 namespace 自动生成了全新的文件系统。挂载传播定义一侧后续挂载事件是否能影响另一侧，因此先检查 /proc/self/mountinfo 的 shared/private 信息，再只在专用私有挂载树做写入实验。chroot 主要改变调用者的根目录路径解析起点；已经打开的旧根 FD 不会因此自动关闭，也不能把它当成安全沙箱。pivot_root 移动根挂载并把旧根移到 put_old，需要符合 mount point 和传播约束；切换之后还要决定何时卸载旧根，清理所有仍引用旧树的 FD。 路径、挂载和文件描述符不是同一个东西 调用 open("/etc/issue") 时，绝对路径从调用进程的 root 起...
2026-10-01
容器 05：容器里的 root 究竟是谁
程序在内部打印 uid=0，并不意味着它在宿主初始 user namespace 中获得了宿主 root 的身份。前提是内核如何把内部 UID/GID 映射到外侧身份，目录所有权从哪一个 user namespace 解释，以及该操作的权限检查针对哪个对象。先把04 的路径/挂载视图与身份映射分开；rootfs 的路径变化不能自动改变用户映射。 UID 是映射关系，不是全局标签 /proc/<pid>/uid_map 的每行含“内部起始 UID、外部起始 UID、数量”，gid_map 同理。进入新的 user namespace 后，内部 root 可以对应外侧非特权 UID，具体权限由映射、文件系统、被检查的 namespace 及内核能力决定；映射不意味着访问所有外侧 root 拥有的目录。写 gid_map 通常还涉及 /proc/.../setgroups 的限制，不能盲目照搬 uid_map 的写法。把进程设为容器内普通 USER 与以非特权身份运行 daemon 并使用 user namespace（rootless）是两个不同维度。 读映射时...
2026-10-01
容器 21：停止、重启和日志分别由谁负责
03解释了 PID 1 的信号与回收，18区分 task 与 content。现在讨论停止与恢复：`stop` 是请求进程退出的流程，`restart` 是另一次启动动作，日志是 FD 输出经采集路径形成的证据；三个动作不自动互相保证。 时间窗口需要观测 通常运行时先发终止信号，留宽限期等待程序自己处理、回收子进程并结束；超时后可强制终止。应用若安装 handler 却不结束在途请求，或 shell 没有转发信号，即使运行时遵守流程也可能直到超时。比较宽限期要保存发送时刻、程序收到的事件、最后一条业务响应、实际退出原因，单看 shell 的 137 不能推出是超时强制杀还是内存 OOM。 日志链也有不同持有者：程序写 stdout/stderr FD、shim/daemon 依配置收集、日志驱动再存储或转发。程序未 flush 缓冲、进程强制终止或采集器重启都可能造成末尾日志缺口；不能以运行时提示“容器 restarted”证明请求、日志和写盘数据已经恢复。daemon 的重启行为依运行时、shim、配置及版本而异，必须在专用实验 daemon 里验证，禁止重启共享宿主服务。 正...
2026-10-01
容器 18：containerd 管的是镜像、任务还是进程
17 的 OCI runtime关注单个 bundle 的 create/start/delete；更上一层还要保存镜像内容、展开快照、管理任务生命周期。containerd 的 content store、snapshotter、container metadata、task 和 shim 并不是五个同义词。它们各自关联不同对象，故一个动作“删镜像”与“停 task”不应被写成相同效果。 内容引用与进程引用分开 按 containerd 的 Runtime V2 文档，运行时 shim 承担与任务相关的运行时集成，OCI runtime 可用于创建实际进程。content store 保存内容寻址的字节；snapshotter 为运行准备文件系统视图；task 对应运行中的进程生命周期。containerd 的 namespace 是其 API/元数据隔离维度，不能拿它代替 Linux namespace inode，更不能把它当 Kubernetes Namespace 的定义。一个镜像引用可以消失而正在运行的进程仍存在；停止任务也不会自动清空 registry 的原始镜像。...
2026-10-01
容器 19：一次 run 在哪一步变成 exec
“docker run 成功了”最多说明某条客户端请求获得了响应，不保证 probe-app 能够接收真实业务请求。先把13 的镜像制品、18 的 content/task和17 的 create/start沿时间摆成一条链，再讨论不同故障落在哪一层。 一次请求的可能路径 用户端请求 daemon 创建或启动容器；daemon 对镜像引用做解析或拉取，准备快照与运行配置；下游运行时创建对应 Linux 进程并执行入口。是否通过 containerd、shim、哪一种 OCI runtime 由本机版本与配置决定，不能给出未经版本验证的唯一函数调用栈。进程 exec 成功之后，应用还可能解析参数失败、只监听 loopback 或尚未就绪。把“客户端返回”、“daemon 对象创建”、“宿主进程执行”、“HTTP /ready=200”各自作为检查点，才能说清哪个阶段失败。 正常案例要求同一次构建的 image digest 贯穿 docker inspect、runtime ID、宿主 PID、namespace inode 和请求日志，按时间排序保存不同组件的...