云原生k8s的金箍棒

        如果云原生是我们喜欢的《西游记》中孙悟空，那Autoscaling就是云原生手中的金箍棒。想象一下，没有金箍棒的孙悟空，还能到处降妖伏魔么？还能成为斗战圣佛吗？

 Autoscaling

        根据需要随时动态扩缩容，有了它，k8s才犹如孙悟空从东海龙宫获得了金箍棒，实现变大变小自由。回想一下孙悟空，金箍棒变大变小不是随意变的，得孙悟空念念有词。接下来，我们就探究一下autoscaling的触发机制。

HPA的架构图

         HPA有两种机制：一种是默认的HPA机制，通过metrics api获取metrics Server里保存的metrics数据，数据来自kubelet返回的cpu/mem等metrics；另一种，就是通过custom metrics api获取来自promethus的业务监控metrics, 比如相应api的响应时间或RPS量。

        实现一个自动运行机制，计算机程序的世界里都少不了循环的参与。HPA也是其中的典范。简而言之，HPA是一个“检查，更新，再检查”的循环。

1. HPA从metrics server获取metrics
2. HPA根据从metrics server获得的metrics计算需要的实例副本数
3. HPA更新对应的replica数目
4. 重复此循环

HPA的客户化metrics

 

HPA的局限性

1.  HPA不支持Damonset
2. HPA的cpu/mem的门限设置得不合理，实例数没法及时扩容，导致系统出现拥塞，甚至出现系统雪崩现象
3. 实例的cpu/mem的limit设置不合理，可能HPA的设置没有及时扩容， 实例内存超限，最终导致实例crash
4. HPA的扩容机制，是基于整个pod的资源计算的，可能主容器的资源使用情况不能简单通过cpu/mem来衡量。 

HPA的实例

     各位看官们，网上例子一堆堆，各自众里寻她吧

References

The Guide To Kubernetes HPA by Example

Advanced HPA in Kubernetes

Horizontal Pod Autoscaling | Kubernetes

Kubernetes Horizontal Pod Autoscaler with Prometheus custom metrics