容器 E07：镜像按需读取是否真的缩短首个请求
两类成本都算入请求链
固定一个支持按需读取的 snapshotter 与镜像格式，记录启动前实际传输字节、读取文件时额外传输字节、首个请求的耗时、后续请求命中缓存情况。stargz-snapshotter 文档描述了远程按需读取与 eStargz 相关机制；具体实现是否选用了该插件、如何缓存，以及失败后如何回退，必须按实际节点版本和源码路径核对。正例预先设计“启动后只访问镜像中少数文件”的探针；边界例第一次访问未预取的大文件或在受控实验网络中断开远端，可能使首请求变慢/失败。断网仅作用于独立 VM 内的自建网络。
实验矩阵与恢复、统一探针源码允许对照常规 snapshotter；云端没有 containerd/snapshotter、没有真正的镜像按需网络路径，下载字节、缺页、首请求数据一律 `NOT_RUN`。不能把 10 的本地 OCI 布局静态校验替代远程读取实验。| 现象 | 要保存 | 判断边界 |
|---|---|---|
| create 更快 | 进程首响应与传输字节 | 首请求未必更快 |
| 第二轮更快 | 缓存/远端状态 | 不推广冷启动 |
| 断网失败 | 访问文件与对象位置 | 不是必然镜像已损坏 |
练习
- 预测只访问少数文件与首次访问一个大文件，两种工作负载对按需读取收益有什么差异，重复运行并报原始下载字节和失败数。
- 预测缓存热时断开自建远端 registry 会否影响后续请求，先界定哪些字节已经在本地，再记录请求与清理。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-01
容器 35：性能差异来自隔离层还是实验条件
“容器性能损耗多少”缺少测量对象和实验条件。应用计算、内存申请、文件系统 copy-up、网络封装都在不同路径上。34只评估启动，不把 steady-state 性能一起平均。本篇先设定可以证伪的对照，再决定哪些数字能归因于容器边界。 逐项只改变一个条件 同一内核、架构、节点、二进制和输入，先在普通进程跑 bounded_load 的有界计算/内存路径，再在专用容器内跑同样命令；分别记录用户态时间、CPU/内存控制器、可运行 CPU 集与真实的 cgroup 限制。文件系统实验区分宿主相同盘的普通写入、容器可写层首次写入与同一镜像的重复写入；网络实验区分 loopback、veth、bridge 与跨主机封装，应用请求也要用相同连接/大小分布。每组预设预热、次数、并发、成功与失败计数，报告吞吐与分位数及原始数据，不可只挑最快一轮。 失败或反例是把一个组放在远端存储、另一个组放在本地盘，却将延迟差归因于 OverlayFS；或让一组命中页缓存、另一组做冷读取，还声称 cgroup 导致 I/O 变慢。必须逐项记录存储设备、缓存条件、CPU 亲和性、流量路径、镜像 digest 和安...
2026-10-01
容器 34：冷启动时间花在哪一段
拿一条从 docker run 到终端提示的总耗时，无法推断是拉取慢、快照准备慢、进程启动慢还是应用就绪慢。先定义测量的边界与可关联的对象，然后谈数值。 先写实验设计，后写结论 同一 probe-app 固定 image digest、节点 CPU 架构、内核与运行时版本，在专用 VM 上分冷缓存与热缓存两组。时间戳分别落在开始拉取、manifest/layer 验证结束、本机解包与 snapshot 准备结束、OCI create/start、进程首条日志、/ready=200。对同一 ID 记录事件时钟来源，跨组件不能把不同机器的墙钟未经校准就做相减。预先确定预热次数、重复次数、并发、输入大小和失败率，报告每段延迟分布而不是一次的总值；把镜像缓存和应用缓存状态同时记录。 边界例是第二轮 pull 因内容已在本地而很快，服务却因独立的就绪延迟仍返回 503。把这两段之和直接叫“镜像启动慢”会误判优化目标。一次用户请求成功还可能发生在 ready 之前或之后，需用相同 readiness 条件比较。实验变量表和有界探针保证输入一致；本机无构建器、运行时或集群，所有时间分段、重复数...
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-06-20
性能模型：吞吐、延迟与调优思路
前面的文章覆盖了 Kafka 的核心机制和生态组件。这一篇回到工程视角：Kafka 的性能模型到底长什么样。 性能调优容易变成一张参数清单。更有效的方式是先建立一个吞吐-延迟的基本模型，再用这个模型解释每个参数的作用方向和代价。 本文只抓一个问题：Kafka 的吞吐和延迟分别由哪些因素决定，调节一个参数时另一端会发生什么变化。 性能基础：四个底层机制 Kafka 的高吞吐不是来自某个单一优化，而是四个机制叠加的结果。 1234567891011Producer Broker Consumer | | | |-- batch N records ---->| | | (linger.ms window) |-- sequential append --> | | | (page cach...
2026-06-20
Ingress 与 Gateway API：七层流量的入口演进
Service 把集群内部的流量调度问题解决了，但把服务暴露到集群外部的 HTTP/HTTPS 流量需要另一层抽象。NodePort 和 LoadBalancer 都在四层工作——它们能把外部 TCP 流量转发进来，但无法根据 HTTP 的 Host 头或 URL 路径做路由决策，也无法终止 TLS、做 URL 重写、实现金丝雀发布。Ingress 就是 Kubernetes 为七层 HTTP 路由设计的原生对象，它在 1.1 版本进入 alpha，1.19 版本 GA，至今仍是绝大多数集群的 HTTP 入口方案。 Ingress 的设计在简单场景里非常直观：声明哪个 host + 哪个路径对应哪个 Service，TLS 证书放在 Secret 里引用，一个 Controller（Nginx、Traefik、HAProxy 等）负责把这些规则翻译成实际的反向代理配置。这套模型在业务不复杂时运作良好，但当需要金丝雀发布、基于请求头的路由、跨命名空间的服务暴露、gRPC 原生路由时，规范本身的表达能力不够，各家 Controller 用 annotation 扩展——结果是注解的命...
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 调用，吞吐、隔离...