思考并回答以下问题：

作为一个监控系统，Prometheus项目的作用和工作方式，其实可以用如下所示的一张官方示意图来解释。

可以看到，Prometheus项目工作的核心，是使用Pull（抓取）的方式去搜集被监控对象的Metrics数据（监控指标数据），然后，再把这些数据保存在一个TSDB（时间序列数据库，比如OpenTSDB、InfluxDB等）当中，以便后续可以按照时间进行检索。

有了这套核心监控机制，Prometheus剩下的组件就是用来配合这套机制的运行。比如Pushgateway，可以允许被监控对象以Push的方式向Prometheus推送Metrics数据。而Alertmanager，则可以根据Metrics信息灵活地设置报警。当然，Prometheus最受用户欢迎的功能，还是通过Grafana对外暴露出的、可以灵活配置的监控数据可视化界面。

有了Prometheus之后，我们就可以按照Metrics数据的来源，来对Kubernetes的监控体系做一个汇总了。

第一种Metrics，是宿主机的监控数据。这部分数据的提供，需要借助一个由Prometheus维护的Node Exporter工具。一般来说，Node Exporter会以DaemonSet的方式运行在宿主机上。其实，所谓的Exporter，就是代替被监控对象来对Prometheus暴露出可以被“抓取”的Metrics信息的一个辅助进程。

而Node Exporter可以暴露给Prometheus采集的Metrics数据，也不单单是节点的负载（Load）、CPU、内存、磁盘以及网络这样的常规信息，它的Metrics指标可以说是“包罗万象”，你可以查看这个列表来感受一下。

第二种Metrics，是来自于Kubernetes的API Server、kubelet等组件的/metrics API。除了常规的CPU、内存的信息外，这部分信息还主要包括了各个组件的核心监控指标。比如，对于API Server来说，它就会在/metrics API里，暴露出各个Controller的工作队列（Work Queue）的长度、请求的QPS和延迟数据等等。这些信息，是检查Kubernetes本身工作情况的主要依据。

第三种Metrics，是Kubernetes相关的监控数据。这部分数据，一般叫作Kubernetes核心监控数据（core metrics）。这其中包括了Pod、Node、容器、Service等主要Kubernetes核心概念的Metrics。

其中，容器相关的Metrics主要来自于kubelet内置的cAdvisor服务。在kubelet启动后，cAdvisor服务也随之启动，而它能够提供的信息，可以细化到每一个容器的CPU、文件系统、内存、网络等资源的使用情况。

需要注意的是，这里提到的Kubernetes核心监控数据，其实使用的是Kubernetes的一个非常重要的扩展能力，叫作Metrics Server。

Metrics Server在Kubernetes社区的定位，其实是用来取代Heapster这个项目的。在Kubernetes项目发展的初期，Heapster是用户获取Kubernetes监控数据（比如Pod和Node的资源使用情况）的主要渠道。而后面提出来的Metrics Server，则把这些信息，通过标准的Kubernetes API暴露了出来。这样，Metrics信息就跟Heapster完成了解耦，允许Heapster项目慢慢退出舞台。

而有了Metrics Server之后，用户就可以通过标准的Kubernetes API来访问到这些监控数据了。比如，下面这个URL：

当你访问这个MetricsAPI时，它就会为你返回一个Pod的监控数据，而这些数据，其实是从kubelet的SummaryAPI（即:/stats/summary）采集而来的。SummaryAPI返回的信息，既包括了cAdVisor的监控数据，也包括了kubelet本身汇总的信息。

需要指出的是，Metrics Server并不是kube-API Server的一部分，而是通过Aggregator这种插件机制，在独立部署的情况下同kube-API Server一起统一对外服务的。

这里，AggregatorAPI Server的工作原理，可以用如下所示的一幅示意图来表示清楚：

可以看到，当Kubernetes的API Server开启了Aggregator模式之后，你再访问apis/metrics.k8s.io/v1beta1的时候，实际上访问到的是一个叫作kube-aggregator的代理。而kube-API Server，正是这个代理的一个后端；而Metrics Server，则是另一个后端。

而且，在这个机制下，你还可以添加更多的后端给这个kube-aggregator。所以kube-aggregator其实就是一个根据URL选择具体的API后端的代理服务器。通过这种方式，我们就可以很方便地扩展Kubernetes的API了。

而Aggregator模式的开启也非常简单：

如果你是使用kubeadm或者官方的kube-up.sh脚本部署Kubernetes集群的话，Aggregator模式就是默认开启的；
如果是手动DIY搭建的话，你就需要在kube-API Server的启动参数里加上如下所示的配置：

而这些配置的作用，主要就是为Aggregator这一层设置对应的Key和Cert文件。而这些文件的生成，就需要你自己手动完成了，具体流程请参考这篇官方文档。

Aggregator功能开启之后，你只需要将Metrics Server的YAML文件部署起来，如下所示：

接下来，你就会看到metrics.k8s.io这个API出现在了你的Kubernetes API列表当中。

在理解了Prometheus关心的三种监控数据源，以及Kubernetes的核心Metrics之后，作为用户，你其实要做的就是将PrometheusOperator在Kubernetes集群里部署起来。然后，按照本篇文章一开始介绍的架构，把上述Metrics源配置起来，让Prometheus自己去进行采集即可。

在后续的文章中，我会为你进一步剖析Kubernetes监控体系以及自定义Metrics（自定义监控指标）的具体技术点。

总结

在本篇文章中，我主要为你介绍了Kubernetes当前监控体系的设计，介绍了Prometheus项目在这套体系中的地位，讲解了以Prometheus为核心的监控系统的架构设计。

然后，我为你详细地解读了Kubernetes核心监控数据的来源，即：Metrics Server的具体工作原理，以及AggregatorAPI Server的设计思路。

通过以上讲述，我希望你能够对Kubernetes的监控体系形成一个整体的认知，体会到Kubernetes社区在监控这个事情上，全面以Prometheus项目为核心进行建设的大方向。

最后，在具体的监控指标规划上，我建议你遵循业界通用的USE原则和RED原则。

其中，USE原则指的是，按照如下三个维度来规划资源监控指标：

1，利用率（Utilization），资源被有效利用起来提供服务的平均时间占比；

2，饱和度（Saturation），资源拥挤的程度，比如工作队列的长度；

3，错误率（Errors），错误的数量。

而RED原则指的是，按照如下三个维度来规划服务监控指标：

1，每秒请求数量（Rate）；

2，每秒错误数量（Errors）；

3，服务响应时间（Duration）。

不难发现，USE原则主要关注的是“资源”，比如节点和容器的资源使用情况，而RED原则主要关注的是“服务”，比如kube-API Server或者某个应用的工作情况。这两种指标，在我今天为你讲解的Kubernetes+Prometheus组成的监控体系中，都是可以完全覆盖到的。

思考题

在监控体系中，对于数据的采集，其实既有Prometheus这种Pull模式，也有Push模式。请问，你如何看待这两种模式的异同和优缺点呢？