作者介绍

在过去的几年中，云计算已经成为及分布式计算最火热的技术之一，其中Docker、Kubernetes、Prometheus等开源软件的发展极大地推动了云计算的发展。本文首先从Prometheus是如何监控Kubernetes入手，介绍Prometheus Operator组件。接着详细介绍基于Kubernetes的两种Prometheus部署方式，最后介绍服务配置、监控对象以及数据展示和告警。通过本文，大家可以在Kubernetes集群的基础上学习和搭建完善的Prometheus监控系统。

Kubernetes使用Docker进行容器管理，如果说Docker和kubernetes的搭配是云原生时代的基石，那么Prometheus为云原生插上了飞翔的翅膀。随着云原生社区的不断壮大，应用场景越来越复杂，需要一套针对云原生环境的完善并且开放的监控平台。在这样的环境下，Prometheus应运而生，天然支持Kubernetes。

在Kubernetes的支持下，管理和伸缩Web应用、移动应用后端以及API服务都变得比较简单了。因为这些应用一般都是无状态的，所以Deployment这样的基础Kubernetes API对象就可以在无需附加操作的情况下，对应用进行伸缩和故障恢复了。

而对于数据库、缓存或者监控系统等有状态应用的管理，就是挑战了。这些系统需要掌握应用领域的知识，正确地进行伸缩和升级，当数据丢失或不可用的时候，要进行有效的重新配置。我们希望这些应用相关的运维技能可以编码到软件之中，从而借助Kubernetes 的能力，正确地运行和管理复杂应用。

Operator这种软件，使用TPR（第三方资源，现在已经升级为CRD）机制对Kubernetes API进行扩展，将特定应用的知识融入其中，让用户可以创建、配置和管理应用。与Kubernetes的内置资源一样，Operator操作的不是一个单实例应用，而是集群范围内的多实例。

Kubernetes的Prometheus Operator为Kubernetes服务和Prometheus实例的部署和管理提供了简单的监控定义。

安装完毕后，Prometheus Operator提供了以下功能：

• 创建/毁坏。在Kubernetes namespace中更容易启动一个Prometheus实例，一个特定的应用程序或团队更容易使用的Operato。

• 简单配置。配Prometheus的基础东西，比如在Kubernetes的本地资源versions， persistence，retention policies和replicas。

• Target Services通过标签。基于常见的Kubernetes label查询，自动生成监控target配置；不需要学习Prometheus特定的配置语言。

Prometheus Operator架构如图1所示。

架构中的各组成部分以不同的资源方式运行在Kubernetes集群中，它们各自有不同的作用。

• Operator：Operator资源会根据自定义资源（Custom Resource Definition，CRD）来部署和管理Prometheus Server，同时监控这些自定义资源事件的变化来做相应的处理，是整个系统的控制中心。

• Prometheus： Prometheus资源是声明性地描述Prometheus部署的期望状态。

• Prometheus Server： Operator根据自定义资源Prometheus类型中定义的内容而部署的Prometheus Server集群，这些自定义资源可以看作用来管理Prometheus Server 集群的StatefulSets资源。

• ServiceMonitor：ServiceMonitor也是一个自定义资源，它描述了一组被Prometheus监控的target列表。该资源通过标签来选取对应的Service Endpoint，让Prometheus Server通过选取的Service来获取Metrics信息。

• Service：Service资源主要用来对应Kubernetes集群中的Metrics Server Pod，提供给ServiceMonitor选取，让Prometheus Server来获取信息。简单说就是Prometheus监控的对象，例如Node Exporter Service、Mysql Exporter Service等。

• Alertmanager：Alertmanager也是一个自定义资源类型，由Operator根据资源描述内容来部署Alertmanager集群。

本节详细介绍Kubernetes通过YAML文件方式部署Prometheus的过程，即按顺序部署了Prometheus、kube-state-metrics、node-exporter以及Grafana。图2展示了各个组件的调用关系。

在Kubernetes Node上部署Node exporter，获取该节点物理机或者虚拟机的监控信息，在Kubernetes Master上部署kube-state-metrics获取Kubernetes集群的状态。所有信息汇聚到Prometheus进行处理和存储，然后通过Grafana进行展示。

部署对外可访问Prometheus，首先需要创建Prometheus所在命名空间，然后创建Prometheus使用的RBAC规则，创建Prometheus的configmap来保存配置文件。创建service进行固定集群IP访问，创建deployment部署带有Prometheus容器的pod，最后创建ingress实现外部域名访问Prometheus。

部署顺序如图3所示。

创建名为monitoring命名空间，相关对象都部署到该命名空间，使用以下命令创建命名空间：

