别再把K8s当万能药，很多团队正被自己搭的运维迷宫拖垮

过去几年，Kubernetes（K8s）几乎成了云原生时代的代名词。只要聊到架构演进、弹性伸缩、高可用，K8s 总是第一个被摆上台面的选项。不少团队在技术选型会上，甚至还没搞清楚业务峰值曲线和发布节奏，就已经把“上 K8s”写进了季度 OKR。但现实往往比理想骨感：很多团队并没有因为 K8s 获得预期的敏捷与稳定，反而被自己搭建的运维迷宫拖得筋疲力尽。

问题的根源不在于 K8s 本身，而在于把 K8s 当成了万能药。K8s 是一个强大的容器编排系统，但它不是开箱即用的运维平台。它提供了丰富的原语和扩展点，同时也把集群网络、存储、安全、可观测性等一系列复杂问题交给了使用者。一个典型的自建 K8s 集群，往往需要叠加 CNI 插件、Ingress 控制器、证书管理、日志采集、监控告警、策略引擎等一整套组件。每引入一个组件，就多一层配置、多一个故障域、多一份维护成本。当这些组件之间的交互出现问题时，排查链路会变得异常漫长。

更隐蔽的风险在于组织层面。K8s 的抽象层度较高，开发人员习惯用 Deployment、Service 描述应用，却未必理解底层的网络转发、调度策略和资源限制。一旦线上出现 Pod 频繁重启或服务间调用超时，开发与运维之间的职责边界就会模糊。运维团队抱怨开发不懂集群约束，开发团队抱怨运维提供的平台不够透明。这种摩擦在自建集群中尤为明显，因为缺少统一的产品化封装，每个团队都可能按照自己的理解去使用集群，最终形成一个个孤岛式的运维迷宫。

那么，什么样的团队适合自建 K8s？答案并不绝对，但有几个判断维度值得参考。首先是规模：如果应用实例数量长期在几十个以下，且发布频率不高，那么轻量级的容器编排方案或托管服务可能更划算。其次是团队能力：是否有人能持续投入精力维护集群的升级、备份、安全补丁和故障处理？如果答案是否定的，那么自建集群很可能成为技术债的温床。最后是业务对弹性的真实需求：很多业务所谓的“弹性”只是应对偶尔的流量高峰，用简单的水平扩展加负载均衡就能解决，并不需要 K8s 级别的调度能力。

对于已经深陷运维迷宫的团队，出路不在于继续堆砌工具，而在于重新审视抽象边界。一种思路是收敛平台层，将集群运维职责集中到少数人手中，对上层开发提供标准化的部署接口和自助服务能力，减少每个团队直接操作集群的频次。另一种思路是评估托管服务或轻量级替代方案，把控制面交给更专业的团队，自己专注于业务负载的编排策略。无论选择哪条路，关键都在于承认 K8s 只是工具箱中的一件工具，而不是架构设计的起点。

技术选型从来都是权衡的艺术。K8s 解决了大规模容器编排的问题，但也引入了新的复杂度。真正成熟的团队不会因为某个技术流行就盲目跟进，而是会先厘清自己的业务痛点、团队能力和运维成本，再决定是否引入以及引入到什么程度。别再把 K8s 当万能药，更别让自建的运维迷宫成为业务创新的绊脚石。