做云平台运维的老郑最近愁坏了：公司既有跑在 OpenStack 上的虚拟机，又有 k8s 管理的容器，两边各管各的，资源浪费不说，数据互通还特别麻烦。想把它们打通，试了几次都没成功，要么是网络连不上，要么是存储不同步，急得他天天加班。其实啊，OpenStack 和 k8s 不是非此即彼的关系，完全能一起用，搭个混合云环境，虚拟机和容器各司其职，效率能翻倍。今天就把混合云协同方案、实操步骤讲清楚，附一个电商公司的迁移数据案例，老郑按这方法操作后，资源利用率提了 30%，一起往下看吧！
先明白：为啥要让 OpenStack 和 k8s 一起用？
其实啊，OpenStack 就像 “重型卡车”，适合拉虚拟机这种 “大件货物”，稳定能装；k8s 像 “轻型货车”，擅长运容器这种 “小件包裹”，灵活快速。两者一起用，就像组建了一个物流车队，啥货都能运，还不浪费运力。
老郑公司以前分开用时，问题特别多：
- OpenStack 的虚拟机占着 80% 的资源，实际只用了 30%，空着可惜；
- k8s 的容器想扩容，却没多余资源，得新买服务器；
- 虚拟机里的数据库，容器里的应用想调数据，要绕好几个弯，延迟高得离谱。
后来打通之后，这些问题全解决了。做电商的小宋公司也是这么干的，他们用 OpenStack 存订单数据（虚拟机稳当），k8s 跑前端应用（容器扩缩容快），大促时资源互相调剂，比以前省了 20% 的服务器成本。
混合云协同方案：让两者各司其职，又能互相帮忙
（1）基础架构：OpenStack 打底，k8s 往上跑
简单说就是让 OpenStack 提供 “地基”—— 计算、存储、网络这些基础资源，k8s 在上面 “盖房子”—— 管理容器化应用。具体怎么搭：
- OpenStack 这边，用 Nova 组件建虚拟机，Cinder 管存储，Neutron 配网络，确保基础资源稳定；
- 在 OpenStack 的虚拟机里装 k8s，把虚拟机当 k8s 的节点，这样 k8s 就能用 OpenStack 的资源了；
- 关键是打通网络：让 k8s 的容器能访问 OpenStack 的虚拟机 IP，老郑用了 OpenStack 的 Neutron 和 k8s 的 Calico 插件，设置好路由，两边 ping 通的那一刻，他说 “比中奖还高兴”。
（2）资源调度：让闲置资源动起来
老郑公司以前 OpenStack 的虚拟机白天满负荷，晚上空一半；k8s 则相反，晚上跑任务需要大量资源。协同之后：
- 用开源工具 Magnum（OpenStack 的容器服务），让 k8s 能直接调用 OpenStack 的闲置虚拟机资源；
- 设置自动调度规则：当 k8s 资源不够时，自动在 OpenStack 上新建虚拟机当 k8s 节点；OpenStack 资源紧张时，把 k8s 里闲置的容器缩容，释放资源。
小宋公司用这招，大促前 k8s 自动从 OpenStack 调用了 3 台闲置虚拟机，订单处理速度快了 40%，还没多花钱。
实操步骤：分 5 步，从打通到协同
（1）先给 OpenStack 装 “容器插件”
老郑用的是 OpenStack Queens 版本，步骤：
- 登录 OpenStack 控制节点，用 yum 装 Magnum 和相关组件：
sudo yum install openstack-magnum* - 配置 Magnum 连接 k8s 的参数，改配置文件
/etc/magnum/magnum.conf，填好 k8s 的 API 地址 - 重启 Magnum 服务：
sudo systemctl restart openstack-magnum-api，这一步老郑忘做了，折腾了俩小时才发现
（2）在 OpenStack 里建 k8s 集群
- 用 OpenStack 的命令行创建集群模板：
openstack coe cluster template create k8s-template --image k8s-image --external-network public（k8s-image 是提前准备好的 k8s 镜像） - 基于模板建集群：
openstack coe cluster create my-k8s-cluster --cluster-template k8s-template --node-count 2，等 10 分钟左右，集群就建好了 - 查集群状态：
openstack coe cluster show my-k8s-cluster，显示 “CREATE_COMPLETE” 就成了
（3）打通存储：让两边数据能互访
- 在 OpenStack 上用 Cinder 建一个共享卷：
openstack volume create --size 50 shared-vol（50G 大小） - 在 k8s 里创建 PersistentVolume，关联这个共享卷，yaml 配置文件里指定 volumeID 和 OpenStack 的认证信息
- 老郑在 k8s 的应用里挂载这个共享卷，测试往里面写文件，然后在 OpenStack 的虚拟机里读，能读到的那一刻，他拍了张照发了朋友圈
（4）设置网络互通
- 在 OpenStack 的 Neutron 里建一个专用网络，比如叫 “k8s-network”，配好子网和网关
- 在 k8s 的 calico.yaml 里，把 OpenStack 的子网段加进允许列表
- 用
kubectl apply -f calico.yaml更新 k8s 网络，再用ping命令测试 k8s 容器到 OpenStack 虚拟机的连通性，通了就成
（5）最后配自动调度规则
老郑用的是 Prometheus+Alertmanager 监控，步骤：
- 在 Prometheus 里配置监控指标：OpenStack 的虚拟机利用率、k8s 的 Pod 数量
- 设阈值：当 k8s 的 PodPending 数量超过 5 个，触发 Alertmanager 调用 OpenStack 的 API 新建节点
- 测试：手动在 k8s 里创建 10 个大 Pod，过了 3 分钟，OpenStack 自动加了 2 个节点，完美
迁移数据案例：电商公司 3 天完成，零停机
小宋公司以前把用户数据存在 OpenStack 的虚拟机里，想让 k8s 的推荐系统用上这些数据，迁移步骤：
- 先在 OpenStack 的虚拟机上装 NFS 服务，把数据目录共享出来
- 在 k8s 里创建 NFS 类型的 PersistentVolume，挂载 OpenStack 的共享目录，测试读数据没问题
- 写个小脚本，把增量数据实时同步到 k8s 的存储里，老数据用 rsync 迁移，花了 8 小时
- 切换推荐系统的数据源，从 k8s 的存储读，观察了 24 小时，没出任何问题
- 最后把 OpenStack 虚拟机里的旧数据备份，删除冗余文件
迁移后效果：
- 数据访问延迟从 150ms 降到 40ms
- 推荐系统响应速度快了 30%，用户点击率提升 12%
- 小宋说：“以前调一次数据要跑 3 个脚本，现在直接读，省了多少事！”
小编的心里话
OpenStack 和 k8s 一起用，就像给云平台装了 “双引擎”，虚拟机的稳和容器的灵结合起来，资源利用率高了，数据通了，运维也省事儿。老郑和小宋的经验证明，只要步骤对，小公司也能搞定。
刚开始可能会遇到各种报错，老郑说他光网络打通就试了 5 种方法，千万别急。建议先在测试环境练手，用最小化集群试通了再上生产。其实啊，技术这东西，不怕复杂，就怕不敢试，你说对吧？
