基于Prometheus自定义指标对k8s集群的容器扩缩容

前面分别对基于云原生k8s自身的hpa和基于阿里云ack集群上的hpa进行了讲解，但同时也有以自身的不足：
1、k8s原生的hpa只能满足硬件资源的需求，并不能对于业务的一些指标做很多的扩容。
2、阿里云ack集群通过集成阿里云厂商自研的插件可以很好的满足业务指标的获取，但是对于没有上云的公司来说也是一个痛点问题。

因为我们可以通过开源的prometheus-adapter可以解决这个问题。

前置条件：

1、k8s集群
2、prometheus监控

背景：

Kubernetes 默认提供 CPU 和内存作为 HPA 弹性伸缩的指标，如果有更复杂的场景需求，比如基于业务单副本 QPS 大小来进行自动扩缩容，可以考虑自行安装 prometheus-adapter 来实现基于自定义指标的 Pod 弹性伸缩。

实现原理：

Kubernetes定义了三种不同的监控数据接口，分别是Resource Metric，Custom Metric以及External Metric。

1. Resource Metric是通过metrics-server采集；
2. Custom Metric是通过prometheus来实现自定义扩容。
3. External Metric就是针对云场景的了，比方说通过获取slb最大连接数来实现自动扩容。

操作：

以开发测试的某个业务服务为例，该服务已经纳入到prometheus监控中，如下所示：

step1:helm部署（helm3版本）

1）编写values文件

cat values.yaml

prometheus:
url: http://prometheus-kube-prometheus-prometheus.prometheus.svc.kiki.local
port: 9090
rules:
default: false
custom:
seriesQuery: dubbo_request_concurrent_total{namespace!="",pod!=""}
resources:
overrides:
namespace:
resource: namespace
pod:
resource: pod
name:
matches: "^(.*)_total"
as: "${1}_per_second"
metricsQuery: (sum(increase(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>))

2）部署prometheus-adapter

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus-adapter prometheus-community/prometheus-adapter -f values.yaml

3）验证adapter服务

kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1

验证服务的相关指标

kubectl get --raw '/apis/custom.metrics.k8s.io/v1beta1/namespaces/kikitrade-dev/pods/*/dubbo_request_concurrent_per_second'

截图下的metricName为获取的关键指标，value就是对应指标获取的值

step2:测试hpa

cat app-hpa.yaml

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: dubbo-hpa
  namespace: kikitrade-dev
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: green-ktrade
  minReplicas: 1
  maxReplicas: 3
  metrics:
  - type: Pods
    pods:
      metricName: dubbo_request_concurrent_per_second
      targetAverageValue: 100

由于我将该指标的值设置的比较低，所以很快就可以看到pod扩上去了

接下来，我将指标的参数调高，看是否可以缩回去

优化调整：

上面我们只是看到了扩所容的现象，但是实际上和我们的grafana显示的还是有出入，接下来优化下：

step1:修改rules

cat values.yaml

prometheus:
  url: http://prometheus-kube-prometheus-prometheus.prometheus.svc.kiki.local
  port: 9090

rules:
  default: false
  custom:
  - seriesQuery: dubbo_request_concurrent_total{namespace!="",pod!=""}
    resources:
      overrides:
        namespace:
          resource: namespace
        pod:
          resource: pod
    name:
      matches: "^(.*)_total"
      as: "${1}_per_second"
    metricsQuery: (sum(increase(<<.Series>>{<<.LabelMatchers>>}[2m])/120) by (<<.GroupBy>>))

step2:更新服务

helm upgrade prometheus-adapter prometheus-community/prometheus-adapter -f values.yaml -n custom-metrics

step3:验证

获取指标，和grafana对比


对比后会发现，获取的指标值为3916m，grafana显示的是3.92，这里存在一个单位换算问题，3916m/1000 约等于3.92，因此可以通过优化有的这个作为业务容器的自动阔缩容，从而更加经济的使用k8s集群。

至此，k8s的自动扩缩容到此完结。都到这儿了，更多文章，详见个人微信公众号ALL In Linux，来扫一扫吧！