kube-state-metrics 和 metrics-server

kube-state-metrics 和 metrics-server

1.简介

对于Kubernetes的集群监控一般我们需要考虑一下几方面

Kubernetes节点的监控；比如节点的cpu、load、fdisk、memory等指标内部系统组件的状态；比如kube-scheduler、kube-controller-manager、kubedns/coredns等组件的运行状态编排级的metrics；比如Deployment的状态、资源请求、调度和API延迟等数据指标

2.监控方案

Kubernetes集群的监控方案主要有以下几种方案

Heapster:Herapster是一个集群范围的监控和数据聚合工具，以Pod的形式运行在集群中。1.8+被遗弃

Kubelet/cAdvisor之外，我们还可以向Heapster添加其他指标源数据，比如kube-state-metrics

Heapster已经被废弃，使用metrics-server代替

cAvisor:​​cAdvisor​​是Google开源的容器资源监控和性能分析工具，它是专门为容器而生，本身也支持Docker容器，Kubernetes中，我们不需要单独去安装，cAdvisor作为kubelet内置的一部分程序可以直接使用​​Kube-state-metrics​​:通过监听API Server生成有关资源对象的状态指标，比如Deployment、Node、Pod，需要注意的是kube-state-metrics只是简单的提供一个metrics数据，并不会存储这些指标数据，所以我们可以使用Prometheus来抓取这些数据然后存储metrics-server:metrics-server也是一个集群范围内的资源数据局和工具，是Heapster的代替品，同样的，metrics-server也只是显示数据，并不提供数据存储服务。他当前的核心作用是：为HPA等组件提供决策指标支持。也可以将接收到的数据存储到influxdb进行存储,简单来说,如果想基础监控,那么就要安装这个组件

不过kube-state-metrics和metrics-server之前还有很大不同的，二者主要区别如下

1.kube-state-metrics主要关注的是业务相关的一些元数据，比如Deployment、Pod、副本状态等

2.metrics-service主要关注的是资源度量API的实现，比如CPU、文件描述符、内存、请求延时等指标

3.metrics-server

3.1 介绍

从 Kubernetes 1.8 开始，资源使用指标（如容器 CPU 和内存使用率）通过 Metrics API 在 Kubernetes 中获取, metrics-server 替代了heapster。Metrics Server 实现了Resource Metrics API，Metrics Server 是集群范围资源使用数据的聚合器。

Metrics Server 从每个节点上的 Kubelet 公开的 Summary API 中采集指标信息。

项目地址：1.7和1.8+的版本,一般选择1.8+的版本安装

简单来说,如果不安装执行不了kubectl top node这样的命令,并且hpa的获取判断是否扩缩容的时候依赖它的数据。如果不安装,hpa获取的阈值那一栏一直都是未知

3.2 安装

3.2.1 EKS

1.安装文件以及目录

2.配置

这里有1点需要修改。如果不修改,日志和查询会有以下的报错

metrics-server-deployment.yaml

新增以下4行

通过以上的command可以增加很多自定义的参数,这些参数可以参考git的文档,并且在该版本里面,经过实验,自建k8s,eks没有这三行参数,那么metrics-server是采集不到数据的,kubect top node会报错

注意:可能出现的问题

## 在新的版本中，授权文内没有 node/stats 的权限，需要手动去添加[root@k8s-master01 metrics]# vim resource-reader.yaml apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: system:metrics-serverrules:- apiGroups: - "" resources: - pods - nodes - nodes/stats ## 添加此参数

3.验证

新增之后,如果查看metrics-server的服务还是会报错,但是等待1分钟左右就可以正常查询了

3.2.2 二进制

该服务在不同平台的部署方式不同,因为在不同平台,安装的组件不一样,比如阿里云,一切额外操作都准备好了.

自建的集群安装metrics-server需要满足以下条件;

1.metrics-server-deployment.yaml增加3行参数（参考eks安装）

2.master01上安装flanneld和kube-proxy,，因为api访问metrics-server是通过10.0.0.0段的集群ip去访问的,如果不安装flanneld和kube-prxoy，metrics-server和kube-apiserver是无法连通的.

3.自建集群的api-server需要添加额外参数开启聚合层

安装flanneld和kube-proxy

这里安装不做演示,如果不安装,将会有以下报错;

二进制部署，所以刚开始并没有在master节点部署kubelet、kube-proxy组件，所以导致一直安装失败:

执行命令kubectl get apiservices v1beta1.metrics.k8s.io -o yaml 看到报错信息："metrics-server error "Client.Timeout exceeded while awaiting headers"",这是因为mertics无法与 apiserver服务通信导致，因此需要在master节点安装部署kubelet、kube-proxy组件(可以选择给master节点打污点，来决定是否让master参与pod调度上来)

开启聚合层

如果不开启聚合层,这里不会有什么影响,但是在使用prometheus opterator的时候,会有类似以下的报错;（网上文档说,二进制可能只要不metrics-server就会有以下报错,所以建议不管有么有prometheus opterator,都建议开启聚合层）

并且prometheus opterator的一个镜像会直接报错

