为什么我们放弃了Kubernetes？

你好呀，我是北哥。8年Java开发者，公众号BiggerBoy号主，原创文章280+，主要分享Java踩坑、面试题、架构演进、技术决策，欢迎关注哦~

以下内容为北哥与读者交流后由北哥整理。

2019年，我们上了K8s。2021年，我们把服务从K8s迁回了物理机+Ansible。

这件事说出来容易挨骂：懂的人说你们是倒退，不懂的人说你们技术不行。

但实际情况是：这个决定救了我们团队。

上K8s的理由：所有人都在上

先说当时为什么上。

2018-2019年，K8s已经是容器编排的事实标准了。行业会议里全是K8s，招聘要求里写着"熟悉K8s"，技术群里聊架构不说K8s显得落后。

老板问：能不能上也搞搞云原生？

我们评估了一圈，结论是：技术上可行，但需要投入。

当时我们团队8个人，没有专职的运维，也没有SRE。上的理由是：

• 服务数量一直在涨，手动部署已经跟不上了
• 想做灰度发布和自动扩缩容
• 招聘市场上有K8s经验的人更好招

于是花了三个月，从0到1搭起了K8s集群。
上线那天，技术群里发了个截图，配文：“上了！”
我们都很兴奋。

上了之后，我们的状态

K8s集群跑起来了，看起来一切正常。

但问题从第二个月开始显现。

第一个月：学习曲线的债开始还。

团队8个人，有5个之前没有K8s实战经验。每天的工作变成了：

• “Pod起不来，谁帮忙看看”
• “Service配置改了要不要重启”
• “集群节点满了怎么扩”
• “kubectl logs命令怎么不好使”

CI/CD流水线要重新写，监控告警要重新配，日志收集方案要换。

这不是"部署变快了"，这是换了一套操作系统。

第三个月：稳定了，但不稳定的那种稳定。

熟悉了之后，K8s确实能跑起来。日常发布有流水线，扩缩容有HPA，不算差。

但每次出问题的排查路径变长了：

• Pod重启：是因为OOM，还是健康检查失败，还是调度失败？
• 网络不通：是Service配置问题，还是网络插件bug，还是iptables规则冲突？
• 集群异常：节点挂了、etcd抖动、kube-dns挂了——每一种情况的处理方式都不一样

我们组没有专职SRE。几个开发轮流值班，每次线上问题都是半夜爬起来。

压垮骆驼的最后一根稻草

2020年Q4，团队扩到10个人，但业务也在扩，人手还是不够。

那段时间连续出了两次事故：

事故一： 凌晨两点，K8s集群某个节点的kubelet进程挂了，节点状态变成NotReady。容器漂移了，但没有自动恢复。我爬起来手动处理了40分钟。

事故二： 一次误操作，把某个命名空间的ResourceQuota配错了，导致核心服务Pod启动失败，持续了20分钟用户受影响。

事后复盘，两个问题有一个共同点：我们对K8s的掌握程度，不足以在紧急时刻快速响应。

这不是K8s的问题，是团队能力的问题。

但问题是：这个能力差距，怎么补？

决定放弃：不是一个轻松的夜晚

2021年初，我们做了个艰难的决定：把服务从K8s迁回物理机。

用Ansible做部署和配置管理，物理机固定资源分配，监控用Prometheus+Grafana。

迁移花了两个月。过程中我心里一直有声音：“是不是在开倒车？”“老板会不会觉得我们技术不行？”

老板倒是没说太多，只问了一句：“这次稳吗？”

我说：“稳。”

放弃K8s之后的这一年

迁回来之后，有几个变化：

一是故障率降了。 物理机没有那么多不可预测的状态，网络层也简单了很多。部署虽然慢一点（手动了点），但出问题的概率也小了。

二是团队精力释放了。 开发重新聚焦在业务上，不是天天和集群搏斗。

三是有代价的。 弹性扩缩容没有了，要加机器得申请采购。灰度发布我们做了，但没K8s那么灵活。

值不值？事后看，是值的。

反思：什么时候不该上K8s

其实这才是这篇文章最想说的。

K8s是好东西，但不是什么场景都适合。

团队没有足够运维能力的时候，慎上。 K8s的学习曲线不是一两周能过的。如果你团队里没有对K8s有深度理解的人，出了问题就会抓瞎。

业务规模没有到那个量的时候，不值得上。 K8s解决的是大规模服务编排的问题。如果你只有十几个服务，手动部署够用，硬上K8s是给自己找麻烦。

没有足够时间投入的时候，不要上。 K8s不是装好了就完事了，要持续投入学习和运维。如果团队本身就996做业务，没有精力维护基础设施，别上。

最后，北哥想说的是：放弃不等于技术落后。有时候，知道什么不该做，比知道什么该做更重要。