容器 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 读取计数，可能把完全不相关的新进程误归因。入口说明关联字段，共用负载与服务探针可供专用 VM 使用。当前 cgroup v1 只读且没有容器 ID/Pod UID，节点关联实验全部 NOT_RUN；00/09 的普通进程日志不可拼接成一次容器请求。
| 现象 | 关联键 | 适用条件 |
|---|---|---|
| 请求延迟上升 | request 时间窗、Pod UID、cgroup | 计数增量对齐采样 |
| 旧 PID 仍可查 | 进程启动时间/容器 ID | PID 会被重用 |
| 日志缺尾 | stdio/collector 时间窗 | 不能仅凭缺行判定没执行 |
练习
- 先预测容器重启后原 PID 的指标能否继续作该应用的性能证据，在 VM 关联两代容器 ID 与 cgroup 路径再判断。
- 先预测
memory.events无变化、CPU 节流增多时/ready延迟会怎样，采集真实请求分布与各控制器增量，不把一次高延迟当全局结论。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-06-20
可观测性——Metrics、Logging、Tracing 的集群实践
一个运行在 Kubernetes 上的分布式系统，出问题时最难回答的问题是"发生了什么"。单机时代，登录服务器查看进程状态和日志文件，基本能还原现场。容器化之后，Pod 随时可能被调度到不同节点，崩溃后立即重启，原始日志消失，这套方法彻底失效。可观测性（Observability）是对这个问题的系统性回答：通过在系统内部埋点、采集、存储和展示三类信号——Metrics（指标）、Logging（日志）、Tracing（链路追踪）——让工程师在不登录服务器的情况下理解系统行为。 Kubernetes 本身对可观测性有明确的架构分工。采集点（kubelet 内嵌的 cAdvisor、node-exporter DaemonSet、应用 SDK）由各组件负责暴露，聚合层（Prometheus、metrics-server）负责拉取和存储，展示层（Grafana、Jaeger UI）负责查询和可视化。这种"采集点内建、存储和展示留给生态"的设计，让 Kubernetes 本身保持简洁，同时允许不同规模的集群选择不同的存储方案。 理解可观测性的关键区分...
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
容器 E03：eBPF 事件属于哪一个容器
eBPF 程序在内核钩子看到的是事件时刻的进程和内核对象，不会自动附赠“这一定属于 Pod A”的可靠标签。31 的身份链需要把 PID、cgroup、namespace inode、容器 ID 与 Pod UID 在时间窗口内对齐，尤其要考虑容器退出后 PID 被重用。 先判定事件是什么 选择一个自编 probe-app 可控的事件，例如打开自己的状态文件；在 eBPF 程序里采集时间戳、PID/TGID 与 cgroup 标识，在用户态按同一时刻运行时映射关联到容器 ID、Pod UID。权限、内核 BPF 功能和事件丢失都应写进记录。若只装了探针、打印几行带 PID 的事件，却没有证明进程当时属于哪一代容器，就仍是错误归因风险。访问 /proc 获取当前 PID 的属性只能证明读取时的状态，不保证事件发生时该 PID 还属于同一进程。 正例在独立 kind VM 中对自有探针触发一次文件打开，核对事件、实际 PID、cgroup/namespace 与 Pod UID；边界例立即重建同名 Pod，检验新旧事件能否正确分组，即使宿主 PID 以后复用也不能并为一条轨迹。身份字...
2026-10-01
容器 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 管理员委派的...
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
容器 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/...