原创 Crafting-Code 2025-02-26 07:15 广东
部署成功率提升89%，基础设施成本降低62%。DevOps团队总算能安心休完年假。
六个月前，我们的DevOps团队还在复杂的技术泥潭中挣扎。当时，我们管理着跨三个云服务提供商的47个Kubernetes集群。
工程师们周末加班是常态，值班轮岗让人望而生畏。直到我们做了一个看似疯狂的决定——逐步从技术栈中移除Kubernetes。
如今，部署成功率提升了89%，基础设施成本降低了62%。两年来第一次，我们的DevOps团队成员能安心休完年假。
以下是我们的故事。
一、Kubernetes的理想与现实
和三年前的许多公司一样，我们满怀希望地搭上了Kubernetes的快车。它承诺的愿景令人心动：
大规模容器编排
云原生架构
基础设施即代码
自动扩缩容与故障自愈
Kubernetes确实兑现了这些承诺，但没人告诉我们背后隐藏的代价。
二、崩溃边缘
2023年“黑色星期五”成了压垮我们的最后一根稻草。即便我们拥有：
8名资深DevOps工程师
3支专职SRE团队
7*24值班轮岗
企业级技术支持合同
完善的监控体系
但当天依然发生了：
4次重大故障
147次误报警报
23次紧急部署
2名团队成员因倦怠离职
必须改变了。
三、Kubernetes的真实成本
当我们核算实际成本时，数字触目惊心：
1、基础设施开销
40%的节点资源用于运行Kubernetes组件
仅控制平面每月花费25,000美元
为高可用性部署3倍冗余
2、人力成本
每名新DevOps员工需3个月培训
60%的DevOps时间花在维护上
值班事件增加30%
12个月内4名资深工程师离职
3、隐藏复杂度
基础部署需200+个YAML文件
5套不同的监控工具
3套独立的日志方案
永无止境的版本兼容问题
四、替代方案的实施
我们从最不重要的服务开始试点，迁移到更简单的技术栈：
用AWS ECS替代容器编排
用CloudFormation管理基础设施
尽可能使用托管服务
用简单Shell脚本处理部署
效果立竿见影：
部署时间：15分钟 → 3分钟
配置文件：200+ → 20个
月成本：12,000美元 → 3,200美元
警报噪音减少80%
五、全面迁移计划
试点成功后，我们制定了4个月迁移计划：
阶段1：审计与评估
梳理所有服务与依赖关系
区分关键与非关键工作负载
计算真实运维成本
记录痛点
阶段2：新架构设计
按需选型：
简单应用 → AWS ECS/Fargate
有状态服务 → EC2+Docker
批量任务 → AWS Batch
事件驱动 → Lambda
阶段3：渐进式迁移
从非关键服务开始
逐个服务组迁移
初期并行运行新旧系统
收集性能指标
阶段4：团队重组
减少专职岗位
成员跨职能培训
简化值班流程
更新文档
六、半年后的成果
1、技术改进
基础设施成本降低58%
平均部署速度提升89%
生产环境事故减少73%
警报噪音减少91%
2、团队收益
零周末部署
值班事件下降82%
无倦怠离职案例
新人上手速度加快
3、业务影响
功能交付提速47%
维持99.99%可用性
DevOps招聘周期缩短60%
年省432,000美元
七、何时该用（或不该用）Kubernetes？
Kubernetes并非不好，只是被滥用了。需要Kubernetes的场景：
管理数千个微服务
需要复杂自动扩缩容
多云部署需求
需要高级部署策略
可能不需要Kubernetes的场景：
服务少于20个
流量可预测
主要使用托管服务
团队规模小（DevOps<5人）
八、后续方向
我们的新技术栈很“无聊”——简单、稳定、不炫技，但团队爱用。现在我们专注：
优先使用托管服务
选择简单性而非灵活性
只自动化必要部分
保持运维透明
九、关键经验
质疑默认选择
巨头用的技术未必适合你
复杂方案常制造更多问题
需核算团队幸福感等隐性成本
工具适配规模
从简单方案起步，按需扩展
用“无聊技术”解决“无聊问题”
考虑团队规模与技能
重视团队幸福感
快乐的团队才高效
简单系统更易维护
少救火，多创新
有时，最好的工程决策是删减复杂度而非堆砌。我们“疯狂”的弃用决定，最终成了最正确的技术选择。
我们否定Kubernetes了吗？没有。但对包括我们在内的许多团队，其复杂度已超过收益。
承认这一点，或许能改变你的整个工程团队。
十、补充说明
本文引发大量讨论后，我们补充以下背景信息：
为什么需要47个集群？
过度隔离：为每个环境（开发/预发/生产）单独建集群，本可通过命名空间实现
多云策略：跨AWS/GCP/Azure部署，徒增复杂度
服务膨胀：微服务激增时未及时合并集群
每月25,000美元花在哪？
托管Kubernetes控制平面（47集群×500美元≈23,500美元）
企业级技术支持（约2,000美元）
高可用性冗余成本
为什么迁移后成本骤降？
控制平面费用归零
改用按需计费的ECS/Fargate
简化监控（仅用CloudWatch）
其他常见问题
Q：为何不用命名空间？
A：早期设计失误，过度追求隔离
Q：监控为何昂贵？
A：曾用5套工具（如Prometheus/DataDog），现统一到CloudWatch
Q：ECS不贵吗？
A：优化后成本远低于Kubernetes
十一、总结
Kubernetes是强大工具，但需量力而行。若满足以下条件，请谨慎选择：
服务规模小（<20个）
流量可预测
团队规模有限
技术选型时，全面评估成本、复杂度与团队影响。对我们而言，简化技术栈不是失败，而是回归本质。
作者丨Crafting-Code 编译丨Rio
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