ns-monitoring.yaml文件内容如下：

可以看到该YAML文件使用的apiVersion版本是v1，kind是Namespace，命名空间的名字是monitoring。

使用以下命令确认名为monitoring的ns已经创建成功：

创建RBAC规则，包含ServiceAccount、ClusterRole、ClusterRoleBinding三类YAML文件。Service Account 是面向命名空间的，ClusterRole、ClusterRoleBinding是面向整个集群所有命名空间的，可以看到ClusterRole、ClusterRoleBinding对象并没有指定任何命名空间。ServiceAccount中可以看到，名字是prometheus-k8s，在monitoring命名空间下。ClusterRole一条规则由apiGroups、resources、verbs共同组成。ClusterRoleBinding中subjects是访问API的主体，subjects包含users、groups、service accounts三种类型，我们使用的是ServiceAccount类型，使用以下命令创建RBAC：

rometheus-rbac.yaml文件内容如下：

使用以下命令确认RBAC是否创建成功：

使用ConfigMap方式创建Prometheus配置文件，YAML文件中使用的类型是ConfigMap，命名空间为monitoring，名称为prometheus-core，apiVersion是v1，data数据中包含prometheus.yaml文件，内容是prometheus.yaml: |这行下面的内容。使用以下命令创建Prometheus的配置文件：

prometheus-core-cm.yaml文件内容如下：

由于篇幅有限，该配置文件只有一个名为kubernetes-apiservers的job，完整配置请查看源码文件。

使用以下命令查看已创建的配置文件prometheus-core：

通过以下命令查看配置文件prometheus-core的详细信息：

创建prometheus rules配置文件，使用ConfigMap方式创建prometheus rules配置文件，包含的内容是两个文件，分别是node-up.yml和cpu-usage.yml。使用以下命令创建Prometheus的另外两个配置文件：

prometheus-rules-cm.yaml文件内容如下：

本节的配置文件是Prometheus告警信息的配置文件，篇幅有限，可在文件后继续增加告警信息文件。

使用以下命令查看已下发的配置文件prometheus-core：

使用以下命令查看配置文件prometheus-core详细信息：

创建prometheus svc，会生成一个CLUSTER-IP进行集群内部的访问，CLUSTER-IP也可以自己指定。使用以下命令创建Prometheus要用的service：

prometheus-service.yaml文件内容如下：

使用以下命令查看已创建的名为prometheus的service：

使用deployment方式创建prometheus实例，命令如下：

prometheus-deploy.yaml文件内容如下：

使用以下命令查看已创建的名字为prometheus-core的deployment的状态：

返回信息表示部署期望的pod有1个，当前有1个，更新到最新状态的有1个，可用的有1个，pod当前的年龄是1天。

创建prometheus ingress实现外部域名访问，使用以下命令创建Ingress：

prometheus_Ingress.yaml文件内容如下：

将prometheus.test.com域名解析到Ingress服务器，此时可以通过prometheus.test.com访问Prometheus的监控数据的界面了。

使用以下命令查看已创建Ingress的状态：

将域名prometheus.test.com指向Ingress服务器，并访问该域名，主界面如图4所示。

kube-state-metrics使用名为monitoring的命名空间，在上节已创建，不需要再次创建，通过以下命令确认ns创建是否成功：

创建RBAC，包含ServiceAccount、ClusterRole、ClusterRoleBinding三类YAML文件，本节RBAC内容结构和上节中内容类似。使用以下命令创建kube-state-metrics RBAC：

kube-state-metrics-rbac.yaml文件内容如下：

使用以下命令确认RBAC是否创建成功，命令分别获取已创建的ServiceAccount、ClusterRole、ClusterRoleBinding：

使用以下命令创建kube-state-metrics Service：

kube-state-metrics-service.yaml文件内容如下：

使用以下命令查看名为kube-state-metrics的Service：

使用以下命令创建名为kube-state-metrics的deployment，用来部署kube-state-metrics Docker容器：

kube-state-metrics-deploy.yaml文件内容如下：

使用以下命令查看monitoring命名空间下名为kube-state-metrics的deployment的状态信息：

使用以下命令查看相关的详细信息：

通过上节已部署的Prometheus界面如图5所示。

在Prometheus中负责数据汇报的程序统一称为Exporter，而不同的Exporter负责不同的业务。它们具有统一命名格式，即xx_exporter，例如，负责主机信息收集的node_exporter。本节为安装node_exporter的教程。node_exporter主要用于*NIX系统监控，用Golang编写。

node-exporter使用名为monitoring的命名空间，上节已创建，不需要再次创建，通过以下命令确认ns创建是否成功：

