共计 3062 个字符，预计需要花费 8 分钟才能阅读完成。
概述
从 v1.8 开始，资源使用情况的监控可以通过 Metrics API 的形式获取，具体的组件为 Metrics Server，用来替换之前的 heapster，heapster 从 1.11 开始逐渐被废弃。
Metrics-Server 是集群核心监控数据的聚合器，从 Kubernetes1.8 开始，它作为一个 Deployment 对象默认部署在由 kube-up.sh 脚本创建的集群中，如果是其他部署方式需要单独安装，或者咨询对应的云厂商。
Metrics API
介绍 Metrics-Server 之前，必须要提一下 Metrics API 的概念
Metrics API 相比于之前的监控采集方式 (hepaster) 是一种新的思路，官方希望核心指标的监控应该是稳定的，版本可控的，且可以直接被用户访问(例如通过使用 kubectl top 命令)，或由集群中的控制器使用(如 HPA)，和其他的 Kubernetes APIs 一样。
官方废弃 heapster 项目，就是为了将核心资源监控作为一等公民对待，即像 pod、service 那样直接通过 api-server 或者 client 直接访问，不再是安装一个 hepater 来汇聚且由 heapster 单独管理。
假设每个 pod 和 node 我们收集 10 个指标，从 k8s 的 1.6 开始，支持 5000 节点，每个节点 30 个 pod，假设采集粒度为 1 分钟一次，则：
10 x 5000 x 30 / 60 = 25000 平均每分钟 2 万多个采集指标
因为 k8s 的 api-server 将所有的数据持久化到了 etcd 中，显然 k8s 本身不能处理这种频率的采集，而且这种监控数据变化快且都是临时数据，因此需要有一个组件单独处理他们，k8s 版本只存放部分在内存中，于是 metric-server 的概念诞生了。
其实 hepaster 已经有暴露了 api，但是用户和 Kubernetes 的其他组件必须通过 master proxy 的方式才能访问到，且 heapster 的接口不像 api-server 一样，有完整的鉴权以及 client 集成。这个 api 现在还在 alpha 阶段（18 年 8 月），希望能到 GA 阶段。类 api-server 风格的写法：generic apiserver
有了 Metrics Server 组件，也采集到了该有的数据，也暴露了 api，但因为 api 要统一，如何将请求到 api-server 的 /apis/metrics 请求转发给 Metrics Server 呢，解决方案就是：kube-aggregator, 在 k8s 的 1.7 中已经完成，之前 Metrics Server 一直没有面世，就是耽误在了 kube-aggregator 这一步。
kube-aggregator（聚合 api）主要提供：
Provide an API for registering API servers.
Summarize discovery information from all the servers.
Proxy client requests to individual servers.
详细设计文档：参考链接
metric api 的使用：
Metrics API 只可以查询当前的度量数据，并不保存历史数据
Metrics API URI 为 /apis/metrics.k8s.io/，在 k8s.io/metrics 维护
必须部署 metrics-server 才能使用该 API，metrics-server 通过调用 Kubelet Summary API 获取数据
如：
http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodes
http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodes/<node-name>
http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/namespace/<namespace-name>/pods/<pod-name>
Metrics-Server
Metrics server 定时从 Kubelet 的 Summary API(类似 /ap1/v1/nodes/nodename/stats/summary)采集指标信息，这些聚合过的数据将存储在内存中，且以 metric-api 的形式暴露出去。
Metrics server 复用了 api-server 的库来实现自己的功能，比如鉴权、版本等，为了实现将数据存放在内存中吗，去掉了默认的 etcd 存储，引入了内存存储（即实现 Storage interface)。因为存放在内存中，因此监控数据是没有持久化的，可以通过第三方存储来拓展，这个和 heapster 是一致的。
Metrics server 出现后，新的Kubernetes 监控架构将变成上图的样子
核心流程（黑色部分）：这是 Kubernetes 正常工作所需要的核心度量，从 Kubelet、cAdvisor 等获取度量数据，再由 metrics-server 提供给 Dashboard、HPA 控制器等使用。
监控流程（蓝色部分）：基于核心度量构建的监控流程，比如 Prometheus 可以从 metrics-server 获取核心度量，从其他数据源（如 Node Exporter 等）获取非核心度量，再基于它们构建监控告警系统。
官方地址：https://github.com/kubernetes…
使用
如上文提到的，metric-server 是扩展的 apiserver，依赖于 kube-aggregator，因此需要在 apiserver 中开启相关参数。
–requestheader-client-ca-file=/etc/kubernetes/certs/proxy-ca.crt
–proxy-client-cert-file=/etc/kubernetes/certs/proxy.crt
–proxy-client-key-file=/etc/kubernetes/certs/proxy.key
–requestheader-allowed-names=aggregator
–requestheader-extra-headers-prefix=X-Remote-Extra-
–requestheader-group-headers=X-Remote-Group
–requestheader-username-headers=X-Remote-User
安装文件下载地址：1.8+，注意更换镜像地址为国内镜像
kubectl create -f metric-server/
安装成功后，访问地址 api 地址为：
Metrics Server 的资源占用量会随着集群中的 Pod 数量的不断增长而不断上升，因此需要 addon-resizer 垂直扩缩这个容器。addon-resizer 依据集群中节点的数量线性地扩展 Metrics Server，以保证其能够有能力提供完整的 metrics API 服务。具体参考：链接
其他
基于 Metrics Server 的 HPA：参考链接
kubernetes 的新监控体系中，metrics-server 属于 Core metrics(核心指标)，提供 API metrics.k8s.io，仅提供 Node 和 Pod 的 CPU 和内存使用情况。而其他 Custom Metrics(自定义指标)由 Prometheus 等组件来完成，后续文章将对自定义指标进行解析。
本文为容器监控实践系列文章，完整内容见：container-monitor-book
