不聊k8s的hpa-横向扩容
序言看看别人家的文章,再看看自己的文章,就知道什么叫low。。。站在底层太久,抬头一看,我C,fuck。。。留下了没有境界的泪水。。。hpa 机会,...
看看别人家的文章,再看看自己的文章,就知道什么叫low。。。
站在底层太久,抬头一看,我C,fuck。。。留下了没有境界的泪水。。。
机会,是留给有准备的人的。。。哼,不阔能.
邋里邋遢遇情敌,花枝招展他却没有局。。。
每次看到技术的新特性,激动,兴奋之情溢于言表,迫不及待的想尝试一把,然后发现。。。根本用不上,毫无价值,毫无意义,说好的机会是留给有准备的人呢?搞错了,重新来。。。
看看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来进行判断。
用不上的工具,特性再好也没啥用,按照道理来说,每天的请求量啥的都是可以找到规律的,可惜。。。如果都有资源来扩容,那为啥不直接扩容好,几个基本进程又不能省电,当然,云平台是另外一说。。。毕竟,都是要花钱的。
良好的特性无用武之地,那这是一种准备还是一种浪费呢?
面对的场景不同,如果是技术,那么会是储备;如果是业务,那就是一种浪费。。。不同的人眼中看到的东西不一样,人与人不同,花有几样红
技术是个好东西,就是人不太正经。面对不同的场景,不同的视角,都需要不同的思考。。。脑子是个好东西,但是!!!我没有。。。喂了狗。
化妆很美,卸妆很残酷,这就是现实,理想很丰满,现实很古板。
面对新特性,可能是炮灰,也可能堵赢了。一个人对你好不好,就看给不给你机会。。。我眼瞎,我看不见,看不清,看不懂。。。新特性就像人间美味,让人念念不忘
这世间的技术,一切皆有因果,是债就该还,是孽就该了,电脑没电了,不聊了。。
更多推荐
所有评论(0)