使用以下命令部署node-exporter service：

node_exporter-service.yaml文件内容如下：

使用以下命令查看monitoring命名空间下名为prometheus-node-exporter的service：

使用daemonset方式创建node-exporter容器，命令如下：

node_exporter-daemonset.yaml文件详细内容如下：

查看monitoring命令空间下名为prometheus-node-exporter的daemonset的状态，命令如下：

从返回信息可以看到，名为prometheus-node-exporter的daemonset，当前有3个实例，都已经是Ready状态，都可用。

查看monitoring命令空间下名为prometheus-node-exporter的daemonset的详细状态信息，命令如下：

Grafana使用名为monitoring的命名空间，前面小节已经创建，不需要再次创建，通过以下命令确认ns创建是否成功：

使用以下命令创建Grafana Service：

grafana-service.yaml文件内容如下：

使用以下命令查看monitoring命令空间下名为grafana的service的信息：

使用deployment方式部署Grafana，命令如下：

grafana-deploy.yaml文件内容如下：

查看monitoring命令空间下名为grafana-core的deployment的状态，信息如下：

要查看monitoring命令空间下名为grafana-core的deployment的详细信息，使用以下命令：

创建grafana ingress实现外部域名访问，命令如下：

grafana-ingress.yaml文件内容如下：

查看monitoring命名空间下名为traefik-grafana的Ingress，使用以下命令：

查看monitoring命名空间下名为traefik-grafana的Ingress的详细信息，使用以下命令：

将grafana.test.com解析到Ingress服务器，此时可以通过grafana.test.com访问Grafana的监控展示的界面。

传统方式部署步骤相对复杂，随着Operator的日益成熟，推荐使用Operator方式部署Prometheus。通过Operator方式部署Prometheus，可将更多的操作集成到Operator中，简化了操作过程，也使部署更加简单。本节详细介绍在Kubernetes中使用Operator方式部署整套Prometheus监控。

部署Prometheus依赖的基础环境如下：

• Kubernetes版本为1.14.0。

• helm版本为v2.13.1。

• 按需要安装coreDNS、Nginx。

本节使用Helm安装。Helm chart根据实际使用修改。

使用git下载prometheus-operator源码，并进入到源码目录，如下所示：

使用git将软件切换到v0.29.0版本，并进入到helm目录：

使用helm在名为monitoring的命名空间下安装prometheus-operator，命令如下：

使用helm命令查看安装结果，命令如下：

创建kube-prometheus/charts目录，使用如下命令：

使用Helm打包kube-prometheus所依赖的chart包，命令如下：

使用Helm在名为monitoring的命名空间下安装kube-prometheus，具体命令如下：

使用以下命令查看安装结果：

本节主要介绍Prometheus的静态配置和服务发现配置，以及静态配置和动态服务发现配置的用法。

静态配置是Prometheus中简单的配置，指定获取指标的地址，并分配所获取指标的标签。Prometheus最简单的配置是静态目标，如下配置文件：

scrape_configs表示定义收集规则，指定了：localhost:9090和localhost:9100作为获取信息的地址，并给获取的信息打上了group=prometheus的标签。

Prometheus支持多种服务发现机制：文件、DNS、Consul、Kubernetes、OpenStack、EC2等。基于服务发现的过程并不复杂，通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮训这些Target获取监控数据，下面主要介绍Kubernetes服务发现机制。

目前，在Kubernetes下，Prometheus通过与Kubernetes API集成主要支持5种服务发现模式：Node、Service、Pod、Endpoints、Ingress。不同的服务发现模式适用于不同的场景，例如：node适用于与主机相关的监控资源，如节点中运行的Kubernetes组件状态、节点上运行的容器状态等；service和igress适用于通过黑盒监控的场景，如对服务的可用性以及服务质量的监控；endpoints和pod均可用于获取Pod实例的监控数据，如监控用户或者管理员部署的支持Prometheus的应用。

以下配置文件指定了间歇时间是30s，超时间是10s，从目标获取数据的http路径是

/metrics，使用http协议。kubernetes服务发现配置列表中指定了服务发现模式为endpoints，命名空间为monitoring。relabel_configs允许在抓取之前对任何目标及其标签进行修改：

以上配置文件对应Prometheus服务发现界面中monitoring/kube-prometheus/0，如图6所示。

Prometheus可以监控Kubernetes非常多的对象，本节主要介绍Docker容器、kube-apiserver、kube-state-metrics以及主机等几个方面。完整的Targets可以通过Prometheus界面查看，如图7所示。

