当前位置：首页 > article >正文

基于Prometheus 和K8S kubernetes 构建搭建监控告警系统

article 2024/11/13 14:46:16

1、Prometheus介绍？

2、Prometheus特点？

2.1 样本

3、Prometheus组件介绍

4、Prometheus工作流程

4、Prometheus和zabbix对比分析

5、Prometheus的几种部署模式

5.1 基本高可用模式

5.2 基本高可用+远程存储

5.3 基本HA + 远程存储 + 联邦集群方案

6、Prometheus的四种数据类型

6.1 Counter

6.2 Gauge

6.3 histogram

6.3.1 为什需要用histogram柱状图？

6.4 summary

7、Prometheus能监控什么？

7.1 DATABASES-数据库

7.2 HARDWARE RELATED-硬件相关

7.3 Messaging systems-消息服务

7.4 Storage-存储

7.5 http-网站服务

7.6 API

7.7 Logging-日志

7.8 Other monitoring systems

7.9 Miscellaneous-其他

7.10 Software exposing Prometheus metrics-Prometheus度量指标

8、Prometheus对kubernetes的监控

9、node-exporter组件安装和配置

9.1 node-exporter介绍？

9.2 安装node-exporter

10、Prometheus server安装和配置

10.1 创建sa账号，对sa做rbac授权

10.2 创建prometheus数据存储目录

10.3 安装Prometheus server服务

10.3.1 创建一个configmap存储卷，用来存放prometheus配置信息

10.3.2 通过deployment部署prometheus

10.3.3 给prometheus pod创建一个service

10.3.4 Prometheus热加载

11、可视化UI界面Grafana的安装和配置

11.1 Grafana介绍

11.2 安装Grafana

11.3 Grafana界面接入Prometheus数据源

12、安装kube-state-metrics组件

文档中的YAML文件配置直接复制粘贴可能存在格式错误，故实验中所需要的YAML文件以及本地包均打包至网盘

链接：https://pan.baidu.com/s/1oyrj0H79-URq2uUfbe87Nw
提取码：sgik

1、Prometheus介绍？

Prometheus是一个开源的系统监控和报警系统，现在已经加入到CNCF基金会，成为继k8s之后第二个在CNCF托管的项目，在kubernetes容器管理系统中，通常会搭配prometheus进行监控，同时也支持多种exporter采集数据，还支持pushgateway进行数据上报，Prometheus性能足够支撑上万台规模的集群。

Prometheus配置：https://prometheus.io/docs/prometheus/latest/configuration/configuration/

Prometheus监控组件对应的exporter部署地址:

https://prometheus.io/docs/instrumenting/exporters/

Prometheus基于k8s服务发现参考:

prometheus/documentation/examples/prometheus-kubernetes.yml at release-2.31 · prometheus/prometheus · GitHub

2、Prometheus特点？

1.多维度数据模型

每一个时间序列数据都由metric度量指标名称和它的标签labels键值对集合唯一确定：

这个metric度量指标名称指定监控目标系统的测量特征（如：http_requests_total- 接收http请求的总计数）。labels开启了Prometheus的多维数据模型：对于相同的度量名称，通过不同标签列表的结合, 会形成特定的度量维度实例。(例如：所有包含度量名称为/api/tracks的http请求，打上method=POST的标签，则形成了具体的http请求)。这个查询语言在这些度量和标签列表的基础上进行过滤和聚合。改变任何度量上的任何标签值，则会形成新的时间序列图。

2.灵活的查询语言（PromQL）

可以对采集的metrics指标进行加法，乘法，连接等操作；

3.可以直接在本地部署，不依赖其他分布式存储；

4.通过基于HTTP的pull方式采集时序数据；

5.可以通过中间网关pushgateway的方式把时间序列数据推送到prometheus server端；

6.可通过服务发现或者静态配置来发现目标服务对象（targets）。

7.有多种可视化图像界面，如Grafana等。

8.高效的存储，每个采样数据占3.5 bytes左右，300万的时间序列，30s间隔，保留60天，消耗磁盘大概200G。

9.做高可用，可以对数据做异地备份，联邦集群，部署多套prometheus，pushgateway上报数据

2.1 样本

在时间序列中的每一个点称为一个样本（sample），样本由以下三部分组成：

1、指标（metric）：指标名称和描述当前样本特征的 labelsets；

2、时间戳（timestamp）：一个精确到毫秒的时间戳；

3、样本值（value）：一个 folat64 的浮点型数据表示当前样本的值。

表示方式：

通过如下表达方式表示指定指标名称和指定标签集合的时间序列：

<metric name>{<label name>=<label value>, ...}

例如，指标名称为 api_http_requests_total，标签为 method="POST" 和 handler="/messages" 的时间序列可以表示为：

api_http_requests_total{method="POST", handler="/messages"}

3、Prometheus组件介绍

1.Prometheus Server: 用于收集和存储时间序列数据。

2.Client Library: 客户端库，检测应用程序代码，当Prometheus抓取实例的HTTP端点时，客户端库会将所有跟踪的metrics指标的当前状态发送到prometheus server端。

3.Exporters: prometheus支持多种exporter，通过exporter可以采集metrics数据，然后发送到prometheus server端，所有向promtheus server提供监控数据的程序都可以被称为exporter

4.Alertmanager: 从 Prometheus server 端接收到 alerts 后，会进行去重，分组，并路由到相应的接收方，发出报警，常见的接收方式有：电子邮件，微信，钉钉, slack等。

5.Grafana：监控仪表盘，可视化监控数据

6.pushgateway: 各个目标主机可上报数据到pushgateway，然后prometheus server统一从pushgateway拉取数据。

从上图可发现，Prometheus整个生态圈组成主要包括prometheus server，Exporter，pushgateway，alertmanager，grafana，Web ui界面，Prometheus server由三个部分组成，Retrieval，Storage，PromQL

1.Retrieval负责在活跃的target主机上抓取监控指标数据

2.Storage存储主要是把采集到的数据存储到磁盘中

3.PromQL是Prometheus提供的查询语言模块。

4、Prometheus工作流程

1.Prometheus server可定期从活跃的（up）目标主机上（target）拉取监控指标数据，目标主机的监控数据可通过配置静态job或者服务发现的方式被prometheus server采集到，这种方式默认的pull方式拉取指标；也可通过pushgateway把采集的数据上报到prometheus server中；还可通过一些组件自带的exporter采集相应组件的数据；

