Kubernetes(K8s)Events介绍（上）

Myth丶恋晨 2022-07-13 03:27 202阅读 0赞

Kubernetes [Events][]虽不常被提起，却意义非凡。它存储在Etcd里，记录了集群运行所遇到的各种大事件。本系列文章将一步一步地揭开Kubernetes Events的神秘面纱。

## 师出有名 ##

前些天群里有位同学（@二东）提问说怎么通过API得到kubectl describe pod的结果，我立刻找到了[Kubernetes][]相关的API并回复他，但他说这不是他要的东西。经过一番描述，我才了解到他想要的是原来如下图中红框里的信息：

![20161219150015][]

Message属于Kubernetes的一种特殊的资源：Events。老实讲，我以前是没有怎么注意过这个Events是怎么来的，甚至一直觉得它应该是Pod的一部分。那么这个Events到底是什么样的资源？它从何而来？下面随我一起踏上捉妖之路。

## 真身难觅 ##

熟悉Kubernetes的小伙伴应该对于它的资源比较有体会，作为调度基本单元的Pod是一种资源，控制[Pod][]更新、扩容、副本数量的ReplicaSet是一种资源，作为发布单位的Deployment也是一种资源，哦，还有[Service][]，Endpoints等等。它们有这么一些共同点：

*  都可以通过[kubectl ][kubectl]get $ResourceName的方式获取
 *  都有对应的RESTful API定义的操作

Events亦如此，kubectl get events的结果为下图：

![20161219150024][]

就像kubectl get pods一样，通过kubectl get events获得当前命名空间下所有Events的列表。如果想查看某条Events的详细信息，是否也可以使用kubectl describe events $EventsName进行获取呢？我尝试了下，得到了下面的失败信息：

![20161219150032][]

甚至连kubectl get events $EventsName也变得没那么好使了：

![20161219150039][]

另外，Events的RESTful API为下图：

![20161219150048][]

而通过最朴素的curl 之刃也没能找出Events的真身：

![20161219150055][]

这着实让人“大吃一斤”。

## 踏破铁鞋 ##

那么这个Events到底是何方神圣？常规手段居然拿它没一丁点办法了？不，还有一招json宝典待我祭出使用。我们知道kubectl get一些资源的时候可以通过它的-o json参数得到该资源的json格式的信息描述，那么对上面的Events进行kubectl get events -o json > /tmp/events.json，得到了一个json数组，里面的每一条都对应着一个Events对象：

![20161219150104][]

Bingo!这就是我们要找的Events对应的实体json。仔细观察，图中红框里的名字正是kubectl get events里得到的Events名字，然而实际上它并不是真正的Events的名字。这是为何？在Kubernetes资源的数据结构定义中，一般都会包含一个metav1.TypeMeta和一个ObjectMeta成员，比如：

![20161219150115][]

TypeMeta里定义了该资源的类别和版本，对应我们平时写json文件或者yaml文件时的kind: Pod和apiVersion: v1。OjbectMeta里定义了该资源的元信息，包括名称、命名空间、UID、创建时间、标签组等。

Events的数据结构定义里同样包含了metav1.TypeMeta和ObjectMeta，那么从前面的json图中可以确定红框里的名字并不是该Events对象的真实名字，它对应的是InvolvedObject的名字，而蓝框里对应的才是Events的真实名字。然后使用kubectl get和curl进行验证：

![20161219150124][]

到此，我们已经探明了Events的真名。仔细观察它的名字，发现它由三部分构成：”发生该Events的Pod名称” + “.” + “神秘数字串”。发生该Events的Pod名称倒是好理解，而后面的神秘数字串却不知从何而来。既然这个Events是来自这个Pod的状态变化，那么想必这个数字串也可以在Pod的详情里找到吧。出乎意料的是在Pod的详情json未曾找到这个神秘数字串，甚至把这个Pod祖上的ReplicaSet和Deployment也翻了个底朝天也是没有一点线索。捉妖行动陷入僵局。

## 星宿Kubelet ##

