内部 PaaS 要不要都迁到 K8s？一份决策评审

评审会上，迁移方案讲到第 12 页，总会有人问一句：迁完之后，研发的发布方式变不变？要变的话，这笔账算进迁移成本了吗？

多数方案答不上来。它们只算了“搬”的成本——应用改造多少人天、新集群多少节点——漏了另一个数：并存期。从第一个应用上 K8s，到最后一台老虚机下线，新旧两套底座同时在线，监控两套、告警两套、值班两套、故障预案也是两套。这段时间通常按年算。

9 月，AWS 给 Elastic Beanstalk 加了一个基于 EKS 的集群模式，社区第一反应是“为什么不把 ECS 做好”。我更在意另一个细节：原来基于 EC2 的模式并没有下线，改名 Standard Mode 继续保留。一家把容器编排当主营业务之一的云厂商，在自己的老 PaaS 上做的选择，也不是“全部迁到 K8s”。

先把我的倾向放在这里：统一到 K8s 的价值主要在编排底座这一层；如果还没把“开发者体验层”从底座里剥出来，先别谈统一底座。这个判断有两个前提——存量应用以无状态为主，平台组里至少有人能兜住 K8s 本身。前提不成立，结论就得改。

那次“加底座”，争的其实是耦合

先纠正一个流行说法。不少讨论把这次发布说成“Beanstalk 换了底座”，AWS 官方发布说明的原文不是这样：Elastic Beanstalk 现在有两种部署模式，Standard Mode 就是原有体验，继续支持现有全部平台；Cluster Mode 把多个应用跑在账户内由 EKS 驱动的共享（pooled）基础设施上，“应用数增长时可以降低单应用计算成本”。开发者指南里还有一句关键的话：两种模式沿用同一套应用、应用版本、环境和配置项概念。

换成架构的语言——上层的开发者体验层没动：提交源码、Dockerfile 或镜像，然后构建、部署、扩缩、看健康状态；下层的编排底座多了一个选项。

InfoQ 的报道引用了 James Eastham（Datadog 工程师，也是 AWS Community Builder）在公告下的评论：“ECS 和 Beanstalk 集群模式看起来有些过于接近，他们本可以集中投入精力，把其中一项服务真正做好。”这是产品组合层面的讨论，谁对谁错我不评价。对企业架构师来说，这场争论背后藏着一个更有用的问题：体验层和底座，是不是一一绑定的？

绑定，换底座就等于换产品，研发要重新学，流水线要重写。解耦，底座就能按场景挑，研发几乎无感。

拿这个问题去看企业内部的老 PaaS，多数答案是“绑定”，而且焊得很死。早些年用虚机加脚本自建的发布平台，或者在某一代 Cloud Foundry、OpenShift 上二开的平台，发布流程、配置规范、日志路径、扩容逻辑全写在底座里。于是“迁 K8s”在评审会上常被放大成“重做整个平台”，工期一拉长，业务方就开始反对。

问题不在 K8s。在耦合。

▲ 体验层和底座解耦后，换哪种底座对研发基本透明

先判断能不能做：四道前提

评审第一轮，我建议先不讨论“K8s 好不好”，只问四个问题。哪个答不上来，方案就自动降一级。

▎谁来兜底 K8s 本身？

K8s 不是装完就完事的软件。按 Kubernetes 官方的发布策略，社区一年大约发 3 个小版本，每个小版本的补丁支持期约 14 个月——也就是说，集群一年多不升级，就会掉出社区支持窗口。控制面升级、CNI（容器网络插件）和 CSI（存储插件）出故障、证书到期轮换，都得有人会、有人值班。

平台组没有这样的人，就只剩两条路：买托管，或者把风险悄悄转给业务。前者要接受托管的约束（Beanstalk 集群模式就不让用户选 K8s 版本，也不开放直接访问集群，在服务之外改了集群会被判为配置漂移、停止维护）；后者，是评审会最该拦下来的。

▎存量里有多少应用是真无状态？

Beanstalk 开发者指南对集群模式上的应用有明确要求：无状态，副本可互换，本地存储只能是临时的。一个托管得这么彻底的产品，都得先立这条规矩，企业自建平台更绕不开。

企业存量的真实情况呢？写本地文件的、依赖会话粘滞的、对端按固定 IP 加白名单的、单实例跑定时任务怕重复执行的，一个都不少。建议先做一次应用盘点，按四类打标：

无状态：可以直接容器化；

可改造：会话外置、文件改对象存储、定时任务加分布式锁之后能迁；

强有状态：数据库、消息队列、核心账务；

特殊运行时：Windows、老版本中间件、绑定硬件或 License 的。

前两类占多少，基本决定了“统一底座”能统一到什么程度。

▎合规隔离会把集群拆成几个？

这一条最容易被低估。AWS 在多租户文档里写得很坦白：共享集群里的隔离控制，无法让共享集群达到与独立集群等同的效果；对受基础设施隔离要求约束的环境，仍建议用不同的子网集合、也就是不同的集群。

放到金融和政企，等保分级、生产与测试分域、不同安全域之间的隔离要求，都会把“一个大集群”拆成好几个。而 K8s 在资源利用率上的收益，恰恰来自共享。拆得越多，省得越少。

