容器平台监控面临的挑战

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