TKE上搭建prometheus
该文章介绍了如何在k8s集群中搭建prometheus来监控集群并通过AlertManager发送告警。
新建namespace部署prometheus

部署prometheus
创建pvc挂载卷挂载prometheus数据


通过configmap配置prometheus配置文件

创建prometheus的pod资源

创建prometheus的svc

页面访问prometheus

我们就可以通过http://任意节点IP:31160访问 prometheus 的 webui 服务了。

监控集群节点
可以通过node_exporter来获取,顾名思义,node_exporter 就是抓取用于采集服务器节点的各种运行指标,目前 node_exporter 支持几乎所有常见的监控点,比如 conntrack,cpu,diskstats,filesystem,loadavg,meminfo,netstat等

我们上面是指定了hostNetwork=true,所以在每个节点上就会绑定一个端口 9100,我们可以通过这个端口去获取到监控指标数据,不需要创建service
让 Prometheus 也能够获取到当前集群中的所有节点信息的话,我们就需要利用 Node 的服务发现模式,同样的prometheus.yml 文件中配置如下的 job 任务即可
prometheus 去发现 Node 模式的服务的时候,访问的端口默认是10250,而现在该端口下面已经没有了/metrics指标数据了,现在 kubelet 只读的数据接口统一通过10255端口进行暴露了,所以我们应该去替换掉这里的端口,但是我们是要替换成10255端口吗?不是的,因为我们是要去配置上面通过node-exporter抓取到的节点指标数据,而我们上面是不是指定了hostNetwork=true,所以在每个节点上就会绑定一个端口9100,所以我们应该将这里的10250替换成9100,但是应该怎样替换呢?
这里我们就需要使用到 Prometheus 提供的relabelconfigs中的replace能力了,relabel 可以在 Prometheus 采集数据之前,通过Target 实例的 Metadata 信息,动态重新写入 Label 的值。除此之外,我们还能根据 Target 实例的 Metadata 信息选择是否采集或者忽略该 Target 实例。比如我们这里就可以去匹配_address这个 Label 标签,然后替换掉其中的端口
最终添加如下job即可
由于 kubelet 也自带了一些监控指标数据,就上面我们提到的10255端口,所以我们这里也把 kubelet 的监控任务也一并配置上

curl一下接口,使配置项生效,去prometheus 的 dashboard 中查看 Targets 是否能够正常抓取数据

容器监控
容器监控我们自然会想到cAdvisor,我们前面也说过cAdvisor已经内置在了 kubelet 组件之中,所以我们不需要单独去安装,cAdvisor的数据路径为/api/v1/nodes//proxy/metrics,同样我们这里使用 node 的服务发现模式,因为每一个节点下面都有 kubelet,自然都有cAdvisor采集到的数据指标,在prometheus.yaml中配置一下即可

reload使配置生效

界面查看cadvisor的target是否生效
Apiservice的监控
集群的 apiserver 在集群内部的 Service 地址,要自动发现 Service 类型的服务,我们就需要用到 role 为 Endpoints 的 kubernetes_sd_configs,我们可以在 ConfigMap 对象中添加上一个 Endpoints 类型的服务的监控任务 由于 kubernetes 这个服务对应的端口是443,需要使用 https 协议,所以这里我们需要使用 https 的协议,对应的就需要将对应的 ca 证书配置上,最终配置如下

reload使prometheus.yml配置生效

Service的监控
配置一个任务用来专门发现普通类型的 Service
想自动发现集群中的 Service,就需要我们在 Service 的annotation区域添加prometheus.io/scrape=true的声明 我们修改下redis的service,生效后可以在target中查看到

部署kube-state-metrics
kube-state-metrice主要是负责监控pod、DaemonSet、Deployment、Job、CronJob 等各种资源对象的状态
部署kube-state-metrice的pod应用
部署kube-state-metrice的service
kube-state-metrics-service.yaml 对 Service 的定义包含prometheus.io/scrape: 'true'这样的一个annotation,因此 kube-state-metrics 的 endpoint 可以被 Prometheus 自动服务发现

部署granafa
新建pvc做数据持久化

创建grafana的svc
创建gafana的deployment
访问grafana界面

现在我们就可以在浏览器中使用http://<任意节点IP:31838>来访问 grafana 这个服务了:

登录账号密码从deployment的配置文件查看
配置数据源


添加Dashboard

我们这里可以使用Kubernetes cluster monitoring (via Prometheus)(dashboard id 为162)


AlertManager配置告警
配置告警配置文件
配置告警发送模板文件
配置alertmanager容器
我们可以直接在之前的 Prometheus 的 Pod 中添加这个容器,对应的 YAML 资源声明如下:
prometheus中配置alermanager
Prometheus 中配置下 AlertManager 的地址,让 Prometheus 能够访问到 AlertManager
设置告警规则
直接在prometheus的配置文件中配置告警规则
查看告警


在这个页面中我们可以进行一些操作,比如过滤、分组等等,里面还有两个新的概念:Inhibition(抑制)和 Silences(静默)。
Inhibition:如果某些其他警报已经触发了,则对于某些警报,Inhibition 是一个抑制通知的概念。例如:一个警报已经触发,它正在通知整个集群是不可达的时,Alertmanager 则可以配置成关心这个集群的其他警报无效。这可以防止与实际问题无关的数百或数千个触发警报的通知,Inhibition 需要通过上面的配置文件进行配置。
Silences:静默是一个非常简单的方法,可以在给定时间内简单地忽略所有警报。Silences 基于 matchers配置,类似路由树。来到的警告将会被检查,判断它们是否和活跃的 Silences 相等或者正则表达式匹配。如果匹配成功,则不会将这些警报发送给接收者。
由于全局配置中我们配置的repeat_interval: 5m,所以正常来说,上面的测试报警如果一直满足报警条件(CPU使用率大于20%)的话,那么每5分钟我们就可以收到一条报警邮件。

配置ingress通过域名访问

将域名解析到对应的vip上

配置好ingress的转发规则

通过域名来访问
最后更新于
这有帮助吗?