linuxea:kubernetes 了解k8s资源指标(45)

我们在之前知道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聚合提供。

0 分享

您可以选择一种方式赞助本站

支付宝扫码赞助

支付宝扫码赞助

日期: 2018-12-09分类: kubernetes

标签: kubernetes

发表评论