Kubernetes 17 (k8s中部署Prometheus、监控nginx、HPA自动伸缩)
目录一、Prometheus简介二、k8s部署Prometheus监控三、prometheus监控nginx四、Prometheus实现hpa动态伸缩一、Prometheus简介Prometheus 是一套开源的系统监控报警框架,它启发于 Google 的 borgmon 监控系统。除了资源指标(如CPU、内存)以外,用户或管理员需要了解更多的指标数据,比如Kubernetes指标、容器指标、节点
一、Prometheus简介
Prometheus 是一套开源的系统监控报警框架,它启发于 Google 的 borgmon 监控系统。除了资源指标(如CPU、内存)以外,用户或管理员需要了解更多的指标数据,比如Kubernetes指标、容器指标、节点资源指标以及应用程序指标等等。自定义指标API允许请求任意的指标,其指标API的实现要指定相应的后端监视系统。Prometheus是第一个开发了相应适配器的监控系统。
- 普罗米修斯与其他度量(metrics)和监控系统的区别在于:
多维数据模型(由度量名称和键/值维度集定义的时间序列)
PromQL是一种强大而灵活的查询语言,可以利用这种维度
不依赖分布式存储;单服务器节点是自治的
用于时间序列采集的HTTP pull模型
通过批处理作业的中间网关支持推送时间序列
通过服务发现或静态配置发现目标
图形和仪表板支持的多种模式
支持分层和水平联合 - 架构
运行流程如下,prometheus根据配置定时去拉取各个节点的数据,默认使用的拉取方式是pull,也可以使用pushgateway提供的push方式获取各个监控节点的数据。将获取到的数据存入TSDB,一款时序型数据库。此时prometheus已经获取到了监控数据,可以使用内置的PromQL进行查询。它的报警功能使用Alertmanager提供,Alertmanager是prometheus的告警管理和发送报警的一个组件。prometheus原生的图标功能过于简单,可将prometheus数据接入grafana,由grafana进行统一管理。
1、Prometheus是一个开源的服务监控系统和时序数据库,其提供了通用的数据模型和快捷数据采集、存储和查询接口。它的核心组件Prometheus服务器定期从静态配置的监控目标或者基于服务发现自动配置的目标中进行拉取数据,新拉取到的数据大于配置的内存缓存区时,数据就会持久化到存储设备当中。
2、如上图,每个被监控的主机都可以通过专用的exporter程序提供输出监控数据的接口,并等待Prometheus服务器周期性的进行数据抓取。如果存在告警规则,则抓取到数据之后会根据规则进行计算,满足告警条件则会生成告警,并发送到Alertmanager完成告警的汇总和分发。当被监控的目标有主动推送数据的需求时,可以以Pushgateway组件进行接收并临时存储数据,然后等待Prometheus服务器完成数据的采集。
二、k8s部署Prometheus监控
server2添加apphub仓库源;
查找prometheus-operator并拉取
解压prometheus-operator包,进入解压得到的目录
可以看到有三个组件:
kube-state-metrics:直接采集的数据集群无法使用,kube-state-metrics负责从prometheus的数据格式转换为k8s集群可以识别的格式。
prometheus-node-exporter:安装在被监控端,负责采集多种数据。Prometheus通常去不同client端拉取数据,但有些应用数据无法拉取,这时候这些应用将数据push到Pushgateway网关,由Pushgateway网关将数据发送给server端。
grafana可以产生图像化监控
仓库中创建新项目,kubeapps
真机将prometheus-operator包发送给server1
server1导入镜像
将镜像上传至仓库
server2修改values.yaml主配置文件;
打开三个ingress,设定域名和路径
修改八个镜像路径到自己的仓库路径
添加登陆密码
编辑完成后去依赖性子目录charts/中,可以看到三个组件:
进入grafana/目录下,修改values.yaml配置文件,打开Ingress,配置hosts
将5个镜像指向私有仓库
进入kube-state-metrics子目录,修改value.yaml文件
修改一个镜像路径到自己的仓库路径
创建prometheus-operator命名空间
将prometheus-operator安装在prometheus-operator命名空间下
(注意宿主机和集群虚拟机时间要同步,因为Prometheus是以时间序列方式采集数据)
查看pod全部正常启动
查看prometheus-operator命名空间内的ingress也正常运行
控制器也就绪
为测试访问,为真实主机添加域名解析
浏览器访问prometheus.westos.org,进入status菜单栏内的service discovery
服务正常显示
访问grafana.westos.org,输入配置文件中设定的用户名和密码
grafana的图形化展示比原本的Prometheus做的好,数据源默认的Prometheus
显示数据源正常工作,点击测试
找到prometheus将其添加到监控面板
可以看到监控页面正常运行
三、prometheus监控nginx
通过helm图形化界面直接安装nginx
进入nginx,使用9.4.1版本;
应用名称设置为nginx,服务类型为LoadBalancer
副本数量选择1个,打开Prometheus监控选项;
Prometheus专门监控nginx的agent插件:nginx-exporter
修改yaml配置文件,更改镜像仓库地址
设置镜像仓库和标签
指定服务部署在prometheus-operator命名空间内
最后可以看到修改的地方
部署成功
通过浏览器访问上图nginx应用的URL,可以看到访问成功
查看pod信息,可以看到刚创建的nginx及其服务和外部访问地址
查看开放了9113端口监控
但是,此时的nginx还无法被prometheus发现,原因是未添加对应的标签release=prometheus-operator
查看nginx没有标签release=prometheus-operator,其他有
为nginx添加release=prometheus-operator这个标签
现在在图形管理界面可以看到nginx服务
点击Graph,将访问流量统计图添加进统计页
如图,可以看到nginx访问流量效果图
四、Prometheus实现hpa动态伸缩
之前学习了根据核心指标(cpu和mem)hpa控制副本的数量。如果想根据其他指标(比如nginx的访问量)控制的话,需要用到自定义指标的HPA,需要提供社区标准的Custom Metric API,一般用户使用Prometheus-Adapter来提供Custom Metric API,其主要功能是将接受到custom metric api转换成Prometheus的请求,从Prometheus中查询数据返回给API Server。简单说,prometheus-adapter负责转换数据
server2查看pod信息可以看到prometheus-operator-kube-state-metrics
执行 kubectl api-versions 查看api group ,metrics为v1beta1版本
查找prometheus-adapter插件,拉取到本地
解压tar包,修改values.yaml配置文件
修改镜像路径和prometheus的服务地址
配置文件中的prometheus的服务地址可以通过下图命令查看
拉起一个容器并进入,测试能否访问到上面prometheus的服务地址
在prometheus-operator命名空间下安装prometheus-adapter
查看prometheus-operator命名空间下的pod信息,都正常运行
一个pod内两个容器,其中一个是nginx服务本身,另一个:9113端口是对prometheus监控开放的agent(metrics的)
查看有了custom.metrics,数据格式可以匹配
安装完成后,使用提示语句,可以看到有变量出现
再次执行刚才复制的指令,这次指定命名空间、pod和监控指标
指定的监控指标名字就是下图红框部分
使用python语句查看,更清晰明了
编写hpa-nginx.yaml 文件
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: hpa-example
spec:
maxReplicas: 10 %最多伸缩到10个副本
minReplicas: 1 %最少伸缩为1个副本
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
metrics:
- type: Pods
pods:
metric:
name: nginx_http_requests %监控类型为nginx的访问流量
target:
type: AverageValue %hpa变化的依据是平均值是否在10附近
averageValue: 10
应用hpa-nginx.yaml文件
查看hpa详细信息;
HPA可以根据pods的nginx访问流量度量成功计算副本计数
接下来使用hey压力测试,真机把hey放到/usr/local/bin,赋予可执行权限
真机运行hey进行访问测试(访问nginx的主发布页面),总运行次数一万次,每秒五次访问,5个线程并发,即每秒25次访问
kubectl get hpa hpa-example -w:查看hpa的动态状态变化,可以看到随着访问压力的增大,hpa开始生效并增加副本数量,逐渐扩容到3个(集群根据压力大小进行动态添加副本,实现动态伸缩);
访问压力是5*5=25,yaml文件中设定了每个pod最多10个请求,所以,需要3个replicas之后就可以稳定
选择graph可以查看到每个时刻的数据(访问nginx的请求)
更多推荐
所有评论(0)