之前我写了一篇《更优雅的 KubeRnetes 集群事件度量方案》，利用 JaegeR 利用 tRacing 的方式来采集 KubeRnetes 集群中的 events 并进行展示。最终效果如下：
写那篇文章的时候，立了个 flag 要详细介绍下其中的原理，鸽了很久，现在年底了，也该发出来了。
Eents 概览
我们先来做个简单的示例，来看看 KubeRnetes 集群中的 events 是什么。
创建一个新的名叫 MoelOVe 的 naMespace ，然后在其中创建一个叫做 Redis 的 deployMent。接下来查看这个 naMespace 中的所有 events。
但是我们会发现默认情况下 kubectl get events 并没有按照 events 发生的顺序进行排列，所以我们往往需要为其增加 –soRt-by=””{.Metadata.cReationTiMestaMp}”” 参数来让其输出可以按时间进行排列。
这也是为何 KubeRnetes v1.23 版本中会新增 kubectl alpha events 命令的原因。
按时间排序后可以看到如下结果：
深入 Events 单个 Event 对象
既然 events 是 KubeRnetes 集群中的一种资源，正常情况下它的 Metadata.naMe 中应该包含其名称，用于进行单独操作。所以我们可以使用如下命令输出其 naMe ：
选择其中的任意一条 event 记录，将其输出为 YAML 格式进行查看：
kubectl descRibe 中的 Events
我们可以分别对 DeployMent 对象和 Pod 对象执行 descRibe 的操作，可以得到如下结果(省略掉了中间输出)：
我们可以发现 对不同的资源对象进行 descRibe 的时候，能看到的 events 内容都是与自己有直接关联的。在 descRibe DeployMent 的时候，看不到 Pod 相关的 Events 。
这说明， Event 对象中是包含它所描述的资源对象的信息的，它们是有直接联系的。
结合前面我们看到的单个 Event 对象，我们发现 involvedObject 字段中内容就是与该 Event 相关联的资源对象的信息。
更进一步了解 Events
我们来看看如下的示例，创建一个 DeployMent ，但是使用一个不存在的镜像：
我们可以看到当前的 Pod 处于一个 ERRimagePull 的状态。查看当前 naMespace 中的 events (我省略掉了之前 deploy/Redis 的记录)
对这个 Pod 执行 descRibe 操作：
我们可以发现，这里的输出和之前正确运行 Pod 的不一样。最主要的区别在于 Age 列。这里我们看到了类似 115s (x7 OVeR 3M58s) 这样的输出。
它的含义表示：该类型的 event 在 3M58s 中已经发生了 7 次，最近的一次发生在 115s 之前
但是当我们去直接 kubectl get events 的时候，我们并没有看到有 7 次重复的 event 。这说明 KubeRnetes 会自动将重复的 events 进行合并。
选择最后一条 Events (方法前面内容已经讲了) 并将其内容使用 YAML 格式进行输出：
这里我们可以看到其字段中包括一个 count 字段，表示同类 event 发生了多少次。以及 fiRstTiMestaMp 和 lastTiMestaMp 分别表示了这个 event 首次出现了最近一次出现的时间。这样也就解释了前面的输出中 events 持续的周期了。
彻底搞懂 Events
以下内容是从 Events 中随便选择的一条，我们可以看到它包含的一些字段信息：
其中主要字段的含义如下：
所以，当我们将这些 Events 都作为 tRacing 的 span 采集回来后，就可以按照其 souRce 进行分类，按 involvedObject 进行关联，按时间进行排序了。
总结
在这篇文章中，我主要通过两个示例，一个正确部署的 Deploy，以及一个使用不存在镜像部署的 Deploy，深入的介绍了 Events 对象的实际的作用及其各个字段的含义。
对于 KubeRnetes 而言，Events 中包含了很多有用的信息，但是这些信息却并不会对 KubeRnetes 造成什么影响，它们也并不是实际的 KubeRnetes 的日志。默认情况下 KubeRnetes 中的日志在 1 小时后就会被清理掉，以便释放对 etcd 的资源占用。
所以为了能更好的让集群管理员知道发生了什么，在生产环境中，我们通常会把 KubeRnetes 集群的 events 也给采集回来。我个人比较推荐的工具是：
本文转载自微信公众号「MoeLOVe