酷应用

「K8s 技术落地实践」从平台到应用，Prometheus在K8s上的监控实践

百家作者：QingCloud 2019-09-02 12:06:29

「K8s 技术落地实践」武汉站，QingCloud 研发团队分享了我们在 Kubernetes 多租户与多集群告警、CI/CD、监控等内容上的经验和解决方案，小编在这里为大家做了总结梳理，让我们共同回顾一下本次分享的技术内容。PPT 资料已经打包好，扫码或点击文末原文链接即可下载?

K8s 技术落地实践资料下载

一、Kubernetes 上的多租户与多集群告警实践

SPEAKER：霍姣

介绍：K8s 上支持高并发创建、高性能运行告警，同时支持告警服务水平扩展、告警自身健康检查、告警节点自动故障迁移的功能；此外，告警服务提供多租户、自定义告警规则、告警抑制、发送时间段控制、灵活的通知方式等功能。

KubeSphere® 告警需求

KubeSphere® 作为 Kubernetes 的发行版，我们知道它支持多租户，可以通过图形界面配置和观察告警状态我们知道它有图形界面的。告警同样有界面配置告警、管理告警、查看告警状态的需求。我们第一版做的告警主要是基于监控指标的告警，就像刚刚看到监控系统得到监控值，我们对它进行判断，大于某个阈值或者小于某个阈值，判断周期连续超过多少次就会产生告警。

KubeSphere® 告警系统架构

从刚才的需求可以看出我们的告警主要包括几部分：

首先，我们的 Alertmanager 实现的是跟用户进行交互，它提供了一套 CRUD 的接口，接受用户过来的增、删、改、查等具体告警需求。最关键的部分是 Manager、Executor、Watch，这三个角色，Manager 负责跟用户交互，Executor 负责具体告警用户发过来新的告警，其使用和执行在这当中。Watch 是对告警集群的状态进行健康检查。

这样一套告警系统的架构主要实现的指标，首先它要有通用的、指标读取、通知发送、API 等组件都是通过内部标准 API 交互，要可转换，要针对不同的业务系统定制插件就可以完成适配。

要有高可用和动态伸缩，它的业务分配策略是刚才我们看到的，我们通过 MySQL 数据库中进行一致性，再通过 Redis 队列进行任务的分配。集群健康检查是通过 Watch 来进行的，有一个问题，目前在 K8s 中执行，我们由 K8s 保证集群中的 Watch 可以用。在其他的地方，我们也要保证在这个集群有多个 Executor，并且被一个 Watch 管理，管理者本身要有一个健康的管理。

微服务架构，我们一个服务过来，API 完成后立刻将任务置于某个状态，再由下面具体的执行者执行，这是一套微服务架构。基础 API 是针对告警的某一条规则或者告警资源来的，我们会封装出适合界面使用的，一次调用就可以完成大部分功能的 API，实现 API 的可扩展性。

我们的告警是开源项目，在 KubeSphere® 这个大项目下，欢迎大家的关注。

二、K8s 监控之路：从平台到应用

SPEAKER：黄广喆

介绍：从传统的主机监控，到云时代容器化应用监控，Prometheus 提供了一体化的解决方案。Prometheus 集成了数据采样、分析、存储和告警等多种功能，是容器生态下监控的首选方案。在实际生产和测试中，我们需要持续关注平台、应用级监控指标，通过它们分析性能瓶颈、验证测试结果、实现水平伸缩从而高效运维。

背景及介绍

监控系统是整个企业 IT 架构中的重中之重，小到故障排查、问题定位，大到业务预测、运营管理，都离不开稳定可靠的监控系统。在云原生时代，传统的监控方案已难以满足一些监控场景，比如跨主机资源对象的持续数据收集和监控。

为了解决这些痛点，Prometheus 项目应运而生。Prometheus 是云原生领域最受认可的时间序列监控解决方案，在 2016 年加入 CNCF 基金会后，成为继 K8s 后第二个毕业项目。Prometheus 已经成为云原生监控领域的事实标准。

