公司想搞容器化，技术部吵翻了天 —— 有人说 “直接把 OpenStack 换成 k8s，一步到位”，有人喊 “千万别换，老系统迁移要出大事”，你是不是夹在中间左右为难？做软件的老周就遇到过这情况，他们公司用 OpenStack 跑了 3 年虚拟机，现在想上容器化应用，团队一半人支持换，一半人反对，拖了俩月没进展。其实啊，容器化不一定非要 “把 OpenStack 扔了换 k8s”，还有更稳妥的办法。今天就给 50 人以下的中小公司，出 3 种过渡方案，附两个真实案例，看完你就知道该咋选，一起往下看吧！
先想清楚：为啥要换？别为了 “容器化” 而容器化
老周后来才明白，他们吵了半天，根本没搞懂 “换 k8s” 的目的。容器化是为了让应用部署更快、扩缩容更灵活，不是为了赶时髦。
要是你公司有这几种情况，再考虑换：
- 应用是新开发的，适合容器化（比如微服务架构），用 OpenStack 的虚拟机跑，启动慢、资源浪费；
- 经常要上线新功能，每次部署都得停虚拟机，影响业务，想换成容器的 “滚动更新”（不停机更新）；
- 服务器资源不够用，OpenStack 的虚拟机占着资源却用不满，k8s 能让容器挤一挤，省硬件钱。
但要是这几种情况，别急着换：
- 老系统是单体架构，改容器化要重写代码，成本比收益高，老周公司的核心系统就是这样，改了 3 个月还没好；
- 团队没人懂 k8s，全靠外包，出问题没人修，还不如用熟了的 OpenStack；
- 业务稳定，一年就更新两次，虚拟机跑着挺稳，没必要折腾。
方案 1：彻底替换，适合 “新公司、新系统”
就是把 OpenStack 全卸了，服务器装 k8s，从头开始。这种方案听着激进，但 50 人以下的小公司，要是没老系统包袱，反而简单。
步骤（老周朋友的初创公司就是这么干的）：
- 先备份 OpenStack 里的数据，用 rsync 把重要文件拷到移动硬盘，别怕麻烦，丢了数据哭都来不及；
- 格式化服务器硬盘，装 Linux 系统（推荐 Ubuntu Server，对 k8s 友好）；
- 用 kubeadm 装 k8s 集群：
kubeadm init --pod-network-cidr=10.244.0.0/16，跟着提示输命令，半小时搞定； - 把新开发的应用打包成容器，用
kubectl apply -f 应用.yaml部署，比在 OpenStack 里装虚拟机快 10 倍。
案例：小宋的创业公司（15 人），去年直接用 k8s，没碰过 OpenStack。他们的应用全是容器化的，上线新功能点一下鼠标就更新，服务器资源利用率从 30% 提到 70%，省了两台服务器的钱。小宋说：“没老系统拖累，换 k8s 太爽了，就是刚开始学命令头疼了一周。”
方案 2：集成起来，让 OpenStack 当 k8s 的 “后勤部”
不扔 OpenStack，让它给 k8s 提供资源（比如虚拟机当 k8s 节点、存储给容器用），俩工具搭伙干活。老周公司最后选了这个，稳妥。
步骤（老周亲手操作的）：
- 在 OpenStack 里新建 3 台虚拟机（2 核 4G 就行），作为 k8s 的节点，别用太旧的虚拟机，容易卡；
- 在这 3 台虚拟机里装 k8s，步骤和方案 1 一样，注意让虚拟机的网络能互通；
- 用 OpenStack 的 Cinder 建个共享存储，挂载到 k8s 的容器里，这样容器删了数据也不会丢，老周试了三次才挂载成功，关键是权限要设对；
- 先把新应用放 k8s 里跑，老应用还在 OpenStack 的虚拟机里，两边各干各的，数据通过共享存储互通。
案例：20 人的电商公司，用这方案半年了。OpenStack 的虚拟机跑数据库（稳当），k8s 跑前端应用（灵活）。大促时 k8s 不够用，就从 OpenStack 再开两台虚拟机当节点，促结束了再关掉，比单独买服务器省了 40% 的钱。技术负责人说：“俩工具各干擅长的，比单用好太多。”
方案 3：并行运行，“老的用 OpenStack，新的上 k8s”
就是不折腾老系统，OpenStack 继续跑原来的虚拟机，新开发的应用全用 k8s，俩系统各走各的网络，井水不犯河水。适合有老系统、没人手改代码的公司。
操作要点（老周的同行小郑公司这么做的）：
- 找两台新服务器装 k8s，别跟 OpenStack 的服务器混着用，省得打架；
- 新应用按容器化开发，直接部署到 k8s，不用管 OpenStack；
- 老系统和新系统的数据互通？用 API 接口就行，比如 k8s 的应用调 OpenStack 虚拟机里的数据库接口，小郑用了 Nginx 做反向代理，两边通信挺顺畅；
- 慢慢把老系统的功能，一点点搬到 k8s 里，今年搬一点，明年搬一点，不着急。
案例：30 人的制造公司，用这方案两年了。OpenStack 跑着老的生产管理系统（改不动），k8s 跑新的销售统计系统。技术经理说：“没出过大问题，团队也有时间学 k8s，等老系统淘汰了，再全换 k8s，一步一步来，稳。”
50 人以下公司选方案，看这张表
| 方案 | 适合情况 | 风险 | 省钱程度 | 老周推荐指数 |
|---|---|---|---|---|
| 彻底替换 | 新公司、没老系统 | 高（怕数据丢） | 高 | ★★★☆☆ |
| 集成起来 | 有老系统、想资源复用 | 中（怕网络不通） | 中 | ★★★★★ |
| 并行运行 | 老系统重要、没人手改代码 | 低 | 低 | ★★★☆☆ |
老周说：“50 人以下的公司，别学大公司搞‘一刀切’，集成和并行更实际。我们公司用集成方案，半年没出问题，新应用上线快了，老系统也没耽误事。”
小编的心里话
容器化不是 “非此即彼” 的选择题，中小公司更该讲究 “拿来主义”——OpenStack 好用的地方留着，k8s 能帮忙的地方加上。老周他们的教训是：别听 “必须换 k8s” 的瞎吹，也别信 “OpenStack 永远够用” 的固执，看自己公司的应用、团队、钱袋子选方案。
其实啊，我到现在也没完全搞懂，为啥有的公司集成方案里，k8s 调用 OpenStack 的存储会偶尔延迟，可能跟网络拓扑有关？但这不影响用，慢慢调总会好的。反正记住，技术是为业务服务的，不是用来秀的，对吧？
