Question

在我们的Kuberenetes集群中，我们遇到了零星节点耗尽内存且Linux调用OOM杀手的零星情况。查看日志，似乎调度到节点上的Pod请求的内存多于节点可以分配的内存。

问题在于，当调用OOM杀手时，它会打印出进程列表及其内存使用情况。但是，由于我们所有的Docker容器都是Java服务，因此“进程名称”只显示为“java”，不允许我们追踪导致问题的特定Pod。

如何获取计划在特定节点上运行哪些Pod的历史记录以及何时？

Answer 1

您现在可以使用kube-state-metrics kube_pod_container_status_terminated_reason来检测OOM事件

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"}

Answer 2

我们使用https://stackblitz.com/edit/angular-nxjeu3来监控OOM事件。

此表达式应报告内存使用量达到限制的次数：

rate(container_memory_failcnt{pod_name!=""}[5m]) > 0

仅供参考：这是正确文档的下一个最佳选择，Prometheus

Answer 3

您的特定命名空间的事件历史记录，按creationTimestamp 排序：

kubectl get events -n YOURNAMESPACE -o wide --sort-by=.metadata.creationTimestamp

或者如果你想检查所有命名空间的事件历史，按creationTimestamp排序：

kubectl get events --all-namespaces -o wide --sort-by=.metadata.creationTimestamp

Answer 4

我猜您的广告连播没有设置requests and limits，或者值不理想。

如果你正确地设置了这个，当一个吊舱开始使用太多的ram时，那个吊舱会被杀死，你将能够找出造成这些问题的原因。

关于查看节点上的所有广告连播，您可以在节点上使用kubectl get events或docker ps -a，如其他答案/评论中所述。

Answer 5

一种方法是查看docker ps -a输出并将容器名称与您容器的容器相关联。

如何获取在Kubernetes Node上运行Pod的历史记录？

5 个答案: