在我们的Kuberenetes集群中，我们遇到了零星节点耗尽内存并且Linux调用OOM杀手的零星情况 . 查看日志，似乎调度到节点上的Pod请求的内存多于节点可以分配的内存 .
问题在于，当调用OOM杀手时，它会打印出进程列表及其内存使用情况 . 但是，由于我们所有的Docker容器都是Java服务，因此“进程名称”只显示为“java”，不允许我们追踪导致问题的特定Pod .
如何获取计划在特定节点上运行哪些Pod的历史记录以及何时？
我们使用Prometheus来监控OOM事件 .
此表达式应报告内存使用量达到限制的次数：
rate(container_memory_failcnt{pod_name!=""}[5m]) > 0
仅供参考：这是正确文档的下一个最好的事情，the code
您现在可以使用kube-state-metrics kube_pod_container_status_terminated_reason 来检测OOM事件
kube_pod_container_status_terminated_reason
kube_pod_container_status_terminated_reason{reason="OOMKilled"} kube_pod_container_status_terminated_reason{container="addon-resizer",endpoint="http-metrics",instance="100.125.128.3:8080",job="kube-state-metrics",namespace="monitoring",pod="kube-state-metrics-569ffcff95-t929d",reason="OOMKilled",service="kube-state-metrics"}
我猜你的 beans 荚没有requests and limits设置，或者值不理想 .
如果你正确地设置了这个，当一个pod开始使用太多ram时，那个pod将会被杀死，你将能够找出造成问题的原因 .
关于查看节点上的所有窗格，您可以在节点上使用 kubectl get events 或 docker ps -a ，如其他答案/评论所述 .
kubectl get events
docker ps -a
一种方法是查看 docker ps -a 输出并将容器名称与pod的容器相关联 .
4 回答
我们使用Prometheus来监控OOM事件 .
此表达式应报告内存使用量达到限制的次数：
仅供参考：这是正确文档的下一个最好的事情，the code
您现在可以使用kube-state-metrics
kube_pod_container_status_terminated_reason来检测OOM事件我猜你的 beans 荚没有requests and limits设置，或者值不理想 .
如果你正确地设置了这个，当一个pod开始使用太多ram时，那个pod将会被杀死，你将能够找出造成问题的原因 .
关于查看节点上的所有窗格，您可以在节点上使用
kubectl get events或docker ps -a，如其他答案/评论所述 .一种方法是查看
docker ps -a输出并将容器名称与pod的容器相关联 .