Kubernetes直接在Kubelet组件中集成了cAdvisor，cAdvisor会自动采集当前节点上容器CPU、内存、文件系统，网络等资源的使用情况。以下是Prometheus配置中容器监控的部分代码：

以上配置文件指定了间歇时间为30s，超时间为10s，从目标获取数据的http路径是

/metrics/cadvisor，使用https协议，指定了服务发现模式为endpoints，命名空间为kube-system，指定了token file和tls ca file。relabel_configs允许在抓取之前对任何目标及其标签进行修改，指定了source_labels为__meta_kubernetes_service_label_k8s_app。

apiserver的监控主要是kube-apiserver，配置文件与容器监控类似。Prometheus配置中关联job的部分配置文件如下：

kube-state-metrics关注于获取Kubernetes中各种资源的最新状态，如deployment或者daemonset。prometheus中关联kube-state-metrics的部分配置文件内容如下：

主机监控是通过node-exporter组件来获取操作系统层面信息的，关联配置文件如下：

随着业务越来越复杂，对软件系统的要求也越来越高，这意味着我们需要随时掌控系统的运行情况。因此，对系统的实时监控以及可视化展示，就成了基础架构的必须能力。Grafana是一个跨平台开源的度量分析和可视化工具，可以将采集的数据查询可视化地展示，并及时通知。

前面小节讨论监控数据的收集和部分处理，本节会使用已收集并处理的数据，通过Grafana展示到Web界面。主要包括在Kubernetes中部署、配置和使用Grafana。

使用helm在名为monitoring的命名空间下安装Grafana。命令如下：

使用以下命令查看安装结果：

把服务alertmanager、grafana-grafana、kube-prometheus的类型改为NodePort。使用如下命令获取service的信息：

使用如下命令编辑修改alertmanager、grafana-grafana、kube-prometheus的service，将服务类型修改为NodePort：

安装完成后可以打开Grafana界面，通过如下命令获取开放的端口号：

打开http://192.168.99.101:30747配置界面，点击添加数据源。填写Prometheus数据源名称类型以及HTTP URL，保存并测试。测试通过后，添加或导入所需模板。点击主界面Create--->import，上传或粘贴所需JSON文件，点击Load。Grafana官方模板下载地址为：

Grafana有许多可以使用的插件，参见官网：

根据前几节的安装配置，可以自由配置展示监控内容。在Grafana界面可以查看所有已存在的仪表盘模板列表、已部署的pod、deployment、statefulset，如图8至图10所示。

导入主机信息模板，该模板使用Node-exporter获取的数据，展示如图11所示。

随着业务复杂性的增加，告警系统越来越重要，及时有效的告警可以在故障到来之前，提前预知风险，提前处理问题，将不良影响最小化。

使用Prometheus进行告警分为两部分。Prometheus服务器中的警报规则会向Alertmanager发送警报。然后，Alertmanager管理这些警报，包括静音、禁止、聚合，以及通过电子邮件、PagerDuty和HipChat等方法发送通知。

设置告警和通知的主要步骤如下：

• 设置并配置Alertmanager。

• 配置Prometheus与Alertmanager协同信息。

• 在Prometheus中创建告警规则。

使用helm在名为monitoring的命名空间下安装Alertmanager，命令如下：

使用以下命令查看安装结果：

Prometheus与Alertmanager关联配置文件信息如下：

在Prometheus全局配置文件中，通过rule_files指定一组告警规则文件的访问路径，配置文件如下：

默认部署中包含alertmanager.rules、kube-scheduler.rules、general.rules等rules。本节不做详细介绍。

在某些情况下除了Alertmanager已经内置的集中告警通知方式以外，对于不同的用户和组织而言还需要一些自定义的告知方式。通过Alertmanager提供的webhook支持可以轻松实现这一类的扩展。

首先需要申请微信企业号，申请地址为：

在Alertmanager配置文件中，加入微信配置信息即可：

Kubernetes与Prometheus有着十分相似的历程，均是源自Google内部多年的运维经验，并且相继从CNCF基金会正式毕业。它们分别代表了云原生模式下容器编排以及监控的事实标准。

本文首先介绍了Kubernetes的监控的基本原理，以及两种基于Kubernetes安装Prometheus的实际方案。然后介绍了服务发现和监控对象是如何配置。最后通过Grafana可视化展示监控界面和Alertmanager告警处理。

• https://github.com/coreos/prometheus-operator/blob/master/Documentation/user-guides /cluster-monitoring.md.
• 闫健勇，等. Kubernetes权威指南：企业级容器云实战［M］.北京：电子工业出版社，2018.
• https://github.com/coreos/prometheus-operator.

​