基于rabbitmq队列的HPA

说明介绍

HPA是k8s 里面的一个资源对象,是基于监控指标对pod 数量做横向的弹性伸缩管理的资源对象。HPA 已经支持了 autoscaling/v1、autoscaling/v2beta1和autoscaling/v2beta2  三个大版本,autoscaling/v1,这个版本只支持CPU一个指标的弹性伸缩。而autoscaling/v2beta1增加了支持自定义指标,autoscaling/v2beta2又额外增加了外部指标支持。

 

在autoscaling/v2beta1版本中已经支持通过监控prometheus 中的指标来实现HPA中的弹性伸缩。所以这里介绍下通过prometheus中监控的rabbitmq队列数量来实现pod 弹性伸缩。

 

指标采集过程

基于rabbitmq队列的HPA

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中添加启动参数,增加以下配置:

基于rabbitmq队列的HPA
```
# 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)没有注册生成,所以此处直接再额外安装一个

基于rabbitmq队列的HPA
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-adapter
View 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

基于rabbitmq队列的HPA
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中被使用,

基于rabbitmq队列的HPA
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就是record

6、定义HPA

基于rabbitmq队列的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 要保证都在同一个命名空间下。

上一篇:一沙框架(YiShaAdmin) -修改数据后回到起始页的解决办法


下一篇:Ubuntu下TFTP、NFS和SSH服务搭建