2.Prometheus server把采集到的监控指标数据保存到本地磁盘或者数据库；

3.Prometheus采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到alertmanager

4.Alertmanager通过配置报警接收方，发送报警到邮件，微信或者钉钉等

5.Prometheus 自带的web ui界面提供PromQL查询语言，可查询监控数据

6.Grafana可接入prometheus数据源，把监控数据以图形化形式展示出

4、Prometheus和zabbix对比分析

5、Prometheus的几种部署模式

5.1 基本高可用模式

基本的HA模式只能确保Promthues服务的可用性问题，但是不解决Prometheus Server之间的数据一致性问题以及持久化问题(数据丢失后无法恢复)，也无法进行动态的扩展。因此这种部署方式适合监控规模不大，Promthues Server也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景。

5.2 基本高可用+远程存储

在解决了Promthues服务可用性的基础上，同时确保了数据的持久化，当Promthues Server发生宕机或者数据丢失的情况下，可以快速的恢复。同时Promthues Server可能很好的进行迁移。因此，该方案适用于用户监控规模不大，但是希望能够将监控数据持久化，同时能够确保Promthues Server的可迁移性的场景。

5.3 基本HA + 远程存储 + 联邦集群方案

Promthues的性能瓶颈主要在于大量的采集任务，因此用户需要利用Prometheus联邦集群的特性，将不同类型的采集任务划分到不同的Promthues子服务中，从而实现功能分区。例如一个Promthues Server负责采集基础设施相关的监控指标，另外一个Prometheus Server负责采集应用监控指标。再有上层Prometheus Server实现对数据的汇聚。

6、Prometheus的四种数据类型

6.1 Counter

Counter是计数器类型：

1、Counter 用于累计值，例如记录请求次数、任务完成数、错误发生次数。

2、一直增加，不会减少。

3、重启进程后，会被重置。

例如：http_response_total{method="GET",endpoint="/api/tracks"} 100

http_response_total{method="GET",endpoint="/api/tracks"} 160

Counter 类型数据可以让用户方便的了解事件产生的速率的变化，在PromQL内置的相关操作函数可以提供相应的分析，比如以HTTP应用请求量来进行说明：

1、通过rate()函数获取HTTP请求量的增长率

rate(http_requests_total[5m])

2、查询当前系统中，访问量前10的HTTP地址

topk(10, http_requests_total)

6.2 Gauge

Gauge是测量器类型：

1、Gauge是常规数值，例如温度变化、内存使用变化。

2、可变大，可变小。

3、重启进程后，会被重置

例如：

memory_usage_bytes{host="master-01"} 100

memory_usage_bytes{host="master-01"} 30

memory_usage_bytes{host="master-01"} 50

memory_usage_bytes{host="master-01"} 80

对于 Gauge 类型的监控指标，通过 PromQL 内置函数 delta() 可以获取样本在一段时间内的变化情况，例如，计算 CPU 温度在两小时内的差异：

dalta(cpu_temp_celsius{host="zeus"}[2h])

你还可以通过PromQL 内置函数 predict_linear() 基于简单线性回归的方式，对样本数据的变化趋势做出预测。例如，基于 2 小时的样本数据，来预测主机可用磁盘空间在 4 个小时之后的剩余情况：

predict_linear(node_filesystem_free{job="node"}[2h], 4 * 3600) < 0

6.3 histogram

histogram是柱状图，在Prometheus系统的查询语言中，有三种作用：

1、在一段时间范围内对数据进行采样（通常是请求持续时间或响应大小等），并将其计入可配置的存储桶（bucket）中. 后续可通过指定区间筛选样本，也可以统计样本总数，最后一般将数据展示为直方图。

2、对每个采样点值累计和(sum)

3、对采样点的次数累计和(count)

度量指标名称: [basename]_上面三类的作用度量指标名称

1、[basename]_bucket{le="上边界"}, 这个值为小于等于上边界的所有采样点数量

2、[basename]_sum

3、[basename]_count

小结：如果定义一个度量类型为Histogram，则Prometheus会自动生成三个对应的指标

6.3.1 为什需要用histogram柱状图？

在大多数情况下人们都倾向于使用某些量化指标的平均值，例如 CPU 的平均使用率、页面的平均响应时间。这种方式的问题很明显，以系统 API 调用的平均响应时间为例：如果大多数 API 请求都维持在 100ms 的响应时间范围内，而个别请求的响应时间需要 5s，那么就会导致某些 WEB 页面的响应时间落到中位数的情况，而这种现象被称为长尾问题。

为了区分是平均的慢还是长尾的慢，最简单的方式就是按照请求延迟的范围进行分组。例如，统计延迟在 0~10ms 之间的请求数有多少，而 10~20ms 之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。Histogram 和 Summary 都是为了能够解决这样问题的存在，通过 Histogram 和 Summary 类型的监控指标，我们可以快速了解监控样本的分布情况。

Histogram 类型的样本会提供三种指标（假设指标名称为 <basename>）：

样本的值分布在 bucket 中的数量，命名为 <basename>_bucket{le="<上边界>"}。解释的更通俗易懂一点，这个值表示指标值小于等于上边界的所有样本数量。

1、http 请求响应时间 <=0.005 秒的请求次数为0

io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.005",} 0.0

2、http 请求响应时间 <=0.01 秒的请求次数为0

io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.01",} 0.0

3、http 请求响应时间 <=0.025 秒的请求次数为0

io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.025",} 0.0

所有样本值的大小总和，命名为 <basename>_sum。

6.4 summary

与 Histogram 类型类似，用于表示一段时间内的数据采样结果（通常是请求持续时间或响应大小等），但它直接存储了分位数（通过客户端计算，然后展示出来），而不是通过区间来计算。它也有三种作用：

1、对于每个采样点进行统计，并形成分位图。（如：正态分布一样，统计低于60分不及格的同学比例，统计低于80分的同学比例，统计低于95分的同学比例）

2、统计班上所有同学的总成绩(sum)

3、统计班上同学的考试总人数(count)

带有度量指标的[basename]的summary 在抓取时间序列数据有如命名。

