Kubernetes 指标监控技术
本文简单整理 Kubernetes 的监控技术，内容包括围绕 Prometheus 的监控架构、监控指标分类、Custom Metrics APIServer + Aggregator 来扩展 API Server 。【Kevin亓】
一、Kubernetes 核心监控体系
1.1 Prometheus 监控架构
Prometheus 核心机制：使用 Pull （抓取）的方式去搜集被监控对象的 Metrics 数据（监控指标数据），然后，再把这些数据保存在一个 TSDB （时间序列数据库，比如 OpenTSDB、InfluxDB 等）当中，以便后续可以按照时间进行检索。
有了这套核心监控机制， Prometheus 剩下的组件就是用来配合这套机制的运行。比如 Pushgateway，可以允许被监控对象以 Push 的方式向 Prometheus 推送 Metrics 数据。而 Alertmanager，则可以根据 Metrics 信息灵活地设置报警。当然， Prometheus 最受用户欢迎的功能，还是通过 Grafana 对外暴露出的、可以灵活配置的监控数据可视化界面。
1.2 核心监控指标分类
1、宿主机指标
这部分数据的提供，需要借助一个由 Prometheus 维护的Node Exporter 工具。一般来说，Node Exporter 会以 DaemonSet 的方式运行在宿主机上，代替被监控对象来对 Prometheus 暴露出可以被“抓取”的 Metrics 信息的一个辅助进程。
2、Kubernetes 各组件指标
来自于 Kubernetes 的 API Server、kubelet 等组件的 /metrics API，是用来检查 Kubernetes 本身工作情况的主要依据。
3、Kubernetes 核心概念指标
其中包括了 Pod、Node、容器、Service 等主要 Kubernetes 核心概念的 Metrics。其中，容器相关的 Metrics 主要来自于 kubelet 内置的 cAdvisor 服务。
- Metrics 规划原则
在具体的监控指标规划上有业界通用的 USE 原则和 RED 原则：USE 原则主要关注的是“资源”，比如节点和容器的资源使用情况，而 RED 原则主要关注的是“服务”，比如 kube-apiserver 或者某个应用的工作情况。
- USE 原则指的是，按照如下三个维度来规划资源监控指标：
（1）利用率（Utilization），资源被有效利用起来提供服务的平均时间占比；
（2）饱和度（Saturation），资源拥挤的程度，比如工作队列的长度；
（3）错误率（Errors），错误的数量。 - RED 原则指的是，按照如下三个维度来规划服务监控指标：
（1）每秒请求数量（Rate）；
（2）每秒错误数量（Errors）；
（3）服务响应时间（Duration）。
二、Kubernetes 自定义监控体系
Custom Metrics + Aggregator 来扩展 API Server：
说明：
- kube-aggregator 是一个根据 URL 选择具体的 API 后端的代理服务器；
- metric-server 是一个 Prometheus 时序数据库查询的 Adaptor。
- 首先，实现 Custom Metrics APIServer
Custom Metrics APIServer 本质就是一个 Prometheus 项目的 Adaptor。
工作原理是：当访问这个 URL 的时候，Custom Metrics APIServer 就会去 Prometheus 里查询相应指标的值，然后按照固定的格式返回给访问者。Prometheus 中指标的值自然是从 exportor 上采集存储的数据。
- 然后，扩展 Kubernetes 的 API Server
API Server 的扩展其实就是添加一个根据 URL 选择具体的 API 后端的代理服务器。
把 Custom Metrics APIServer 启动之后，Kubernetes 里就会出现一个叫作custom.metrics.k8s.io的 API。而当你访问这个 URL 时，借助 Aggregator APIServer 扩展机制，Aggregator 就会把请求转发给 Custom Metrics APIServer 。
《深入剖析Kubernetes | 极客时间》张磊，Kubernetes容器监控2讲