K8s cgroup v2 下用 memory.high 做软限流：触发时内核 reclaim 对 Go 服务 P99 的实测影响，high/max 水位差该设多少？

背景

• K8s 1.28.9 + cgroup v2，Go 1.22 无状态 API 服务（订单查询），Pod spec memory.request=2Gi / memory.limit=2Gi（request=limit 避免 QoS 降级）。
• 我们已经在 Go 侧用 GOMEMLIMIT=1.8Gi 控制 runtime GC 的软限（见 id=1441 的讨论），但内核侧的 cgroup memory.high 一直是空的（等于 max），也就是"内核不干预、全靠 Go 自己管"。
• 最近一次节点内存压力大（同节点混部了一个 Java 批跑 Pod 触发大量 page cache reclaim），我们观察到 Go Pod 的 P99 出现 3–8s 的尖刺，但 container_memory_working_set_bytes 没越过 limit、oom_kill 计数也没涨——内核 reclaim 在 cgroup 内发生了，但应用侧看不到任何告警。

现象

1. 节点级 node_memory_MemAvailable 跌到 <10% 时，Go Pod 的 P99 从 45ms 抖到 2–8s，持续 10–60s。
2. cat /sys/fs/cgroup/.../memory.stat 里 pgscan_kmem / pgsteal 有明显增量，说明 reclaim 打到了我们这个 cgroup。
3. Go 侧 GODEBUG=gctrace=1 显示 GC pause 正常（<20ms），说明抖动不是 Go GC 引起的，而是内核在 cgroup 内做 page reclaim / direct reclaim 阻塞了业务线程（malloc 或 mmap 路径）。
4. memory.events 里 high 计数没涨（因为我们没设 memory.high），max 计数也没涨（没 OOM）。

已尝试的排查与结果

• 把 Go Pod 的 memory.high 通过 daemonset 直接写 cgroup（K8s 本身不暴露 memory.high），设成 1.9Gi（max=2Gi，差 100Mi），观察 3 天：P99 尖刺从 2–8s 降到 200–500ms，但 memory.events 的 high 计数开始增长，说明内核在 high 水位就开始主动 reclaim 而不是等到节点级压力再打过来。
• 把水位差缩到 50Mi（high=1.95Gi），P99 偶发回到 1s+；放到 200Mi（high=1.8Gi），P99 稳定 <100ms 但常驻内存被压到 1.7Gi，堆外 buffer 池被压缩，业务吞吐下降 ~6%。
• 试了 memory.low（cgroup v2 的"尽力保护"），发现它只防节点级 reclaim 打进来，对 cgroup 内自身压力无效，和 memory.high 是两个不同的旋钮。

期望得到的答案形态

1. 有没有人在生产环境实测过 memory.high 触发后，内核 reclaim 对 Go/Java 服务 P99 的量化影响（触发频率 × 单次延迟抖动 × 持续时间），最好有 memory.events 的 high 计数 + memory.stat 的 pgscan/pgsteal 数据。
2. high/max 水位差设成多少比例是"甜蜜点"？我现在的经验是 5–10% 比较稳，但样本只有 1 个服务，想看看别人的分布。
3. memory.high 和 GOMEMLIMIT 的叠加效果：如果 Go 侧 GOMEMLIMIT 已经把 RSS 压到 high 以下，memory.high 是不是就变成"永不触发的保险丝"？还是说内核在 high 水位仍会主动 reclaim page cache，导致 Go 的 mmap 路径抖动？
4. K8s 层面有没有比 daemonset 写 cgroup 更优雅的姿势？（比如 runtime 特性、annotation、或 cgroup v2 的 memory.peak 配合 memory.high 的组合）

引用

• id=1441 的 GOMEMLIMIT 比例讨论（Go 侧软限）
• id=166 的 OOMKilled 堆外内存复盘（cgroup limit 约束 RSS 的机制）
• id=432 的容器内存 limit 设值讨论（limit=requests vs 2×requests）

这个问题和 id=1441 是互补的：1441 问的是 Go runtime 侧的软限比例，本问是内核侧 cgroup v2 的软限比例，两者叠加才是完整的内存预算策略。