1、观察时间的φ-quantiles (0 ≤ φ ≤ 1), 显示为[basename]{分位数="[φ]"}

2、[basename]_sum，是指所有观察值的总和

3、[basename]_count, 是指已观察到的事件计数值

样本值的分位数分布情况，命名为 <basename>{quantile="<φ>"}。

1、含义：这 12 次 http 请求中有 50% 的请求响应时间是 3.052404983s

io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.5",} 3.052404983

2、含义： http 请求中有 90% 的请求响应时间是 8.003261666s

io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.9",} 8.003261666

所有样本值的大小总和，命名为 <basename>_sum。

1、含义：http 请求的总响应时间为 51.029495508s

io_namespace_http_requests_latency_seconds_summary_sum{path="/",method="GET",code="200",} 51.029495508

样本总数，命名为 <basename>_count。

1、含义：当前一共发生了 12 次 http 请求

io_namespace_http_requests_latency_seconds_summary_count{path="/",method="GET",code="200",} 12.0

现在可以总结一下 Histogram 与 Summary 的异同：

它们都包含了 <basename>_sum 和 <basename>_count 指标

Histogram 需要通过 <basename>_bucket 来计算分位数，而 Summary 则直接存储了分位数的值。

prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463

prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005

prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173

prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002

prometheus_tsdb_wal_fsync_duration_seconds_count 216

从上面的样本中可以得知当前Promtheus Server进行wal_fsync操作的总次数为216次，耗时2.888716127000002s。其中中位数（quantile=0.5）的耗时为0.012352463，9分位数（quantile=0.9）的耗时为0.014458005s。

7、Prometheus能监控什么？

Databases
Hardware related
Messaging systems
Storage
HTTP
APIs
Logging
Other monitoring systems
Miscellaneous
Software exposing Prometheus metrics

7.1 DATABASES-数据库

Aerospike exporter
ClickHouse exporter
Consul exporter (official)
Couchbase exporter
CouchDB exporter
ElasticSearch exporter
EventStore exporter
Memcached exporter (official)
MongoDB exporter
MSSQL server exporter
MySQL server exporter (official)
OpenTSDB Exporter
Oracle DB Exporter
PgBouncer exporter
PostgreSQL exporter
ProxySQL exporter
RavenDB exporter
Redis exporter
RethinkDB exporter
SQL exporter
Tarantool metric library
Twemproxy

7.2 HARDWARE RELATED-硬件相关

apcupsd exporter
Collins exporter
IBM Z HMC exporter
IoT Edison exporter
IPMI exporter
knxd exporter
Netgear Cable Modem Exporter
Node/system metrics exporter (official)
NVIDIA GPU exporter
ProSAFE exporter
Ubiquiti UniFi exporter

7.3 Messaging systems-消息服务

Beanstalkd exporter
Gearman exporter
Kafka exporter
NATS exporter
NSQ exporter
Mirth Connect exporter
MQTT blackbox exporter
RabbitMQ exporter
RabbitMQ Management Plugin exporter

7.4 Storage-存储

Ceph exporter
Ceph RADOSGW exporter
Gluster exporter
Hadoop HDFS FSImage exporter
Lustre exporter
ScaleIO exporter

7.5 http-网站服务

Apache exporter
HAProxy exporter (official)
Nginx metric library
Nginx VTS exporter
Passenger exporter
Squid exporter
Tinyproxy exporter
Varnish exporter
WebDriver exporter

7.6 API

AWS ECS exporter
AWS Health exporter
AWS SQS exporter
Cloudflare exporter
DigitalOcean exporter
Docker Cloud exporter
Docker Hub exporter
GitHub exporter
InstaClustr exporter
Mozilla Observatory exporter
OpenWeatherMap exporter
Pagespeed exporter
Rancher exporter
Speedtest exporter

7.7 Logging-日志

Fluentd exporter
Google's mtail log data extractor
Grok exporter

7.8 Other monitoring systems

Akamai Cloudmonitor exporter
Alibaba Cloudmonitor exporter
AWS CloudWatch exporter (official)
Cloud Foundry Firehose exporter
Collectd exporter (official)
Google Stackdriver exporter
Graphite exporter (official)
Heka dashboard exporter
Heka exporter
InfluxDB exporter (official)
JavaMelody exporter
JMX exporter (official)
Munin exporter
Nagios / Naemon exporter
New Relic exporter
NRPE exporter
Osquery exporter
OTC CloudEye exporter
Pingdom exporter
scollector exporter
Sensu exporter
SNMP exporter (official)
StatsD exporter (official)

7.9 Miscellaneous-其他

ACT Fibernet Exporter
Bamboo exporter
BIG-IP exporter
BIND exporter
Bitbucket exporter
Blackbox exporter (official)
BOSH exporter
cAdvisor
Cachet exporter
ccache exporter
Confluence exporter
Dovecot exporter
eBPF exporter
Ethereum Client exporter
Jenkins exporter
JIRA exporter
Kannel exporter
Kemp LoadBalancer exporter
Kibana Exporter
Meteor JS web framework exporter
Minecraft exporter module
PHP-FPM exporter
PowerDNS exporter
Presto exporter
Process exporter
rTorrent exporter
SABnzbd exporter
Script exporter
Shield exporter
SMTP/Maildir MDA blackbox prober
SoftEther exporter
Transmission exporter
Unbound exporter
Xen exporter

7.10 Software exposing Prometheus metrics-Prometheus度量指标

App Connect Enterprise
Ballerina
Ceph
Collectd
Concourse
CRG Roller Derby Scoreboard (direct)
Docker Daemon
Doorman (direct)
Etcd (direct)
Flink
FreeBSD Kernel
Grafana
JavaMelody
Kubernetes (direct)
Linkerd

8、Prometheus对kubernetes的监控

对于Kubernetes而言，我们可以把当中所有的资源分为几类：

基础设施层（Node）：集群节点，为整个集群和应用提供运行时资源
容器基础设施（Container）：为应用提供运行时环境
用户应用（Pod）：Pod中会包含一组容器，它们一起工作，并且对外提供一个（或者一组）功能
内部服务负载均衡（Service）：在集群内，通过Service在集群暴露应用功能，集群内应用和应用之间访问时提供内部的负载均衡
外部访问入口（Ingress）：通过Ingress提供集群外的访问入口，从而可以使外部客户端能够访问到部署在Kubernetes集群内的服务