▎并存期，人从哪来？

回到开头那个数。迁移期间至少两套底座并行，要问清三件事：并存期计划多长？两套平台各由谁值班？告警和监控是不是一个入口？答不清的话，这个项目大概率会在第二年变成“新平台跑了三成应用，老平台一台机器也下不掉”。

把四道前提放进一张表，评审时逐行过：

维度

倾向“统一底座”的信号

倾向“多底座并存”的信号

一票否决条件

团队能力

平台组有人能处理控制面升级、网络与存储插件故障

平台组 2～3 人，以运维老平台为主

无人兜底，又不能用托管

存量应用形态

无状态 + 可改造占多数

强有状态、特殊运行时占多数

核心系统依赖本地状态且无改造预算

合规隔离

安全域少，共享集群能过审

等保分级、多安全域，需要拆多个集群

监管明确要求物理隔离

运维人力

并存期有预算、有上限、有值班安排

并存期没有人力预算

双平台值班找不到人

三个方案，各自押注什么

把选项摆上桌。每个方案背后都押了一个假设，假设不成立，它就会变成另一副样子。

▎A：保持现状，多底座并存

押注：现有平台够稳，业务增长不靠弹性。代价是多套运维、技能分散，新人要学三套发布流程。

这不等于“不作为”。应用数量不多、平台组只有两三个人、一两年内有信创替换计划的团队，选它常常最划算。前提是把发布规范和观测入口统一起来，别让“并存”退化成“各管各的”。

▎B：体验层不变，底座逐步换成 K8s

Beanstalk 集群模式走的就是这条路：同一套应用、版本、环境概念，下面多了一个 K8s 底座。

押注：能先抽出一层稳定的平台契约——应用怎么描述、怎么构建、用什么发布策略、配置和密钥放哪、日志指标从哪看。契约稳了，底座替换对研发基本透明。

风险也很具体。抽象做得不好，体验层会沦为“最大公约数平台”，底座的高级能力透不上来。还有一种情况：新底座上的能力反而比老底座少。InfoQ 的报道提到，Beanstalk 集群模式的架构文档只列了滚动更新和一次性全部更新两种部署策略，不可变部署仍然是 Standard 模式的功能。企业内部迁移一定也会碰到这类差异，要在迁移前列清楚、提前告诉研发，而不是等上线那天才被发现。

▎C：全量重构为 K8s 原生

研发直接面对 Helm、Operator、GitOps，平台只提供集群和规范。

押注：团队整体云原生能力强，应用以新建微服务为主。收益是能力上限最高，研发能用上 K8s 的全部表达力。

风险是认知负担整体转给了研发，改造周期长，最难迁的那一批系统会在收尾阶段卡住所有人，项目进入“永远差一点完成”的状态。我的判断是，C 更适合新业务线从零起步，而不是拿来改造存量平台。

A 保持现状

B 体验层不变换底座

C K8s 原生

押注的假设

现有平台够稳，不靠弹性

能抽出稳定的平台契约

团队云原生能力强、新应用为主

研发感知

无变化

基本无感，需告知功能差异

需学习 Helm、探针、配额等

平台组负担

多套运维长期并行

前期重（抽象 + 并存），后期降

集群运维 + 研发支持

典型适用

小团队、近期有信创替换

存量多、无状态占比高

新业务线、微服务为主

不适用

平台已严重碎片化、运维撑不住

契约抽不出来、底座能力差异大

存量重、研发团队云原生基础弱

成本与风险：五个维度逐项算 ▎迁移成本：并存期常常比改造更贵

算迁移账，我用一个很粗的公式：

迁移人力 = 需改造应用数 × 单应用改造人天 + 并存月数 × 并存期额外运维人数 × 每月工作日

举个例子（数字只为说明量级而假设，不对应任何真实项目）：80 个应用要改造，平均每个 5 人天；并存期 12 个月，每月多出 2 名运维人力，每月按 21.75 个工作日计。

输入

计算

结果（人天）

应用改造

80 × 5

400

并存期运维（12 个月）

12 × 2 × 21.75

522

并存期缩到 6 个月

6 × 2 × 21.75

261

并存期拉到 24 个月

24 × 2 × 21.75

1044

盈亏平衡点

400 ÷ (2 × 21.75)

约 9.2 个月

结论很直接：按这组假设，并存期一过 9 个月，双平台多出来的运维人力就超过了全部应用的改造人力；拉到两年，是改造成本的 2.6 倍。不少方案只算了前一半。

▲ 按文中假设，并存期一过约 9 个月，双平台运维就比全部改造还贵

资源节省也要算对基准。Beanstalk 的定价页写得清楚：集群模式不收平台费，但多了每个集群固定的 EKS 小时费和 EKS Auto Mode 管理费，后者 Savings Plans、Spot 这类 EC2 折扣都抵扣不了；AWS 也说明，节省来自共享节点，独立集群成本更高、利用率更低。企业自建是同一个道理——每多拆一个集群，就多一套控制面、多一份冗余节点。所以“迁 K8s 能省多少资源”，要拿“按安全域拆完之后的集群数”去算，而不是拿理想中的一个大集群。

