CFS

一、现象与背景 K8s 1.28 / cgroup v2 / 内核 5.15，共享节点 16C64G，一个 Go 1.22 的 Kafka 消费者 Pod："cpu.request=1 / cpu.limit=2"（Burstable，成本

一、现象或背景：CPU 没打满，延迟却翻了 46 倍 我们一个 12 节点（8C16G，Kubernetes 1.28.9 + containerd 1.7.13，cgroup v1）的网关集群，跑着一个 Go 网关（单实例 4C limi

背景 做了 15 年性能调优，最近在排查一个 K8s 1.29 集群（cgroup v2、内核 5.15.0-91、containerd 1.7）上的 Java 服务 P99 毛刺。 - 服务：JDK 17 + G1GC，单 Pod 单容器

背景 K8s 1.28 / cgroup v2 / 内核 5.15，共享节点 16C64G，一个 Go 1.22 的 Kafka 消费者 Pod："cpu.request=1 / cpu.limit=2"（Burstable，成本原因没给独

背景 8 年嵌入式出身，习惯了"资源就是钱"——MCU 上 512KB RAM 每一字节都要算清楚，超了直接 hard fault，没有"再给点"的余地。转 K8s 运维后最不适应的一点：调度器按 "requests" 装箱，但 "requ

背景 - K8s 1.28.9 / containerd 1.7.13 / cgroup v2 / 内核 5.15.0-91，共享节点 16C64G。 - Go 1.22 无状态订单查询服务（HTTP + gRPC 混合），Pod spec

«结论先行：给容器设 "cpu.limits"（cgroup v2 的 "cpu.max"）时，K8s 给你的是带宽上限，不是算力保障。你的服务平时只用 0.5 核，被限到 1 核没问题；可一旦瞬时想跑满 1 核，CFS 调度器会按「每 1

一、现象：P50 稳如老狗，P99 却间歇性飙到 5 倍 先给结论：这次 P99 长尾的根因不是 GC、不是下游、不是连接池，而是我们给容器设的 "cpu.limit=1.5" 触发了 Linux CFS 的周期性硬切（throttling