因此，如果要构建一个完整的监控体系，我们应该考虑，以下5个方面：

集群节点状态监控：从集群中各节点的kubelet服务获取节点的基本运行状态；
集群节点资源用量监控：通过Daemonset的形式在集群中各个节点部署Node Exporter采集节点的资源使用情况；
节点中运行的容器监控：通过各个节点中kubelet内置的cAdvisor中获取个节点中所有容器的运行状态和资源使用情况；
如果在集群中部署的应用程序本身内置了对Prometheus的监控支持，那么我们还应该找到相应的Pod实例，并从该Pod实例中获取其内部运行状态的监控指标。
对k8s本身的组件做监控：apiserver、scheduler、controller-manager、kubelet、kube-proxy

9、node-exporter组件安装和配置

机器规划：

我的实验环境使用的k8s集群是一个master节点和一个node节点

master节点的机器ip是192.168.40.180，主机名是xianchaomaster1

node节点的机器ip是192.168.40.181，主机名是xianchaonode1

9.1 node-exporter介绍？

node-exporter可以采集机器（物理机、虚拟机、云主机等）的监控指标数据，能够采集到的指标包括CPU, 内存，磁盘，网络，文件数等信息。

9.2 安装node-exporter

[root@xianchaomaster1 ~]# kubectl create ns monitor-sa

把课件里的node-exporter.tar.gz镜像压缩包上传到k8s的各个节点，手动解压：

[root@xianchaomaster1 ~]# ctr -n=k8s.io images import node-exporter.tar.gz

[root@xianchaomaster1 ~]# docker load -i node-exporter.tar.gz

[root@xianchaonode1 ~]# docker load -i node-exporter.tar.gz

[root@xianchaonode1 ~]# ctr -n=k8s.io images import node-exporter.tar.gz

node-export.yaml文件在课件，可上传到自己k8s的控制节点xianchaomaster1：

cat node-export.yaml

apiVersion: apps/v1

kind: DaemonSet #可以保证k8s集群的每个节点都运行完全一样的pod

metadata:

name: node-exporter

namespace: monitor-sa

labels:

name: node-exporter

spec:

selector:

matchLabels:

name: node-exporter

template:

metadata:

labels:

name: node-exporter

spec:

hostPID: true

hostIPC: true

hostNetwork: true

# hostNetwork、hostIPC、hostPID都为True时，表示这个Pod里的所有容器，会直接使用宿主机的网络，直接与宿主机进行IPC（进程间通信）通信，可以看到宿主机里正在运行的所有进程。

加入了hostNetwork:true会直接将我们的宿主机的9100端口映射出来，从而不需要创建service 在我们的宿主机上就会有一个9100的端口

containers:

- name: node-exporter

image: prom/node-exporter:v0.16.0

imagePullPolicy: IfNotPresent

ports:

- containerPort: 9100

resources:

requests:

cpu: 0.15 #这个容器运行至少需要0.15核cpu

securityContext:

privileged: true #开启特权模式

args:

- --path.procfs #配置挂载宿主机（node节点）的路径

- /host/proc

- --path.sysfs #配置挂载宿主机（node节点）的路径

- /host/sys

- --collector.filesystem.ignored-mount-points

- '"^/(sys|proc|dev|host|etc)($|/)"'

#通过正则表达式忽略某些文件系统挂载点的信息收集

volumeMounts:

- name: dev

mountPath: /host/dev

- name: proc

mountPath: /host/proc

- name: sys

mountPath: /host/sys

- name: rootfs

mountPath: /rootfs

#将主机/dev、/proc、/sys这些目录挂在到容器中，这是因为我们采集的很多节点数据都是通过这些文件来获取系统信息的。

tolerations:

- key: "node-role.kubernetes.io/master"

operator: "Exists"

effect: "NoSchedule"

volumes:

- name: proc

hostPath:

path: /proc

- name: dev

hostPath:

path: /dev

- name: sys

hostPath:

path: /sys

- name: rootfs

hostPath:

path: /

#通过kubectl apply更新node-exporter.yaml文件

[root@xianchaomaster1]# kubectl apply -f node-export.yaml

#查看node-exporter是否部署成功

[root@xianchaomaster1]# kubectl get pods -n monitor-sa

显示如下，看到pod的状态都是running，说明部署成功

NAME READY STATUS RESTARTS AGE

node-exporter-9qpkd 1/1 Running 0 89s

node-exporter-zqmnk 1/1 Running 0 89s

通过node-exporter采集数据

curl http://主机ip:9100/metrics

#node-export默认的监听端口是9100，可以看到当前主机获取到的所有监控数据

curl http://192.168.40.180:9100/metrics | grep node_cpu_seconds

显示192.168.40.180主机cpu的使用情况

# HELP node_cpu_seconds_total Seconds the cpus spent in each mode.

# TYPE node_cpu_seconds_total counter

node_cpu_seconds_total{cpu="0",mode="idle"} 72963.37

node_cpu_seconds_total{cpu="0",mode="iowait"} 9.35

node_cpu_seconds_total{cpu="0",mode="irq"} 0

node_cpu_seconds_total{cpu="0",mode="nice"} 0

node_cpu_seconds_total{cpu="0",mode="softirq"} 151.4

node_cpu_seconds_total{cpu="0",mode="steal"} 0

node_cpu_seconds_total{cpu="0",mode="system"} 656.12

node_cpu_seconds_total{cpu="0",mode="user"} 267.1

#HELP：解释当前指标的含义，上面表示在每种模式下node节点的cpu花费的时间，以s为单位

#TYPE：说明当前指标的数据类型，上面是counter类型

node_cpu_seconds_total{cpu="0",mode="idle"} ：

cpu0上idle进程占用CPU的总时间，CPU占用时间是一个只增不减的度量指标，从类型中也可以看出node_cpu的数据类型是counter（计数器）

counter计数器：只是采集递增的指标

curl http://192.168.40.180:9100/metrics | grep node_load

# HELP node_load1 1m load average.

# TYPE node_load1 gauge

node_load1 0.1

node_load1该指标反映了当前主机在最近一分钟以内的负载情况，系统的负载情况会随系统资源的使用而变化，因此node_load1反映的是当前状态，数据可能增加也可能减少，从注释中可以看出当前指标类型为gauge（标准尺寸）

