监控是保障系统稳定性的重要组成部分,在Kubernetes开源生态中,资源类的监控工具与组件监控百花齐放。
cAdvisor:kubelet内置的cAdvisor,监控容器资源,如容器cpu、内存;
Kube-state-metrics:kube-state-metrics通过监听 API Server 生成有关资源对象的状态指标,主要关注元数据,比如 Deployment、Pod、副本状态等;
metrics-server:metrics-server 也是一个集群范围内的资源数据聚合工具,是 Heapster 的替代品,k8s的HPA组件就会从metrics-server中获取数据;
还有node-exporter、各个官方、非官方的exporter,使用 Prometheus 来抓取这些数据然后存储,告警,可视化。但这些还远远不够。
监控的实时性与准确性不足
大部分资源监控都是基于推或者拉的模式进行数据离线,因此通常数据是每隔一段时间采集一次,如果在时间间隔内出现一些毛刺或者异常,而在下一个采集点到达时恢复,大部分的采集系统会吞掉这个异常。而针对毛刺的场景,阶段的采集会自动削峰,从而造成准确性的降低。
监控的场景覆盖范围不足
部分监控场景是无法通过资源表述的,比如Pod的启动停止,是无法简单的用资源的利用率来计量的,因为当资源为0的时候,我们是不能区分这个状态产生的真实原因。
基于上述两个问题,Kubernetes是怎么解决的呢?
在Kubernetes中,事件分为两种,一种是Warning事件,表示产生这个事件的状态转换是在非预期的状态之间产生的;另外一种是Normal事件,表示期望到达的状态,和目前达到的状态是一致的。我们用一个Pod的生命周期进行举例,当创建一个Pod的时候,首先Pod会进入Pending的状态,等待镜像的拉取,当镜像录取完毕并通过健康检查的时候,Pod的状态就变为Running。此时会生成Normal的事件。而如果在运行中,由于OOM或者其他原因造成Pod宕掉,进入Failed的状态,而这种状态是非预期的,那么此时会在Kubernetes中产生Warning的事件。那么针对这种场景而言,如果我们能够通过监控事件的产生就可以非常及时的查看到一些容易被资源监控忽略的问题。
一个标准的Kubernetes事件有如下几个重要的属性,通过这些属性可以更好地诊断和告警问题。
Namespace:产生事件的对象所在的命名空间。
Kind:绑定事件的对象的类型,例如:Node、Pod、Namespace、Componenet等等。
Timestamp:事件产生的时间等等。
Reason:产生这个事件的原因。
Message: 事件的具体描述。
[root@master work]# kubectl get event --all-namespaces
LAST SEEN TYPE REASON OBJECT MESSAGE
default 14m Normal Created pod/busybox2 Created container busybox
default 14m Normal Started pod/busybox2 Started container busybox
default 24m Warning Failed pod/litemall-all-584bfdcd99-q6wd2 Error: ErrImagePull
default 4m47s Warning Failed pod/litemall-all-584bfdcd99-q6wd2 Error: ImagePullBackOff
针对Kubernetes的事件监控场景,Kuernetes社区在Heapter中提供了简单的事件离线能力,后来随着Heapster的废弃,相关的能力也一起被归档了。为了弥补事件监控场景的缺失,阿里云容器服务发布并开源了kubernetes事件离线工具kube-eventer。支持离线kubernetes事件到钉钉机器人、SLS日志服务、Kafka开源消息队列、InfluxDB时序数据库等等。
GitHub地址:https://github.com/AliyunContainerService/kube-eventer
下面是以企业微信机器人告警发送为例:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kube-eventer
rules:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kube-eventer
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: kube-eventer
subjects:
apiVersion: v1
data:
content: >-
{“msgtype”: “text”,“text”: {“content”: “EventType:{{ .Type }}\nEventNamespace:{{ .InvolvedObject.Namespace }}\nEventKind:{{ .InvolvedObject.Kind }}\nEventObject:{{ .InvolvedObject.Name }}\nEventReason:{{ .Reason }}\nEventTime:{{ .LastTimestamp }}\nEventMessage:{{ .Message }}”}}
kind: ConfigMap
metadata:
name: custom-webhook-body
namespace: kube-system
效果: