不聊k8s的hpa-横向扩容

序言

    看看别人家的文章，再看看自己的文章，就知道什么叫low。。。

    站在底层太久，抬头一看，我C，fuck。。。留下了没有境界的泪水。。。

hpa

    机会，是留给有准备的人的。。。哼，不阔能.

    邋里邋遢遇情敌，花枝招展他却没有局。。。

    每次看到技术的新特性，激动，兴奋之情溢于言表，迫不及待的想尝试一把，然后发现。。。根本用不上，毫无价值，毫无意义，说好的机会是留给有准备的人呢？搞错了，重新来。。。

    看看k8s的failover和hpa特性，感觉好酷，毕竟是高级特性，但是想象一种场景，当一个应用，挂了4个pod的时候，分别分散到四台不同的机器上，然后一台机器宕机，那么就必然会有2个pod在一个机器上，再想象一下，如果这两个服务监听的是相同的端口，使用的是host网络，emmm，端口冲突。

    failover，故障迁移，无论是主动迁移或者是被动迁移，当一个应用只有2个pod的时候，一旦迁移到相同的机器上，那么还有高可用么，emmm，系统短时间的不可用是否可以接受。。。不，你不想。。

    failover，当一个zk集群或者是etcd集群是跨机架跨交换机跨机器的时候，那么能不能跨越这个来进行迁移？还是说一个机架必然要有多少多少台物理机，组成的机器成本有多高。

    failover，如果就俩物理机，你的应用也就俩pod，你是迁移还是不迁移？当物理机修好了，你是迁移回去还是不动？

    运气很重要，但不是唯一，突然想起来是讲述hpa的。。。

    hpa，俗称horizontalpodautoscale，叫做水平自动扩容，其实也就是横向扩容，在面对负载升高的时候，自动扩容pod，当面对负载下降的时候，自动缩容pod，自动伸缩，好酷。

    在给应用申请资源的时候，需要设置一个申请量requests，也就是满足应用的最低值，也需要设置一个限制值limits，也就是应用的最高值，在限定的时候，可以设置cpu和memory，当容器超过这个值的时候，那么kubelet会杀死它，然后重启，哼，不要触碰我的底线。。。我是一个没有感情的杀手。

    说是这么说，但是实际上能衡量的指标只有cpu，因为这个会有峰值，会有低谷，对于内存来说，可能一时间无法释放，取决于很多其他的因素，所以hpa的特性一般都是根据cpu来进行判断。

    用不上的工具，特性再好也没啥用，按照道理来说，每天的请求量啥的都是可以找到规律的，可惜。。。如果都有资源来扩容，那为啥不直接扩容好，几个基本进程又不能省电，当然，云平台是另外一说。。。毕竟，都是要花钱的。

    

    良好的特性无用武之地，那这是一种准备还是一种浪费呢？

    面对的场景不同，如果是技术，那么会是储备；如果是业务，那就是一种浪费。。。不同的人眼中看到的东西不一样，人与人不同，花有几样红

    技术是个好东西，就是人不太正经。面对不同的场景，不同的视角，都需要不同的思考。。。脑子是个好东西，但是！！！我没有。。。喂了狗。

    化妆很美，卸妆很残酷，这就是现实，理想很丰满，现实很古板。

    面对新特性，可能是炮灰，也可能堵赢了。一个人对你好不好，就看给不给你机会。。。我眼瞎，我看不见，看不清，看不懂。。。新特性就像人间美味，让人念念不忘

    这世间的技术，一切皆有因果，是债就该还，是孽就该了，电脑没电了，不聊了。。