gauge标准尺寸：统计的指标可增加可减少

10、Prometheus server安装和配置

10.1 创建sa账号，对sa做rbac授权

#创建一个sa账号monitor

[root@xianchaomaster1 ~]# kubectl create serviceaccount monitor -n monitor-sa

#把sa账号monitor通过clusterrolebing绑定到clusterrole上

[root@xianchaomaster1 ~]# kubectl create clusterrolebinding monitor-clusterrolebinding -n monitor-sa --clusterrole=cluster-admin --serviceaccount=monitor-sa:monitor

#注意：有的同学执行上面授权也会报错，那就需要下面的授权命令：

[root@xianchaomaster1~]# kubectl create clusterrolebinding monitor-clusterrolebinding-1 -n monitor-sa --clusterrole=cluster-admin --user=system:serviceaccount:monitor:monitor-sa

10.2 创建prometheus数据存储目录

#在k8s集群的xianchaonode1节点上创建数据存储目录

[root@xianchaonode1 ~]# mkdir /data

[root@xianchaonode1 ~]# chmod 777 /data/

10.3 安装Prometheus server服务

10.3.1 创建一个configmap存储卷，用来存放prometheus配置信息

prometheus-cfg.yaml文件在课件，可上传到k8s控制节点xianchaomaster1上:

#通过kubectl apply更新configmap

[root@xianchaomaster1 prometheus]# kubectl apply -f prometheus-cfg.yaml

prometheus-cfg.yaml文件内容如下：

---

kind: ConfigMap

apiVersion: v1

metadata:

labels:

app: prometheus

name: prometheus-config

namespace: monitor-sa

data:

prometheus.yml: |

global:

scrape_interval: 15s #采集目标主机监控据的时间间隔

scrape_timeout: 10s # 数据采集超时时间，默认10s

evaluation_interval: 1m #触发告警检测的时间，默认是1m

我们写了超过80%的告警，结果收到多条告警，但是真实超过80%的只有一个时间点。
这是另外一个参数影响的

evaluation_interval

这个是触发告警检测的时间，默认为1m。
假如我们的指标是5m被拉取一次。
检测根据evaluation_interval 1m一次，所以在值被更新前，我们一直用的旧值来进行多次判断，造成了1m一次，同一个指标被告警了4次。

scrape_configs:

#scrape_configs：配置数据源，称为target，每个target用job_name命名。又分为静态配置和服务发现

- job_name: 'kubernetes-node'

kubernetes_sd_configs:

#使用的是k8s的服务发现

- role: node

# 使用node角色，它使用默认的kubelet提供的http端口来发现集群中每个node节点。

relabel_configs:

#重新标记

- source_labels: [__address__] #配置的原始标签，匹配地址

regex: '(.*):10250' #匹配带有10250端口的url

replacement: '${1}:9100' #把匹配到的ip:10250的ip保留

target_label: __address__ #新生成的url是${1}获取到的ip:9100

action: replace

- action: labelmap

#匹配到下面正则表达式的标签会被保留,如果不做regex正则的话，默认只是会显示instance标签

regex: __meta_kubernetes_node_label_(.+)

注意：Before relabeling表示匹配到的所有标签

instance="xianchaomaster1"

Before relabeling:
__address__="192.168.40.180:10250"
__meta_kubernetes_node_address_Hostname="xianchaomaster1"
__meta_kubernetes_node_address_InternalIP="192.168.40.180"
__meta_kubernetes_node_annotation_kubeadm_alpha_kubernetes_io_cri_socket="/var/run/dockershim.sock"
__meta_kubernetes_node_annotation_node_alpha_kubernetes_io_ttl="0"
__meta_kubernetes_node_annotation_projectcalico_org_IPv4Address="192.168.40.180/24"
__meta_kubernetes_node_annotation_projectcalico_org_IPv4IPIPTunnelAddr="10.244.123.64"
__meta_kubernetes_node_annotation_volumes_kubernetes_io_controller_managed_attach_detach="true"
__meta_kubernetes_node_label_beta_kubernetes_io_arch="amd64"
__meta_kubernetes_node_label_beta_kubernetes_io_os="linux"
__meta_kubernetes_node_label_kubernetes_io_arch="amd64"
__meta_kubernetes_node_label_kubernetes_io_hostname="xianchaomaster1"
__meta_kubernetes_node_label_kubernetes_io_os="linux"
__meta_kubernetes_node_label_node_role_kubernetes_io_control_plane=""
__meta_kubernetes_node_label_node_role_kubernetes_io_master=""
__meta_kubernetes_node_name="xianchaomaster1"
__metrics_path__="/metrics"
__scheme__="http"
instance="xianchaomaster1"
job="kubernetes-node"

- job_name: 'kubernetes-node-cadvisor'

# 抓取cAdvisor数据，是获取kubelet上/metrics/cadvisor接口数据来获取容器的资源使用情况

kubernetes_sd_configs:

- role: node

scheme: https

tls_config:

ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

relabel_configs:

- action: labelmap #把匹配到的标签保留

regex: __meta_kubernetes_node_label_(.+)

#保留匹配到的具有__meta_kubernetes_node_label的标签

- target_label: __address__

#获取到的地址：__address__="192.168.40.180:10250"

replacement: kubernetes.default.svc:443

#把获取到的地址替换成新的地址kubernetes.default.svc:443

- source_labels: [__meta_kubernetes_node_name]

regex: (.+)

#把原始标签中__meta_kubernetes_node_name值匹配到

target_label: __metrics_path__

#获取__metrics_path__对应的值

replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

#把metrics替换成新的值api/v1/nodes/xianchaomaster1/proxy/metrics/cadvisor

${1}是__meta_kubernetes_node_name获取到的值

新的url就是https://kubernetes.default.svc:443/api/v1/nodes/xianchaomaster1/proxy/metrics/cadvisor

- job_name: 'kubernetes-apiserver'

kubernetes_sd_configs:

- role: endpoints

#使用k8s中的endpoint服务发现，采集apiserver 6443端口获取到的数据

scheme: https

tls_config:

ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

relabel_configs:

- source_labels: [__meta_kubernetes_namespace

#endpoint这个对象的名称空间

,__meta_kubernetes_service_name

#endpoint对象的服务名

, __meta_kubernetes_endpoint_port_name

#exnpoint的端口名称]

action: keep #采集满足条件的实例，其他实例不采集

regex: default;kubernetes;https

#正则匹配到的默认空间下的service名字是kubernetes，协议是https的endpoint类型保留下来

- job_name: 'kubernetes-service-endpoints'

kubernetes_sd_configs:

- role: endpoints

relabel_configs:

- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]

action: keep

regex: true

# 重新打标仅抓取到的具有 "prometheus.io/scrape: true" 的annotation的端点，意思是说如果某个service具有prometheus.io/scrape = true annotation声明则抓取，annotation本身也是键值结构，所以这里的源标签设置为键，而regex设置值true，当值匹配到regex设定的内容时则执行keep动作也就是保留，其余则丢弃。

- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]

action: replace

target_label: __scheme__

regex: (https?)

#重新设置scheme，匹配源标签__meta_kubernetes_service_annotation_prometheus_io_scheme也就是prometheus.io/scheme annotation，如果源标签的值匹配到regex，则把值替换为__scheme__对应的值。

- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]

action: replace

target_label: __metrics_path__

regex: (.+)

# 应用中自定义暴露的指标，也许你暴露的API接口不是/metrics这个路径，那么你可以在这个POD对应的service中做一个"prometheus.io/path = /mymetrics" 声明，上面的意思就是把你声明的这个路径赋值给__metrics_path__，其实就是让prometheus来获取自定义应用暴露的metrices的具体路径，不过这里写的要和service中做好约定，如果service中这样写 prometheus.io/app-metrics-path: '/metrics' 那么你这里就要
__meta_kubernetes_service_annotation_prometheus_io_app_metrics_path这样写。

- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]

action: replace

target_label: __address__

regex: ([^:]+)(?::\d+)?;(\d+)

replacement: $1:$2

# 暴露自定义的应用的端口，就是把地址和你在service中定义的 "prometheus.io/port = <port>" 声明做一个拼接，然后赋值给__address__，这样prometheus就能获取自定义应用的端口，然后通过这个端口再结合__metrics_path__来获取指标，如果__metrics_path__值不是默认的/metrics那么就要使用上面的标签替换来获取真正暴露的具体路径。

- action: labelmap #保留下面匹配到的标签

regex: __meta_kubernetes_service_label_(.+)

- source_labels: [__meta_kubernetes_namespace]

action: replace #替换__meta_kubernetes_namespace变成kubernetes_namespace

target_label: kubernetes_namespace

- source_labels: [__meta_kubernetes_service_name]

action: replace

target_label: kubernetes_name

#更新configmap资源

[root@xianchaomaster1 prometheus]# kubectl apply -f prometheus-cfg.yaml

10.3.2 通过deployment部署prometheus

安装prometheus需要的镜像prometheus-2-2-1.tar.gz在课件，上传到k8s的工作节点xianchaonode1上，手动解压：

[root@xianchaonode1 ~]# ctr -n=k8s.io images import prometheus-2-2-1.tar.gz

[root@xianchaonode1 ~]# docker load -i prometheus-2-2-1.tar.gz

prometheus-deploy.yaml文件在课件里，上传到自己的k8s的控制节点xianchaomaster1

#通过kubectl apply更新prometheus

[root@xianchaomaster1]# kubectl apply -f prometheus-deploy.yaml

#查看prometheus是否部署成功

[root@xianchaomaster1]# kubectl get pods -n monitor-sa

显示如下，可看到pod状态是running，说明prometheus部署成功

NAME READY STATUS RESTARTS AGE

node-exporter-9qpkd 1/1 Running 0 76m

node-exporter-zqmnk 1/1 Running 0 76m

prometheus-server-85dbc6c7f7-nsg94 1/1 Running 0 6m7

注意：在上面的prometheus-deploy.yaml文件有个nodeName字段，这个就是用来指定创建的这个prometheus的pod调度到哪个节点上，我们这里让nodeName=xianchaonode1，也即是让pod调度到xianchaonode1节点上，因为xianchaonode1节点我们创建了数据目录/data，所以大家记住：你在k8s集群的哪个节点创建/data，就让pod调度到哪个节点，nodeName根据你们自己环境主机去修改即可。

prometheus-deploy.yaml文件内容如下：

---

apiVersion: apps/v1

kind: Deployment

metadata:

name: prometheus-server

namespace: monitor-sa

labels:

app: prometheus

spec:

replicas: 1

selector:

matchLabels:

app: prometheus

component: server

#matchExpressions:

#- {key: app, operator: In, values: [prometheus]}

#- {key: component, operator: In, values: [server]}

template:

metadata:

labels:

app: prometheus

component: server

annotations:

prometheus.io/scrape: 'false'

spec:

nodeName: xianchaonode1

serviceAccountName: monitor

containers:

- name: prometheus

image: prom/prometheus:v2.2.1

imagePullPolicy: IfNotPresent

command:

- prometheus

- --config.file=/etc/prometheus/prometheus.yml

- --storage.tsdb.path=/prometheus #旧数据存储目录

- --storage.tsdb.retention=720h #何时删除旧数据，默认为15天。

- --web.enable-lifecycle #开启热加载

ports:

- containerPort: 9090

protocol: TCP

volumeMounts:

- mountPath: /etc/prometheus

name: prometheus-config

- mountPath: /prometheus/

name: prometheus-storage-volume

volumes:

- name: prometheus-config

configMap:

name: prometheus-config

- name: prometheus-storage-volume

hostPath:

path: /data

type: Directory

10.3.3 给prometheus pod创建一个service

prometheus-svc.yaml文件在课件，可上传到k8s的控制节点xianchaomaster1上：

#通过kubectl apply 更新service

[root@xianchaomaster1]# kubectl apply -f prometheus-svc.yaml

prometheus-svc.yaml文件内容如下：

---

apiVersion: v1

kind: Service

metadata:

name: prometheus

namespace: monitor-sa

labels:

app: prometheus

spec:

type: NodePort

ports:

- port: 9090

targetPort: 9090

protocol: TCP

selector:

app: prometheus

component: server

#查看service在物理机映射的端口

[root@xianchaomaster1]# kubectl get svc -n monitor-sa

显示如下：

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

