容器 E04：Windows 容器不能照搬 Linux namespace 模型
两种隔离与一个版本矩阵
微软官方资料区分 Windows Server containers 的进程隔离，以及借助 Hyper-V 实现的隔离模式。进程隔离复用兼容的主机内核，Hyper-V 模式引入独立的虚拟化边界；宿主/基础镜像版本兼容、镜像架构和运行时支持需要按官方矩阵与真实系统确认。网络驱动、卷和账号语义也不能从 Linux 名称直接套用。
正例要在专用 Windows VM 固定主机与基础镜像版本，运行相同 HTTP 功能的 Windows 构建探针，分别记下隔离模式、进程/VM 状态与请求结果；反例强制不兼容镜像/宿主组合，保存构建与启动错误，不能把 Windows VM 内 Linux 进程的成功冒充 Windows 容器实测。版本表和补跑入口与同功能 Linux 侧源码说明差异。本云端只有 Linux、没有 Windows VM，Windows 编译/运行/兼容全部 NOT_RUN；官方资料只支持边界分析。
| 现象 | 查什么 | 不能推断 |
|---|---|---|
| 同一应用跨 OS | 镜像平台与 ABI | 同一镜像字节可直接跑 |
| Hyper-V 隔离 | guest/宿主版本 | Linux namespaces 已启用 |
| 镜像拒绝启动 | 版本配对与隔离模式 | 一定是网络问题 |
练习
- 先预测相同 tag 下
os=linux与os=windows的制品能否交换运行，再核对 image index 与节点系统。 - 在专用 Windows VM 分别预测两种隔离模式对主机/基础镜像版本要求的差异，按所选组合记录成功与错误，而非从 Linux
uname推断。
先修：00：进程与 VM、15：多平台。下一篇：E05：GPU/CDI。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-06-20
生产集群运维——升级、备份、故障排查与容量规划
把 Kubernetes 集群跑起来是第一步，让它在生产环境中长期稳定运行才是真正的挑战。版本升级、etcd 备份恢复、节点维护、故障排查、容量规划——这些 Day-2 运维场景，每一个都有足以让集群中断服务的操作风险。Kubernetes 为这些场景提供了明确的工具和流程约定，但操作顺序和细节上的失误仍然是生产事故的主要来源。 版本升级是最高风险的操作之一。Kubernetes 的 API 在版本间存在兼容性约束（skew policy），错误的升级顺序——例如先升级 kubelet 而非先升级 control plane——会导致集群进入不一致状态，轻则调度异常，重则 API Server 无法与节点通信。etcd 备份看似简单，但备份时机（必须在升级前）、恢复流程（必须停止 API Server 再恢复）、验证方式（恢复后检查关键对象）如果有任何一步出错，都可能导致数据丢失或集群无法启动。 节点维护（drain + upgrade + uncordon）有 PodDisruptionBudget（PDB）这道安全网，但前提是 PDB 本身配置正确。容量规划需要理解"...
2026-10-01
容器 26：Pod 到达节点后变成哪些对象
Pod 对象已分配给节点之后，如何找到真正处理请求的宿主进程？把17 的 OCI runtime、18 的任务和24 的插件网络连接起来，比重新罗列 Kubernetes 对象名更有用。已有Kubernetes 核心概念是词汇入口，这一篇只追踪节点上从声明到执行的对象关系。 一条可核查的身份链 kubelet 观察已分配到本节点的 Pod，通过 CRI 与节点上的容器运行时交互；CRI 对 sandbox 和容器的生命周期建模，不是 OCI 的 create/start 原样 RPC，也不是 CNI 的网络设备实现。具体 runtime 为 Pod sandbox 准备网络等环境，创建应用容器，向更低层传入符合本机实现的执行配置。每一步要记录 Pod UID、sandbox ID、容器 ID、宿主 PID，再读该 PID 的 namespace inode 和 cgroup 路径；containerd 的 namespace 与 Kubernetes Namespace 不能替代这条身份链。Pod 名称可被重建而复用，不能只靠显示名称关联旧进程。 正常案例应在专用 kind VM...
2026-10-01
容器 02：namespace 改变的是哪些资源视图
在一个终端里改了主机名，另一个终端为什么没变？关键不是 shell 的变量，而是两个进程引用的 UTS namespace 不同。沿01 的进程生命周期继续，把隔离看成“进程持有哪些内核对象”，而不是把容器想象成一台小型物理机。 比较视图，不比较字符串 clone 可让新进程进入新建的 namespace；unshare 使调用者与先前共享的指定 namespace 分离；setns 把调用者加入已有 namespace，但有具体的权限、类型和多线程前提。UTS 隔离 hostname 与 domainname，IPC 隔离相应的进程间通信对象；PID、mount、net 与 user 各有自己的资源集合。/proc/<pid>/ns/<type> 的链接目标包含可比对的 namespace inode。两个进程具有相同 UTS inode，表示指向同一 UTS namespace；两个进程恰好都输出 hostname=demo，却可能在不同 UTS 对象里。不能跨类型比较数字本身。 普通读者并不必在宿主得到所有 capability。unshare -U...
2026-10-01
容器 E05：GPU 设备可见为什么不等于能计算
08 的设备权限只是前提：GPU 工作还依赖真实设备、宿主驱动、用户空间库、设备节点与 runtime 注入路径。CDI（Container Device Interface）提供描述第三方设备怎样被运行时注入的接口；一个 CDI 名称或 Pod 请求字段存在，不证明容器已获得可用的驱动堆栈。 将注入分解成四个核对点 先记录宿主 GPU 型号/驱动与设备节点，再查看 CDI 描述是否指向实际设备以及需要哪些 mount/env/permissions，运行时是否把这些要求应用到进程，最后运行一个小规模受控功能请求并保存错误/成功。Kubernetes 设备插件宣告的 allocatable 资源也不能代替容器内驱动库可加载证据。正例应在专用 GPU 节点固定驱动、CUDA/runtime/CDI spec 版本，使用同一探针只做设备可见和最小调用；边界案例撤去自建 CDI 描述的一项库挂载或让设备权限拒绝，定位失败层。不可卸载共享节点驱动或抢占他人的 GPU。 设备、驱动与清理表、应用侧探针包仅是素材；本机尚未发现 GPU/运行时、没有执行过设备注入与 CUDA 调用，吞吐、隔离...
2026-10-01
容器 10：OCI 镜像到底保存了什么
09已经能让自编探针作为进程退出，但无法用一个可分发制品重建其根文件系统。OCI 镜像表示的是若干内容寻址的字节和元数据，而非正在运行的进程。以这一区别为出发点读 `index.json`，比背一串 Docker 命令更容易定位“拿到的是哪个制品”。 从索引走到字节 本地 OCI image layout 的入口是 oci-layout 与 index.json。索引中的 descriptor 用 media type、digest、size 指向 manifest，可能列有平台信息；manifest 再指向 image config 与一组层。config 描述操作系统、架构、根文件系统的 diff_ids 及进程默认参数等；层可以是 tar gzip 的变更集。给定 sha256:<hex>，实际 blob 路径是 blobs/sha256/<hex>，应以文件真实字节核验 digest 和 size，不能只看 JSON 里字符串长得像摘要。 一个特别容易混淆的点是压缩层 descriptor 的 digest 与 config 中 DiffID：前者...
2026-10-01
容器 09：组合隔离机制时启动和清理的顺序
前八篇分别讨论进程、namespace、身份、资源和权限。如果只把它们列在命令行上，很容易遗漏“父进程何时写映射”“谁等待子进程”“初始化失败后对象如何退出”。这篇用一个受限教学启动器展示顺序，并明确它没有实现的隔离，避免误当成生产容器。 一个可核查的局部链路 源码共用源码包内的 teaching_launcher.c 固定执行同目录内自编译的 process_probe，没有接受用户指定的命令行、镜像或任意路径。启动器记录外侧 UID/GID，先 unshare(CLONE_NEWUSER)，将内部 UID/GID 0 映射到原外侧身份；在写 GID 映射之前向 setgroups 写 deny。随后建立新的 UTS、IPC namespace，在私有 UTS 中设置测试 hostname。fork 后只有子进程 exec 自编程序，父进程 waitpid 并返回子进程状态。设置顺序的核心是写映射时“当前进程处于哪个 namespace”，而不是把一串 unshare 选项当成 magic flag。 从当前源码画出真实的控制流 第一步在外侧读取实际 UID/GID；这两个数字...