共计 1013 个字符，预计需要花费 3 分钟才能阅读完成。
最近应用阿里云的 kubernetes 容器服务，在一个利用上发现了 HPA 的一些奇怪的中央。如下图所示，以后使用率高于期望值使用率时，没有产生扩容事件，当以后使用率低于期望值使用率时，没有产生缩容事件。由此，通过源码剖析一下其中的过程。
先大抵说下 HPA 的原理，当一个 HPA 被创立时，kubernetes 外部会常见一个死循环，一直的去查看以后的 metrics 使用率与预期的使用率做比照。当达到扩容条件时，会扩容，而后期待 3 分钟才会持续下一次扩容，缩容是 5 分钟。
当初问题来了，显著再上图中条件是达到了的，然而为什么扩容缩容都没有产生呢？
翻阅 Kubernetes 源码发现了一个计算正本数的函数：
https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/podautoscaler/replica_calculator.go#L64GetResourceReplicas如下图
通过一系列的 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 的一些其余的判断吗，心愿大佬们领导一下，不甚感谢！！