基于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 弹性伸缩。

指标采集过程

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 
...
```

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-adapter

验证是否安装成功

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 匹配映射

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中的标签。

验证：

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

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

 

注意：

HPA 、HPA管理的deployment、PrometheusRule、prometheus-exporter 要保证都在同一个命名空间下。