K8s中的监控 - 技术栈

文章目录

- - 监控类
  - [Kubernetes 的监控演进](#Kubernetes 的监控演进)
  - [Kubernetes 的监控接口标准](#Kubernetes 的监控接口标准)
  - [Prometheus - 开源社区的监控"标准"](#Prometheus - 开源社区的监控“标准”)
  - - [Prometheus 的主要特点：](#Prometheus 的主要特点：)
  - [kube-eventer - Kubernetes 事件离线工具](#kube-eventer - Kubernetes 事件离线工具)
  - - [kube-eventer 的主要功能：](#kube-eventer 的主要功能：)

监控类

先看一下监控，从监控类型上划分，在 K8s 中可以分成四个不同的类型：

资源监控（Resource Monitoring）

比较常见的像 CPU、内存、网络这种资源类的一个指标，通常这些指标会以数值、百分比的单位进行统计，是最常见的一个监控方式。这种监控方式在常规的监控里面，类似项目 zabbix telegraph，这些系统都是可以做到的。
性能监控（Performance Monitoring）

性能监控指的就是 APM 监控，也就是说常见的一些应用性能类的监控指标的检查。通常是通过一些 Hook 的机制在虚拟机层、字节码执行层通过隐式调用，或者是在应用层显示注入，获取更深层次的一个监控指标，一般是用来应用的调优和诊断的。

比较常见的类似像 jvm 或者 php 的 Zend Engine，通过一些常见的 Hook 机制，拿到类似像 jvm 里面的 GC 的次数、各种内存代的一个分布以及网络连接数的一些指标，通过这种方式来进行应用的性能诊断和调优。
安全监控（Security Monitoring）
- 安全监控主要是对安全进行的一系列的监控策略，类似像越权管理、安全漏洞扫描等等。
事件监控（Event Monitoring）

事件监控是 K8s 中比较另类的一种监控方式。

之前的文章为大家介绍了在 K8s 中的一个设计理念，就是基于状态机的一个状态转换。从正常的状态转换成另一个正常的状态的时候，会发生一个 normal 的事件，而从一个正常状态转换成一个异常状态的时候，会发生一个 warning 的事件。

通常情况下，warning 的事件是我们比较关心的，而事件监控就是可以把 normal 的事件或者是 warning 事件离线到一个数据中心，然后通过数据中心的分析以及报警，把相应的一些异常通过像钉钉或者是短信、邮件的方式进行暴露，弥补常规监控的一些缺陷和弊端。

Kubernetes 的监控演进

在早期，也就是 1.10 以前的 K8s 版本。大家都会使用类似像 Heapster 这样的组件来进行监控的采集，Heapster 的设计原理其实也比较简单。

首先，我们在每一个 Kubernetes 上面有一个包裹好的 cadvisor，这个 cadvisor 是负责数据采集的组件。当 cadvisor 把数据采集完成，Kubernetes 会把 cadvisor 采集到的数据进行包裹，暴露成相应的 API。在早期的时候，实际上是有三种不同的 API：

第一种是 summary 接口；
第二种是 kubelet 接口；
第三种是 Prometheus 接口。

这三种接口，其实对应的数据源都是 cadvisor，只是数据格式有所不同。在 Heapster 里面，其实支持了 summary 接口和 kubelet 两种数据采集接口，Heapster 会定期去每一个节点拉取数据，在自己的内存里面进行聚合，然后再暴露相应的 service，供上层的消费者进行使用。

在 K8s 中比较常见的消费者，类似像 dashboard，或者是 HPA-Controller，它通过调用 service 获取相应的监控数据，来实现相应的弹性伸缩，以及监控数据的一个展示。

这个是以前的一个数据消费链路，这条消费链路看上去很清晰，也没有太多的一个问题，那为什么 Kubernetes 会将 Heapster 放弃掉而转换到 metrics-service 呢？其实这个主要的一个动力来源是由于 Heapster 在做监控数据接口的标准化。为什么要做监控数据接口标准化呢？

第一点在于客户的需求是千变万化的，比如说今天用 Heapster 进行了基础数据的一个资源采集，到了第二天，我想在应用里面暴露在线人数的一个数据接口，放到自己的接口系统里进行数据的一个展现，以及类似像 HPA 的一个数据消费。这个场景在 Heapster 下能不能做呢？答案是不可以的，所以这就是 Heapster 自身扩展性的弊端；
第二点是 Heapster 里面为了保证数据的离线能力，提供了很多的 sink，而这个 sink 包含了类似像 influxdb、sls、钉钉等等一系列 sink。这个 sink 主要做的是把数据采集下来，并且把这个数据离线走，然后很多客户会用 influxdb 做这个数据离线，在 influxdb 上去接入类似像 grafana 监控数据的一个可视化的软件，来实践监控数据的可视化。

但是后来社区发现，这些 sink 很多时候都是没有人来维护的。这也导致整个 Heapster 的项目有很多的 bug，这个 bug 一直存留在社区里面，是没有人修复的，这个也是会给社区的项目的活跃度包括项目的稳定性带来了很多的挑战。

基于这两点原因，K8s 把 Heapster 进行了 break 掉，然后做了一个精简版的监控采集组件，叫做 metrics-server。

上图是 Heapster 内部的一个架构。大家可以发现它分为几个部分：

第一个部分是 core 部分，然后上层是有一个通过标准的 http 或者 https 暴露的这个 API；
然后中间是 source 的部分，source 部分相当于是采集数据暴露的不同的接口，然后 processor
的部分是进行数据转换以及数据聚合的部分；
最后是 sink 部分，sink 部分是负责数据离线的，这个是早期的 Heapster 的一个应用的架构。那到后期的时候呢，K8s做了这个监控接口的一个标准化，逐渐就把 Heapster 进行了裁剪，转化成了 metrics-server。
-
目前 0.3.1 版本的 metrics-server 大致的一个结构就变成了上图这样，是非常简单的：有一个 core 层、中间的 source 层，以及简单的 API 层，额外增加了 API Registration 这层。

Registration 层的作用就是它可以把相应的数据接口注册到 K8s 的 API server 之上，以后客户不再需要通过这个 API 层去访问 metrics-server，而是可以通过 API server 访问 API 注册层，再到 metrics-server。

这样的话，真正的数据消费方可能感知到的并不是一个 metrics-server，而是说感知到的是实现了这样一个 API 的具体的实现，而这个实现是 metrics-server。这个就是 metrics-server 改动最大的一个地方。

Kubernetes 的监控接口标准

Kubernetes 监控接口标准帮助确保各种监控工具和系统能够与 Kubernetes 平台无缝集成并且顺利工作。Kubernetes 提供了一些标准的 API 来实现监控数据的采集、查询和展示。

Kubernetes Metrics API
- Kubernetes 提供的 Metrics API 允许获取集群中节点、Pod 和容器的资源使用数据，主要包括 CPU 使用率、内存使用量等信息。该 API 是 Prometheus 等工具采集指标的基础。
- 例：/metrics 和 /metrics/cadvisor API 接口，分别提供集群资源和容器级别的资源使用情况。
Kubernetes Events API
- Kubernetes 事件提供了关于集群状态变化、故障、警告等信息。这些事件可以帮助开发者了解集群运行中的关键状态变化。
- 事件通常包括对象的创建、删除、调度、错误状态等信息。
Kubernetes Custom Metrics API
- 允许用户为特定应用创建自定义的监控指标，超出资源使用范围的应用性能或业务指标也能通过此 API 进行收集和管理。
Prometheus Exporters
- Kubernetes 中的各种资源（如容器、应用、存储）通常需要通过 Prometheus Exporters 进行数据暴露，Prometheus 可以通过 service discovery 功能自动发现需要监控的对象。
- Kubernetes 监控可以通过 Prometheus Operator 实现，支持动态的监控和自动发现服务。

Prometheus - 开源社区的监控"标准"

Prometheus 是一个由 CNCF（Cloud Native Computing Foundation） 维护的开源监控系统，它为 Kubernetes 提供了标准化的监控解决方案，特别适用于容器化和微服务架构的环境。

Prometheus 的主要特点：

多维数据模型：
- Prometheus 使用时间序列数据（time series data）存储监控信息，每个数据点由 时间戳 和 标签（labels） 组成，通过标签可以对不同应用、服务、实例等进行区分。
PromQL 查询语言：
- Prometheus 提供强大的查询语言 PromQL，可以执行复杂的聚合、过滤、计算等操作，对采集到的数据进行深度分析。
拉取模型（Pull Model）：
- Prometheus 采用拉取模型，定期从监控对象（如 Kubernetes 中的 Pod、节点）拉取指标数据。这种模式使得 Prometheus 可以更好地适应动态和弹性的环境。
服务发现（Service Discovery）：
- Prometheus 可以通过与 Kubernetes API 集成，动态发现和监控 Kubernetes 集群中的服务和 Pod。无需手动配置监控目标，自动适应容器和 Pod 的生命周期变化。
告警机制（Alerting）：
- Prometheus 集成了 Alertmanager，用于处理和发送告警。当监控数据达到某个阈值时，系统会自动触发告警，并通过邮件、Slack、PagerDuty 等通知渠道发送警报。
可视化支持：
- Prometheus 配合 Grafana 使用，能够提供强大的数据可视化功能，帮助用户实时监控系统和应用的性能。

kube-eventer - Kubernetes 事件离线工具

kube-eventer 是一个 Kubernetes 事件收集和处理工具，专门用于离线存储和处理 Kubernetes 集群中的事件数据。它可以帮助用户捕获 Kubernetes 中的事件，进行持久化存储和后续的分析。

kube-eventer 的主要功能：

收集事件：
- kube-eventer 会监听 Kubernetes 集群中的事件（如 Pod 创建、调度、删除等）并将其转发到外部存储系统（如 Kafka、Elasticsearch、InfluxDB 等）。
离线存储：
- 支持将 Kubernetes 事件数据存储在外部数据库中，使得事件数据可以离线处理和长期存储，便于后续分析和审计。
简化事件管理：
- 通过将事件收集和

存储进行分离，kube-eventer 可以帮助减轻 Kubernetes API Server 的负担，优化集群性能，并且将重要事件数据持久化，便于事后回溯和分析。

集成与告警 ：
- kube-eventer 可以与现有的监控系统集成，基于收集到的事件数据触发告警，帮助 DevOps 团队及时发现潜在的故障或异常。

综上所述，Kubernetes 的监控演进包括从基础的资源监控到更复杂的性能、事件和安全监控的逐步扩展。借助 Prometheus 、kube-eventer 等工具，Kubernetes 生态系统内的监控能力得到了极大增强，能够提供全面的可观测性和及时的故障响应。