标签：队列 adapter rabbitmq metrics -- prometheus HPA k8s
说明介绍
HPA是k8s 里面的一个资源对象，是基于监控指标对pod 数量做横向的弹性伸缩管理的资源对象。HPA 已经支持了 autoscaling/v1、autoscaling/v2beta1和autoscaling/v2beta2 三个大版本，autoscaling/v1，这个版本只支持CPU一个指标的弹性伸缩。而autoscaling/v2beta1增加了支持自定义指标，autoscaling/v2beta2又额外增加了外部指标支持。
在autoscaling/v2beta1版本中已经支持通过监控prometheus 中的指标来实现HPA中的弹性伸缩。所以这里介绍下通过prometheus中监控的rabbitmq队列数量来实现pod 弹性伸缩。
指标采集过程
prometheus-adpter 负责把prometheus采集的指标经过转换提供给HAP，提供数据的方式是api 接口，这个接口是prometheus-adpter 注册到k8s的聚合层 metrics aggregator 上面生成的接口 v1beta1.custom.metrics.k8s.io
关于汇聚层
在 Kubernetes 1.7 版本引入了聚合层，允许第三方应用程序通过将自己注册到kube-apiserver上，仍然通过 API Server 的 HTTP URL 对新的 API 进行访问和操作。为了实现这个机制，Kubernetes 在 kube-apiserver 服务中引入了一个 API 聚合层（API Aggregation Layer），用于将扩展 API 的访问请求转发到用户服务的功能。
当你访问 apis/metrics.k8s.io/v1beta1 的时候，实际上访问到的是一个叫作 kube-aggregator 的代理。而 kube-apiserver，正是这个代理的一个后端；而 Metrics Server、Prometheus-adapter 则是另外的后端 。通过这种方式，我们就可以很方便地扩展 Kubernetes 的 API 了。
操作步骤
1、确认聚合层已经启用
如果你使用kubeadm部署的，默认已开启。如果你使用二进制方式部署的话，需要在kube-APIServer中添加启动参数，增加以下配置：
``` # vi /opt/kubernetes/cfg/kube-apiserver.conf ... --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 \ --enable-aggregator-routing=true \ ... ```View Code
2、安装prometheus及exporter
2.1、之前已经安装kube-prometheus，所以此处省略
2.2、安装rabbitmq 的exporter,此处省略
3、安装prometheus-adapter
网上文档显示在安装kube-prometheus后就会顺带安装prometheus-adater ，实际确实如此，但是接口（v1beta1.custom.metrics.k8s.io）没有注册生成，所以此处直接再额外安装一个
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm pull prometheus-community/prometheus-adapter vi prometheus-adapter/values.yaml ... prometheus: # Value is templated url: http://prometheus-k8s.monitoring #prometheus-k8s 是prometheus operator 的service 名字 port: 9090 replicas: 3 #默认是1个，网上说应该把所有的master节点都部署一个，否则可能查询接口的时候会很慢，经验证确实如此，原因未知。 ... helm install prometheus-adapter prometheus-adapterView Code
验证是否安装成功
kubectl get apiservice | grep custom
v1beta1.custom.metrics.k8s.io default/prometheus-adapter True 24h注意：到此为止，prometheus 配置的监控指标有关pod 的都可以通过promethues-adapter 使用了。
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/monitoring/pods/*/kube_pod_status_phase" | jq .但是现有的指标可能不能满足监控条件，例如现有的指标rabbitmq_queue_messages 默认查询所有实例子的所有队列数量，如果要监控某一个队列某一个时间段的增长率就需要通过定义一个PrometheusRule来定义一个record类型的监控指标，所以需要后续操作
4、定义一个PrometheusRule
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
labels:
app: prometheus-rabbitmq-exporter
prometheus: k8s
role: alert-rules
name: rabbit-mq.rules
namespace: monitoring
spec:
groups:
- name: rabbitmq
rules:
- record: RabbitmqQueueHpa
expr: |
rabbitmq_queue_messages{queue="citic_news_msg_online",job="rabbitmq-161-189-7-94-prometheus-rabbitmq-exporter"}
labels:
service: rabbitmq-161-189-7-94
namespace: default
- record: RabbitmqQueueHpa
expr: |
rabbitmq_queue_messages{job="rabbitmq-52-82-60-41-prometheus-rabbitmq-exporter",queue="FyMonitorQueue"}
labels:
service: rabbitmq-52-82-60-41
namespace: default
解释：
上面的labels 是为了方便后面的prometheus-adapter 匹配映射
View Code
5、配置prometheus-adapter
在prometheusRule中定义的record 需要在prometheus-adapter 中配置后才能在api中被使用，
vi kzf/hpa-rabbitmq.yaml （实际上配置的就是prometheus-adapter 的confiamap）
...
rules:
53 default: true
54 custom:
66 - seriesQuery: 'RabbitmqQueueHpa{namespace!="",service!=""}'
67 resources:
68 overrides:
69 namespace: {resource: "namespace"}
70 service: {resource: "service"}
71 name:
72 matches: "^(.*)"
73 as: "${1}"
74 metricsQuery: '<<.Series>>{<<.LabelMatchers>>}'
...
解释一下：
name 区域是命名区域，实际上就是名字没变动，最终的名字还是RabbitmqQueueHpa。overrides区域中的key就是prometheusrule中的标签。
View Code
验证：
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/services/rabbitmq-161-189-7-94/RabbitmqQueueHpa" | jq .
注意上面的格式，namespaces和service在此处都用了复数，namespaces/default和services/rabbitmq-161-189-7-94 对应的就是prometheusRule中的标签，RabbitmqQueueHpa就是record6、定义HPA
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: metrics-app-hpa
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: metrics-app
minReplicas: 1
maxReplicas: 10
metrics:
- type: Object
object:
target:
kind: service
name: rabbitmq-161-189-7-94
metricName: RabbitmqQueueHpa
targetValue: 1000
解释一下：
1、HPA管理的是名为metrics-app的deployment 里面的pod，伸缩范围是1-10，也就是说当RabbitmqQueueHpa 的指标值达到1000的时候pod 会自动增加数量知道指标值低于1000,最大增加到10个，当值小于1000的时候pod 数量会自动减少。
2、在 HPA 中，扩容默认的扩容冷却周期是 3 分钟，缩容冷却周期是 5 分钟。可以通过调整kube-controller-manager组件启动参数设置冷却时间：
- --horizontal-pod-autoscaler-downscale-delay ：扩容冷却
- --horizontal-pod-autoscaler-upscale-delay ：缩容冷却
3、HPA 管理的是它所在的命名空间的deployment，相应的监控指标也是基于它所在的命名空间来查询的，所以要保证rabbit-exporter也部署在default
View Code
注意：
HPA 、HPA管理的deployment、PrometheusRule、prometheus-exporter 要保证都在同一个命名空间下。
标签：队列,adapter,rabbitmq,metrics,--,prometheus,HPA,k8s 来源： https://www.cnblogs.com/fanggege/p/14242513.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。