公司弃用 Kubernetes 后，部署成功率飙升 89%，生产事故减少 73%，成本降低 62%，还不用加班！

— 特色专栏 —

MySQL/PostgreSQL/MongoDB

ElasticSearch/Hadoop/Redis

Kubernetes/Docker/DevOps

Kafka/RabbitMQ/Zookeeper

监控平台/应用与服务/集群管理

Nginx/Git/Tools/OpenStack

大家好，我是民工哥！

我们放弃 Kubernetes 后，部署成功率飙升 89%，再也不用加班了！

半年前，我们的 DevOps 团队深陷复杂性的泥潭，我们在三家云服务商上管理着 47个 Kubernetes 集群。

工程师们不得不牺牲周末加班，值班轮岗成了令人恐惧的噩梦。

于是我们做出了一个看似疯狂的决定 — 开始从技术栈中移除 Kubernetes。

如今，我们的部署成功率提升了89%，基础设施成本降低了62%。而且两年来首次，我们的 DevOps 团队能够安心度假了。

这就是我们的故事。

K8s：美好愿景与残酷现实

和许多公司一样，我们三年前追随潮流采用了 Kubernetes。它的承诺令人心动：

• 大规模容器编排
• 云原生架构
• 基础设施即代码
• 自动扩缩容和自我修复

诚然，Kubernetes 实现了这些承诺。 但它也带来了鲜为人知的隐形成本。

转折点

我们的转折点出现在 2023 年的黑色星期五。尽管我们拥有：

• 8 名资深 DevOps 工程师
• 3 个专职 SRE 团队
• 24/7 全天候值班
• 企业级技术支持
• 全面的监控系统

我们仍然遭遇了：

• 4 次严重宕机
• 147 次误报警报
• 23 次紧急部署
• 2 名团队成员因过度劳累而离职

情况亟需改变。

K8s 的真实成本

当我们分析实际成本时，数字令人震惊：

基础设施开销

• 40% 的节点用于运行 Kubernetes 组件
• 仅控制平面每月就花费 25,000 美元
• 为保证高可用性需要 3 倍冗余

人力成本

• 每位新 DevOps 员工需要 3 个月的培训
• DevOps 60% 的时间花在维护上
• 值班事件增加 30%
• 12 个月内 4 名经验丰富的工程师离职

隐藏的复杂性

• 基本部署需要 200 多个 YAML 文件
• 5 种不同的监控工具
• 3 个独立的日志解决方案
• 持续存在的版本兼容性问题

寻找替代方案

我们从小处着手。我们选择了最不重要的服务，将其迁移到一个更简单的技术栈：

• 使用 AWS ECS 进行容器编排
• 使用 CloudFormation 管理基础设施
• 尽可能使用托管服务
• 使用简单的 shell 脚本进行部署

结果立竿见影：

• 部署时间：从 15 分钟缩短到 3 分钟
• 基础设施文件：从 200 多个减少到 20 个
• 月度成本：从 12,000 美元降至 3,200 美元
• 告警噪音：减少 80%

全面迁移

受初步结果的鼓舞，我们制定了为期 4 个月的迁移计划：

第一阶段：审计与评估

• 梳理所有服务及其依赖关系
• 识别关键与非关键工作负载
• 计算真实的运营成本
• 记录痛点

第二阶段：替代架构

• 为每种工作负载选择合适的工具：
• 简单应用 → AWS ECS/Fargate
• 有状态服务 → 带 Docker 的 EC2
• 批处理作业 → AWS Batch
• 事件驱动 → Lambda

第三阶段：渐进式迁移

• 从非关键服务开始
• 每次迁移一组服务
• 初期并行运行系统
• 收集性能指标

第四阶段：团队重组

• 减少专业化角色
• 对团队成员进行交叉培训
• 简化值班轮换
• 更新文档

6 个月后的成果

技术改进：

• 基础设施成本降低 62%
• 平均部署时间缩短 89%
• 生产事故减少 73%
• 告警噪音减少 91%

团队收益

• 零周末部署
• 值班事件减少 82%
• 没有因过度劳累而离职的情况
• 新团队成员入职速度更快

业务影响

• 功能交付速度提高 47%
• 保持 99.99% 的正常运行时间
• DevOps 招聘时间缩短 60%
• 每年节省基础设施成本 432,000 美元

何时应该（以及不应该）使用 Kubernetes

Kubernetes 并非不好，只是被滥用了。以下情况你可能需要 Kubernetes：

• 你正在运行数千个微服务
• 你需要复杂的自动扩缩容
• 你有多云需求
• 你需要高级部署模式

以下情况你可能不需要 Kubernetes：

• 你的服务数量少于 20 个
• 你的规模可预测
• 你主要使用托管服务
• 你的团队规模较小（DevOps 人员少于 5 人）

未来之路

我们的新技术栈很普通，很简单。它不会成为令人兴奋的会议演讲主题。但它有效，而且我们的团队喜欢它。

我们现在专注于：

• 尽可能使用托管服务
• 选择简单性而非灵活性
• 只自动化必要的内容
• 保持运营透明

关键启示

质疑默认选择

• 科技巨头使用的技术并不意味着你也应该使用
• 复杂的解决方案往往会带来更多问题
• 考虑全面成本，包括团队幸福感

明智选择工具

• 从简单开始，需要时再扩展
• 对于普通问题使用普通技术
• 考虑团队规模和专业知识

重视团队幸福感

• 快乐的团队就是高效的团队
• 简单的系统更易于维护
• 减少救火时间意味着有更多时间创新

有时，最佳的工程决策是减少复杂性而不是增加它。我们放弃 Kubernetes 的”疯狂”决定最终成为我们做出的最佳技术选择之一。

我们是否在说 Kubernetes 不好？不是。 我们的意思是，对于许多团队，包括我们自己，它带来的复杂性超过了其好处。

有时，承认这个简单的事实可以彻底改变整个工程组织。

链接：https://blog.stackademic.com/i-stopped-using-kubernetes-our-devops-team-is-happier-than-ever-a5519f916ec0

👍 如果你喜欢这篇文章，请点赞并分享给你的朋友！