运维总监怒怼开发:你真的需要 K8s 吗?( 二 )


从零开始的项目上 K8s 除了不用在x山代码里重构之外,拆服务划边界写文档还有基础设施维护等等细碎而且让人头大的工作,都是要跟老板要人力的 。
除非上 K8s 还是老办法一把梭,无非把 docker run 换成 deployment , 那这 K8s 其实用了就跟没用一样 。像是另一位答主说服务 down了几个月没人知道 。换到K8s上,Pod 不知道啥时候 evicted 了几个月也一样没人知道,节点啥时候挂了几个月也没人知道,某台节点莫名其妙挂上了 tAInt 也不会有人注意,又或者内存配额不够服务OOM重启了,代码报错了 , 死锁了,难道就有人注意了吗 。
问题显然不是出在用 docker 还是 K8s,换 K8s 出的问题只会比用 docker run 直接跑的时候更多、更频繁、更隐蔽 。
别把 K8s 当银弹,回归理性,好好想想为什么去用它 , 怎么用好它 。
5号知乎网友:runzhliu
Kubernetes 的重点在于服务编排 , 这个才是 Kubernetes 真正流行的原因,当然基于 Kubernetes 上做一些架构的创新的想法一直都没停止过 , 未来会有更多的玩法 。
回到问题,开发同学想用 Kubernetes 经常都是被 Kubernetes 强大的社区的宣传所洗脑……这个现象跟十年前 Hadoop/Spark 为代表的大数据框架开始流行很像 。
因为很多宣发的文章都把这些新技术宣传的非常高大上,而比较少会提到这些新技术带来的技术管理和运维上的负担 。
虽然说大家都是从0开始摸着石头过河的,但是能过河终究要看人才能力上的储备,这就要通过存量的员工或者招聘来的员工来实现团队的建设了 。
假设你公司的运维总监找来一个所谓搞过 K8S 的 Leader(实际只是做 K8S 机器运维的工作),要让这样的 Leader 带领公司的容器化工作,肯定是吃苦头的 , 因为实际他只是搞了机器交付的环节,对 K8S 内部的运作机器、容器、内核都不够熟悉,那么在招聘人才的时候,也经常会走漏眼,毕竟他自己都不懂,很难指望他能够建立一个足以应付大型业务的容器团队 。
所以关于到底用不用,除了要考虑公司业务的形态,还得考虑人才和团队储备,而不是看了一堆通稿或者分享之后就兴致勃勃开始容器化 。
6号知乎网友:RLLvmd
开发代码逻辑有问题,容易服务终止 。K8s 自愈功能自动重启容器,一小时重启三千多次,硬生生扛下了所有 , 用户没发现服务中断 。
7号知乎网友:网瘾大爷
上个月为了成本优化,把全部200多个节点都轮转了一遍,除了数据库节点和一些有状态服务节点,没麻烦其他人 , 总计2天 。
这种操作在没有 K8s 的时候估计得加班搞几周,稍微不小心就是个P0故障 。
8号知乎网友:Chen Moore
一共3、5台EC实例的规模你别说K8s了,上个SpringCloud 我都嫌麻烦 。
整个 SpringBoot 前面扔个 Nginx 完事,这还是建立在必须得前后端分离用 JAVA 的基础上 。
真要从0开始,这点规模
我选择 react / vue + next.js 一把梭 。
"你真的需要 K8s 吗?"欢迎在留言区交流 , 留下你的观点~
整理丨dbaplus社群
来源丨zhihu.com/question/430952886/




推荐阅读