容器 E05：GPU 设备可见为什么不等于能计算
将注入分解成四个核对点
先记录宿主 GPU 型号/驱动与设备节点，再查看 CDI 描述是否指向实际设备以及需要哪些 mount/env/permissions，运行时是否把这些要求应用到进程，最后运行一个小规模受控功能请求并保存错误/成功。Kubernetes 设备插件宣告的 allocatable 资源也不能代替容器内驱动库可加载证据。正例应在专用 GPU 节点固定驱动、CUDA/runtime/CDI spec 版本，使用同一探针只做设备可见和最小调用；边界案例撤去自建 CDI 描述的一项库挂载或让设备权限拒绝，定位失败层。不可卸载共享节点驱动或抢占他人的 GPU。
设备、驱动与清理表、应用侧探针包仅是素材；本机尚未发现 GPU/运行时、没有执行过设备注入与 CUDA 调用，吞吐、隔离和功能结果全部 `NOT_RUN`。即使能静态解析 CDI 文件，也不能声称 GPU 可用。| 现象 | 核查 | 不可推出 |
|---|---|---|
| 看见设备节点 | 库、驱动与权限 | 计算请求一定成功 |
| CDI 解析通过 | 实际设备与注入后 mount | 节点有 GPU |
| Pod Pending | device plugin allocatable | 是应用内部驱动错误 |
练习
- 预测 CDI 描述可解析但没有物理 GPU 的节点会在哪层失败；在独立 GPU VM 核对声明、实际节点设备与 runtime 返回。
- 预测驱动和用户态库版本不匹配时设备可见与计算结果的区别，固定版本做小负载，不编造性能数据。
先修：17：运行时、27：节点资源。下一篇：E06：Wasm/WASI。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-01
容器 38：重启了，业务真的恢复了吗
37建立了正常请求链路；故障实验只问这一条链断在何处、多久恢复、有没有损坏或丢失状态。容器重启、Pod 重建和节点恢复不是同一个操作；Pod 出现 Ready 也不等于所有请求成功、数据校验通过。 先界定故障注入范围 仅在专用 kind 集群和自建 namespace 中注入四类故障：单容器内存上限的有界申请、明确终止自建容器进程、只阻断实验 Pod 之间的网络、停掉专门提供的测试节点。每次保留注入前的基线：镜像 digest、Pod UID、容器 ID、PID、网络路径、state 文本哈希与固定负载；注入后记录每次请求开始/结束、HTTP 状态/超时、相应事件及新的对象 ID。先定义恢复为“连续指定次数业务请求成功，且状态校验一致”，再测从第一条失败请求到恢复的时间。节点测试需有宿主控制台/VM 恢复路径，不能停止共享宿主上的 kubelet、daemon 或默认网络。 正常恢复例是一个受控容器被终止后由节点重新启动，新 PID 取得原有卷并在约定窗口内重新响应；边界例是 readiness 重新变绿，但自有测试卷上的状态未满足应用数据条件，因而不能称为完整恢复。内存事件还要...
2026-10-01
容器 36：同一 digest 怎样交付并安全回退
33 的制品身份和28 的就绪状态属于交付的两个不同条件。单机 Compose 和 Kubernetes 可以消费同一镜像 digest，但不会因此拥有相同的网络、卷、策略或回退语义。应以实际 digest 为连接点，再记录各自的声明配置与请求结果。 固定制品，不固定假设 附件中的 `compose.yaml` 要求 `PROBE_IMAGE` 是实际 `repo@sha256:...`，把仅属于实验的 volume 挂到探针 state-dir，限制发布端口为本机 loopback；Kubernetes 则需在专用集群部署同 digest 的 Deployment/Service，并明确 storage/NetworkPolicy 和探针版本。运行两侧 `/identity` 与 `/state`，可追踪到真正服务该请求的 Pod UID/容器 ID/PID，而不只是 YAML 的 image 字段。 正例先部署已验证版本，记录 digest、配置和合成状态文本，再将应用或配置换成已知坏版本，在专用环境观测失败并按明确回退动作恢复旧 digest 与请求；负例是回退了容器镜像但...
2026-06-20
控制器模式与 Informer 机制：调谐循环的工程实现
Kubernetes 的控制平面由一批控制器组成，每个控制器负责把某种资源的实际状态收敛到期望状态。Deployment 控制器确保 ReplicaSet 数量正确，ReplicaSet 控制器确保 Pod 数量正确，StatefulSet 控制器维护有序 Pod 的标识和存储绑定。这些控制器全部运行在 kube-controller-manager 进程中，共享同一个 Go runtime，但逻辑上彼此独立。 控制器的核心模式是调谐循环（Reconcile Loop）：读取资源当前状态，与期望状态对比，对差异执行操作，然后等待下一次触发。这个循环不是基于轮询的——每隔几秒查一次 etcd 的方式在规模上不可持续。实际实现依赖 Informer 机制：Informer 在本地维护一份与 etcd 同步的缓存，用 Watch 接收增量变更，把变更转换成事件分发给控制器。控制器从工作队列取出事件，执行 Reconcile，写回 API Server。 这篇的核心问题是：从 etcd 的一次写入，到控制器的一次 Reconcile 调用，中间经历了哪些层次，每层解决什么问题？ Info...
2026-06-20
kubelet 与容器运行时：节点上到底发生了什么
前两篇讲了调度（选节点）和 Pod 生命周期（状态机）。这一篇下到节点层：kubelet 在节点上把一个 Pod spec 变成真实运行的进程。 容器运行时曾经等于 Docker。Kubernetes 1.24 移除了 dockershim，此后所有节点必须使用实现了 CRI（Container Runtime Interface）的运行时：containerd、CRI-O 或其他。这次迁移对用户基本无感，但原理上有重要变化——kubelet 和运行时之间的通信从内嵌的特定实现变成了标准 gRPC 接口。 本文只问一个问题：从 pod.spec.nodeName 被写入，到容器进程在节点上跑起来，发生了什么？ 节点内部全景图 123456789101112131415161718192021222324API Server → etcd (Pod.spec.nodeName = this-node) │ ▼kubelet (watches own node's Pods via Informer)┌───────────────────────────...
2026-10-01
容器 08：namespace 之外还需要什么权限边界
05 的 UID 映射说明谁拥有某个身份，06说明资源预算。但“内部是 root、有独立 hostname”不等于可信边界：进程发起系统调用时仍会进入宿主内核。允许执行什么操作，还要逐项解释 capability、seccomp、`no_new_privs` 与实际启用的 LSM。 把拒绝归还给负责的层 capability 将特权操作拆成较细粒度的授权，内核权限检查会结合针对的 user namespace。CAP_SYS_ADMIN 在新 user namespace 中的有效位不等于初始 namespace 的万能通行证，挂载还受文件系统与上层策略约束。seccomp BPF 按系统调用及可检查参数限制调用面，不识别“这个路径属于秘密”这样的完整安全语义；内核文档明确说过滤器本身不是 sandbox。no_new_privs 禁止 exec 后取得比此前更多的特权，不能据此说所有操作都会拒绝。SELinux、AppArmor 等 LSM 是否启用、具体 profile 如何拒绝，要按专用 VM 的配置和审计日志核查，不能套用另一台机器的默认值。 从系统调用走到目标对象 进程...
2026-10-01
容器 00：运行中的容器究竟是哪一个进程
同一份应用文件在本机运行时只是进程；打包为镜像之后也不会自动变为“正在运行的容器”。要解释一次请求为什么失败，先区分磁盘上的制品、运行时创建的对象、内核里的进程和应用的就绪状态。这四者不处在同一层；把它们都叫“容器”会使故障归因失去落点。 从制品到请求 OCI Image Specification 约定索引、描述符、配置和层等制品表示；Runtime Specification 约定 bundle 配置与执行环境。镜像的摘要标识内容，不是 PID；bundle 描述将要执行的命令与隔离、挂载等参数，不是已经建立的内核对象。运行时准备根文件系统、进程配置，创建或加入 namespace、应用资源及权限约束，最后让内核执行程序。一个处于不同 namespace 的 Linux 进程仍与同机进程共享一个内核；VM 内的 Linux 容器共享 VM 的内核，而非桌面宿主内核。 实际排查时需要沿对象逐一核验：镜像引用解析到哪个 digest；运行时对象的 ID 是什么；运行程序在宿主侧 PID 是什么；/proc/<pid>/ns/* 指向哪些 inode；/proc/<...