如何扩展单个Prometheus实现近万Kubernetes集群监控？

最新推荐文章于 2024-07-22 17:23:05 发布

「已注销」

最新推荐文章于 2024-07-22 17:23:05 发布

阅读量1.4k

点赞数 3

文章标签：云计算容器 kubernetes docker 运维

本文链接：https://blog.csdn.net/yunxiao6/article/details/108326880

版权

本文介绍了TKE团队在监控近万个Kubernetes集群时遇到的挑战，包括Prometheus性能瓶颈、采集周期长、存储限制等问题。通过设计Kvass系统，实现了可扩展、高可用的Prometheus集群，采用Thanos实现统一存储，解决了跨集群查询和长期存储的需求。Kvass提供全局视图和原生告警，简化了运维难度。

摘要由CSDN通过智能技术生成

引言

TKE团队负责公有云，私有云场景下近万个集群，数百万核节点的运维管理工作。为了监控规模如此庞大的集群联邦，TKE团队在原生Prometheus的基础上进行了大量探索与改进，研发出一套可扩展，高可用且兼容原生配置的Prometheus集群系统，理论上可支持无限的series数目和存储容量，支持纳管TKE集群，EKS集群以及自建K8s集群的监控诉求。

本文从TKE的架构出发，逐步介绍了整个监控系统的演进过程，包括早期的方案和遇到的问题，社区方案的瓶颈，我们的改进原理等。

TKE架构简介

为了让读者更好理解我们的场景，我们首先简单介绍一下TKE的基础架构。

TKE团队是公有云界首家采用Kubernetes in Kubernetes进行集群联邦管理的Kubernetes运营团队，其核心思想就是用一个Meta Cluster来托管其他集群的apiserver，controller-manager，scheduler，监控套件等非业务组件，在Meta Cluster中的组件对用户而言是隐藏的，如下图所示。

上图Meta Cluster中的组件对于用户而言都是隐藏的。支撑环境服务用于直接处理来至TKE控制台的请求。

Meta Cluster用于管理集群的控制面板组件，如apiserver等
Meta Cluster中还与一些隐藏的功能组件，例如监控组件
支撑服务用于接收来至控制台的请求，并连接到用户集群进行实际操作

早期的监控方案

需求

TKE早期监控方案不支持用户添加业务相关的监控指标，只包括集群运维关注的监控，主要希望监控的目标如下：

每个用户集群的核心组件监控，如apiserver, scheduler, controller-manager等
每个用户集群的基础资源监控，如Pod状态，Deployment负载，集群总负载等
Meta Cluster中所有组件的监控，包含Cluster-monitor自身，一些Meta Cluster自身的addon组件等
支撑环境组件的监控，如支持web server服务处理成功率，外部接口调用成功率等

架构

集群级别

在上一节的TKE架构图中，我们在Meta Cluster中看到每个集群有一套Cluster-monitor组件，该组件就是单集群级别的监控采集套件。Cluster-monitor包含了以Prometheus为核心的一系列组件，其基本功能就是采集每个用户集群的基础监控数据，例如Pod负载，Deployment负载，Node CPU使用率等，采集到的数据将直接写到云监控团队提供的Argus系统中存储于告警。核心组件如下图。

Barad：云监控提供的多维监控系统，是云上其他服务主要使用的监控系统，其相对成熟稳定，但是不灵活，指标和label都需要提前在系统上设置好。

Argus：云监控团队提供的多维业务监控系统，其特点是支持较为灵活的指标上报机制和强大的告警能力。这是TKE团队主要使用的监控系统。

数据流:

Prometheus从kubelet采集container负载信息，从kube-state-metrics采集集群元数据，比如Pod状态，Node状态等。数据在Prometheus进行聚合，产生固定的聚合指标，如container级别指标，Pod级别指标。采集到的数据写往两个地方，一部分数据写往Argus系统，这部分数据用于支撑TKE控制台上的监控面板及告警，另外一部分数据会写往Barad系统，这是因为更早时期的TKE支持在Barad控制台配置容器相关的告警，这份数据是为了使旧版告警能继续使用。
另外一条数据流是Barad-importer组件会从Barad(云监控)处拉取节点相关的数据，比如CPU使用率，内存使用率等，并将数据导入Argus系统，从而使得Argus也能进行节点相关的数据展示和告警。这里没有选择社区主流的node-exporter来收集节点数据是因为node-exporter需要在用户集群内部署Daemonset，而我们希望整个监控数据采集系统对用户是隐藏的。

这部分数据将通过控制台输出给用户

地域级别

成功采集到了属于每个用户集群的数据，但是，对于一些地域级别的监控，包括

Meta Cluster中的管理组件
Cluster-monitor组件自身
整个地域级别的集合信息，如总集群数，集群平均节点数，平均创建时间等数据

通过单个Cluster-monitor无法采集。需要构建更上一级的地域级别监控。

Region Prometheus不仅拉取如meta cluster operator，meta cluster service controller等核心组件的数据外，还通过Prometheus联邦接口拉取Cluster-monitor中的单集群数据进行二次聚合，产生地域级别集群的数据。地域级别数据直接存在本地，不写往Argus，因为这部分数据需要对接Grafana，由团队内部使用。