度量获取流程：pod到cadvisor到heapster到hpa
cadvisor获取当前node节点的pod的度量信息，向上汇总到heapster，然后hpa从heapster抓取信息，然后hpa控制器根据用户定义的度量的targetavg值做计算，让pod的平均度量值达到要求，比如以cpu度量为例子，用户定义30%，若当前有三个Pod，里面的currentcpu/requestscpu 的百分比分别为50,50,60，那么（50+50+60）/3 = 55,超过了用户定义的30，这时就会以160/30取值然后向上取整，即160/30=5.34，那么就会取整数6，当6不超过用户定义的最大允许存在的容器时，hpa就会自动横向扩容pod数量达到6个，具体是hpa取到整数6副本时，会去更改所监控的资源的replicas数量，然后由资源对象的控制器去调整pod数量，比如以deployment为例子，deplyment控制器watch监听deployment资源对象，当对象的replicas数量改变时，deployment控制器会生成replicaset对象，然后replicaset控制器根据对象又会生成pod资源清单，资源清单此时没有调度器调度，所以pod清单里面的node节点为空，调度器就会根据一系列算法对pod选择合适的node节点运行，选择好后，apiserver会让选中的node节点的kubelet去根据pod清单调用docker创建对应的pod。
kubectl autoscale deployment learnlogs --cpu-percent=30 --min=1 --max=5 -n devops
以上命令会生成hpa，监控deployment对象learnlogs，度量以cpu百分比为度量，最小的pod数量为1，最大的pod数量为5 deployment所在的命名空间是devops
可以用watch -n 1 kubectl get hpa,deployment -n devops 监听hpa与deployment对象的变化
之前使用的是heapster，但是1.12后就废弃了，之后使用的替代者是metrics-server；metrics-server是由用户开发的一个api server，用于服务资源指标，而不是服务pod，deploy的。metrics-server本身不是k8s的组成部分，是托管运行在k8s上的一个pod，那么如果想要用户在k8s上无缝的使用metrics-server提供的api服务，因此在新一代的架构中需要这样去组合它们。如图，使用一个聚合器去聚合k8s的api server与metrics-server，然后由群组/apis/metrics.k8s.io/v1beta1来获取。
所以新版本的k8s要想用hpa自动伸缩资源，需要先部署mertrics-server，主要部署的资源是serveraccount跟role,clusterrole，metrics-server的deployment，还有service，最后把service注册到apiserver服务中去
aggregated-metrics-reader.yaml auth-reader.yaml metrics-server-deployment.yaml metrics-server-service.yaml
auth-delegator.yaml metrics-apiservice.yaml resource-reader.yaml
参考：https://www.cnblogs.com/binghe001/p/12821804.html