k8s事件告警-升级版:k8swatch

继之前介绍的k8s的事件告警,这里介绍一个对它功能做进一步扩充和完善的一个服务:k8swatch github

k8swatch介绍与应用

  • k8swatch是监听并存储记录k8s各类资源变化的一个工具,并能对事件类资源进行分析、报警、查询处理。
  • 它通过自定义控制器实现对k8s各种资源的list&watch,并支持以插件化的方式实现对各种资源变更的处理,如存储、发送到MQ、分析报警等。
  • 参考开源项目kubewatch并做了改进。

功能

  • 提供HTTP接口对各类资源的事件进行查询
  • alert,用来对events做分析和异常报警,并生成json日志落盘,会被收集到日志平台分析。
  • elasticsearch,发布到elasticsearch,支持更久存储和查询
  • rabbitmq,发布到rabbitmq,目前graylog会从其消费并做分析报表,如:
    • 应用发布频率统计
    • 业务组发布量排名
    • 应用新建或销毁的记录
    • node的心跳宏观趋势(node的update多为心跳)
  • influxdb
  • webhook,调用webhook用于后续扩展

已支持的资源类别

  • events
  • endpoints
  • pods
  • nodes
  • services
  • namespaces
  • replicationcontrolleres
  • persistentvolumes
  • persistentvolumeclaim
  • secrets
  • configmaps
  • deployments
  • replicasets
  • daemonset
  • ingresses
  • jobs
  • roles
  • rolebindings
  • clusterroles
  • clusterrolebindings

HTTP查询

  • 方法:GET
  • 参数:
    • namespace,string,命名空间同k8s
    • kind_name,string,如podname
    • limit,string,最大条数,不设则为10
  • 返回:[]{“k”:“v”}如:
    [{
    "count": 340,
    "createTimestamp": "2019-10-18 12:01:36",
    "evt_name": "asset-restful-8458bb8dcc-bvxjh.15cea1de7fce8b7f",
    "firstTimestamp": "2019-10-18 12:01:36",
    "kind": "events",
    "kind_name": "asset-restful-8458bb8dcc-bvxjh.15cea1de7fce8b7f",
    "lastTimestamp": "2019-10-19 23:23:30",
    "message": "Readiness probe failed: Get http://10.12.35.133:8080/info: net/http: request canceled (Client.Timeout exceeded while awaiting headers)\nevents:asset-restful-8458bb8dcc-bvxjh.15cea1de7fce8b7f in namespace test-coreasset has been CREATED\n",
    "namespace": "test-coreasset",
    "reason": "Unhealthy",
    "resourceVersion": "",
    "source_component": "kubelet",
    "source_host": "t-k8s-node-38-99",
    "time": "2019-10-19 23:23:30",
    "type": "Warning"
    },
    {
    "count": 343,
    "createTimestamp": "2019-10-18 12:01:36",
    "evt_name": "asset-restful-8458bb8dcc-bvxjh.15cea1de7fce8b7f",
    "firstTimestamp": "2019-10-18 12:01:36",
    "kind": "events",
    "kind_name": "asset-restful-8458bb8dcc-bvxjh.15cea1de7fce8b7f",
    "lastTimestamp": "2019-10-19 23:24:46",
    "message": "Readiness probe failed: Get http://10.12.35.133:8080/info: net/http: request canceled (Client.Timeout exceeded while awaiting headers)\nevents:asset-restful-8458bb8dcc-bvxjh.15cea1de7fce8b7f in namespace test-coreasset has been UPDATED\n",
    "namespace": "test-coreasset",
    "reason": "Unhealthy",
    "resourceVersion": "",
    "source_component": "kubelet",
    "source_host": "t-k8s-node-38-99",
    "time": "2019-10-19 23:24:46",
    "type": "Warning"
    }]
    

运行

  • ./k8swatch -h查看帮助信息
  • 通常./k8swatch –config xxx即可
  • 或通过环境变量如:export K8SWATCH_CONF=cretest ./k8swatch 将读取当前目录下的configs/ 或/etc/k8swatch/configs/或$HOME下对应的yaml结尾的配置文件。
  • 容器部署:k8s的incluster模式运行。

对事件进行分析告警

  • 对诸多事件的Reason判断做了较为“笨拙”的方式,没有完全按照normal或是warning决定是否发送报警,因为有些k8s的事件级别(eventType)是Normal但依然需要关注,比如:

    • 节点notready————通常是节点心跳偶尔异常,也可能是节点真实不可用。
    • pod被killing————正常滚动升级时killing无需关注,但因healthCheck失败触发的killing就需要报警了。 而有些event是自定义写的Reason不是很规范,因此通过白名单的方式进行控制,对未知的事件则打日志为unknown,便可在日志系统中分析得出。
  • 对发送人的区分

    • 集群级别的发送给管理员,如私服异常,节点异常,调度异常等。
    • 应用级别的发给最终用户(在云平台查询应用维护人,TL等),如容器启动失败,unhealthy被删除等。
    • 找不到应用维护人的,也将发给管理员。
  • 效果:

开发时遇到的问题

  • 要注意client-go的版本应与k8s版本匹配,可去client-go的GitHub上查找对应关系。
  • gomod依赖关系bug: 更换版本之后依赖总无法解决,最后把 $GOPATH/pkg/mod/k8s.io/[email protected]* 全部删掉,再重新拉取对应的版本就可以了
  • 对于不同资源,创建listwatch的参数也要注意是不同的:
    • 不同资源,使用的restclient不同,如deployments,ds使用的是: KubeClient.ExtensionsV1beta1().RESTClient(),pod则是KubeClient.CoreV1().RESTClient()
  • onDelete的处理,不能试图从index中获取,因为其已经被删除。
  • 事件在k8s的etcd中只存储过去1小时的,k8swatch启动时会得到过去1小时的所有事件,需做处理(避免报警重复)
  • rs 存储时间更久,而node信息在etcd中则一直存储(不会主动删除),因此create动作需做时间判断(避免重复)
  • workqueue的使用要注意延迟堆积,可通过查看其队列长度发现延迟。node心跳类update较多,因此将worker放入goroutine加快队列消费速度,以减少堆积。

events的来源

除了kubelet之外,还有controller-manager等组件也能产生相应的组件,如:replicaset-controller ,default-scheduler,deployment-controller,nginx-ingress-controller,node-controller,甚至kube-proxy(Starting kube-proxy.) eventRecorder

可用的分析场景:

  • 高频异常节点
  • 高频故障时间
  • 各类资源的创建+时间排序,得知发布规律、频率等