说明介绍
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就是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也部署在defaultView Code
注意:
HPA 、HPA管理的deployment、PrometheusRule、prometheus-exporter 要保证都在同一个命名空间下。