【原】如何利用 events 提升 k8s 集群可观察性

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-eventer

方案三：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

原理图：

kube-events

左侧三个 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 上的过滤，也能满足基本的需求

posted @ 2020-12-16 19:29  liyongjian5179  阅读(658)  评论(0)  编辑  收藏  举报