Kubernetes Pod自动扩容和缩容基于自定义指标

为满足更多的需求，HPA也支持自定义指标，例如QPS、5xx错误状态码等，这些都是已经统计好的指标信息，实现自定义指标由autoscaling/v2版本提供，而v2版本又分为beta1和beta2两个版本。

之前基于cpu实现的是v1版本，这个v1版本目前只支持资源指标，只能基于cpu进行扩容/缩容

[root@master ~]# kubectl get hpa -o yaml
apiVersion: v1
items:
- apiVersion: autoscaling/v1
  kind: HorizontalPodAutoscaler
  metadata:
    annotations:

这两个版本的区别是 autoscaling/v1支持了：

Resource Metrics（资源指标）
Custom Metrics（自定义指标）

要使用自定义指标，也就是用户提供的指标，去参考着并且扩容，这个时候就需要用到其v2版本。

v1和v2版本最大区别是v1版本只支持资源指标，v2版本支持自定义的指标，包括扩展的指标。

而在 autoscaling/v2beta2的版本中额外增加了External Metrics（扩展指标）的支持。

对于自定义指标（例如QPS），将使用custom.metrics.k8s.io API，由相关适配器（Adapter）服务提供。

已知适配器列表：https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api

（基于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大概步骤：

1、部署Prometheus

2、对应用暴露指标，部署应用，并让Prometheus采集暴露的指标

3、部署Prometheus Adapter

4、为指定HPA配置Prometheus Adapter

5、创建HPA

6、压测、验证

制作好demo

先模拟自己开发一个网站，采用Python Flask Web框架，写两个页面：

/ 首页
/metrics 指标

然后使用Dockefile制作成镜像并部署到Kubernetes平台。

可以看到制作镜像和启动容器是没有问题的

[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当中所有的数据都帮你去翻译。

增加一段配置，增加完后删除adapter pod重建生效。

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标签。
name：将Prometheus指标名称在自定义指标API中重命名， matches正则匹配，as指定新名称。
metricsQuery：一个Go模板，对调用自定义指标API转换为 Prometheus查询语句

主要是告诉adapter