开头前前后后折腾了大概一年半我把公司所有能塞进 Kubernetes 的服务都塞了进去最后又老老实实全部搬了出来。这个标题写出来有点打脸但我觉得对很多中小团队来说这段经历比单纯的“Kubernetes 落地实践”更有参考价值。我会尽量把整个过程复盘清楚包括当初为什么要 all in、迁移的实际步骤和踩坑、稳定运行后的隐形成本以及最终决定撤出的完整判断链条。全程没有保留该丢人的地方我也就不藏着了。这不会是一篇“Kubernetes 权威指南”式的教程也不会是云原生布道文章。它更像是一个工程决策的完整病历记录了我们在“基础设施复杂度”和“业务交付效率”之间反复权衡的过程。如果你正带着一个 20 人左右的后端团队准备或正在把系统搬上容器编排平台这篇内容应该能帮你省掉一笔不小的学费。1. all in K8s 之前的决策推演我们当时到底在赌什么1.1 上 K8s 之前的真实技术债务先交代一下背景。我们的业务是一个偏电商交易加内容运营的互联网产品后端大概 20 多个服务以 Java Spring Boot 为主Python 写一部分数据聚合Go 扛几个高并发接口。数据库用 MySQL缓存 Redis消息队列 RabbitMQ搜索走 Elasticsearch部署在自建机房的几十台虚拟机上环境管理是靠 Ansible 剧本加上各类手工操作。当时的痛点非常明显多到你随便揪一个开发都能列出一长串环境不一致开发本地能跑测试环境经常缺配置发布靠人肉盯着一台一台滚动重启发布一个核心服务经常要拉上运维一起熬夜扩容能力基本为零活动预估流量翻倍只能提前申请机器等审批、等上架、等装机服务之间的调用关系没人说得清配置分散在各台机器的环境变量和配置文件里时间一长谁都不敢乱动。这个状态下任何有上进心的技术负责人都会考虑引入新的基础设施。我们当时的第一反应也是“我们要上容器化上 Kubernetes把这些乱七八糟的事全部收编。”1.2 我们对 Kubernetes 的核心预期现在回头看当时的决策逻辑其实不复杂就是我们列了四个核心诉求而 Kubernetes 在纸面上都能满足标准化交付通过镜像和 Deployment 清单让应用的打包、发布、回滚变成同一条流水线省掉各环境的手工配置差异。自动扩缩容用 HPA 根据 CPU、内存、QPS 等指标自动扩缩 Pod理论上不再怕流量突增。高可用自愈节点挂了Pod 自动调度到其他节点服务挂了自动重启把运维从“半夜抢救”中解放出来。统一运维入口所有服务都通过 kubectl、Dashboard、API 来管理不再挨台机器登录。这四条在当时看起来完美对应我们所有的痛点。但决策会里我们忽略了一件事Kubernetes 提供的是“可能性”不是“免费的能力”。它把标准化、自动化、高可用的承诺摆在你面前但背后的实现是需要平台工程团队持续投入的这个投入在决策表上被严重低估了。1.3 被选择性忽略的隐性成本事后复盘我们当时的评估至少有四个盲区第一个盲区是团队技能。团队里真正读过 Kubernetes 核心概念、能独立排查集群问题的人一开始就只有我自己和另一位运维同事。其他同学对 Pod、Service、Ingress 的理解基本停留在“知道名字”的层面。这就意味着集群一旦出现边缘问题排障链路会集中在极少数人身上。第二个盲区是有状态服务的占比。我们并不是一个一百个服务全是无状态接口的团队MySQL、Redis、Elasticsearch 这些中间件加起来占了生产依赖的一大半。而 Kubernetes 对有状态应用的支持尤其是在存储和网络层面跟“虚拟机装个软件”的复杂度完全不是一个量级。第三个盲区是配套工具链的缺口。K8s 只是底座真正要好用还得接上镜像仓库、日志收集、监控告警、链路追踪、CI/CD、密钥管理……每一样都要选型、部署、维护最后这些全变成了新的存量系统。第四个盲区是故障域模型的变化。以前一台虚拟机挂了的排查范围很清楚而现在一个请求要经过负载均衡、Ingress Controller、Service、Endpoint、Pod、容器网络、存储卷每一层都可能出问题。新的故障域引入了大量此前团队没有经验的新网络组件。这些盲区没有在最初唤醒我们是因为当时的痛点太痛了而 Kubernetes 的光环又太亮了。我们带着很强的“技术先进性预期”启动了这个项目这在企业内部是一场很典型的“解决方案驱动”而不是“问题驱动”的架构演进。提示如果今天有人问我“该不该上 K8s”我的第一个问题永远是你团队里有没有至少两个人不看文档也能把一次 Node 节点异常、网络插件故障、etcd 快照恢复这类问题处理掉如果没有后面的账都不用算先别上。2. 迁移改造的落地清单从容器化到上线的完整链路决定要做之后我们没有立刻动生产而是先花了一个多月做了一轮技术预研和迁移方案设计。这个阶段踩了很多坑也有一些值得后来者照抄的经验我按执行的顺序拆开讲。2.1 服务容器化趁手的镜像才是地基K8s 调度的是容器所以第一步永远是把应用容器化。这个步骤看起来简单实际里面全是坑。我们先做了一轮基础镜像标准化。Java 服务统一用基于 OpenJDK 的镜像Python 服务统一用基于 Debian slim 的镜像Go 服务直接用多阶段构建产出静态二进制。基础镜像里预置了时区、字体、常用调试工具像 curl、netstat、tcpdump 这类排查工具必须带不然线上出了问题你想进容器看一眼都没有命令可用。然后是为每个服务编写 Dockerfile。这里最重要的经验是分层缓存和镜像瘦身。以 Java 服务为例一开始很多同事直接把 Jar 包打进去一个 800MB 的镜像传到 Harbor 仓库能等半天。后来我们统一改成三层结构底层 JDK 镜像只放运行时环境中间层放依赖库最上层才是业务 Jar这样每次代码变更只需要重新构建最上层镜像体积降到150MB左右发布速度明显加快。另外还要处理容器的优雅退出。Java 应用收到 SIGTERM 信号后Spring Boot 默认会立刻退出但正在处理的请求可能还没结束会造成数据不一致或报错。我们的做法是在镜像里加入一段优雅停机脚本让应用先摘掉流量、等待存量请求处理完再真正退出进程这个过程在后续的滚动发布中极其重要。2.2 集群搭建我们选型的网络与高可用方案集群我们一开始用的是自建 K8s三个 master 节点加五个 worker 节点etcd 独立部署在 master 上全部走 HAProxy 做 apiserver 负载均衡。这么做的好处是完全掌控坏处是升级维护都得自己扛。网络插件这块我们在 Calico 和 Flannel 之间纠结过。Flannel 简单VXLAN 模式部署快捷但性能一般网络策略基本只能靠外部方案补齐。Calico 功能强支持 BGP 和 NetworkPolicy但组件更重排查路径更长。我们最终选择了 Calico理由是我们有跨节点通信的安全隔离需求同时后续要做 NetworkPolicy 来做服务间的访问控制。实际用下来性能损耗确实比 Flannel 好一些但这个选型也导致后面不少网络排障的复杂场景。Ingress Controller 我们用的 NGINX Ingress没有选 Traefik。原因是团队对 Nginx 配置的熟悉度更高遇到问题能直接用老经验定位而 Traefik 的功能虽新但知识积累要从头来。后来证明这个决定是对的我们的很多问题恰恰出在 Ingress 规则编写和虚拟主机路由上换成 Nginx 生态我们至少能依托经验排查。2.3 工作负载对象的选型一种类型的服务用哪种资源大部分无状态应用都用 Deployment这没什么好说的。真正需要在迁移前想清楚的是哪些服务该用 StatefulSet哪些该用 DaemonSet哪些该用 Job/CronJob。我们的日志采集用 DaemonSet 部署 Filebeat在每台节点上跑一个 Pod 去收集容器日志这很合理。定时任务类的服务原来的 crontab 全部改造成 CronJob。这里有一个值得强调的坑CronJob 的时区默认是 UTC我们的任务是北京时间凌晨跑的起初没注意任务整整跑偏了两小时才被系统告警发现。有状态服务当时的选择是分开处理的。Redis 集群先放进 K8s 试水用 StatefulSet 管理存储挂 NFSMySQL 一开始就没敢直接拆进去而是继续跑在集群外的虚拟机上通过内网 DNS 让 Pod 访问。现在回头看这个“半上不上”的状态其实是最难受的既没有享受到集群的自动化管理又多引入了一层跨网络的访问复杂度后面还会细说。2.4 配置管理从环境变量到 ConfigMap 和 Secret迁移前我们的配置分散在各台服务器的环境变量、properties 文件、Nacos 配置中心、前端静态配置文件里。迁移之后这些配置的载体必须统一。我们最终的方案是允许变动的配置放 Nacos 配置中心保留动态刷新能力非敏感的静态配置放到 ConfigMap数据库密码、第三方密钥等敏感信息放到 Kubernetes Secret。ConfigMap 有几个隐蔽的坑值得记一下。第一ConfigMap 更新后有延迟Kubelet 大概每 60 秒同步一次不是改了立即生效第二如果通过环境变量方式引用 ConfigMap更新 ConfigMap 后 Pod 内的环境变量不会自动变必须滚动重启 Pod第三如果通过挂载文件方式引用更新后文件会变但应用未必监听文件变化需要结合 reload 机制。所以我们的经验是这类配置变化最好走 configmap roll restart用命令重启相关 Deployment既简单又靠谱。Secret 我们遇到的问题是默认的 etcd 明文存储这在安全审计时肯定不行。后来我们用了 Sealed Secrets 方案把 Secret 加密后提交到 Git 仓库只有集群内的控制器能解密。这比直接在 Git 里躺着一堆 base64 密码要安全得多。2.5 发布流程与探针调优从 GitLab CI 到滚动发布的细节我们的 CI 是 GitLab CI构建镜像后推到 Harbor而 CD 侧要求 Git 提交变更清单、ArgoCD 自动同步到集群。最早的时候我甚至想过完全用 Jenkins但后来发现 GitOps 模式对回滚太友好了改一行镜像版本提交ArgoCD 帮忙干剩下的活。看滚动更新的剧本是容易的但真正让发布稳定是探针调优。我们第一次上线测试环境时图省事没配 livenessProbe 和 readinessProbe。结果发布时K8s 默认滚动策略是 maxSurge25%maxUnavailable25%新 Pod 刚起来就被杀流量切过去就 502。当时查了半天最后打开日志才发现新 Pod 需要 40 秒预热才能接受流量而就绪探针没配老 Pod 被提前摘除等于发布期间所有流量都打到了还没就绪的实例上。后续我们统一了探针规范readinessProbe 用 HTTP 请求 /actuator/health/readinessinitialDelaySeconds 设置 20 秒periodSeconds 10 秒failureThreshold 3。livenessProbe 用 TCP 检测服务端口频率不用太高防止 JVM GC 停顿造成误杀。startupProbe 单独给慢启动服务预留 60 秒预热时间避免 liveness 在启动期干掉容器。这些参数看起来简单但每一个都是拿线上故障换来的。探针配置得不好滚动发布永远处于“要么惊心动魄要么频繁回滚”的状态。3. 稳定运行之后真正拖垮我们的不是 K8s 本身经过小半年的迁移应用层面基本上都跑在了 K8s 上各种 Dashboard 指标也好看得很。但这里是我最想说的一部分稳定审美梦之后真正的成本才开始一点点浮出水面。这些成本不是 Kubernetes 直接抛给你的异常而是藏在你每一个操作细节里。3.1 故障定位从线性排查变成了链路式排查以前一台虚拟机部署服务服务不可用你登录机器看进程、看磁盘、看端口基本一轮能定位。但在 K8s 里一次用户报障你的排查链路过长用户请求到 Slb / 负载均衡负载均衡到 Ingress ControllerIngress Controller 根据 Ingress 规则把流量转到 ClusterIP ServiceService 再通过 Endpoint 找到 PodPod 运行时还要经过 Calico 的网络策略和 iptables 规则。中间任何一层出问题表象都是 “服务 502 或超时”。举个真实案例。有一次用户反馈某个核心接口偶发超时我们在监控里看到业务 Pod 的 CPU、内存都正常日志也没有异常但错误率就是那么一点一点冒出来。折腾了一晚上最后把问题定位在 Calico 的 ipip 隧道在跨节点转发时出现了丢包而原因是宿主机的 MTU 和隧道 MTU 不一致。这个问题放在虚拟机时代完全不存在而在 K8s 环境里网络栈被插进了好几层虚拟化组件每个组件都可能成为新的故障点。你需要具备的排障能力从“会看服务日志”变成了“懂 DNS、懂 CNI、懂 kube-proxy 的 iptables 规则、懂 Ingress 路由匹配、懂 Service 和 Endpoint 的实时状态”。对一个小团队来说这个技能树的扩张是非常吃力的。3.2 资源配额与成本管控requests 和 limits 成了玄学你问任何一个运行着 K8s 集群的团队requests 和 limits 怎么设置大概率得到的是一个“经验值”而不是一个精确答案。我们当时也一样为了省资源所有 Java 服务的 requests 都压得很低CPU 给 250m内存给 512Mi但 limits 给到 2 核 / 2Gi。结果就是节点内存经常被 Pod 占满系统 OOM 杀进程然后业务报警再调整 limits……整个循环非常痛苦。原因在于 JVM 默认的堆大小是基于宿主机内存来计算的而不是基于容器 limits。如果容器 limit 是 2Gi而宿主机是 64GiJVM 可能直接默认申请了 1/4 的宿主机内存这远超过容器限制造成频繁 OOMKilled。后来我们统一在 Kubernetes Deployment 里加 JAVA_OPTS 环境变量显式指定 -Xmx 和 -Xms才控制住这类问题。但即使调参数资源的实际利用率依然不高。我们监控发现平均 CPU 使用率不到 30%内存使用率不到 60%却要留足 requests 保证调度和容灾加上 master 节点、Ingress、监控、日志系统本身的开销整体成本比原来的虚拟机部署模式高出一截。这就是容器化带来的“资源碎片化”代价——你管理的粒度变细了但每次调度都可能留下无法填补的缝隙。3.3 有状态服务成了最扎手的刺无状态服务在 K8s 上是真的香只要把探针配置好发布、缩容、自愈都省心。但一旦轮到中间件整个画风就变了。我们的存储方案用 NFS 做 PersistentVolume 的底层问题接踵而至。首先是性能NFS 的 IO 吞吐和延迟比本地 SSD 差了一个量级MySQL 的数据文件放在 NFS 上根本没法看后来我们只敢把非核心业务和 Redis 放到 NFS但这些服务的 IO 延迟还是经常报警。其次是故障恢复的动作太复杂NFS 单点挂了所有挂载该存储的 Pod 全部变成 ContainerCreating平台直接把所有依赖它的服务一波带走。用 StatefulSet 管理 Redis理论上支持稳定的网络标识和有序部署但真正遇到节点宕机、存储卷重新调度时操作手册要翻老半天。更现实的是很多像 Redis Cluster、Elasticsearch 这类中间件在 K8s 里的生产级运维方式需要专门的 Operator——额外引入 Operator 等于又引入一个新的复杂系统。我们的运维团队能操作 K8s 里的无状态服务流但操作有状态中间件的能力始终没有建立起来。3.4 业务开发的体感变差了这是最致命的信号技术的账算到最后其实就是人力的账。K8s 之前后端开发要排查问题登录虚拟机就好了你想看哪个日志就看哪个。到 K8s 之后开发得先弄明白 Pod 和节点的概念还要会用 kubectl exec、kubectl logs、kubectl port-forward……这些工具对运维来说是基础对业务开发真的是一道很高的入门门槛。业务开发同学如果想在本地连测试环境调试也需要先理解 Service 和 Ingress 的关系否则你根本不知道该用哪个地址访问什么服务。好几次听到开发抱怨“以前一条命令就能跑起来的服务现在先要懂一堆 K8s 概念”还有“环境挂了我也只能在群里等运维帮忙”。这种体感下降直接影响了研发效率整个团队的交接成本反而比搬迁前更高了。后来我们内部做了几个小工具去屏蔽底层细节比如把常用服务封装成一条 Makefile 命令但每增加一个封装就多一层需要维护的代码。到头来我们为了让团队不被 K8s 的复杂度淹没付出了一套额外平台的建设代价。3.5 连续两次 P1 故障之后撤退的情绪开始蔓延真正让我产生“必须重新评估”的念头是两个月内的两次 P1 故障。第一次是节点升级时触发的。我们给一组 worker 节点打内核补丁需要先 kubectl drain 节点排空 Pod。原本以为滚动迁移很平滑结果因为有状态服务和一些无状态服务的本地缓存没处理好大量 Pod 在新节点重建预热时间叠加数据库连接数被打满线上接口大面积超时。虽然最后恢复但整个事故持续了快 40 分钟。第二次是网络策略误配置。当时为了安全加固启用了一个 NetworkPolicy 策略结果策略没写对误拦了服务之间的内网调用核心链路的依赖全断监控里看到的现象是所有服务都在报 “connection refused”。我们花了很长时间排查最后发现同名的 namespace 和 label 选择器匹配错了一头雾水又十分绝望。这两次故障放在传统虚拟机时代根本不会以这种方式发生。它们很清楚地说明了一个问题K8s 并没有消除运维复杂度它只是把运维复杂度换了一种形式并加了转换层。而我们的团队体量显然还不足以接住这个复杂度。4. 从 K8s 迁回虚拟机平台迁移过程、取舍和中间摇摆决定迁回并不是一个轻松的决定中间我们也认真讨论过“留在 K8s 里继续补强”这条路。毕竟 K8s 是趋势谁也不愿意在技术上“开倒车”。但最终让我们下决心的是一套非常现实的成本模型。4.1 为什么不选择“留在 K8s 继续治理”我们首先评估了留存的成本改善方案。比如用托管版 K8s 来减轻集群自建带来的升级和维护负担再招一个专业的 SRE 来专职支撑集群。这个方案的最大问题是“远水救不了近火”托管版可以解决 etcd 备份、控制面升级这些事但业务 Pod 的排障、网络问题、存储问题还得平台组自己扛招 SRE 需要时间和我们的业务节奏完全不匹配。第二个备选方案是“缩小 K8s 使用范围只跑无状态应用”让有状态中间件全部回归虚拟机。这个方案执行起来其实跟“全部迁回”的工作量差不多但保留部分 K8s 组件意味着还是要持续维护集群本身。我们问了自己一句如果要长期维护集群最终投入的成本和收益能平衡吗答案是否定的。还有一个不可忽略的原因是团队里真正为 K8s 而兴奋的人开始变少了。大家原本期待它能把我们从繁琐运维里解放出来结果反而多了更多和网络栈、存储驱动、调度策略搏斗的时间。士气这种东西一旦开始流逝留在原地解决问题的主观意愿就会大幅衰减。4.2 迁出的技术路径把“搬上去”的动作再做一遍只是方向相反迁出的路径其实比较朴素我们没有搞什么花活原则是“一次只动一个服务尽量不影响线上”。第一步梳理服务依赖和状态清单。把每个服务对集群内 DNS、ConfigMap、Secret、PVC 的依赖全部列出来标出依赖顺序。这一步和上 K8s 前做依赖梳理一样重要但当初我们没这么仔细走了一些弯路。第二步在集群外准备虚拟机资源。每个服务规划了独立的虚拟主机或 Docker Compose 环境把 ConfigMap 内容还原成环境变量或配置文件把 Secret 还原成加密的文件或环境变量。对于之前已经依赖 Nacos 的服务配置迁移就简单一些直接复用配置中心即可。第三步确定“先无状态、后有状态、最后中间件”的迁移顺序。先迁移无状态 Web 服务和 API 网关验证流量切换没有问题再迁移依赖数据库的批量任务服务最后把 Redis、Elasticsearch 等中间件数据迁到新机器。每完成一个服务就在 K8s 端摘掉流量观察稳定后再下线对应 Deployment。第四步流量切换。我们通过还在集群外的负载均衡设备加上 Ingress 里的权重分配逐步把线上流量引到新环境。为了减小风险采用了灰度切流方式——先切 5% 的流量观察 15 分钟再逐步放量。这个过程比迁入时更谨慎因为我们已经吃过太多次“大动作”的亏。4.3 迁回后的真实效果其实没有倒退迁回最初的几周我一直在担心这是不是一场技术倒退。但实际跑下来之后我逐渐意识到技术选型没有绝对的新旧只有匹配度。问题定位变得简单了因为服务直接跑在虚拟机上日志、进程、端口都是我们熟悉的形态半夜被叫起来处理故障时心理负担小了很多。发布效率不但没有下降反而因为少了 K8s 探针、滚动更新策略这些环节整体发布节奏变得更顺滑。资源成本也下降了不少去掉 master 节点和一堆平台组件后我们只用原来 60% 左右的机器就扛住了同样的流量。当然代价也是存在的。弹性缩扩容变得笨重需要人工申请机器和调整负载均衡节点级的高可用不再那么智能一台机器挂了需要人工去拉起服务。但这些代价对我们当时的业务体量来说完全在可接受范围内。业务量没有大到需要按分钟级扩缩容的程度人工介入的频率其实极低。5. 这次反复之后我总结出的 Kubernetes 适用范围和决策清单很多朋友听说我们从 K8s 上撤回来都会问“那 K8s 到底还能不能上”我的答案是能但对团队有硬性要求。K8s 不是不好而是它有自己的一套基本盘离开了这个基本盘它不是灵药而是新负担。5.1 K8s 的价值不是“省机器”而是“规模化的工程能力”我刚入行时也以为上 K8s 能省钱后来发现这完全是把概念搞反了。K8s 不是帮你省机器的它是帮你在大规模服务下维持效率和稳定性的。当你有几十个、上百个服务每周发布几十次团队分布在多个产品线统一调度和基础设施标准化的收益才会大于成本。如果你的服务数量只有一二十个发布频率不高团队就几个人那虚拟机的直接操作反而更直观、更快。一个反直觉的经验是K8s 的资源利用率和集群规模呈正相关。集群越大资源碎片越容易被调度器抹平。我们当时只有 5 个 worker 节点节点一少调度余地就小资源配额和 Pod 调度互相打架反而比相互隔离的虚拟机更费资源。5.2 我后来使用的“是否值得上 K8s”判断清单如果今天再让我做一次决策我会先给团队打个分判断项关键问题如果答案是否定团队规模是否有至少 2 名能独立排障维护集群的工程师别上先补技能服务规模服务数量是否超过 30 个发布频率是否每周多次容器化就好不一定要编排有状态服务占比中间件和数据库能否全部或大部分外置慎重有状态是最大的复杂度来源故障容忍度业务能否接受因基础设施升级或网络组件引入的偶发故障虚拟机更稳长期投入公司是否愿意长期养一个平台/运维小组专门做 K8s 治理上托管版否则别全量迁这个清单看起来像是废话但其中的每一条都是我们拿真金白银试出来的。尤其是“有状态服务能否外置”如果只能用普通的 NFS 存储跑数据库那我真诚建议你不要放进 K8s存储的性能和故障处理会耗尽你的耐心。5.3 如果重来一次我们可能走的更轻量路线基于这次的教训我觉得对一个中小团队来说更稳妥的演进路线不是一上来就 all in K8s而是分步走第一步先做容器化收益最高的部分。把所有服务都打成 Docker 镜像在单机或 Docker Compose 环境里标准化运行方式。这一步就能解决大部分环境不一致和交付标准化问题成本极低收益却很直接。第二步解决部署编排问题。如果只是需要更快的发布、回滚和进程管理可以先考虑 Docker Compose、Nomad 这类轻量编排把复杂度控制在“能看懂、能排障”的范围。第三步等真正出现了大规模服务、多租户、混合云调度这类需求再逐步引入 K8s。而且届时不要一次性全量迁移而是先跑一个边缘业务做试点让团队先积累足够的集群运维手感再决定是否扩大范围。别学我们哪热往哪上最后只能把一座桥修到了水里。这次折腾让我深刻体会到复杂基础设施不是能力的勋章它只是你解决业务问题的工具之一。好的架构应该是温和的、可解释的而不是一上来就给团队施加巨大的认知压力。最后分享一点个人的经验无论你是决定上还是不上 K8s都一定要把“迁移成本”和“维护成本”分开算。迁移是一次性的看着再高也能咬牙扛过去维护却是每天睁开眼就要面对的。你把维护这套系统的成本摊到团队每个成员身上再乘以他们失去的业务开发时间这笔账才是最真实的选型依据。如果这个账算完仍然划算那 K8s 是很好的选择如果算完有点心虚那不妨再等等不用为了追赶名词而让业务为基建买单。