metrics-server-deployment.yaml

新增以下4行

通过以上的command可以增加很多自定义的参数,这些参数可以参考git的文档,并且在该版本里面,经过实验,自建k8s,eks没有这三行参数,那么metrics-server是采集不到数据的,kubect top node会报错

注意:可能出现的问题

## 在新的版本中，授权文内没有 node/stats 的权限，需要手动去添加[root@k8s-master01 metrics]# vim resource-reader.yaml apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: system:metrics-serverrules:- apiGroups: - "" resources: - pods - nodes - nodes/stats ## 添加此参数

1.Kube-apiserver配置文件修改

注意:这是二进制1.12版本，当时没有增加参数以及复用证书，是为metrics重新生成证书。

编辑kube-apiserver.conf 添加如下红色参数，从下面参数中可以看出，需要生产新的证书，因此我们还需要为metrics生产证书

"--logtostderr=true \--v=4 \--etcd-servers=\--bind-address=172.21.161.145 \--secure-port=6443 \--advertise-address=172.21.161.145 \--allow-privileged=true \--service-cluster-ip-range=10.0.0.0/24 \--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,NodeRestriction \--authorization-mode=RBAC,Node \--kubelet-\--enable-bootstrap-token-auth \--token-auth-file=/opt/kubernetes/cfg/token.csv \--service-node-port-range=30000-50000 \--tls-cert-file=/opt/kubernetes/ssl/server.pem \--tls-private-key-file=/opt/kubernetes/ssl/server-key.pem \--client-ca-file=/opt/kubernetes/ssl/ca.pem \--service-account-key-file=/opt/kubernetes/ssl/ca-key.pem \--etcd-cafile=/opt/etcd/ssl/ca.pem \--etcd-certfile=/opt/etcd/ssl/server.pem \--etcd-keyfile=/opt/etcd/ssl/server-key.pem \--requestheader-client-ca-file=/opt/kubernetes/ssl/ca.pem \--requestheader-allowed-names="" \--requestheader-extra-headers-prefix=X-Remote-Extra- \--requestheader-group-headers=X-Remote-Group \--requestheader-username-headers=X-Remote-User \--proxy-client-cert-file=/opt/kubernetes/ssl/metrics-proxy.pem \--proxy-client-key-file=/opt/kubernetes/ssl/metrics-proxy-key.pem"#这7行配置一定要配置在最后

参数说明：

--requestheader-XXX、--proxy-client-XXX 是 kube-apiserver 的 aggregator layer 相关的配置参数，metrics-server & HPA 需要使用；--requestheader-client-ca-file：用于签名 --proxy-client-cert-file 和 --proxy-client-key-file 指定的证书(ca证书)，在启用了 metric aggregator 时使用；

注：如果 --requestheader-allowed-names 不为空，则--proxy-client-cert-file 证书的 CN 必须位于 allowed-names 中，默认为 aggregator；

如果 kube-apiserver 机器没有运行 kube-proxy，则还需要添加 --enable-aggregator-routing=true 参数

在1.20版本中，复用了master的证书，不需要重新生成，并且，在安装部署k8s集群的时候，就已经增加了该参数了

KUBE_APISERVER_OPTS="--logtostderr=false \--v=2 \--log-dir=/opt/kubernetes/logs \--etcd-servers=\--bind-address=172.21.161.110 \--secure-port=6443 \--advertise-address=172.21.161.110 \--allow-privileged=true \--service-cluster-ip-range=10.0.0.0/24 \--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,NodeRestriction \--authorization-mode=RBAC,Node \--enable-bootstrap-token-auth=true \--token-auth-file=/opt/kubernetes/cfg/token.csv \--service-node-port-range=30000-32767 \--kubelet-client-certificate=/opt/kubernetes/ssl/server.pem \--kubelet-client-key=/opt/kubernetes/ssl/server-key.pem \--tls-cert-file=/opt/kubernetes/ssl/server.pem \--tls-private-key-file=/opt/kubernetes/ssl/server-key.pem \--client-ca-file=/opt/kubernetes/ssl/ca.pem \--service-account-key-file=/opt/kubernetes/ssl/ca-key.pem \--service-account-issuer=api \--service-account-signing-key-file=/opt/kubernetes/ssl/server-key.pem \--etcd-cafile=/opt/etcd/ssl/ca.pem \--etcd-certfile=/opt/etcd/ssl/server.pem \--etcd-keyfile=/opt/etcd/ssl/server-key.pem \--requestheader-client-ca-file=/opt/kubernetes/ssl/ca.pem \--proxy-client-cert-file=/opt/kubernetes/ssl/server.pem \--proxy-client-key-file=/opt/kubernetes/ssl/server-key.pem \--requestheader-allowed-names=kubernetes \--requestheader-extra-headers-prefix=X-Remote-Extra- \--requestheader-group-headers=X-Remote-Group \--requestheader-username-headers=X-Remote-User \"

2.为metrics server生成证书

上面可以看到，kube-apiserver开启聚合层，也需要使用证书，为了便于区分，我们这里为mertics 单独生产证书