道高一尺，魔高一丈。纵使齐天大圣也得经常搬救兵，而不少时候这个妖怪就是某个星宿的坐骑或童子。拿起这个Events的json仔细观察，发现里面有个不起眼的component: kubelet：

![20161219150133][]

回想一下kubelet的作用是：负责管理和维护在这台主机上运行着的所有容器，维持pod的运行状态(status)和它的期望值(spec)一致。kubelet启动时，会加载它本身的配置信息、接入容器运行时(Docker或Rkt)、以及定义kubelet与整个集群进行交互所需的信息。在启动后，会进行一系列的初始化工作，创建ContainerManager、设置OOMScoreAdj值、创建DiskSpaceManager、PodManager等等。那么会不会是kubelet为这个Pod创建了该Events呢？

为了解答这个问题，不得不拿出尘封已久的究极“源码大法”。

果然在Kubernetes源码的kubernetes/pkg/kubelet/events/event.go里有了一些收获。event.go里定义了是Events资源常用的一些常量，挑选列出如下：

> const (  
> FailedToStartContainer = “Failed”  
> BackOffStartContainer = “BackOff”  
> ErrImageNeverPullPolicy = “ErrImageNeverPull”  
> BackOffPullImage = “BackOff”  
> FailedSync = “FailedSync”  
> …  
> )

这里面的不少我们平时都会经常遇到。它们是各种事件的原因列表，包含容器事件（创建、启动、失败等）、镜像事件（镜像拉取失败等）、kubelet事件（节点失效、节点不可调度等）、Pod Worker事件（同步失败）等。随便拿出一条进行暴力搜寻，比如”FailedToStartContainer”，发现除了在此处的定义进行了引用外，还在kubernetes/pkg/kubelet/dockertools/docker\_manager.go里711行进行了引用:

> dm.recorder.Eventf(ref, api.EventTypeWarning, events.FailedToStartContainer, “Failed to start container with docker id %v with error: %v”, utilstrings.ShortenString(createResp.ID, 12), err)

由此更加确认的是Events跟Kubelet密不可分。循着这条线索一直往下，还会有什么惊奇的发现？

## 火眼金睛 ##

上面引用了docker\_manager.go里的一行，除开事件本身外，里面还有一些关键词值得琢磨：dm, recorder, Eventf。

> dm是结构体DockerManager的实例，该结构体定义也在这个文件中。定义比较长，这里就不贴出来了，它包含了DockerInterface的成员、EventRecorder的成员、OSInterface的成员以及cadvisorapi.MachineInfo的成员等等。这个EventRecorder的定义在k8s.io/kubernetes/pkg/client/record/event.go里，是一个接口，可以按照EventSource的表现记录相应的事件。  
> type EventRecorder interface \{  
> Event(object runtime.Object, eventtype, reason, message string)  
> Eventf(object runtime.Object, eventtype, reason, messageFmt string, args …interface\{\})  
> PastEventf(object runtime.Object, timestamp unversioned.Time, eventtype, reason, messageFmt string, args …interface\{\})  
> \}

在这个文件的285~295行有对这个三个接口的实现：

> func (recorder \*recorderImpl) Event(object runtime.Object, eventtype, reason, message string) \{  
> recorder.generateEvent(object, unversioned.Now(), eventtype, reason, message)  
> \}  
> func (recorder \*recorderImpl) Eventf(object runtime.Object, eventtype, reason, messageFmt string, args …interface\{\}) \{  
> recorder.Event(object, eventtype, reason, fmt.Sprintf(messageFmt, args…))  
> \}  
> func (recorder \*recorderImpl) PastEventf(object runtime.Object, timestamp unversioned.Time, eventtype, reason, messageFmt string, args …interface\{\}) \{  
> recorder.generateEvent(object, timestamp, eventtype, reason, fmt.Sprintf(messageFmt, args…))  
> \}

不管是PastEventf()、Eventf()还是Event()最终都指向了辅助函数generateEvent()，它的实现在255行：