相比于传统的监控，Prometheus 有以下几个优势：

高效存储引擎

Prometheus 把用户关心的监控场景以时序数据的形式进行采集、存储和处理到时序数据库。相比关系数据库，监控数据存储在基于时间序列的数据库内，便于对已有数据进行新的聚合，在高并发的情况下，读写性能是远高过传统的关系型数据库的

Prometheus 2.0 版本重构了底层时序存储引擎。目前，单个 Prometheus 服务器可以做到每秒存储百万条指标数据，同时占用磁盘空间也很小。（Prometheus 会将所有采集到的样本数据以时间序列(time-series)的方式保存在内存数据库中，并且定时保存到硬盘上）

强大的查询能力：PromQL

Prometheus 有独立的 PromQL 查询语言，另外还提供了很多内置的基于时间的处理函数，降低数据聚合的难度。

面向服务的架构

Prometheus 采用拉模型收集时序数据，数据拉取行为是由服务端来决定的。服务端可以通过某种服务发现机制来自动发现监控对象。而对于推模型的监控系统，客户端需要负责在服务端上进行注册及监控数据推送，这在微服务架构里实现起来比较难的。当大量客户端向服务的主动推送数据时，服务端的压力较大。

与 K8s 天然集成

K8s 本身的指标也是以 Prometheus 格式暴露出来的。

逐步完善的生态

OpenMetrics：Prometheus 的数据格式逐渐成为一种标准。OpenMetrics 正在从 Prometheus 的数据格式中分离出来，逐渐成为监控数据格式的国际标准

Thanos：支持数据存储的可伸缩，弥补 Prometheus 数据持久化方面的不足Prometheus

Prometheus Operator：简化 Prometheus 配置管理

也许我们现在看这些 feature 觉得理所当然，但是当时 Prometheus 发布的时候，是非常吸引人的。

Prometheus 的架构

Prometheus 如何工作？我们能用 Prometheus 做些什么？

首先，用户编写客户端程序，为需要监控的服务生成相应的指标并暴露给 Prometheus 服务器。Prometheus 通过 HTTP 协议周期性抓取被监控组件的状态，任意组件只要提供对应 /metrics 接口就可以接入监控。不需要任何其他的集成过程，这样做非常适合做虚拟化环境监控系统。

对于不适合自己编写客户端程序的场景，比如第三方应用监控、物理节点监控、K8s 集群监控，Prometheus 提供了 exporter 来暴露第三方应用指标，比如 mysql exporter。还有我们使用比较多 node exporter 和 kube-state-metrics exporter，这些都是 Prometheus 官方在维护。

Prometheus 把监控数据存储在本地的时序数据库中，缺少数据副本，这是 Prometheus 在数据持久化方面做的不足的地方。这是因为 Prometheus 开发团队聚焦核心，只开发单节点的 Prometheus。但 Prometheus 也提供 remote_write 的方式，支持将数据存储到其他时序数据库中。比较常见的持久化方案有：Cortex、InfluxDB、Thanos

Prometheus 支持通过 Kubernetes、静态文本、Consul、DNS 等多种服务发现方式来指定抓取目标的监控数据。最后，用户编写 PromQL 语句查询数据并进行可视化。

Prometheus 在 K8s 部署的架构图

这张图是我们在 K8s 容器平台上部署 Prometheus 的架构。左下角 Prometheus 可以从 Kubernetes 集群的各个组件中采集监控数据，比如 kubelet 中自带的 cadvisor 提供的容器相关指标数据，API Server 提供 QPS 数据等。

上面两个 Prometheus 副本提供 HA 的能力，以负载均衡的方式对外提供 API。数据可视化界面和告警模块会用到Prometheus 提供的监控 API，中间的 Prometheus Operator，提供自动化管理和配置 Prometheus。

我们来看一下 Prometheus 的数据模型：

