引言
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,由团队内部使用。
全网级别
我们在单地域监控的基础上又构建了一层全网级别的监控。用于监控
- 支撑环境组件监控
- 所有地域的Region Prometheus数据再聚合得到全网级别指标
全网数据也是给内部人员查看。
架构总览
逐渐暴露出的问题
上述介绍的架构虽然解决了我们对于大规模集群联邦的基本监控诉求,但是依旧存在几点不足。
Prometheus性能不足
原生Prometheus并不支持高可用,也不能做横