> func (recorder \*recorderImpl) generateEvent(object runtime.Object, timestamp unversioned.Time, eventtype, reason, message string) \{ // 获取发生事件的对象，比如前面说到的Pod  
> ref, err := api.GetReference(object) if err != nil \{  
> glog.Errorf(“Could not construct reference to: ‘%\#v’ due to: ‘%v’. Will not report event: ‘%v’ ‘%v’ ‘%v'”, object, err, eventtype, reason, message) return  
> \}  
> // 验证事件类型  
> if !validateEventType(eventtype) \{  
> glog.Errorf(“Unsupported event type: ‘%v'”, eventtype) return  
> \}  
> // 生成Event  
> event := recorder.makeEvent(ref, eventtype, reason, message)  
> event.Source = recorder.source
> 
> go func() \{  
> // NOTE: events should be a non-blocking operation  
> defer utilruntime.HandleCrash()  
> // 将Event进行广播  
> recorder.Action(watch.Added, event)  
> \}()  
> \}

recorder.makeEvent()就是这个Events的真正来源：

> func (recorder \*recorderImpl) makeEvent(ref \*api.ObjectReference, eventtype, reason, message string) \*api.Event \{ t := unversioned.Time\{Time: recorder.clock.Now()\} namespace := ref.Namespace  
> if namespace == “” \{  
> namespace = api.NamespaceDefault  
> \}  
> return &api.Event\{  
> ObjectMeta: api.ObjectMeta\{  
> // 事件的命名规则  
> Name: fmt.Sprintf(“%v.%x”, ref.Name, t.UnixNano()),  
> Namespace: namespace,  
> \},  
> InvolvedObject: \*ref,  
> Reason: reason,  
> Message: message,  
> FirstTimestamp: t,  
> LastTimestamp: t,  
> Count: 1,  
> Type: eventtype,  
> \}  
> \}

到此恍然大悟，原来前面所说的Events的命名规则：”发生该Events的Pod名称” + “.” + “神秘数字串”实际上是”ref.Name” + “.” + “t.UnixNano())”。

终于找到了Events的真身，原来它是Kubelet负责用来记录多个容器运行过程中的事件，命名由被记录的对象和时间戳构成。前面看起来难以捉摸的表现最终还是逃不过火眼金睛。到此上篇解决了Events从哪儿来的问题，暂告一段落。在下篇中将对Events关于到哪儿去、怎么根据Pod找到对应的Events等进行深度拷问。欢迎继续关注！

本文中出现的curl 之刃、json宝典、源码大法均属于为了轻松阅读体验而凭空捏造的词汇，分别对应用命令行工具curl进行访问和实验、查看该对象的json信息、阅读源码寻找答案释疑。

来源：[Kubernetes(K8s)Events介绍（上）][Kubernetes_K8s_Events]

[Events]: https://www.kubernetes.org.cn/tags/events
[Kubernetes]: https://www.kubernetes.org.cn/
[20161219150015]: /images/20220713/7fa433298f6c4796bb30974ed7e11023.png
[Pod]: https://www.kubernetes.org.cn/kubernetes-pod
[Service]: https://www.kubernetes.org.cn/kubernetes-services
[kubectl]: https://www.kubernetes.org.cn/doc-45
[20161219150024]: /images/20220713/65c08ba64a554de09c98c5f98a0f4a0a.png
[20161219150032]: /images/20220713/e4fe603c871c4ff39766ffdb05797661.png
[20161219150039]: /images/20220713/f8a7b17cf50e4338890218fe2ab29d7c.png
[20161219150048]: /images/20220713/ba577e249b0041dcac7e4a24b232dd2d.png
[20161219150055]: /images/20220713/59153f897e464623b0ebd5524308584c.png
[20161219150104]: /images/20220713/720180de56d44936b8bdc8ab879adf89.png
[20161219150115]: /images/20220713/f790bd9290f24e29b981182dfc121504.png
[20161219150124]: /images/20220713/789c6183b8b3467dbd487c392c003a59.png
[20161219150133]: /images/20220713/f2c049c415384d658b2a1e3de13b2bbb.png
[Kubernetes_K8s_Events]: https://www.kubernetes.org.cn/1031.html