事件监控

Kubernetes事件是可以深入了解集群内部事件的对象,例如调度程序做出了哪些决定或为什么从节点上驱逐了某些Pod。

事件监控是Kubernetes中的另一种监控方式,可以弥补资源监控在实时性、准确性和场景上的缺欠。开发者可以通过获取事件,实时诊断集群的异常与问题。

在Kubernetes中,事件分为两种,一种是Warning事件,表示产生这个事件的状态转换是在非预期的状态之间产生的;另外一种是Normal事件,表示期望到达的状态,和目前达到的状态是一致的。我们用一个Pod的生命周期进行举例,当创建一个Pod的时候,首先Pod会进入Pending的状态,等待镜像的拉取,当镜像录取完毕并通过健康检查的时候,Pod的状态就变为Running,此时会生成Normal的事件。而如果在运行中,由于OOM或者其他原因造成Pod宕掉,进入Failed的状态,而这种状态是非预期的,那么此时会在Kubernetes中产生Warning的事件。那么针对这种场景而言,如果我们能够通过监控事件的产生就可以非常及时的查看到一些容易被资源监控忽略的问题。

背景信息

Kubernetes的架构设计基于状态机,不同的状态之间进行转换则会生成相应的事件,正常的状态之间转换会生成Normal等级的事件,正常状态与异常状态之间的转换会生成Warning等级的事件。

由于事件是API对象,因此它们存储在master上的apiserver中。为避免填满主磁盘,将执行保留策略:在上次发生事件后一小时删除事件。

我们希望能够在时间轴上看到kuberentes集群发生的所有各种情况,包括何时发现节点已死,何时添加新节点,何时pod崩溃以及何时重新启动。

到目前为止,我们发现的最好的方法是,kubectl get event --watch,但这似乎有一些限制:

  • 它没有回到过去那么长时间(我不确定它回到过去多少天。)
  • 它结合了类似的事件,并按每个组中最新事件的时间对结果列表进行排序。由于该范围内的事件可能已与该范围外的后续事件合并,因此无法知道在某个时间范围内发生了什么。

kube-eventer 

kube-eventer:是ACK维护的开源Kubernetes事件离线工具,可以将集群的事件离线到Elasticsearch、钉钉、微信等系统,并提供不同等级的过滤条件,实现事件的实时采集、定向告警、异步归档。

node-problem-detecto

node-problem-detector:是Kubernetes节点诊断的工具,可以将节点的异常,例如Docker Engine Hang、Linux Kernel Hang、网络出网异常、文件描述符异常转换为Node的事件,集合kube-eventer可以实现节点事件告警的闭环。

容器 OOMKilled 事件没有记录在事件中(issue)的补救方案:

可以使用 prometheus对OOMkilled POD 发出报警:

sum_over_time(kube_pod_container_status_terminated_reason{reason="OOMKilled"}[5m]) > 0

参考:

https://help.aliyun.com/document_detail/125679.html?spm=a2c4g.11186623.2.19.565748f17niTNm#section-rya-7i0-9e3

aliyun 解决方案:

https://github.com/AliyunContainerService/kube-eventer

https://github.com/AliyunContainerService/node-problem-detector

k8s官方解决方案:

https://github.com/kubernetes/node-problem-detector

Google Kubernetes 解决方案:

https://kubernetes.io/docs/tasks/debug-application-cluster/events-stackdriver/

容器 OOMKilled 事件没有记录在事件中: 

https://github.com/kubernetes/kubernetes/issues/69676