确认oomkilled需先用kubectl describe pod检查events和last state：reason为oomkilled表明超limits.memory，evicted则属节点内存不足；再查cgroup内存用量与限制差值，若过小需排查/dev/shm、jvm元空间或直接内存等隐性占用。

处理K8s中容器因内存溢出被OOMKilled，核心不是堆大就安全，而是让内存使用可预测、有边界、能分级响应。

确认是否真超限，还是误判

先别急着加内存。用kubectl describe pod <pod-name></pod-name>检查Events和Last State——若Reason明确是OOMKilled，说明容器确实突破了resources.limits.memory；若显示Evicted，则是节点整体内存不足，需查调度或节点负载。

再进容器执行cat /sys/fs/cgroup/memory/memory.usage_in_bytes和memory.limit_in_bytes，对比实际用量与硬限制。差值小于50MB却触发OOM？大概率是/dev/shm或JVM元空间/直接内存撑满，而非堆内存。

给容器划清内存“红线”和“黄线”

硬限制（limits.memory）必须设，且不能拍脑袋：

Kubernetes Network Policy Generator

使用加权评分卡在12项标准上评估和比较隐私解决方案供应商。适用于选择隐私管理软件、比较数据保护方案等场景。

下载

• 用kubectl top pod --containers持续观察高峰内存用量，取P95值再上浮20%～30%作为limits
• requests.memory设为实际稳定用量的70%～80%，确保调度不塞到资源吃紧的节点
• Java应用务必启用容器感知：-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0，避免JVM按宿主机内存分配堆

堵住几个常见隐性“内存黑洞”

很多OOM根本不是业务代码导致，而是配置盲区：

• /dev/shm太小：Docker默认64MB，Chrome Headless、PyTorch、PostgreSQL都可能瞬间打满。K8s中加emptyDir: { medium: Memory, sizeLimit: 512Mi }
• JVM直接内存未控：Netty、NIO等大量使用堆外内存。加-XX:MaxDirectMemorySize=512m并监控NativeMemoryTracking
• 日志/临时文件堆积：检查容器内是否有未轮转的大日志、解压缓存目录，建议挂载emptyDir并设sizeLimit

让关键服务更难被杀，次要任务主动让路

K8s本身不支持--oom-score-adj，但可通过优先级和QoS间接实现：

• 将核心服务Pod设为Guaranteed QoS（requests == limits），系统默认赋予更低OOM评分
• 非关键批处理任务设为BestEffort或低requests，在节点压力下更早被驱逐
• 配合priorityClassName，确保高优Pod在资源紧张时优先获得调度和保留

不复杂但容易忽略：OOMKilled本质是cgroup配额被突破后的内核保底动作。调优的关键，在于让配额合理、用量透明、非堆内存可控、服务等级可区分。