Kubernetes中的事件监控

随着微服务以及云原生的发展，越来越多的企业都将业务部署运行到Kubernetes中，主要是想依托Kubernetes的可扩展、可伸缩、自动化以及高稳定性来保障业务的稳定性。

然而，Kubernetes本身是一个复杂的管理系统，它既然是作为企业业务的基础设施，其本身以及运行在集群内部的业务系统对于企业来说都变得非常重要。为此，在实际工作中，我们会借助需要的监控手段来提升Kubernetes本身以及业务的可观测性，常见的有：

• 使用cAdvisor来获取容器的资源指标，比如cpu、内存；
• 使用kube-state-metrics来获取资源对象的状态指标，比如Deployment、Pod的状态；
• 使用metrics-server来获取集群范围内的资源数据指标；
• 使用node-exporter等一系列官方以及非官方的exporter来获取特定组件的指标；

在大部分的监控场景中，我们都是对特定资源进行特定监控，比如Pod，Node等。但是，在Kubernetes中还有一些场景是无法通过资源来表述的，就是说它们不是特定的资源，比如Pod调度、重启，在Kubernetes中，这类场景主要称之为事件。

在Kubernetes中，存在两种事件：

• Warning事件，事件的状态转换是在非预期的状态之间产生。
• Normal事件，期望达到的状态和目前的状态是一致的。

在这里，我们用Pod来进行说明。当创建Pod的时候，会先进入Pending状态，然后再进入Creating状态（主要是在拉取镜像），再进去NotReady状态（主要是应用启动并且等待健康检测通过），最后进入Running状态，这整个过程就会生成Normal事件。但是，如果在运行过程中，如果Pod因为一些异常原因进入其他状态，比如节点驱逐、OOM等，在这个状态转换的过程中，就会产生Warning事件。在Kubernetes中，我们可以通过其他办法来保障业务的稳定性，比如为了避免Pod调度到一个节点或者同可用区等而采用亲和性以及反亲和性调度，为了避免节点驱逐导致某个单个Pod不可用而采用的PDB等，也许某个Warning事件并不会对整个业务的稳定性带来致命的影响，但是如果能够通过监控事件的手段来感知集群的某个状态变化是有助于进行查漏补缺的，也有助于我们感知一些容易忽略的问题。

在Kubernetes中，所有事件都通过事件系统记录到APIServer中，并且最终存入在Etcd中，我们可以通过API或者kubectl进行查看，比如：

也可以查看某个对象的事件，比如：

事件包含了时间、类型、对象、原因以及描述等，通过事件我们能够知道应用的部署、调度、运行、停止等整个生命周期，也能通过事件去了解系统中正在发生的一些异常。在Kubernetes各个组件的源码中都会定义该组件可能会触发的事件类型，比如在kubelet的源码中定义了许多的事件类型，如下：

package events

// Container event reason list
const (
 CreatedContainer        = "Created"
 StartedContainer        = "Started"
 FailedToCreateContainer = "Failed"
 FailedToStartContainer  = "Failed"
 KillingContainer        = "Killing"
 PreemptContainer        = "Preempting"
 BackOffStartContainer   = "BackOff"
 ExceededGracePeriod     = "ExceededGracePeriod"
)

// Pod event reason list
const (
 FailedToKillPod                = "FailedKillPod"
 FailedToCreatePodContainer     = "FailedCreatePodContainer"
 FailedToMakePodDataDirectories = "Failed"
 NetworkNotReady                = "NetworkNotReady"
)
......