本质是节点资源严重透支触发系统保护机制批量终止pod，需按“止血→诊断→加固→预防”四步处理：先cordon/drain异常节点，再分层定位内存占用根源，修正requests/limits配置与调度策略，最后通过eviction-hard和可观测性闭环实现长期防护。
这种情况本质是节点资源被严重透支，系统触发保护机制批量终止 Pod，不是单个容器问题，而是整体调度失衡。核心思路是“止血→诊断→加固→预防”，不能只调高 limit 或重启服务。
立即止血：暂停新负载并隔离异常节点
避免雪球效应，先阻止问题扩大：
- 将该 Worker 节点设置为不可调度：
kubectl cordon <node-name></node-name>，防止新 Pod 继续分配过去 - 驱逐非关键、可重建的 Pod：
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data</node-name>（慎用，确认无状态） - 若节点已频繁 OOMKilled 且无法响应，考虑临时下线该节点，从集群中移除：
kubectl delete node <node-name></node-name>
定位真实内存超限根源
“超出宿主机物理上限”不等于“某个 Pod 配置错了”，要分层查清谁在吃内存：
- 登录宿主机，运行
free -h和cat /proc/meminfo | grep -E "MemTotal|MemAvailable|WorkingSet"，看实际可用内存是否真的低于 500MB - 检查
dmesg -T | grep -i "killed process"，确认哪些进程被 OOM Killer 杀掉——是业务容器？还是 kubelet、containerd、日志 agent 等系统组件？ - 用
top -o %MEM或ps aux --sort=-%mem | head -20查看内存占用 Top 20 进程，注意区分容器内进程和宿主机原生进程 - 检查
kubectl describe node <node-name></node-name>中的 Allocatable vs Capacity，确认是否因kube-reserved或system-reserved设置过低，导致可调度内存远小于物理内存
修正资源配置与调度策略
很多“超限”其实源于配置矛盾，而非真实内存不足：
- 所有 Pod 必须设置
resources.requests.memory，否则 K8s 调度器无法做资源预留，容易造成 overcommit - 限制
limits.memory不能盲目设高；建议按应用实测 WorkingSet 上浮 20%～30% 设置，避免预留浪费又留出缓冲空间 - 对 Java、Node.js 等易内存泄漏或堆外内存大的应用，额外预留 memoryOverhead（如 Spark executor 增加
spark.executor.memoryOverhead） - 检查 DaemonSet（如日志采集、监控 agent、安全扫描器）是否未设 limits，它们会在每个节点静默吃掉 1–2GB 内存
长期防护：启用驱逐与可观测性闭环
靠人工盯指标不现实，必须让系统自动干预：
- 配置
eviction-hard（如memory.available），让 kubelet 在内存紧张时主动驱逐低优先级 Pod，而不是等 OOM Killer 出手 - 在 Prometheus + Grafana 中建立多维内存看板：节点 Allocatable vs WorkingSet、Pod Memory Usage vs Limit、OOMKilled 事件计数、Inactive(file) 缓存占比（防误报）
- 对高频 OOM 的应用，开启 JVM Native Memory Tracking（NMT）或使用
jemalloc替代 glibc malloc，定位堆外内存泄漏 - 定期执行
kubectl top nodes和kubectl top pods --all-namespaces，结合历史趋势判断是否出现缓存堆积或缓慢泄漏
