Events 简介
Events 是什么？
启动一个 deployment, 从声明开始到 pod 启动完成，会生成一系列的事件，用来告知用户现在的状态，同时还能回答一些，比如为什么 pod 没启动，是因为没配置私有仓库的密码；为什么 pod 会被 kill ，是因为超过了 limit 的限制，再比如 pod 被重新调度了、某个 node 节点的 imageGC 失败了，某个 hpa 触发了...
Events 如何查看？
kubectl get events
kubectl describe pods xxx -n xxx
Events 存在哪？
存储在Etcd里，记录了集群运行所遇到的各种大事件。同时，防止大量的事件都存储在 etcd 中带来较大的性能与容量压力，所以 etcd 中默认的 events 事件只保留最近一小时的，在排查过程中，如果耗时过久，将不能查看到历史的 events。
Events 类型？
Warning: 表示产生这个事件的状态转换是在非预期的状态之间产生的Normal: 表示期望到达的状态，和目前达到的状态是一致的
Events 典型的 Reason有哪些？
- Created
- Started
- Failed
- Killing
- Preempting
- Backoff
- pulled
- Unhealthy
- Failed Mount
- ErrImage Never Pull
- Failedvalidation
- Rebooted
- Starting
- Network NotReady
- Node Notschedulable
- Volume Resize Successful
- Failed Rescale
- UnexpectedJob
- Missingjob
- UnAvailable Load Balancer
- SystemOOM
- Free DiskSpace Failed
What to do？
k8s 生态中已有metrics-server 、Prometheus 等，但是这些并不能实时推送事件。同时 events 存储时间过短，不方便排查历史问题。所以，我们要想办法把事件收集起来。方便回顾历史，还可以利用数据做更多扩展性的分析，同时提高集群的可观察性。
How to do?
见收集方案
展示
数据分享
2019年11月21日 kubecon 2019 分享：《导出 k8s 事件对象以提高可观察性》
https://static.sched.com/hosted_files/kccncna19/d0/Exporting K8s Events.pdf
收集方案
方案一：eventrouter
github 地址：https://github.com/heptiolabs/eventrouter
stars数：617
具体方案：eventrouter---->kafka---->logstash(过滤、解析)----->ES----->elastalert
后端支持： s3、kafka、stdout
缺点：需要引入 EFK 等组件，然后输出 es ，不支持报警通知
方案二：kube-eventer 采纳
github 地址：https://github.com/AliyunContainerService/kube-eventer
stars 数：413
具体方案：自身实现了多种后端的输出，支持常见的 stdout、kafka 、es、mysql、influxdb等，报警支持 dingtalk（按 namespace、kind 过滤用逗号分隔匹配多个）、微信、webhook（支持过滤，按 namespace、kind、reason（支持正则））
缺点：过滤性相对比方案 3 和 4 没有那么灵活，只有 webhook 支持过滤（可以考虑配置多个 webhook）
原理图:
方案三：kube-events
视频介绍：2020.8.1 Kubecon 2020 《多租户环境中的K8s事件导出、过滤和警报》 https://v.qq.com/x/page/v3130vg5lme.html
github 地址：https://github.com/kubesphere/kube-events
stars 数：23
具体方案：通过 EFK 收集归档日志，报警通过 alertmanger 结合notification-manager
后端：stdout、webhook 或者通过 alertmanger 结合notification-manager 实现更多端的报警
主要组件：
-
Exporter: 监视 Kubernetes 事件，并向接收器发出事件， 事件导出只支持stdout 和 webhook（默认给 Ruler 用）
-
Ruler: 接收事件，按 Rule 过滤事件，然后发出通知或将其作为警报处理，最终将发送给 Alertmanager或 Webhooks
原理图：
左侧三个 CRD:
1.exporter: 用来定义exporter 的期望状态
2.ruler: 定义了 ruler 组件，监听 rule 资源
3.rule 资源
右侧 deployment 监听左侧的 crd 资源
架构图：
优点：本地化做的比较好，可以定义事件的过滤（使用类似 SQL的方式）规则，根据规则去触发 alertmanager 和 notification
ruler组件针对事件进行组合归类（condition 参考：https://github.com/kubesphere/kube-events/blob/master/config/crs/cluster-rules-default.yaml）
缺点：引入的组件过多
方案四：kubernetes-event-exporter
github 地址：https://github.com/opsgenie/kubernetes-event-exporter
stars 数：320
具体方案：支持输出stdout、kafka、 es 、webhook，支持过滤
优点：报警配置比较灵活
缺点：配置比较复杂
demo：https://github.com/opsgenie/kubernetes-event-exporter/blob/master/config.example.yaml
方案对比（源自方案三厂商的对比）
结论：如果只考虑收集到 es，方案2 和 4 是相对比较简便的，不用引入其他组件；方案 1 和 3 需要引入类efk ；如果再考虑到事件过滤和报警的灵活性，可能方案 4 是比较好的，方案3的由于涉及 crd 的配置，稍显复杂，方案2在 webhook 上的过滤，也能满足基本的需求