资源监控与资源指标

资源监控与heapster

k8s集群监控三大方面：

• k8s集群本身的监控：
  • 包括，cpu、内存、存储、网络、节点规模、节点健康状态等监控
• k8s之上容器的监控
  • 包括，容器的cpu、内存使用率，有无异常，副本数等
• 容器中业务应用监控
  • 包括，业务并发数、连接数、数据库中表数据规模等

监控系统的一般构成

• 各节点的采集器，一般是agent程序，采集当前节点各项指标数据
• 中心的收集器，收集个节点上agent收集的指标数据，并汇总，（并转化为提供给客户端的api服务）
• 存储端，数据存储系统，一般是时序型数据库，对收集的数据做持久化存储，（且方便做历史数据的分析）
• 展示端，一个webUI，对数据做数据可视化展示，图表形式更直观

原有k8s中的监控架构

• 采集器：cadvisor、kubelet内置了cadvisor程序，负责收集各个节点上的指标数据，只能收集cpu、内存等最基本的指标数据
• 收集器：heapster、收集各个节点的cadvisor采集到的数据
• 存储：infuxdb，时序型存储数据库
• 展示：grafana：webUI框架，做图形化展示

资源指标api的使用方，即其客户端

• kubectl top等命令：借助资源指标服务提供的api查询集群的资源使用率，类似linux的top
• hpa控制器：水平-pod-自动扩缩容控制器：通过资源指标服务提供的api监控某pod的副本数和负载情况，监控到负载高时，自动通过replicas增加副本
• schduler调度器：选择节点调度时需要参考资源指标服务收集来的指标数据
• dashboard展示部分

heapster简介：

​ heapster为收集各节点指标数据的聚合器，并将数据转换为api对外提供服务，如kubectl top等客户端；可以结合influxdb做存储、grafana做展示；

新一代k8s监控架构

​ heapster的耦合度较高，不方便扩展，且只支持cpu指标，因此heapster逐渐被metric-server替代，heapster-》metric-server；

​ k8s将指标数据分为了2部分：且只定义了其api规范，并未具体实现，从而可以在保持api不变的情况下，可切换其底层实现，从而降低了耦合度，提高了灵活度；其具体实现由用户采用的组件而定，

• 核心资源指标api：【resource metrics server】
  • 定义的是核心的基础资源监控，如cpu、内存、网络等
  • 常用实现为：matric-server
• 自定义指标api：【custom metrics server】
  • 为用户自定义的监控指标，可以是业务的、可以是集群本身的、pod的
  • 常用实现为：prometheues，不同的监控指标由节点上不同的exporter采集，再由promethus-server收集并存储到数据库中，借助grafana展示

2种指标api架构图示：

• metrics-server
  • 节点上的cadvisor收集各项基础指标数据
  • 由metrics-server收集汇总各节点的指标数据
    • 存储到存储系统
    • 借助UI展示
  • 通过kube-aggregator聚合到api-server，统一对外提供服务
  • 客户端hpaV2第二版，kubectl top或scheduler通过api-server访问其服务
• prometheus
  • prometheus各种exporter部署在节点上，收集不同的指标数据；
  • promethues-adapter汇总收集各个节点采集到的数据；
    • 存储到存储系统
    • 借助UI展示
  • 通过kube-aggregator聚合到api-server，统一对外提供服务
  • 客户端hpaV2第二版，或scheduler通过api-server访问其服务

资源指标及其应用

部署metrics-server

​ metrics-server为heapster的替代品和升级版，运行模式为k8s之上的pod，从各节点的kubelet上的cadvisor收集数据，并存于内存中，没有外部存储时，客户端访问只能访问一段时间的数据，重启后数据丢失；

​ 采用清单创建时，会创建：

• pod的sa身份
• clusterrole和对应的rolebinding，授予pod相应的权限
• service暴露服务
• deployment控制pod
• apiService对象，将metrics-server通过kube-aggerator注册到api-server之上；

[root@client metrics-server]# kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.4.1/components.yaml
serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created

问题？容器创建失败

kubectl top

kubectl top在部署好metrics-server后，可以查看node和pod的资源使用率

自定义指标与prometheus

​

prometheus概述

​ prometheus是一个开源的服务监控系统、加、时序数据库TSDB，prometheus提供了通用的数据模型、便捷的数据采集、存储、和查询接口，核心组件：prometheus server定期从静态配置的监控目标targets，或基于服务发现发现的目标，主动拉取数据，

​ 拉取数据超过内存缓存区时，会持久化到存储数据库上；

prometheus自定义指标实现

​ 自定义指标的采集实现，依赖节点上各种采集程序，就prometheus来说，是依赖节点上各类的exporter实现，流程如下：

1. 节点的各类exporter采集数据；
2. prometheus通过“拉”的方式从节点收集数据；
   1. 并提供了promQL接口，给客户端工具如grafana、命令行、promeWebUI使用
3. k8s-prometheus-adapter适配器将收集的数据，（转为k8s定义的：自定义指标api的标准形式）

prometheus组件架构

• 各类exporter：
  • 节点上的exporter负责采集数据，然后由prometheus server拉取
• prometheus server：
  • 主动拉取节点上采集到的数据
  • 收集汇集、解析
  • 数据存储到TSDB中
  • 对外提供http server
  • 对外提供PromQL接口：供客户端使用
  • 对外，对接altermanager告警系统，通过多种媒介报警
• 服务发现
  • prometheus可以通过静态配置、
  • 或kube-apiserver动态发现机制，实现要监控对象的动态发现
• pushgateway
  • 节点想推送数据时，可以先推送到pushgateway暂存，然后由prometheus server拉取

prometheus可采集数据源

​ prometheus可以采集的数据来源有如下几种：

prometheus可监控对象：

• node_exporter，收集节点的cpu、内存、负载等信息
• kubelet(cadvisor)，收集容器基础指标，如cpu、内存使用率等
• api server，收集api server性能数据，
• etcd，etcd集群数据
• kube-state-metrics：k8s本身指标数据

k8s可通过api server动态发现，新调度的pod，并纳入监控，但pod需要有以下注解信息，才允许prometheus监控

prometheus.io/scrape
prometheus.io/path
prometheus.io/port

部署prometheus监控

​ 部署prometheus包含4个组件：

• prometheus server：拉取各个数据源采集到的数据并存储，对外提供promQL查询接口
• kube-state-metrics：通过api-server收集k8s集群整体信息，并转为指标数据
• alter-manager：定义告警规则，推送告警信息
• node_exporter以及其他类型的exporter

自定义适配器k8s-prometheus-adapter

​ prometheus server收集到的所有数据，并不适用于k8s定义的custom metrics api标准，需要借助k8s-prometheus-adapter做一层转换；转为custom metrics api格式，并聚合到api-server之上；

自动扩缩容之hpa

​ k8s提供了四种常用的自动扩缩容组件，分别针对不对的对象：

• hpa：水平pod自动扩缩容，通过pod的负载状态，动态调整pod副本数
  • hpav1，只能通过cpu指标，判断是否扩缩容
  • hpav2，可以通过cpu等核心资源指标、以及自定义资源指标，判断是否扩缩容
• vpa：垂直pod资源扩缩容，扩缩容pod的资源分配量
• ca：cluster autoscaler，通过集群整体负载状态，调整节点的数据，（通常是云环境，依赖云厂商）
• ar：addons resizer，通过检测集群的规模，动态调整附件pod的数量

HPA概述

​ hpa全称：horizontal pod autoscaler水平pod自动扩缩容控制器

HPAv1版本

HPAv2版本