我对K8s监控的看法

做监控的过程

万事开头难,某天领导甩给你一个环境,说:小明给把环境监控起来。小明该怎么做呢?如果我是小明,我会分三个阶段考虑这个问题:
我对K8s监控的看法_第1张图片
1个where和两个how,接下来我们一个一个的解决。

where

数据源有哪些呢?? ,考虑一下k8s的架构,我总结如下:
我对K8s监控的看法_第2张图片

  • K8s方面
    K8s服务本身、k8s内部部署的应用、k8s的资源(pod,deployment,daemonset等等)
  • ETCD层面
    作为k8s的存储,我们应该监控 etcd的服务
  • Linux层面
    K8s部署在操作系统之上,我们有理由监控操作系统

第一个How

怎么取到这些数据呢?? , 先上一张图
我对K8s监控的看法_第3张图片
上图是K8s官网给的监控架构的图,我们看到上图分为两个颜色,为什么是两个颜色的?
k8s把监控指标分为两部分,核心和自用。(1)核心包括node、pod、容器的信息以及一个资源评估,其中资源评估是从kubelet抽取资源数据,然后进行汇总计算后发送给api-server,以供调度器使用。核心指标的设计是为了满足k8s内部的功能,可以理解为k8s自用的。(2)自定义指标则是用户运用自己的手段提取的指标,说白了就是你想要什么你自己搞,我k8s不Care。
我对K8s监控的看法_第4张图片

  • 提取核心指标
    核心指标的提取是通过metric-server完成。metric-server提取核心指标的数据,发送给apiserver,然后供调度器、HPA、Top使用
    我对K8s监控的看法_第5张图片
  • 为什么apiserver自己不去提取呢
    我对K8s监控的看法_第6张图片
    (1)k8s从1.7能支持5000个node,每个node上30个pod。假如我们每分钟每个pod抽取30个指标,最终apiserver要额外增加每秒抽取25000个指标的能力 (2)metrics复用性差,今天的数据明天很少用到;再者metric是可以重复获取;如果是apiserver抽取这些数据,就有可能要存取到ETCD中,这样就会增加etcd的压力。
    因此,metrics-server就诞生了,metrics-server使用内存存储,不考虑历史数据的持久存储。官网中提到一个Infrastore接口,用于解决持久存储的问题,好像这个接口还没有(此处可能不准确)。
    我对K8s监控的看法_第7张图片
  • 提取自定义指标
    我对K8s监控的看法_第8张图片
    (1) operator是在k8s环境中操作PrometheUS的入口,如果我们想在k8s里面添加一个告警规则,需要创建alertmanager一个资源,而不像往常的环境,修改配置文件。
    (2) k8s组件在启动的时候,自带了metric接口,可以使用PrometheUS直接抽取
    (3)pod或者deployment这样的资源,需要使用kube-state-metrics聚合后,才能被PrometheUS抽取
    (4) 操作系统或者其他的指标,需要我们借助node-exporter或者自己开发的exporter抽取数据
  • 自定义指标也可以给HPA使用,如下图:
    我对K8s监控的看法_第9张图片
    至此数据我们都拿到了

第二个How

数据怎么展现呢
我个人认为数据可以通过告警和大屏两种方式展现给用户。

  • 告警
    我觉得告警最起码要具有多途径和审计两个特点。其中审计用于确定我们的告警是否真正的发送出去,这个特点往往会被忽略,因为发送告警和发告警基本上都是两个系统,而发告警的系统往往会被建设的比较简陋。
  • 大屏
    大屏一般会在故障发生或者巡检中被用到,结合这些用途我认为要有总分、直观、可回溯这三个特点。
    (1)总分。要有几个全局dashboard,通过全局dashboard就能了解全局,不用再去看细节的dashboard。当在全局dashboard发现问题的时候,然后进入细节的dashboard查看问题
    (2)直观,就是通过dashboard一眼看出问题,换句话说就是合理的使用图表
    (3)可回溯,对于某些指标要能从dashboard中查看历史的指标
    我自己也制作一版grafana的dashboard,https://github.com/goingHan/k8s-grafana-dashboard-

如果对本文有疑问或者发现不对的地方,希望能给予评论或者进群630300475,讨论一下。

你可能感兴趣的:(k8s,k8s,grafana)