有道Kubernetes容器API监控系统设计和实践

1.背景

Kubernetes 已经成为事实上的编排平台的领导者、下一代分布式架构的代表，其在自动化部署、监控、扩展性、以及管理容器化的应用中已经体现出独特的优势。

在k8s容器相关的监控上， 我们主要做了几块工作，分别是基于prometheus的node、pod、k8s资源对象监控，容器服务API监控以及基于grafana的业务流量等指标监控。

在物理机时代，我们做了分级的接口功能监控——域名级别接口监控和机器级别监控，以便在某个机器出现问题时，我们就能快速发现问题。

上图中，左边是物理机时代对应的功能监控，包括域名级别接口监控和3台物理机器监控。右边是对应的k8s环境，一个service的流量会由k8s负载均衡到pod1，pod2，pod3中，我们分别需要添加的是service和各个pod的监控。

由于K8s中的一切资源都是动态的，随着服务版本升级，生成的都是全新的pod，并且pod的ip和原来是不一样的。

综上所述，传统的物理机API不能满足容器服务的监控需求，并且物理机功能监控需要手动运维管理， 为此我们期望设计一套适配容器的接口功能监控系统，并且能够高度自动化管理监控信息，实现pod API自动监控。

2.技术选型

为了满足以上需求，我们初期考虑了以下几个方案。

• 手动维护各个service 和pod 监控到目前物理机使用的podmonitor开源监控系统。
• 重新制定一个包含k8s目录树结构的系统，在这个系统里面看到的所有信息都是最新的， 在这个系统里面，可以做我们的目录树中指定服务的发布、功能监控、测试演练等。
• 沿用podmonitor框架，支持动态获取k8s集群中最新的服务和pod信息，并更新到监控系统中。

2.2方案分析

• 针对方案一，考虑我们服务上线的频率比较高，并且k8s设计思想便是可随时自动用新生成的pod（环境）顶替原来不好用的pod，手动维护pod监控效率太低，该方案不可行。
• 第二个方案应该是比较系统的解决办法，但需要的工作量会比较大，这种思路基本全自己开发，不能很好地利用已有的功能监控系统，迁移成本大。
• 于是我们选择了方案三 ，既能兼容我们物理机的接口功能监控方案，又能动态生成和维护pod监控。

3.整体设计思路

k8s监控包括以下几个部分：

其中API功能监控，是我们保证业务功能正确性的重要监控手段。

通常业务监控系统都会包含监控配置、数据存储、信息展示，告警这几个模块，我们的API功能监控系统也不例外。

我们沿用apimonitor框架功能，并结合了容器服务功能监控特点，和已有的告警体系，形成了我们容器API功能监控系统结构：

首先介绍下目前我们物理机使用的apimonitor监控&#