我们多年来一直为澳大利亚企业搭建和运维 Kubernetes，但仍然会劝退大约三分之一的咨询者。并不是因为这项技术不好，它在自己擅长的领域表现出色，而是因为摆在我们面前的商业论证，通常建立在一份遗漏了大部分成本的成本对比之上。
如果你正在权衡是否迁移，下面这六项费用决定了它能否收回成本。它们都不会出现在许可费用对比中。
报价涵盖了什么
一份典型的迁移报价包括集群搭建、CI/CD 流水线工作、应用容器化以及切换上线。这些工作是真实的，估算通常也合理。
问题在于，搭建集群是其中简单、成熟、高度可自动化的部分。借助 Terraform 和托管控制平面，一个生产级集群只需几天的工作量。真正耗尽预算的，是集群随后所触及的一切。
1. 你没有估算在内的应用改造
“已容器化”和“适合容器运行”是两种不同的状态，两者之间的差距，就是第一笔超支所在。
任何东西都可以装进容器。但当 Kubernetes 以它对待一切的方式对待它时，它能否正常运行，就是另一回事了。Kubernetes 会杀掉你的 pod、把它重新调度到另一个节点、运行多个副本，并在不合时宜的时候重启它。基于相反假设编写的应用，会以看似偶发的方式出错。
常见的问题有：
- 写入本地文件系统。上传文件、缓存、生成的文件、写入磁盘的日志。容器文件系统是临时的。这些都需要迁移到对象存储或卷中。
- 内存中的会话状态。一个实例时没问题。三个实例时，用户会被随机登出。
- 从磁盘文件而不是环境变量读取配置，导致每个环境都需要不同的镜像，这就失去了意义。
- 启动缓慢或“谎报”就绪。Kubernetes 需要知道你的应用何时真正就绪。报告已就绪、随后却花四十秒预热缓存的应用，每次部署都会丢失流量。
- 忽略 SIGTERM。没有优雅关闭，每次部署都会中断正在处理的请求。用户在每次发布时都会看到少量错误，却没人把它和部署联系起来。
对于已经遵循十二要素（twelve-factor）约定的现代应用，这部分工作几乎为零。对于一个只在单台服务器上运行过的十年老应用，它可能是整个项目中最大的一项开支。最诚实的摸底方法是：在确定完整范围之前，先把一个有代表性的应用容器化，并以三个副本运行。
2. 有状态性
无状态工作负载正是 Kubernetes 真正、毫无疑问擅长的领域。难点集中在状态上。
数据库、消息队列以及任何保存数据的组件都需要持久卷，这意味着存储类、访问模式、能理解这层抽象的备份与恢复，以及节点在写入过程中宕机时的应对方案。Kubernetes 为此提供了良好的基础组件。但要正确运维它们，仍然明显比运行在虚拟机上、备份任务自 2019 年起就一直正常工作的数据库更难。
务实的答案
保留大部分价值、去掉大部分风险的做法是：在 Kubernetes 中运行无状态工作负载，把状态留在托管服务中，例如 RDS、Azure Database 或托管 Redis，或者留在已经运行良好的虚拟机上。“一切都放进集群”是一种审美偏好，而不是工程需要，迁移也往往正是在这里出问题。
3. 网络与出站流量
这里有两个截然不同的意外。
网络模型是真正全新的。Service、Ingress 控制器、网络策略、服务网格（如果你要用的话）、集群内部的 DNS，以及这一切如何连接到你现有的企业网络。熟悉 VLAN 和防火墙规则的团队有能力胜任，但尚不熟练，而熟练需要几个月。
云出站流量费用是一项实实在在的预算支出。离开云服务商的流量要收费，跨可用区的流量通常也要收费。原本一个进程内的本地函数调用，在微服务架构中变成了许多服务之间的网络调用，有时还跨可用区。我们见过这在一个原本合理的设计上，变成每年五位数的意外开支。通过可用区感知路由和合理的服务边界可以避免这种情况，但前提是在架构定型之前就有人考虑到这一点。
4. 你现在需要的平台团队
这是最常被忽略的成本，也是最可能决定成败的成本。
Kubernetes 是一项运维承诺。必须有人负责这个集群，弄清楚某个 pod 为什么处于 Pending 状态，让 Ingress 控制器、CNI 和监控栈保持最新，并在半夜出故障时能联系得上。这是一种能力，无论你是招聘、培养还是外包。
失败的模式是可以预见的：一位热情的工程师主导了迁移，成为唯一了解这个平台的人，然后离职了。剩下的是一个没人敢碰的生产系统。我们不止一次被请去处理这种情况，而这比他们最初使用虚拟机时的处境要糟糕得多。
在做出承诺之前，请坦率回答：十八个月后由谁来运维它？如果那个人辞职了怎么办？
5. 永无止境的版本升级
Kubernetes 每年发布数个版本，每个版本的支持周期大约一年。无论你是否准备好，托管服务最终都会替你升级。
这意味着一个永久性的定期升级节奏。每次升级都伴随一定风险：清单中仍在使用的已弃用 API、需要匹配版本的控制器、偶尔的行为变化。这是可控的，做过几次之后也确实会变成例行工作，但它是一项持续性的工作，而在过去一台服务器连续四年运行同一个操作系统时，这项工作根本不存在。
每次升级预留几天时间，每年几次，无限期持续。连续十八个月跳过升级的团队，将面临一次跨越多个版本、难度大得多的跳跃升级，而且通常是在时间压力之下。
6. 排障在变容易之前会先变难
在虚拟机上，工程师通过 SSH 登录，查看日志，运行 top，凭借十年积累的技能，两分钟内就能形成一个假设。
在集群中，流程完全不同。是哪个 pod？它被调度到了哪个节点？它是否在有人查看之前就因 OOM 被杀掉并重启了？日志是否被发送到了某处，那个地方能否搜索？答案都存在，工具也很好，但熟练度是全新的，需要几个月才能重新建立。
预计迁移后的一段时间内，平均故障解决时间会变差。这是正常且暂时的，但它是真实的，而且恰恰发生在所有人都密切关注新平台的时候。为此做好计划：在切换之前就让集中式日志和指标正常运作，而不是等到第一次事故证明你需要它们之后。
什么时候真正值得
这些都不是反对 Kubernetes 的理由。我们自己在用它，我们也喜欢它，对于适合它的问题，没有别的方案能与之相比。
| 信号 | 适合 Kubernetes | 可能不适合 |
|---|---|---|
| 服务数量 | 很多，且独立部署 | 两三个 |
| 部署频率 | 每天或更频繁 | 每月 |
| 负载模式 | 波动或突发 | 平稳且可预测 |
| 负责部署的团队 | 多个，且希望自主 | 一个 |
| 可移植性 | 需要跨云或本地部署 | 单一环境，并将保持不变 |
| 运维能力 | 已具备或正在投入 | 一个人，兼职 |
我们见过的最有说服力的商业论证，都与基础设施成本无关。它们关乎部署速度，团队从每两周发布一次变成每天发布数次；也关乎一致性，开发、预发布和生产环境终于表现一致，一整类 bug 随之消失。
这些都是真实且有价值的成果。只是它们不会出现在成本对比表格中，而以节省基础设施成本为卖点来推销迁移，往往在十二个月后以一场关于账单的尴尬对话收场。
如果有人给你报了 Kubernetes 迁移的价，问问他们这六项中估算了哪几项。好的回答会具体针对你的应用。含糊的回答则意味着，你将在生产环境中自己去发现这些成本。
Kubernetes 比虚拟机便宜吗？
在小规模下，仅看基础设施通常并不便宜；一旦计入平台人员成本，总体上也常常更贵。Kubernetes 的优势在于资源密度、部署速度以及各环境之间的一致性，而不是原始算力成本。只在几台虚拟机上运行少量服务的组织，迁移后通常花费更多，因为控制平面、平台工具和专业技能在很大程度上都是固定成本。
Kubernetes 迁移需要多长时间？
单个无状态 Web 应用只需几周。如果是一整套服务，包括有状态组件和遗留应用，六到十八个月很常见。起决定作用的变量不是集群搭建时间（只需几天），而是应用需要改动多少，尤其是在状态、配置和启动假设方面。
小企业应该使用 Kubernetes 吗？
通常不应该。如果你只运行少量负载可预测的服务，并且每周部署一次，托管容器服务或运维良好的虚拟机成本更低、故障更少。当你拥有大量服务、多个需要独立部署的团队、确实波动的负载，或对跨环境可移植性有硬性要求时，Kubernetes 的复杂度才物有所值。
Kubernetes 迁移中最大的错误是什么？
把所有东西都迁移过去。回报最高的做法是只迁移能从中获益的工作负载，即无状态、频繁部署、负载波动的那些，并有意识地保留其余部分。一个在虚拟机上愉快运行了六年的数据库，迁入集群后很少会变得更好，而迁移它却承担了项目的大部分风险。