关于证书的创建也可参考之前部署其它组件时创建证书时候的步骤

## 创建kube-proxy证书请求

[root@k8s-master01 ~]# vim /opt/k8s/certs/metrics-proxy-csr.json { "CN": "metrics-proxy", "hosts": [], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "ShangHai", "L": "ShangHai", "O": "metrics-proxy", "OU": "System" } ]}

## 生成kube-proxy证书与私钥

[root@k8s-master01 ~]# cd /opt/k8s-certs/[root@k8s-master01 certs]# cfssl gencert -ca=/opt/kubernetes/ssl/ca.pem \ -ca-key=/opt/kubernetes/ssl/ca-key.pem \ -config=/opt/k8s-certs/ca-config.json \ -profile=kubernetes metrics-proxy-csr.json | cfssljson -bare metrics-proxy## 证书分发

然后重启kube-apiserver就可以了,使用如下命令可以简单验证

如果有安装prometheus operator,看以下pod的状态是否正常

4.kube-state-metrics

4.1 介绍

已经有了cadvisor、heapster、metric-server，几乎容器运行的所有指标都能拿到，但是下面这种情况却无能为力：

我调度了多少个replicas？现在可用的有几个？多少个Pod是running/stopped/terminated状态？Pod重启了多少次？我有多少job在运行中

而这些则是kube-state-metrics提供的内容，它基于client-go开发，轮询Kubernetes API，并将Kubernetes的结构化信息转换为metrics。

kube-state-metrics是一个简单的服务，它监听Kubernetes API服务器并生成相关指标数据，它不单关注单个Kubernetes组件的运行情况，而是关注内部各种对象的运行状况

在K8s集群上Pod、DaemonSet、Deployment、Job、CronJob等各种资源对象的状态也需要监控，这些指标主要来自于apiserver和kubelet中集成的cAvisor，但是并没有具体的各种资源对象的状态指标。对于Prometheus来说，当然是需要引入新的exporter来暴露这些指标，Kubernetes提供了一个​​kube-state-metrics​​

kube-state-metrics已经给出了在Kubernetes部署的文件，我们直接将代码Clone到集群中执行yaml文件即可

将kube-state-metrics部署在kubernetes上之后，会发现kubernetes集群中的prometheus会在kube-state-metrics这个job下自动发现kube-state-metrics，并开始拉去metrics，这是因为部署kube-state-metrics的manifest定义文件kube-state-metrics-server.yaml对Service的定义包含prometheus.io/scrape: 'true'这样的一个annotation。因此kube-state-metrics的endpoint可以被Prometheus自动发现

关于kube-state-metrics暴露所有监控指标可以参考kube-state-metrics的文档​​kube-state-metrics Documentation​​:​​安装

1.安装文件以及目录

在1.8的版本里面,只剩下5个文件,归纳为 权限文件和部署文件

2.配置

这里有2点需要修改。

1).deployment

在默认的文件里面,配置了node亲和性,导致没有标签的node无法调度

2).service.yaml

因为prometheus从kube-state-metrics获取信息,就要prometeus能够获取到它的api,所以需要增加以下:（kube-state-metrics的service文件就要加，因为prometehus通过这个配置自动发现kube-state-metrics，然后获取监控数据，如果不加上，即使安装成功kube-state-metrics，很多key也是没有数据的）

3.prometheus收集

在配置里面 kube-state-metrics的service开启了annotations,Prometheus就是通过这个来过滤出这个service的。

Prometheus的具体配置在文章  <监控pormetheus集群的方式>→ Kubernetes监控配置 →集群内监控配置

4.使用endpoinits监控service(番外)

以上可以看出prometheus已经寻找到了,接下来，在prometheus就可以看到监控指标了

4.3 遗留问题

4.3.1 限制值

本案例在这里没有限制

（该文章摘自git）

集群状态指标的资源使用量随集群的Kubernetes对象（Pods / Nodes / Deployments / Secrets等）的大小而变化。在某种程度上，集群中的Kubernetes对象与集群的节点数成正比

作为一般规则，您应该分配

200MiB内存0.1核心

对于超过100个节点的集群，至少分配

每个节点2 MiB内存每个节点0.001个核心

这些数字基于每个节点30个Pod的​​可伸缩性测试​​。

请注意，如果将CPU限制设置得太低，则将无法足够快地处理kube-state-metrics的内部队列，从而导致随着队列长度的增加而增加的内存消耗。如果遇到内存分配过多导致的问题，请尝试增加CPU限制。

4.3.2 优化点和问题

kube-state-metrics在之前的版本中暴露出两个问题：

1./metrics接口响应慢(10-20s)

2.内存消耗太大，导致超出limit被杀掉

问题一的方案就是基于client-go的cache tool实现本地缓存，具体结构为：

var cache = map[uuid][]byte{}

问题二的的方案是：对于时间序列的字符串，是存在很多重复字符的（如namespace等前缀筛选），可以用指针或者结构化这些重复字符。

4.4 指标

具体指标可以参考本文介绍的git地址

作者：​​小家电维修​​

转世燕还故榻,为你衔来二月的花。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。