prometheus NodePort 10.96.45.93 <none> 9090:32732/TCP 50s

通过上面可以看到service在宿主机上映射的端口是32732，这样我们访问k8s集群的master1节点的ip:32732，就可以访问到prometheus的web ui界面了

#访问prometheus web ui界面

火狐浏览器输入如下地址：

http://192.168.40.180:32732/graph

可看到如下页面：

#点击页面的Status->Targets，可看到如下,说明我们配置的服务发现可以正常采集数据

10.3.4 Prometheus热加载

#为了每次修改配置文件可以热加载prometheus，也就是不停止prometheus，就可以使配置生效，想要使配置生效可用如下热加载命令：

[root@xianchaomaster1 prometheus]# kubectl get pods -n monitor-sa -o wide -l app=prometheus

#10.244.121.4是prometheus的pod的ip地址，如何查看prometheus的pod ip

想要使配置生效可用如下命令热加载：
[root@xianchaomaster1]# curl -X POST http://10.244.121.4:9090/-/reload

#热加载速度比较慢，可以暴力重启prometheus，如修改上面的prometheus-cfg.yaml文件之后，可执行如下强制删除：

kubectl delete -f prometheus-cfg.yaml

kubectl delete -f prometheus-deploy.yaml

然后再通过apply更新：

kubectl apply -f prometheus-cfg.yaml

kubectl apply -f prometheus-deploy.yaml

注意：

线上最好热加载，暴力删除可能造成监控数据的丢失

11、可视化UI界面Grafana的安装和配置

11.1 Grafana介绍

Grafana是一个跨平台的开源的度量分析和可视化工具，可以将采集的数据可视化的展示，并及时通知给告警接收方。它主要有以下六大特点：

1、展示方式：快速灵活的客户端图表，面板插件有许多不同方式的可视化指标和日志，官方库中具有丰富的仪表盘插件，比如热图、折线图、图表等多种展示方式；

2、数据源：Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch和KairosDB等；

3、通知提醒：以可视方式定义最重要指标的警报规则，Grafana将不断计算并发送通知，在数据达到阈值时通过Slack、PagerDuty等获得通知；

4、混合展示：在同一图表中混合使用不同的数据源，可以基于每个查询指定数据源，甚至自定义数据源；

5、注释：使用来自不同数据源的丰富事件注释图表，将鼠标悬停在事件上会显示完整的事件元数据和标记。

11.2 安装Grafana

安装Grafana需要的镜像heapster-grafana-amd64_v5_0_4.tar.gz,把镜像上传到k8s的工作节点xianchaonode1上，手动解压：

[root@xianchaonode1 ~]# ctr -n=k8s.io images import heapster-grafana-amd64_v5_0_4.tar.gz
[root@xianchaonode1 ~]# docker load -i heapster-grafana-amd64_v5_0_4.tar.gz

grafana.yaml文件在课件里，可上传到k8s的控制节点：

更新yaml文件：

[root@xianchaomaster1 prometheus]# kubectl apply -f grafana.yaml

#查看grafana是否创建成功：

[root@xianchaomaster1 prometheus]# kubectl get pods -n kube-system -l task=monitoring

显示如下，说明部署成功

NAME READY STATUS RESTARTS AGE

monitoring-grafana-675798bf47-cw9hr 1/1 Running 0 39s

grafana.yaml文件内容如下：

apiVersion: apps/v1

kind: Deployment

metadata:

name: monitoring-grafana

namespace: kube-system

spec:

replicas: 1

selector:

matchLabels:

task: monitoring

k8s-app: grafana

template:

metadata:

labels:

task: monitoring

k8s-app: grafana

spec:

containers:

- name: grafana

image: k8s.gcr.io/heapster-grafana-amd64:v5.0.4

ports:

- containerPort: 3000

protocol: TCP

volumeMounts:

- mountPath: /etc/ssl/certs

name: ca-certificates

readOnly: true

- mountPath: /var

name: grafana-storage

env:

- name: INFLUXDB_HOST

value: monitoring-influxdb

- name: GF_SERVER_HTTP_PORT

value: "3000"

# The following env variables are required to make Grafana accessible via

# the kubernetes api-server proxy. On production clusters, we recommend

# removing these env variables, setup auth for grafana, and expose the grafana

# service using a LoadBalancer or a public IP.

- name: GF_AUTH_BASIC_ENABLED

value: "false"

- name: GF_AUTH_ANONYMOUS_ENABLED

value: "true"

- name: GF_AUTH_ANONYMOUS_ORG_ROLE

value: Admin

- name: GF_SERVER_ROOT_URL

# If you're only using the API Server proxy, set this value instead:

# value: /api/v1/namespaces/kube-system/services/monitoring-grafana/proxy

value: /

volumes:

- name: ca-certificates

hostPath:

path: /etc/ssl/certs

- name: grafana-storage

emptyDir: {}

---

apiVersion: v1

kind: Service

metadata:

labels:

# For use as a Cluster add-on (https://github.com/kubernetes/kubernetes/tree/master/cluster/addons)

# If you are NOT using this as an addon, you should comment out this line.

kubernetes.io/cluster-service: 'true'

kubernetes.io/name: monitoring-grafana

name: monitoring-grafana

namespace: kube-system

spec:

# In a production setup, we recommend accessing Grafana through an external Loadbalancer

# or through a public IP.

# type: LoadBalancer

# You could also use NodePort to expose the service at a randomly-generated port

# type: NodePort

ports:

- port: 80

targetPort: 3000

selector:

k8s-app: grafana

type: NodePort

11.3 Grafana界面接入Prometheus数据源

查看grafana前端的service

[root@xianchaomaster1]# kubectl get svc -n kube-system | grep grafana

显示如下：

monitoring-grafana NodePort 10.106.3.47 <none> 80:30858/TCP

1）登陆grafana，在浏览器访问

192.168.40.180:30858

可看到如下界面：

2）配置grafana界面：
开始配置grafana的web界面：
选择Create your first data source

出现如下

Name: Prometheus

Type: Prometheus

HTTP 处的URL写如下：

http://prometheus.monitor-sa.svc:9090

配置好的整体页面如下：

点击左下角Save & Test，出现如下Data source is working，说明prometheus数据源成功的被grafana接入了

导入的监控模板，可在如下链接搜索
Grafana dashboards | Grafana Labs

