导语： 我们通常使用Prometheus来对Kubernetes运行情况进行监控。并根据监控数据来扩容或者缩容。通常的扩/缩容都是根据内存或者CPU的使用，但是很多时候我们扩/缩容的依据通常是业务监控指标。如何根据业务监控指标来进行扩/缩容，本文作者给出了很优雅的方式。
Kubernetes自动弹性伸缩
自动弹性伸缩是一种基于资源使用情况自动弹性伸缩工作负载的方法。
Kubernetes的自动弹性伸缩有两个维度：
-
处理node缩放操作的Cluster Autoscaler
-
自动弹性伸缩部署副本集Pod数量的Horizontal Pod Autoscaler（HPA）。
Cluster Autoscaling和Horizontal Pod Autoscaler（HPA）可用于动态调整计算能力以满足系统SLA的要求。
虽然群集Cluster Autoscaler高度依赖云提供程序的底层功能，但HPA可以独立于IaaS / PaaS提供程序运行。
HPA的演变
Horizontal Pod Autoscaler功能首次在Kubernetes V1.1中引入，自那时起已经发展了很久。 HPA V1版本基于观察到的CPU利用率和内存使用情况来自动伸缩POD。 在Kubernetes 1.6中引入了新的API自定义度量API，使HPA可以访问任意度量标准。 最终，Kubernetes 1.7引入了聚合层，允许第三方应用程序通过将自己注册为API附加组件来扩展Kubernetes API。
Custom Metrics API和聚合层使得Prometheus等监控系统可以向HPA控制器公开特定于应用的指标。
Horizontal Pod Autoscaler使用控制循环来实现功能，它定期查询Resource Metrics API的核心度量标准，如CPU /内存和Custom Metrics API以获取特定于应用程序的度量标准。
以下是关于为Kubernetes 1.9或更高版本配置HPA v2的指南：
-
安装提供核心指标的Metrics Server插件。
-
使用demo应用根据CPU和内存使用情况展示pod自动调节。
-
部署Prometheus和一个自定义的API服务器。 将自定义API服务器注册到聚合层。
-
demo应用程序使用自定义指标配置HPA。
在开始之前，您需要安装Go 1.8或更高版本，并在您的GOPATH克隆k8s-prom-hpa[1]：
1. 设置Metrics server
Kubernetes Metrics Server[2]是一个集群范围的资源使用数据聚合器，是Heapster[3]的继任者。 Metrics Server通过汇集来自kubernetes.summary_api.数据来收集node和POD的CPU和内存使用情况。summary API是用于将数据从Kubelet / cAdvisor传递到Metrics Server的API(基于内存十分高效)。
如果在HPA的第一个版本中，您需要Heapster提供CPU和内存指标，但在HPA v2和Kubernetes 1.8中，只有启用horizontal-pod-autoscaler-use-rest-clients时才需要Metrics Server。 Kubernetes 1.9默认启用HPA rest 客户端。 GKE 1.9预装了Metrics Server。
在kube-system命名空间中部署Metrics Server：
kubectl create -f ./metrics-server
一分钟后， metric-server开始报告node和POD的CPU和内存使用情况。
查看node指标：
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes" | jq .
查看pods指标：
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/pods" | jq .
2.基于CPU和内存使用情况的Auto Scaling
我们将使用一个基于Golang的小型Web应用程序来测试Horizontal Pod Autoscaler（HPA）。
将podinfo[4]部署到default名称空间：
kubectl create -f ./podinfo/podinfo-svc.yaml,./podinfo/podinfo-dep.yaml
使用http://<K8S_PUBLIC_IP>:31198.上的NodePort服务访问podinfo。
接下来定义一个保持最少两个副本的HPA，如果CPU平均值超过80％或内存超过200Mi，则可扩展到10：
创建HPA：
kubectl create -f ./podinfo/podinfo-hpa.yaml
几秒钟后，HPA控制器联系Metrics Server，然后获取CPU和内存使用情况：
为了增加CPU压力，使用rakyll / hey运行负载测试：
暂时删除podinfo。 稍后将在本教程中再次部署它：
kubectl delete -f ./podinfo/podinfo-hpa.yaml,./podinfo/podinfo-dep.yaml,./podinfo/podinfo-svc.yaml
3.设置自定义Metrics Server
为了根据自定义指标进行缩放，您需要两个组件。 一个从您的应用程序收集指标并将它们存储在Prometheus[5]时间序列数据库中。 第二个组件使用collect， k8s-prometheus适配器[6]提供的度量标准扩展Kubernetes自定义指标API。
您将在专用命名空间中部署Prometheus和适配器。
创建monitoring名称空间：
kubectl create -f ./namespaces.yaml
在monitoring命名空间中部署Prometheus v2：
kubectl create -f ./prometheus
生成Prometheus适配器所需的TLS证书：
make certs
部署Prometheus自定义指标API适配器：
kubectl create -f ./custom-metrics-api
列出Prometheus提供的自定义指标：
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .
获取monitoring命名空间中所有POD的FS使用情况：
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/monitoring/pods/*/fs_usage_bytes" | jq .
4.基于自定义指标的Auto Scaling
在default命名空间中创建podinfoNodePort服务并部署：
kubectl create -f ./podinfo/podinfo-svc.yaml,./podinfo/podinfo-dep.yaml
podinfo应用程序公开名为http_requests_total的自定义指标。 Prometheus适配器移除_total后缀并将度量标记为计数器度量。
从自定义指标API获取每秒的总请求数：
m代表milli-units，例如， 901m 意味着901 milli-requests （就是大约0.9个请求）。
创建一个HPA，如果请求数量超过每秒10个，将增加podinfo：
在default名称空间中部署podinfoHPA：
kubectl create -f ./podinfo/podinfo-hpa-custom.yaml
几秒钟后，HPA从度量API获取http_requests值：
以每秒25个请求的速度为podinfo服务加压：
几分钟后，HPA开始增加POD数量：
按照目前每秒的请求速度，部署将永远不会达到10个POD的最大值。 三个副本足以使每个POD的RPS保持在10以下。
负载测试完成后，HPA会将部署缩减为其初始副本数量：
您可能已经注意到自动调节器不会立即响应峰值。 默认情况下，指标同步每30秒一次。 如果在最近3-5分钟内没有重新缩放，才能进行扩容/缩容。这确保了HP以防止冲突决策快速执行，并为Cluster Autoscaler提供了时间。
结论
并非所有系统都可以通过单独依靠CPU /内存使用量度来满足其SLA，但大多数Web和移动后端均需要基于每秒请求数来对任何流量突发进行处理。
对于ETL应用程序，自动弹性伸缩可能由作业队列长度超过某个阈值引发，等等。
通过使用Prometheus提供的适用于自动弹性伸缩的指标，您可以微调应用程序以更好地处理突发事件并确保高可用性。
参考链接
[1] https://github.com/stefanprodan/k8s-prom-hpa
[2] https://github.com/kubernetes-incubator/metrics-server
[3] https://github.com/kubernetes/heapster
[4] https://github.com/stefanprodan/k8s-podinfo
[5] https://prometheus.io
[6] https://github.com/DirectXMan12/k8s-prometheus-adapter