关于kubernetes:Kubernetes源码分析阿里云Kubernetes关于HPA没有扩缩容的原因定位

36次阅读

共计 1013 个字符,预计需要花费 3 分钟才能阅读完成。

最近应用阿里云的 kubernetes 容器服务,在一个利用上发现了 HPA 的一些奇怪的中央。如下图所示,以后使用率高于期望值使用率时,没有产生扩容事件,当以后使用率低于期望值使用率时,没有产生缩容事件。由此,通过源码剖析一下其中的过程。


先大抵说下 HPA 的原理,当一个 HPA 被创立时,kubernetes 外部会常见一个死循环,一直的去查看以后的 metrics 使用率与预期的使用率做比照。当达到扩容条件时,会扩容,而后期待 3 分钟才会持续下一次扩容,缩容是 5 分钟。
当初问题来了,显著再上图中条件是达到了的,然而为什么扩容缩容都没有产生呢?
翻阅 Kubernetes 源码发现了一个计算正本数的函数:
https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/podautoscaler/replica_calculator.go#L64
GetResourceReplicas如下图

通过一系列的 pod 衰弱状态判断后进入这段正本数的算法


计算公式就是如官网提供的这段如下

意思是用以后使用率与预期使用率之比,再乘以后正本数,向上取整数值就是预期的新正本数
https://github.com/kubernetes/kubernetes/blob/6b388f06845009b8bd9963a8bd0796189b679486/pkg/controller/podautoscaler/metrics/utilization.go#L26

其中上图正本数运算中的 usageRatio 是 GetResourceUtilizationRatio 函数的返回值
这个函数的返回值,意思是以后使用率与预期使用率相除得出比率,如下图

所以说咱们当初遇到的状况应道产生 HPA 行为,拿咱们的例子来说就是 math.Ceil((118/110)2),比率运算约等于 2.14545454 而后向上取整数值该当是 3,很显著应该扩容,而后 math.Ceil((92/110)3),比率运算约等于 2.609090909, 向上取整应该是 3,缩容的状况依据我的剖析,没有缩容对的,然而没有发扩容这是为什么呢?
咱们提了一个阿里云工单,工单回复的算法与源码中的有出入,少了一个以后正本数的乘积运算,如下图

是阿里云改了源码吗,还是我这菜鸡脱漏了一些 kubernetes 的一些其余的判断吗,心愿大佬们领导一下,不甚感谢!!

正文完
 0