本篇内容介绍了“Kubernetes HPA Controller的工作原理”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

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的工作原理”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注天达云网站，小编将为大家输出更多高质量的实用文章！