可直接导入node_exporter.json监控模板，这个可以把node节点指标显示出来

node_exporter.json在课件里

可直接导入docker_rev1.json，显示容器资源指标的，docker_rev1.json在课件里

怎么导入监控模板，按如下步骤：

上面Save & Test测试没问题之后，就可以返回Grafana主页面

点击左侧+号下面的Import，出现如下界面

选择Upload json file，出现如下

选择一个本地的json文件，我们选择的是上面让大家下载的node_exporter.json这个文件，选择之后出现如下：

注：箭头标注的地方Name后面的名字是node_exporter.json定义的

Prometheus后面需要变成Prometheus，然后再点击Import，就可以出现如下界面：

导入docker_rev1.json监控模板，步骤和上面导入node_exporter.json步骤一样，导入之后显示如下：

扩展：如果Grafana导入Prometheusz之后，发现仪表盘没有数据，如何排查？

1、打开grafana界面，找到仪表盘对应无数据的图标

Edit之后出现如下：

node_cpu_seconds_total 就是grafana上采集的cpu的时间，需要到prometheus ui界面看看采集的指标是否是node_cpu_seconds_total

如果在prometheus ui界面输入node_cpu_seconds_total没有数据，那就看看是不是prometheus采集的数据是node_cpu_seconds_totals，怎么看呢？

12、安装kube-state-metrics组件

kube-state-metrics是什么？

kube-state-metrics通过监听API Server生成有关资源对象的状态指标，比如Node、Pod，需要注意的是kube-state-metrics只是简单的提供一个metrics数据，并不会存储这些指标数据，所以我们可以使用Prometheus来抓取这些数据然后存储，主要关注的是业务相关的一些元数据，比如Pod副本状态等；调度了多少个replicas？现在可用的有几个？多少个Pod是running/stopped/terminated状态？Pod重启了多少次？我有多少job在运行中。

安装kube-state-metrics组件

1）创建sa，并对sa授权

在k8s的控制节点生成一个kube-state-metrics-rbac.yaml文件，kube-state-metrics-rbac.yaml文件在课件，大家上传到k8s的控制节点即可：

通过kubectl apply更新资源清单yaml文件

[root@xianchaomaster1 prometheus]# kubectl apply -f kube-state-metrics-rbac.yaml

kube-state-metrics-rbac.yaml文件内容如下：

---

apiVersion: v1

kind: ServiceAccount

metadata:

name: kube-state-metrics

namespace: kube-system

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

name: kube-state-metrics

rules:

- apiGroups: [""]

resources: ["nodes", "pods", "services", "resourcequotas", "replicationcontrollers", "limitranges", "persistentvolumeclaims", "persistentvolumes", "namespaces", "endpoints"]

verbs: ["list", "watch"]

- apiGroups: ["extensions"]

resources: ["daemonsets", "deployments", "replicasets"]

verbs: ["list", "watch"]

- apiGroups: ["apps"]

resources: ["statefulsets"]

verbs: ["list", "watch"]

- apiGroups: ["batch"]

resources: ["cronjobs", "jobs"]

verbs: ["list", "watch"]

- apiGroups: ["autoscaling"]

resources: ["horizontalpodautoscalers"]

verbs: ["list", "watch"]

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

name: kube-state-metrics

roleRef:

apiGroup: rbac.authorization.k8s.io

kind: ClusterRole

name: kube-state-metrics

subjects:

- kind: ServiceAccount

name: kube-state-metrics

namespace: kube-system

2)安装kube-state-metrics组件

安装kube-state-metrics组件需要的镜像在课件，可上传到k8s各个工作节点，手动解压：

[root@xianchaonode1 ~]#ctr -n=k8s.io images import kube-state-metrics_1_9_0.tar.gz

[root@xianchaonode1 ~]# docker load -i kube-state-metrics_1_9_0.tar.gz

在k8s的控制节点生成一个kube-state-metrics-deploy.yaml文件，kube-state-metrics-deploy.yaml在课件，可上传到xianchaomaster1节点：

通过kubectl apply更新yaml文件

[root@xianchaomaster1 prometheus]# kubectl apply -f kube-state-metrics-deploy.yaml

kube-state-metrics-deploy.yaml文件内容如下：

apiVersion: apps/v1

kind: Deployment

metadata:

name: kube-state-metrics

namespace: kube-system

spec:

replicas: 1

selector:

matchLabels:

app: kube-state-metrics

template:

metadata:

labels:

app: kube-state-metrics

spec:

serviceAccountName: kube-state-metrics

containers:

- name: kube-state-metrics

image: quay.io/coreos/kube-state-metrics:v1.9.0

ports:

- containerPort: 8080

查看kube-state-metrics是否部署成功

[root@xianchaomaster1]# kubectl get pods -n kube-system -l app=kube-state-metrics

显示如下，看到pod处于running状态，说明部署成功

kube-state-metrics-79c9686b96-4njrs 1/1 Running 0 76s

3）创建service
在8s的控制节点生成一个kube-state-metrics-svc.yaml文件，kube-state-metrics-svc.yaml文件在课件，可上传到k8s的xianchaomaster1节点：

通过kubectl apply更新yaml

[root@xianchaomaster1]# kubectl apply -f kube-state-metrics-svc.yaml

kube-state-metrics-svc.yaml文件内容如下：

apiVersion: v1

kind: Service

metadata:

annotations:

prometheus.io/scrape: 'true'

name: kube-state-metrics

namespace: kube-system

labels:

app: kube-state-metrics

spec:

ports:

- name: kube-state-metrics

port: 8080

protocol: TCP

selector:

app: kube-state-metrics

查看service是否创建成功

[root@xianchaomaster1]# kubectl get svc -n kube-system | grep kube-state-metrics

显示如下，说明创建成功

kube-state-metrics ClusterIP 10.105.53.102 <none> 8080/TCP

在grafana web界面导入Kubernetes Cluster (Prometheus)-1577674936972.json和Kubernetes cluster monitoring (via Prometheus) (k8s 1.16)-1577691996738.json，Kubernetes Cluster (Prometheus)-1577674936972.json和Kubernetes cluster monitoring (via Prometheus) (k8s 1.16)-1577691996738.json文件在课件

导入Kubernetes Cluster (Prometheus)-1577674936972.json文件