我们在之前知道heapster在1.113后将完全启用。
在资源指标中分为资源指标和自定义指标，先前的heapster就提供了资源收集存储和监控基本的功能，并且支持多个存储接收器，如：InflxDB等。这些组件均由第三方提供，由于某些不稳定的因素，heapster整合了十多个后端存储适配器，匹配这些适配器同时也增加了代码量，并且尚未得到改善，由此可见，这种架构下，heapster并不是很适用于后期的稳定发展。
heapster是一个原始的时间序列存储数据库，每个接收器都作为核心代码的一部分，使得整个监控结构定义越来越麻烦。我们知道kuberntes是非常灵活可扩展的，替换heapster，并不困难。
现有的版本中，支持开发人员定义API服务器扩展核心API服务，一些特殊应用程序可以进行扩展到kuerntes支持的资源类型中，一般情况，有三种方式：CRD：自定义资源指标，自定义API server，修改源码定义
在kubernetes中，有一种方式可以使开发人员轻松使用自己的API服务器，来扩展附加到已有的kubernetes之上，聚合进更多新的功能
在kubernetes集群中，api server支持那些组件，都是kubernetes事先定义好的，如果我们想要的组件，这里面没有的话，就可以自己开发api server，并且可以单独运行，也可以托管到kubernetes上运行，然后在kubernetes服务器和开发的api server前段添加代理服务，而后所有对api server的请求，既能获取已有的api，也能获取自己开发定义的api server。像这种就成为聚合器。如下：
在1.8中引入了资源指标API，资源内容当作接口数据获取，和早先的heapster本身自己提供不同，传统的heapster和API是不同的，在1.8之前是没有引入API的，在之后引入了APi资源指标，整合到一起。在1.6引入了自定义指标。有一些组件是依赖这些指标的，如kubectl top命令，如果没有一个收集资源指标的供给，是无法正常运行的。
另外像HPA(水平pod自动伸缩器)，这些还是需要根据获取当前pod的资源情况定义。比如CPU占用量已经达到百分之80，负载较高就添加pod，如果CPU 占用率低于百分之五，就删减几个pod。
- 我们知道无论pod运行与否，只要pod定义了requests，只要被调度，就会调度到某个节点上，节点上的资源就会预留给pod使用，如果这个pod空闲，那就会浪费资源。可以将这个pod移出，从而腾出更多的空间以供应其他的pod使用。
这些组件都是依赖资源指标才能工作的，早期都是依赖heapster才能实现。比如早期在kubernetes之上必须部署heapster才能使用top命令，另外才能使用hpa，对deployment之下的pod做水平自动伸缩。
此前这些指标只能让heapster提供，并且都是很有限度的，伸缩数据能力只能根据CPUY用量来伸缩，并不能根据io，内存，网卡等，heapster是做不到的。我们期望使用越来越多的指标来做，比如：cpu利用率都很低。而pod并发访问量很大，可能这时候已经需要添加pod了，但是这时候并不能根据并发指标来做。所以，仅仅根据cpu不足以反馈应用伸缩的场景，这时候就需要引入更多的其他的指标。
这时候就出现了新的资源指标模型，以及更多的自定义指标模型。新的资源指标获取的主要方式，是通过metrics-server来实现的。
prometheus
用来也允许开始的自定义指标的有一些监控系统，如prometheus，prometheus已经被收入到cncf(云原生计算基金会构建可持续生态系统 Cloud Native Computing Foundation)下的項目，第一個是kubernetes，第二个则是prometheus。
prometheus能收集各种维度的指标，如：CPu，内存，io，流量等等，这些数据被整合到kubernetes中，让kubernetes能够拿来作为判断是否来伸缩pod规模的基本标准。
后来，自定义指标通过prometheus来使用，即作为监控系统，有作为特殊资源指标提供，这些指标可自定义指标。
新的架构中有核心指标和监控：
- 核心指标包括主要指kubelet，metrics-server以及由api server提供的api组件组成。其中CPU累计使用率(累计使用时长占整个CPU使用总执行时间)，内存实时使用率，pod资源占用率，容器磁盘占用率。
除了这些之外，可能还要去评估网络质量，链接数量，带宽等等，这些就需要第三方工具使用。而核心指标是不能委托给第三方的，核心指标会被一些核心组件使用，如：kubectl top，dashboard都会用到，所以这些称为核心指标。
- 监控指标： 用于系统收集各种指标数据并提供终端用户，并不限于内存，pod资源占用磁盘使用，存储系统以及HPA等等。
hpa不单单可以使用核心指标有也可以使用监控自定义的扩展指标。监控指标就成为非核心指标，也包含一些核心指标，除此之外还能包含很多其他的指标。
这些非核心指标本身是无法被kubernetes解析的。prometheus是可以理解的，而kunernetes是无法理解的，这也就是为什么需要一个k8s-prometheus-adapter的原因。我们需要将prometheus采集的数据转换成kubernetes理解的格式。
k8s本身不提供这样的组件，如果用户不打算使用prometheus，就可以不用部署，但是核心的核心指标组件是必须要部署的。核心指标组件早期是heapster提供的，1.12彻底废弃，核心指标就交给metrics-server聚合提供。
