容器平台监控面临的挑战

根据 CNCF 最新调查显示,有 38% 的用户认为监控是其应用 Kubernetes 遇到的最大挑战之一,随着企业规模的增长,这个比例甚至达到了 46%。这其中存在的重要原因是与传统监控相比,容器与微服务的监控面临着更多难点和考验,因为容器监控与传统监控的区别在于:

  • 监控频率不同:容器启停都是秒级,而且扩缩容也非常快,传统系统监控可能是分钟级的,容器系统监控是秒级的;
  • 数量级不同:传统的监控针对基础设备,数量较少,容器是运行在基础设施之上,每个节点可以支撑多个容器实例,容器数量通常是以前监控设备的数十倍以上;
  • 更偏向应用监控:容器随时可以启停,具备可以动态扩缩容等特点,应用的健康状况对用户来说更为重要。

KubeSphere 监控系统支持大规模系统监控、多指标监控、多维度监控,为每一个层级资源的运行状态都提供实时的多种指标监控,而且收集资源实时监控数据和历史监控数据,旨在帮助用户观察和建立资源和集群性能的正常标准。通过不同时间、不同负载条件下监测集群各项基础指标,并以图表或列表的形式展现。例如,用户可以监控集群和节点的 CPU 利用率、内存使用率和磁盘 I/O、网卡流量等物理层级的基础指标,还可以监控平台的企业空间、容器组 (Pod) 和容器的 CPU 使用量、内存使用量等指标,以及项目资源用量、资源用量趋势和服务组件的状态。监控数据支持按节点、企业空间或项目排行。KubeSphere 监控还提供逐级钻取能力,用户可以很方便地掌握资源和业务的运行情况并快速定位故障。

监控指标

KubeSphere 的监控中心包括 物理资源监控应用资源监控 两大类。通常,只有平台管理员 (cluster-admin) 或在该平台角色的权限列表中勾选了 查看监控管理 的用户才有权限在控制台查看监控中心,详见 物理资源监控应用资源监控

值得一提的是,监控中心支持用户按用量排序和自定义时间范围查询,帮助快速定位故障。

KubeSphere 对资源的监控从两条线提供多维度的监控指标,即

  • 管理员视角:Cluster -> Node -> Pod -> Container
  • 用户视角:Cluster -> Workspace -> Namespace -> Workload/Pod -> Container

监控指标

从上图中不难发现,平台的监控指标和 IaaS 层相似,也就是我们常见的 CPU、内存、磁盘和网络等四个方面的使用量和使用率。另外我们也提供主机的 inode 监控,Kubernetes 对镜像和日志都有回收机制,但没有对 inode 的回收或清理机制,有可能发生 inode 已经用光,但是硬盘还未存满的情况,此时已无法在硬盘上创建新文件,可能会造成整个集群中某个节点无法创建工作负载。

监控技术选型

KubeSphere 监控模块的设计和架构主要是采用了开源的解决方案,经过长时间的技术选型,最后选择了 Prometheus,主要原因有:

  • Prometheus 和 Kubernetes 天然集成,为 CloudNative 而设计,多种工具和服务纷纷推出适配的 Exporter,供 Prometheus 抓取,Prometheus + Grafana 逐渐成为监控告警的首选;
  • 采用主动拉数据的 Pull 模式,相当于有了数据获取 Agent 的能力;
  • 2.0 之后重写了底层时序数据存储层,针对时序数据特点优化,能利用更少的资源存储和查询更多的数据;
  • 灵活好用的查询语言 PromQL,能把 PromQL 嵌入 http 请求的强大的 API;
  • OpenMetrics 项目推动 Prometheus exposure format 成为监控数据的标准格式;
  • Prometheus Operator 打包了 Kubernetes 监控所需的所有必要组件,提供更丰富的监控数据;
  • 单节点处理海量数据的强大能力。

KubeSphere 监控中心的所有组件都是容器化且可以部署在 Kubernetes 之上。下图是目前 KubeSphere 监控系统以及即将集成的告警模块的设计架构。

架构

展望未来

目前 KubeSphere 监控中心已经具备了高可用和多维度的特性。在提供了监控之后,我们将在下一个版本支持创建告警、消息通知和日志收集等功能,支持根据给定阈值每隔一段时间发送告警,比如设置告警策略类型、告警规则和接收方式。