Java服务K8s资源配额：Netty off-heap buffer定量配置与limits联动策略

背景

维护一个12节点K8s集群（16C64G），运行40+服务含Java应用（Spring Boot 2.7/JDK17）。去年统一requests=limits策略后，发现Java服务频繁OOMKill，复盘发现Netty的off-heap buffer预分配是主因。

现象

• 订单服务（Guaranteed 4C/4Gi）突发流量时连续OOMKill，jcmd分析显示native内存占用达4.8Gi（含Netty 1.2Gi + glibc 400MB）
• Batch ETL任务按peak设limits导致资源浪费，但Burstable策略下节点调度容量提升6Gi
• CI worker limits设16C却通过nodeAffinity控制并发，实际未超卖

已尝试

1. 设置MALLOC_ARENA_MAX=16减少glibc碎片
2. 调整NettynumDirectArenas=4降低off-heap占用
3. 将limits从4Gi调至5Gi给native留余量
4. 添加memory.current/limits>0.85告警

期望答案

1. 如何定量计算Netty off-heap buffer需求？numDirectArenas和maxOrder如何与K8s limits联动？
2. Java服务limits设成"允许OOMKill但PDB兜底" vs "永不OOMKill"的实战对比？
3. 有无使用VPA做动态推荐的经验？如何平衡Prometheus历史P95与资源预留？
4. 除了MaxRAMPercentage，还有哪些JVM参数能配合K8s资源策略？

引用：

• K8s资源配额：requests=limits一刀切 vs 留burst空间
• Java服务该不该「把弹性让出去」
• CFS throttling的隐性性能税