容器 39：CPU weight 在竞争下是否才起作用
独立研究要回答一个可以被实际结果推翻的问题，而不是重新打包35 的性能清单。选用 Linux kernel cgroup v2 官方技术文档中 cpu.weight 的语义作原始来源，提出命题：同一父 cgroup 的两个有界计算负载同时争用相同 CPU 集时，改变其相对 weight 会影响所得 CPU 时间份额；若只有一个任务运行且 CPU 足够空闲，改变 weight 不应当被写成“硬配额”。
将文档语义变成可证伪实验
实验前固定专用 Linux VM、内核/cgroup v2 版本、物理或虚拟 CPU 数、cpuset、频率与可用邻居负载，两个探针用同一 bounded_load.py 代码但以较长的有界窗口重复。各组预设至少十次，交叉调换两个子 cgroup 的 weight 与运行顺序，保存 cpu.stat、调度相关计数、每次工作量、总耗时和错误数；以相同父组和相同配额条件比较。另运行“只有一个子组工作”的反例组，排除把权重理解成任何时候都有的硬限速。若 CPU 饱和条件不成立，即使观察不到差异也不能归因于权重规则失效。
实际文件写入只允许在专用 VM 管理员委派的子树，任务每轮有最长时限；退出后确认自建 cgroup 无进程并删除。研究设计、原始表格字段与清理及统一负载源码是研究材料。当前云端是 cgroup v1 只读，实验 NOT_RUN，没有基线数据、重复运行、统计分布或反例结果，故这篇仍是未完成的研究稿件，不能称为“成功复现”。将来的最终结论必须引用原始输出、失败轮次和 VM 环境，而非这里的预测。
| 条件 | 想比较什么 | 如果结果相反先查什么 |
|---|---|---|
| 两组同核竞争 | CPU 时间份额比 | cpuset、额外负载、父组委派 |
| 单组运行 | weight 是否是硬上限 | 是否另有 cpu.max |
| 顺序交换 | 位置/缓存偏差 | 计数窗口与任务身份 |
练习
- 先预测两组 weight 为 100 与 200 且同时饱和时资源份额的定性关系；在独立 VM 用原始计数跨十次检验，而不写死吞吐百分比。
- 预测只有一组运行时把 weight 减半能否令它同样变慢；做负面组实验，再用
cpu.max限额的对照解释两个机制。
上一篇：38：故障恢复；系列主线结束后，选修主题用于说明何时需要不同的隔离或执行模型。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-01
容器 31：指标如何归属到一次真实请求
监控面板中一条“容器 CPU 高”曲线，只要没绑定到同一个26 的 Pod UID/容器 ID/PID，就未必能解释这一次 /ready 延迟。最小可迁移做法是从业务请求返回时间追到当时进程，再读该进程所属 cgroup 的 CPU、内存和 I/O 计数器，而不是把不同采样窗口的曲线拼在一起。 建立时间和身份的双重坐标 固定一份 bounded_load 的输入规模、持续时间与并发，在请求侧保留开始/结束时间、HTTP 状态与总耗时；在应用侧保留日志、PID 和真实服务延迟；在节点侧同一时间窗读取 cpu.stat、memory.events、io.stat 与压力指标。Counter 必须算增量，采样间隔、是否包含子 cgroup、任务迁移时的身份更换都要标记。cpu.stat 的节流增量能证明指定 cgroup 发生节流，但还需排除应用排队、网络超时与缓存变化才可把某次慢请求归因于 CPU。 正例应让两个有界负载中只有一个在限额组里，通过 UID→容器 ID→PID→cgroup 关联请求与计数；反例在进程退出重建后只沿旧 PID 读取计数，可能把完全不相...
2026-10-01
容器 27：requests 与 limits 怎样走到节点的 cgroup
26 的 Pod UID告诉我们去哪儿找宿主进程；06和07告诉我们实际限制要到内核层核验。Kubernetes 的 requests 用于资源预留/调度和相应资源权重，limits 则用于节点限制机制；节点是否接受某 Pod、容器会否 CPU 节流、谁因内存不足被杀、Pod 会否被驱逐，是四类不同事件。 不要把所有失败叫 OOM 调度阶段因资源 requests 不满足而 Pending，没有理由从宿主寻找已运行进程的 cpu.stat。容器已启动后超过 CPU limit，可在所选 cgroup 的 cpu.stat 观察节流增量，应用仍可能继续运行；达到 memory limit 可能发生组内内存事件与进程终止，要对照 memory.events、container status 和相应节点事件；节点整体内存/磁盘压力下的 eviction 又由 kubelet 决策，不等于同一个 memory.max 触发点。不同 Kubernetes 与 cgroup 版本的 QoS、CPU weight、OOM 和驱逐细节有版本前提，不能机械套一个表格。 专用 kind 节点正例用两...
2026-10-01
容器 06：CPU 配额与竞争权重为什么不同
05 的身份映射不会阻止一个进程消耗 CPU。隔离“看见什么”、规定“谁是谁”和限制“能用多少”是三个独立问题。cgroup v2 的层级与控制器负责第三个问题；套用 v2 的文件名到本机的 v1 只读层级，会得到看似合理但根本没生效的配置。 带宽、竞争与亲和性 cpu.max 是带宽额度和周期：例如在支持该接口的 cgroup 中写 50000 100000 表示每 100000 微秒最多使用 50000 微秒配额，具体跨多个 CPU 的行为还要看周期和并发。达到额度会节流，读取 cpu.stat 的 nr_throttled、throttled_usec 观察变化；延迟增加却不一定是因为节流，还可能是排队、存储或网络。cpu.weight 是父层级内的相对权重，主要在同一竞争条件下分配份额，空闲时并不等于硬上限。cpuset.cpus.effective 表示可运行 CPU 集，CPU 集缩小不等于改变权重；还需比较宿主拓扑与亲和性。 控制器的可见性与委派也有层级条件。只有父层启用对应的 cgroup.subtree_control、将可写子层委派给实验用户并满足内核规则，才...
2026-10-01
容器 07：内存超限与 I/O 变慢不是一种失败
06已经区分 CPU 带宽与相对竞争。内存、进程数量和块设备 I/O 也通过不同控制器暴露各自的失败证据；把“容器慢/死了”统一解释为 OOM，会错过问题所在。 内存约束不是单个数字 cgroup v2 中 memory.current 提供当前使用量，memory.max 为硬上限，memory.high 引导回收与节流；memory.events 的 high、max、oom、oom_kill 记录不同事件。超过 memory.high 不意味着立即杀进程；达到 memory.max 也不能不看回收成败就声称发生了 OOM kill。计数器是累积的，需比较实验前后，记录关联进程和层级。先在专用 VM 给单一小组设置有界内存与申请上限，绝不在共享宿主引发全局压力；每轮记录进程退出状态、memory.events、memory.current 和 dmesg 是否有权限取得相应事件。 pids.max 限制组内任务数量，达到时新的 fork 可以失败，并非旧进程自动被终止。io.max 规定特定设备的 BPS/IOPS 上限，需要先确认设备号、后端以及页缓存是否掩盖了真实块 I/...
2026-06-20
Helm 与应用打包——从 YAML 到可复用制品
在 Kubernetes 上部署一个生产级应用，往往需要几十个甚至上百个 YAML 文件：Deployment、Service、ConfigMap、Ingress、RBAC 规则、HorizontalPodAutoscaler……这些文件之间存在依赖关系，不同环境（开发、预发、生产）需要不同参数，手工管理极易出错。Helm 正是为了解决这个问题而生：把一组相关的 Kubernetes 资源打包成一个可版本化、可参数化、可共享的制品（Chart），并提供安装、升级、回滚、卸载的生命周期管理。 Helm 的本质是"带版本历史的 YAML 打包器"。它不追踪资源的真实运行状态（那是 Operator 的职责），只记录"这次 install/upgrade 渲染出了哪些 manifest，交给 Kubernetes 执行"。Release 状态存储在集群内的 Secret 对象中（key 为 helm.sh/release.v1），每次升级都新增一个版本，rollback 本质上是重新 apply 旧版本的 manifest 集合。 理解 Helm...
2026-10-01
容器 32：从错误症状回到失败层
启动失败的提示往往出现在最高一层：CLI、Pod condition 或 HTTP 超时。修复需要逆向定位首个出错环节。沿10 的 digest、17 的 bundle、24 的网络对象与28 的就绪状态逐层判断，先记录假设，再以明确证据排除。 四种会混成一个“起不来”的情况 第一，镜像无法解析或 layer blob 缺失：还没有完整根文件，查看拉取响应与 digest。第二，平台不匹配：索引没该平台或启动可执行文件时产生架构错误，核对节点架构与目标文件格式。第三，运行时配置或挂载权限被拒：先找 OCI bundle/config、宿主权限与 errno，不能怪应用网络。第四，进程已经运行但监听 127.0.0.1、readiness 返回 503 或 Service 后端未更新：先比较 PID、目标地址、探针与真实请求。每类都要设计一条可被反例推翻的排除证据，不能只列故障关键词。 在专用实验 VM 以相同 probe-app 分别制造四类受控故障：错误镜像摘要/缺 blob、错误架构、只读写入目录、错误监听地址或 readiness 延迟；同一时刻只改一个变量，并为每次保留镜...