▎技能储备：B 集中，C 摊开

B 方案把 K8s 的技能需求压在平台组，研发看到的仍是“应用、版本、环境”。C 方案让每个研发团队都得懂 Deployment、Service、探针和资源配额。研发团队越大，后者的培训和出错成本越不能忽略。

▎有状态应用：别跟首批走

数据库、消息队列、文件服务，不建议跟着首批迁。StatefulSet 和各类 Operator 当然能跑，但运维复杂度和在虚机上不是一个量级：存储卷故障切换、备份恢复演练、升级时的数据兼容，都得重新验证一遍。

▎信创适配：两次改造别叠在一起

目标栈如果涉及国产 CPU（鲲鹏、飞腾属 ARM 架构，海光属 x86，龙芯是 LoongArch），镜像就要做多架构构建，容器运行时、K8s 发行版、网络和存储插件要逐项过兼容清单。真正的风险是叠加：底座迁移和中间件国产化同时推进，出了故障，很难判断是哪一层的问题。

▎故障域：统一底座，故障也统一了

十个虚机集群，坏一个影响十分之一；一个共享 K8s 集群，控制面或网络插件出问题，影响面是全部。缓解办法不复杂：按业务等级拆集群，核心系统独立故障域，非核心再共享。只是拆完之后，回头看迁移成本那一节的资源节省，还剩多少？

维度

A 保持现状

B 体验层不变换底座

C K8s 原生

迁移成本

低：无迁移，但长期多套运维

中：前期抽象 + 并存期

高：全量改造 + 长并存期

技能储备

低：沿用现有技能

中：集中在平台组

高：摊到每个研发团队

有状态应用

低风险：原地不动

中：可留旧底座，接入统一入口

高：被迫上 StatefulSet / Operator

信创适配

中：随信创计划单独做

中：可按批次与信创节奏对齐

高：两次改造易叠加

故障域

分散，单点影响小

可按等级拆集群控制

集中，需额外设计隔离

这三类系统，现在不该迁

小团队。平台组两三个人，撑不起 K8s 自身的运维，托管又受合规限制时，统一底座只是把风险集中到了一个更难排查的地方。保持现状、把发布流程规范起来，更划算。

强有状态的核心系统。核心账务、交易、清算，迁移带来的弹性和部署密度对它们意义不大，风险却最大。留在虚机或物理机上，把它们接入统一体验层的发布入口和观测入口，就够了。

一两年内要做信创替换的系统。别让“底座迁移”和“信创替换”在一年内对同一个系统各做一次。先定国产化目标栈，再定底座，一次迁到位。

我知道这一节会让一部分推动迁移的同行不太舒服。不过在评审会上，能说清“哪些不迁”的方案，往往比“全部迁”的方案更容易批下来。

过渡态路线：先抽体验层，再换底座

Beanstalk 这次的做法，正好提供了一个过渡模式的样本：先统一概念（应用、版本、环境），再让底座可替换。落到企业内部，我会分四段走。

阶段一：现状盘点。应用按四类打标，列出底座清单，算出并存成本的基线。退出条件：所有应用都有分类标签，有一份各方认可的成本基线。

阶段二：体验层抽象。定义平台契约：应用描述、构建规范、发布策略、配置与密钥、观测入口。老 PaaS 和虚机集群先接进这层契约，研发入口先统一。这一步一个应用都不迁，却决定了后面每一步的成本。退出条件：新应用全部走契约，存量的契约覆盖率达到立项时约定的比例。

阶段三：底座逐步替换。无状态和新应用先上 K8s；按业务等级划分集群与故障域；每批迁移都留回退窗口，回退演练过才算完成。退出条件：并存期不超过立项时定的上限——参照前面的测算，这个上限值得认真谈。

阶段四：目标态。体验层统一，底座“一主多辅”：K8s 为主，强有状态系统、特殊运行时、信创过渡期的系统保留其他底座。不追求 100% 统一。

每个阶段都要有退出条件。这是整条路线里我最想强调的一点，因为没有退出条件的过渡态，迟早会变成永久态。

▲ 先抽体验层再换底座，每段设退出条件，目标态是一主多辅而非百分之百统一

带进评审会的 7 个问题

1

开发者体验层和底座解耦了吗？没有，先做这一步。

2

存量应用里，无状态和可改造的占比是多少？

3

K8s 控制面、网络和存储插件出故障，平台组谁来兜底？

4

合规隔离会把集群拆成几个？拆完还剩多少资源节省？

5

并存期计划多长？双平台运维的人力从哪来？

6

未来一两年，这些系统有没有信创替换计划？

7

核心系统的故障域独立吗？回退方案演练过没有？

体验层统一是必选项，底座统一是可选项。前者决定研发效率；后者只有在应用以无状态为主、平台组撑得住的前提下，才值得做。

你们现在是几套底座并存，卡在哪一步？欢迎留言聊聊。

IT架构师联盟

面向企业架构师与技术负责人的专业号：讲企业 IT 架构的选型与演进，把关键决策的取舍和代价讲清楚。