我对K8s监控的看法

做监控的过程

万事开头难，某天领导甩给你一个环境，说：小明给把环境监控起来。小明该怎么做呢？如果我是小明，我会分三个阶段考虑这个问题：

1个where和两个how，接下来我们一个一个的解决。

where

数据源有哪些呢？？ ，考虑一下k8s的架构，我总结如下：

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

第一个How

怎么取到这些数据呢?? ， 先上一张图

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

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

第二个How

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

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

---

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