随着企业服务向kubernetes迁移，对k8s事件的实时监控和报警需求增加。文章详细拆解了获取事件信息、实时报警、事件持久化和查询这四个核心功能，并介绍了kubernetes自带的event-exporter及局限性。通过kubewatch和自定义控制器的实现方式，阐述如何监听并处理Event类型，以满足报警和存储需求。
背景：
随着企业内越来越多的服务迁移到了kubernetes上，用户对kubernetes相关信息的获取更加迫切，他们想知道自己的服务实例都“经历过”什么，比如在有业务异常的时候，他们想要知道自己的实例是否被重启过，在上线失败的时候他们也希望第一时间知道原因。更进一步，他们希望这些都能实时通知并且能事后查看。但通常他们又无法直接接触集群服务器，包括kubectl等。因此需要有一个好的解决方案。
需求拆解：
上述需求可以拆解为如下四个基本功能：
- 能够实时获取kubernetes上的事件信息
- 能够对异常事件做实时报警通知
- 能够对事件做更持久的保留以便问题追溯
- 能够对保存的事件进行查询
这些功能听起来都停合理的，而且kubernetes.io里有一篇文章Events in Stackdriver也讲到了事件的存储。
它提到：“事件作为kubernetes的一个对象资源，有助于排错，但大量的事件如果都存储在etcd中，会带来较大的性能与容量压力，所以etcd中默认只保存最近1小时的。因此需要一个第三方的工具来更持久的保存它们。”
具体实现而言，就是对于1.7+版本，在Google Kubernetes Engine上启用了cloud logging后，默认会在集群内部署一个event-exporter，它将使用最低优先级且尽可能少的资源（通常0.1核的CPU和0.1G的内存）。
听起来
最低0.47元/天 解锁文章
890
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
