K8s HPA 设计实现

介绍

Horizontal Pod Autoscaling（Pod 水平自动伸缩），简称HPA，HPA 通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整 Pod 的副本数量，

应对线上的各种复杂情况，我们需要能够做到自动化去感知业务，来自动进行扩缩容。

原理

HPA 控制器定期查询Resource Metrics API（Metrics Server）以获取CPU内存等核心指标和针对特定应用程序指标的Custom Metrics API (Prometheus adapter)

扩缩容算法

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
即当前副本数 * （当前指标值/期望的指标值），将结果向上取整。

实践

扩容的指标 CPU 、内存、TPS(自定义) ，系统将针对每种类型的指标都计算 Pod 副本的目标数量，以最大值为准进行扩缩容操作。

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: {{ metadata_name }}   #APP Name
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: {{ spec_scaleTargetRef_name }}  #APP Name
  minReplicas: {{spec_minReplicas}}  # 最小副本数
  maxReplicas: {{spec_maxReplicas}} # 扩容最大副本数
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: {{metrics_resource_targetAverageUtilization}}
  - type: Resource
    resource:
      name: memory
      targetAverageValue: {{metrics_resource_targetAverageValue}}
  - type: Pods
    pods:
      metric:
        name: http_server_requests_seconds_count # k8s-prometheus-adapter configMap 配置
      target:
        type: AverageValue
        averageValue: {{metrics_pods_target_averageValue}}

主要参数如下：

scaleTargetRef：目标作用对象，可以是 Deployment、ReplicationController 或 ReplicaSet。
minReplicas 和 maxReplicas：Pod 副本数量的最小值和最大值，系统较脏这个范围内进行自动扩缩容操作，并维持每个 Pod 的CPU 使用率为 50%。
metrics：目标指标值。在 metrics 中通过参数 type 定义指标的类型，通过参数 target 定义相应的指标目标值，系统将在指标数据达到目标值时（考虑容忍度的区间，见前面算法部分的说明）触发扩缩容操作。

可以将 metrics 中的 type（指标类型）设置为以下四种，可以设置一个或多个组合，如下所述。
（1）Resource：基于资源的指标值，可以设置的资源为 CPU 和内存。
（2）Pods：基于 Pod 的指标，系统将对全部 Pod 副本的指标值进行平均计算。
（3）Object：基于某种资源对象（如 Ingress）的指标或应用系统的任意自定义指标。
（4）External：基于外部指标值，用户使用了公有云服务商提供的消息服务或外部负载均衡器，希望基于这些外部服务的性能指标（如消息服务的队列长度、负载均衡器的 QPS）对自己部署在 Kubernetes 中的服务进行自动扩缩容操作

规则

1.定义metric name 和格式比如统计TPS

http_server_requests_seconds_count{application=“hello-word”,env=“test”,instance=“10.142.22.9:9090”,job=“op-app-prometheus-prod-dayu”,method=“GET”,namespace=“base”,pod=“hello-word-7cdfc8bb48-nn5vf”}

Label 必须含有 env ，pod ，namespace

2.接入prometheus

Java（spring boot 和 Eureka）引入dayu starter (内部编写统一暴露metric sdk)

Python

配置

k8s-prometheus-adapter configMap 部署adapter前需要配置adapter的rule，用于预处理metrics

- seriesQuery: 'http_server_requests_seconds_count{namespace !="", pod!="",,env="test"}'
      resources:
        overrides:
          namespace: {resource: "namespace"}
          pod: {resource: "pod"}
      name:
        matches: ""
        as: ""
      metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[1m])) by (<<.GroupBy>>)'

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/base/pods/*/http_server_requests_seconds_count" | jq .

http_server_requests_seconds_count custom metrics name ，环境匹配当前的env

seriesQuery 可以根据标签进行查找(如下)，也可以直接指定metric name查找

resources 设置metric与kubernetes resources的映射关系

name 用于将prometheus metrics名称转化为custom metrics API所使用的metrics名称，但不会改变其本身的metric名称

metricsQuery 处理调用custom metrics API获取到的metrics的value 该值最终提供给HPA进行扩缩容

未来

1，当前custom metric 需要在k8s-prometheus-adapter 创建rules ，如果custom metric 太多了人工修改是一个低效的工作，考虑rules 根据业务自行定义
自行动态创建
2，以上需要满足不了，自行实现 custom-metric-apiserver

资料

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
https://github.com/kubernetes/metrics
https://github.com/DirectXMan12/k8s-prometheus-adapter
https://github.com/kubernetes-sigs/custom-metrics-apiserver