本篇内容介绍了“Kubernetes HPA Controller的工作原理”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
K8s通过HPA，基于获取到的metrics(CPU utilization, custom metrics) value，对rc, deployment管理的pods进行自动伸缩。
截止到Kubernetes 1.6，Release特性中仅支持CPU utilization这一
resource metrics，对custom metrics的支持目前仍在alpha阶段，请知晓。
HPA Controller周期性(默认每30s一次，可通过kube-controller-manager的flag--horizontal-pod-autoscaler-sync-period进行设置)的调整对应的rc, deployment中的replicas数量，使得指定的metrics value能匹配用户指定的target utilization value。
在每个HPA Controller的处理周期中，kube-controller-manager都去查询HPA中定义的metrics的utilization。查询方式根据metric类型不同而不同：
如果metric type是resource metrics，则通过resource metrics API查询。
如果metric type属于custom metrics，则通过custom metrics API查询。
计算伸缩比例算法：
对于resource metrics，比如CPU，HPA Controller获取HPA中指定的metrics，如果HPA中设定了target utilization，则HPA Controller会将获取到的metrics除于对应的容器的resource request值作为监测到的当前pod的resource utilization。如此计算完所有HPA对应的pods后，对该resource utilization values取平均值。最后将平均值除于定义的target utilization，得到伸缩的比例。
注意：如果HPA对应的某些pods中的容器没有定义对应的resource request，则HPA不会对这些pods进行scale。
对于custome metrics，HPA Controller的伸缩算法几乎与resource metrics一样，不同的是：此时是根据custome metrics API查询到的metrics value对比target metics value计算得到的，而不是通过utilization计算得到的。
HPA与rc, deployment, pod的关系如下图所示。
HPA通过Scale sub-resource接口，对RC和Deployment的replicas进行控制。
HPA最终对Pod副本数的控制终归还是通过RC和Deployment控制器。
HPA Controller有两种方式获取metrics：
direct Heapster access: 用于对resource metrics的监控，需要提前在kube-system namespace中部署Heapster。
REST client access: 用于对custom metrics的监控，需要设置kube-controller-manager的--horizontal-pod-autoscaler-use-rest-clients flag为true。
“Kubernetes HPA Controller的工作原理”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