Prometheus 采用的是时序数据模型 time-series，时序数据是按照时间戳序列存放。每一条时间序列由指标名称 metric name 和一组标签 labelset 命名。对于相同的度量名称，通过不同标签列表的结合, 会形成特定的度量维度实例。这里是实时采集 node exporter 指标的一个例子，自增 counter 类型的指标，反应节点各 CPU 不同模式下的运行时间。

总结来说，time-series 中的每一行数据称为一个 sample ，sample 由以下三部分组成：

指标(metric) ：metric name 和描述当前样本特征的 labelset

时间戳(timestamp)：一个精确到毫秒的时间戳。

样本值(value)：一个 float64 的浮点型数据表示当前样本的值。 4

Prometheus 配置管理

Prometheus 配置管理是很麻烦的，需要手动。Prometheus 配置分两种：

不可变的启动参数

包括最大连接数、数据存储路径、数据最大保留时长。对 Prometheus 不可变参数进行升级，我们需要手动移除已经运行的 Pod 实例，从而让 Kubernetes 可以使用最新的配置文件创建 Prometheus。

Prometheus 采集参数配置

包括监控对象的列表、recording rules 等。修改这类配置需要在修改后，手动调用 reload 接口。

对于较少 Prometheus 实例，可以手动修改配置。如果实例的数量更多时，通过手动的方式部署和升级 Prometheus 过程繁琐并且效率低下。我们可以使用 Prometheus Operator 以声明式配置的方式实现自动化配置管理。

上图是 Prometheus Operator 官方提供的架构图，其中 Operator 是最核心的部分，作为一个控制器，它会持续观察 Prometheus、ServiceMonitor、以及 PrometheusRules 3 个 CRD 资源对象，并维持 Prometheus Server 的状态。

其中创建的 Prometheus 这个 CRD 是作为 Prometheus Server 存在，而 ServiceMonitor 负责定位 exporter，exporter 前面我们已经学习了，是专门用来提供 metrics 数据接口的客户端程序，Prometheus 通过 ServiceMonitor 提供的监控对象列表去 pull 数据的，这样我们要在集群中监控什么数据，就变成了直接去操作 Kubernetes 集群的 CRD 资源对象，方便了很多。

我们也在为 Prometheus 开源社区作贡献。

三、基于 Kubernetes 的 Serverless Jenkins——Jenkins X

SPEAKER：夏润泽

介绍：所谓现代化，与传统 Jenkins 不同，传统 Jenkins 关注如何将流水线跑起来，Jenkins X 更贴近用户想法——当创建流水线的时候，用户想要的是什么？不是为了 DevOps 而 DevOps，而是获得更短的部署周期、更高的部署频率等等。即通过自动化「软件交付」和「架构变更」的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

设计理念

Jenkins 项目 2004 年从Hudson 项目诞生，大约 250,000的 Jenkins 服务器正在运行。Jenkins 在使用过程中，遇到单点故障、JVM 消耗资源多、Job 调度方式使 CI/CD 变得困难，以及 Jenkins 经常耗尽磁盘空间，需要定时任务或人工清理等挑战。

Jenkins X – 现代化的 CI / CD 工具，2018年 2 月从 JEP （Jenkins Enhancement Proposals）中诞生，使用 Kubernetes 的力量来构建现代化的 CI/CD 平台，为用户提供自动化的 CI/CD，同时支持传统的与云原生的工作负载。

所谓现代化，与传统 Jenkins 不同，传统 Jenkins 关注如何将流水线跑起来，Jenkins X 更贴近用户想法——当创建流水线的时候，用户想要的是什么？不是为了 DevOps 而 DevOps，而是获得更短的部署周期、更高的部署频率等等。即通过自动化「软件交付」和「架构变更」的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

通过版本化所有制品、自动执行部署过程、使用基于主干的开发、实施持续集成、实施持续交付、使用松耦合架构、让团队成员获得动力等 DevOps 方法可以打造高性能的团队。

背后的技术

Draft 与Build Packs：本次演讲同时介绍了简化在 Kubernetes 应用创建的方法，通过使用 Draft 等工具，可以一键进行应用的创建及打包。