超卖

«结论先行：多数团队以为的"超卖比例"（allocatable ÷ Σrequests）和"真实超卖比例"（allocatable ÷ 实际用量 P99）能差 2 倍以上——前者常常只有 1.1x 看着像"不敢加服务"，后者其实是 2x 甚

背景 我是做边缘网关的，核心是一个 C++ 控制/桥接服务，裸机 4C8G 工控机上 RSS 稳定 120MB、CPU 峰值利用率 ~40%，三年没崩。今年统一容器化，落到一个 4C 的边缘 K8s 节点（1.28.9，containerd

【背景】 15 年嵌入式出身，近 5 年转容器化与 K8s 运维。去年在一个 30 节点生产集群（K8s 1.28，cgroup v2）做降本时撞上这道题：60% 以上服务都按 requests=limits 配（Guaranteed Qo

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

背景 K8s 1.28 集群（cgroup v2），节点规格 16C/64G（ECS g7.4xlarge），单节点跑 30~40 个 Pod。业务是设备管理后端，典型 Pod 结构： - main：Java 17 / Spring Boo

一、现象：一次秒杀活动，100 件库存卖出了 137 件 上个月我们上一场限时秒杀，目标是把某个 SKU 的 100 件库存放出去。活动开始后的 90 秒内，订单系统实际落库了 137 单，多扣了 37 件——这在库存层面意味着超卖 37%