[root@master ~]# kubectl get hpa -o yaml
apiVersion: v1
items:
- apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
annotations:
这两个版本的区别是 autoscaling/v1支持了 :
- Resource Metrics(资源指标)
- Custom Metrics(自定义指标)
要使用自定义指标,也就是用户提供的指标,去参考着并且扩容,这个时候就需要用到其v2版本。
而在 autoscaling/v2beta2的版本中额外增加了External Metrics(扩展指标)的支持。
(基于Prometheus来获取资源指标,基于微软云服务获取指标等)
目前最成熟的就是Prometheus adapter,现在很多都是基于其实现hpa扩展。
和之前的HPA扩容类似。
之前基于cpu实现HPA扩容:metrics server从kubelet cadvisor里面获取数据,获取完数据注册到api server的聚合层里面,hpa请求的是聚合层。(图最右边的步骤)
同理现在要基于自定义的指标,就图上面中间的步骤,基于自定义指标,那么指标就需要用户来提供,通过应用程序来提供,也就是要从pod当中获取应用程序暴露出来的指标,暴露出来的数据由Prometheus采集到,Prometheus adapater充当适配器,即中间转换器的作用,因为hpa是不能直接识别Prometheus当中的数据的,要想获取Prometheus当中的数据就需要一定的转换,这个转换就需要使用Prometheus adapter去做的。
prometheus adapter注册到聚合层,api server代理当中,所以当你访问custom.metrics.k8s.io API这个接口的时候会帮你转发到prometheus adapter当中,就类似于metric server,然后从Prometheus当中去查询数据,再去响应给hpa,hap拿到指标数据就开始对比的你阈值,是不是触发了,触发了就扩容。
示例
假设我们有一个网站,想基于每秒接收到的HTTP请求对其Pod进行自动缩放,实现HPA大概步骤:
制作好demo
先模拟自己开发一个网站,采用Python Flask Web框架,写两个页面:
- / 首页
- /metrics 指标
可以看到制作镜像和启动容器是没有问题的
[root@master metrics-app]# ls
Dockerfile main.py metrics-flask-app.yaml
[root@master metrics-app]# docker run -itd metrics-flask-app:latest
[root@master metrics-app]# docker logs 51d5afe9d7f8
* Serving Flask app 'main' (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
* Running on all addresses (0.0.0.0)
WARNING: This is a development server. Do not use it in a production deployment.
* Running on http://127.0.0.1:80
* Running on http://172.17.0.2:80 (Press CTRL+C to quit)
访问该服务的接口,有两个,一个是正常提供的服务hello world,另外一个是暴露的指标接口,这个指标是由prometheus 客户端去组织的。
下面是基于request_count_total 2.0这个指标去扩容的。这个是记录访问这个接口的次数
[root@master metrics-app]# docker inspect 51d5afe9d7f8 | grep IPAddress
"SecondaryIPAddresses": null,
"IPAddress": "172.17.0.2",
"IPAddress": "172.17.0.2",
[root@master metrics-app]# curl 172.17.0.2
Hello World[root@master metrics-app]# curl 172.17.0.2/metrics
# HELP request_count_total 缁..HTTP璇锋?
# TYPE request_count_total counter
request_count_total 2.0
# HELP request_count_created 缁..HTTP璇锋?
# TYPE request_count_created gauge
request_count_created 1.6555203522592156e+09
部署
[root@master metrics-app]# cat metrics-flask-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: metrics-flask-app
spec:
replicas: 3
selector:
matchLabels:
app: flask-app
template:
metadata:
labels:
app: flask-app
# 澹版.Prometheus?..
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "80"
prometheus.io/path: "/metrics"
spec:
containers:
- image: lizhenliang/metrics-flask-app
name: web
---
apiVersion: v1
kind: Service
metadata:
name: metrics-flask-app
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: flask-app
这里加了一个注解,这个注解就声明了让Prometheus去采集,这里采用了pod的服务发现
apiVersion: v1
kind: Service
metadata:
name: metrics-flask-app
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "80"
prometheus.io/path: "/metrics"
在访问的时候pod是轮询的方式,代理到后面某些pod,所以每个pod当中的请求总数是不一样的。
Prometheus监控 对应用暴露指标
Endpoints: 10.233.90.202:80,10.233.90.209:80,10.233.96.110:80
可以看到指标都被统计到了,次数也在里面
Prometheus Adapter
需要adapter从里面去查询指标,并且可以以metrics aggregator的方式去获取到指标。metrics aggregator充当着和metrics server的功能。
spec:
service:
name: prometheus-adapter
namespace: "kube-system"
group: custom.metrics.k8s.io
可以看到使用的是这个接口custom.metrics.k8s.io
Adapter作用是用于k8s与Prometheus进行通讯,充当两者之间的翻译器。
不管是metrics server还是metrics aggreator都是一个注册在k8s当中的一个接口,接口代理到prometheus adapter,然后它向prometheus去查询数据。查询完数据返回给接口,最后给到hpa。
所以prometheus adapter是k8s和prometheus之间的桥梁,metrics aggreator接口是不支持直接从prometheus当中拿数据的。因为hpa metrics的数据接口它是不支持从prometheus当中获取数据。
[root@master prometheus_adapter]# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
prometheus-adapter-7f94cc997d-xk9w8 1/1 Running 0 12m
验证是否正常工作
(1)验证是否正常注册到api server
[root@master prometheus_adapter]# kubectl get apiservices |grep custom
v1beta1.custom.metrics.k8s.io kube-system/prometheus-adapter True 13m
v1beta1.custom.metrics.k8s.io 这个是它的接口,访问不同的接口,会代理到后面不同的服务。
(2)调用其api,看看是否能够返回监控的数据
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1"
为指定HPA配置Prometheus Adapter
虽然充当了翻译器的角色,建立了k8s和Prometheus的一个桥梁,但是你得和他说明需要针对哪个应用去实现这么一个翻译,这个要明确告诉adapter的,而不是默认将Prometheus当中所有的数据都帮你去翻译。
apiVersion: v1
kind: ConfigMap
metadata:
name: prometheus-adapter
labels:
app: prometheus-adapter
chart: prometheus-adapter-2.5.1
release: prometheus-adapter
heritage: Helm
namespace: kube-system
data:
config.yaml: |
rules:
- seriesQuery: 'request_count_total{app="flask-app"}'
resources:
overrides:
kubernetes_namespace: {resource: "namespace"}
kubernetes_pod_name: {resource: "pod"}
name:
matches: "request_count_total"
as: "qps"
metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)'
- seriesQuery:Prometheus查询语句,查询应用系列指标。(做hpa的指标,范围越小越好,精确到某个应用)
- resources:Kubernetes资源标签映射到Prometheus标签。(这块配置是将namespace pod以标签的形式发在seriesQuery要查询的指标里面,这样更加精确)
- name:将Prometheus指标名称在自定义指标API中重命名, matches正则匹配,as指定新名称。
- metricsQuery:一个Go模板,对调用自定义指标API转换为 Prometheus查询语句
sum(rate(request_count_total{app="flask-app", kubernetes_namespace="default",
求出了速率再加上sum那么就是每秒所有的请求数,即qps。最后查询语句如下:
由于HTTP请求统计是累计的,对HPA自动缩放不是特别有用,因此将其转为速率指标。
向自定义指标API访问:
创建HPA
这个使用的是v2版本
name这个地方改为qps
average value 指的是平均值,会采集所有pod的指标,拿到这个值求一个平均,然后再去对比这个阈值。
你可以定义任意的指标,只要能够被Prometheus采集到,同时指标的值是动态变化的根据实际负载,这个值可以反应负载的变化,最后决定需不需要扩容。或者500类的错误指标都行。