OpenStack与Kubernetes：互补而非替代，私有云与容器编排的选型指南

1. 从两个部署现场说起：为什么这个话题总被反复提起

前阵子帮一个朋友看他们公司的私有云环境，机房里跑着一套五年前搭的 OpenStack，控制节点上各种服务状态灯红红绿绿，Nova 调度偶尔抽风，Cinder 卷挂载超时是家常便饭。运维小哥的原话是"能不动就不动，一动就出事"。同一周，另一个做 SaaS 的团队在群里晒他们的 K8s 集群，kubectl get nodes 一屏刷下来全是 Ready，滚动发布、自动扩缩容跑得飞起。这两个场景放在一起，就特别容易让人产生一种错觉：OpenStack 是不是已经被 Kubernetes 拍死在沙滩上了？

这个说法在技术圈流传了好几年，每次云原生大会、每次 K8s 发新版本，都会有人拿出来炒一遍。但如果你真的在两种环境里都干过活，就会发现事情远没有"谁取代谁"这么简单。OpenStack 和 Kubernetes 压根不是同一个层面的东西，把它们放在一起比"生死"，有点像拿"盖楼"和"装修"比谁更重要——听着热闹，逻辑上站不住。

我写这篇东西，不是想给谁翻案，也不是想唱衰谁。而是想把这两个东西到底解决什么问题、各自的能力边界在哪、什么场景该选谁、以及现在业界真实的使用姿势是什么，掰开揉碎讲清楚。如果你正在纠结公司的基础设施该往哪个方向走，或者单纯被"OpenStack 已死"这类标题搞得心里没底，那这篇内容应该能帮你把思路理顺。关键词里提到的 openstack安装、openstack云平台搭建、kubernetes 这些，我也会在对应章节里给出实操层面的参考。

2. 把两个东西放回它们各自的坐标系里

2.1 OpenStack 到底在管什么：从物理机到虚拟机的资源池化

要理解 OpenStack 的定位，得先回到它诞生的那个年代。2010 年前后，虚拟化技术已经成熟，VMware 在企业里卖得风生水起，但开源世界缺一个能跟它掰手腕的、能管理大规模虚拟机集群的平台。OpenStack 就是在这个背景下起来的，它的核心使命是：把一堆物理服务器抽象成一个统一的资源池，然后按需切出虚拟机、存储卷、网络给用户用。

拆开看，OpenStack 是一堆服务的集合，每个服务管一摊事：

• Nova：计算服务，负责虚拟机的生命周期管理，调度、创建、销毁都归它。
• Neutron：网络服务，管虚拟网络、子网、路由、安全组，SDN 那套东西基本都在这里。
• Cinder：块存储服务，给虚拟机提供持久化的云硬盘。
• Glance：镜像服务，存虚拟机镜像模板。
• Keystone：认证服务，所有组件的统一鉴权入口。
• Swift：对象存储服务，类似 S3 的定位。
• Horizon：Web 控制台，给运维和用户点的界面。

这套架构的特点是"重"。每个服务都是独立的进程，有自己的数据库、消息队列、API 端点。装一套最小可用的 OpenStack，控制节点上跑十几个服务是常态，再加上计算节点、存储节点、网络节点，一个像样的环境少说十几台机器。这也是为什么 openstack安装 一直是新手劝退的重灾区——光是搞明白各个服务之间的依赖关系，就够喝一壶的。

但它的能力也是实打实的。OpenStack 管的是 IaaS 层，也就是基础设施层。它能把裸金属、虚拟机、存储、网络这些底层资源统一编排起来，向上提供标准的 API。你在它上面可以跑任何东西：传统应用、数据库、大数据集群，当然也包括 Kubernetes。

2.2 Kubernetes 在管什么：从容器到应用的编排层

Kubernetes 的出身和 OpenStack 完全不同。它来自 Google 内部跑了十几年的 Borg 系统，2014 年开源，目标很明确：解决大规模容器化应用的部署、调度、扩缩容、自愈问题。

K8s 的核心抽象是 Pod、Service、Deployment、StatefulSet 这些。它不关心底层是物理机还是虚拟机，只要你能给它提供计算资源（Node），它就能把容器编排起来。它的调度单位是容器，粒度比虚拟机细得多，启动速度快、资源利用率高、弹性能力强。

K8s 的架构相对轻量：一个控制平面（API Server、Scheduler、Controller Manager、etcd），加上若干工作节点（Kubelet、Kube-proxy、容器运行时）。装一个单节点集群，用 kubeadm 十几分钟就能跑起来，这也是为什么 kubernetes 的入门门槛比 OpenStack 低得多。热词里那个 [init] using kubernetes version: v1.26.0 [preflight] running pre-flight chec 就是 kubeadm 初始化时的典型输出，跑过的人应该都眼熟。

但 K8s 管的是 PaaS 层偏下的部分，也就是应用编排层。它不负责给你变出物理机，不负责管理底层网络设备，不负责提供块存储（虽然可以通过 CSI 对接）。它假设你已经有了计算资源，它只负责在这些资源上把应用跑好。

2.3 一张表看清两者的能力边界

这张表想说明的核心就一句话：它们不在一个层面上，是互补关系，不是替代关系。说 OpenStack 被 K8s 取代，就像说"操作系统被数据库取代了"一样，逻辑上就不成立。

3. "OpenStack 已死"这个说法是怎么来的

3.1 早期 OpenStack 确实踩了一堆坑

这个说法不是空穴来风，OpenStack 早期确实问题一大堆，我列几个最典型的：

部署复杂度爆炸。早期没有成熟的自动化工具，装一套 OpenStack 要手动配几十个配置文件，每个服务的配置项动辄上百个。一个参数配错，整个环境起不来，而且报错信息往往指向不明。这也是为什么 openstack安装 成了无数人的噩梦。

升级路径痛苦。OpenStack 的版本迭代很快，但跨版本升级经常出问题。数据库 schema 变更、API 不兼容、配置项废弃，每次升级都像拆炸弹。很多团队装完一套就再也不敢动，导致环境越来越旧。

稳定性看运气。Nova 调度失败、Neutron 网络不通、Cinder 卷挂载超时，这些问题在老版本里很常见。运维团队大量时间花在救火上，而不是做有价值的事。

社区分裂。OpenStack 项目太多，各厂商各自为政，兼容性和一致性一直是个问题。

这些问题叠加起来，让很多团队对 OpenStack 产生了"又爱又恨"的复杂情绪。爱的是它确实能解决资源池化的问题，恨的是维护成本太高。

3.2 K8s 的崛起让对比变得刺眼

与此同时，K8s 在 2016 年之后迅速崛起，成为容器编排的事实标准。它的优势太明显了：部署简单、生态繁荣、社区活跃、迭代快。大量应用开始容器化，开发团队发现用 K8s 部署应用比在虚拟机上折腾爽太多了。

于是就有了这样的叙事：既然 K8s 这么好用，为什么还要 OpenStack？直接把应用跑在 K8s 上不就行了？这个叙事在互联网公司里特别有市场，因为他们的应用本来就是云原生的，对底层基础设施的定制需求不高。

但这里有个关键问题被忽略了：K8s 跑在哪？ 它总得跑在某种计算资源上。在公有云上，它跑在云厂商的虚拟机上；在私有环境里，它要么跑在裸金属上，要么跑在虚拟化平台上。而 OpenStack 恰恰就是提供这些底层资源的一种方式。

3.3 真实情况：OpenStack 没死，只是角色变了

看几个数据。OpenStack 基金会（现在叫 Open Infrastructure Foundation）的成员里，依然有大量电信运营商、金融企业、政府机构。这些用户的特点是：规模大、对自主可控要求高、需要管理异构资源。对他们来说，OpenStack 依然是私有云 IaaS 层的主流选择。

变化在于，OpenStack 的定位从"什么都管"变成了"专注管好底层资源"。以前它还想在 PaaS 层插一脚（比如 Solum、Murano 这些项目），后来发现干不过 K8s，就干脆放弃了，转而做好 IaaS 本分，同时主动拥抱 K8s——比如 Magnum 项目就是专门用来在 OpenStack 上快速拉起 K8s 集群的。

所以更准确的说法是：OpenStack 从舞台中央退到了幕后，但它没有死，只是不再站在聚光灯下。它成了很多 K8s 集群脚下的那块地基。

4. 两者真实的关系：不是对手，是上下游

4.1 K8s on OpenStack：最常见的组合姿势

在私有云场景里，K8s 跑在 OpenStack 上是最常见的组合。具体做法是：用 OpenStack 提供虚拟机，在虚拟机上部署 K8s 集群。这样做的好处是：

• 资源隔离：不同团队的 K8s 集群跑在不同的虚拟机上，互不干扰。
• 弹性伸缩：K8s 的节点不够了，可以通过 OpenStack API 动态创建虚拟机加入集群。
• 统一管理：底层资源由 OpenStack 统一纳管，运维团队不用维护两套体系。

OpenStack 的 Magnum 项目就是干这个的，它能一键创建 K8s 集群，自动处理虚拟机创建、网络配置、节点加入这些琐事。虽然 Magnum 的普及度不算特别高，但它代表了一个明确的方向：OpenStack 主动为 K8s 服务。

实操层面，如果你要在 OpenStack 上手动搭 K8s，大致流程是：

1. 在 OpenStack 里创建若干虚拟机作为 K8s 节点，配置好安全组和网络。
2. 在所有节点上安装容器运行时（containerd 或 CRI-O）。
3. 用 kubeadm 初始化控制平面节点，注意 --apiserver-advertise-address 要指向虚拟机的内网 IP。
4. 其他节点用 kubeadm join 加入集群。
5. 安装 CNI 插件（Calico、Flannel 等）和 CSI 插件（对接 Cinder 块存储）。

这里有个坑要注意：OpenStack 的安全组默认可能不允许 K8s 需要的端口（比如 6443、10250、2379 等），得提前放行，否则 join 的时候会卡住。

4.2 OpenStack 作为 K8s 的存储和网络后端

K8s 本身不提供持久化存储和复杂网络，它通过 CSI 和 CNI 接口对接外部系统。OpenStack 的 Cinder 和 Neutron 正好可以填补这两个空缺：

• Cinder CSI：让 K8s 的 PVC 直接对接 Cinder 卷，Pod 挂载的持久化存储实际落在 Cinder 上。
• Neutron CNI：让 K8s 的 Pod 网络直接跑在 Neutron 上，复用 OpenStack 的网络能力。

这种深度集成的做法在电信行业特别常见，因为电信网络对网络功能有特殊要求，需要底层网络可编程、可定制，Neutron 的 SDN 能力正好派上用场。

4.3 反过来：K8s 也在"吃掉"一部分 OpenStack 的活

公平地说，K8s 确实在蚕食 OpenStack 的一部分场景。比如：

• 轻量级私有云：如果需求只是"跑几个容器化应用"，那直接上 K8s 就够了，没必要搞一套 OpenStack。
• 边缘计算：边缘节点资源有限，跑不动 OpenStack 那套重家伙，K8s 的轻量发行版（K3s、MicroK8s）更合适。
• CI/CD 环境：临时性的构建、测试环境，用 K8s 动态创建 Pod 比创建虚拟机快得多。

所以真实图景是：在重资产、大规模、需要管理异构资源的场景，OpenStack 依然是底座；在轻量、敏捷、云原生的场景，K8s 直接上阵。两者各守各的地盘，同时在中间地带有所重叠。

5. 选型决策：什么场景该用谁

5.1 先问自己三个问题

选型不是比谁技术先进，而是看谁更匹配需求。我一般会先问三个问题：

第一，你要管的是物理资源还是应用？ 如果你需要把一堆物理服务器池化，按需分配虚拟机、存储、网络，那 OpenStack 是对的工具。如果你已经有计算资源了，只是想把应用跑好，那 K8s 更合适。

第二，你的团队擅长什么？ OpenStack 对运维团队的要求很高，需要懂 Linux、网络、存储、虚拟化。K8s 对开发和 DevOps 团队更友好，但要做好也需要一定的学习成本。团队能力是选型的重要约束。

第三，你的规模有多大？ 几台机器的环境，上 K8s 就够了，OpenStack 的复杂度不划算。上百台以上的物理机，需要统一资源管理，OpenStack 的价值就体现出来了。

5.2 典型场景对照

5.3 一个容易被忽略的点：混合场景才是常态

现实中很少有"纯 OpenStack"或"纯 K8s"的环境。更常见的是混合：底层用 OpenStack 管资源，上层用 K8s 跑应用，中间通过 API 打通。这种架构的好处是各取所长，坏处是运维复杂度高，需要团队同时具备两方面的能力。

我的建议是：如果团队规模允许，尽量把两层分开，让专门的团队各管一摊。基础设施团队管 OpenStack，应用团队管 K8s，中间定义清晰的接口。这样职责清晰，出问题也好定位。

6. 实操层面的几个关键细节

6.1 OpenStack 部署：别一上来就追求生产级

很多人第一次搞 openstack云平台搭建，上来就想搭一套高可用的生产环境，结果卡在第一步。我的建议是分阶段来：

第一阶段：单节点 all-in-one。用 DevStack 或者 Kolla-Ansible 的 all-in-one 模式，在一台机器上把所有服务跑起来。目的是熟悉各个组件、理解它们之间的关系。这个阶段不用考虑性能和高可用，能跑通就行。

第二阶段：最小多节点。一台控制节点、一台计算节点、一台存储节点。开始接触真实的分布式部署，理解服务之间的网络通信、数据库共享、消息队列这些。

第三阶段：生产级高可用。控制节点做集群，数据库做主从，消息队列做集群，存储做副本。这个阶段才是真正考验运维能力的地方。

跳过前两个阶段直接上第三个，基本等于自找苦吃。

6.2 K8s 部署：kubeadm 的坑集中在网络和证书

kubernetes 部署现在主流用 kubeadm，流程本身不复杂，但坑集中在两个地方：

网络。kubeadm init 的时候要指定 --pod-network-cidr，这个网段不能和宿主机网段冲突，也不能和 Service 网段冲突。很多人在这里翻车，导致 Pod 起不来。另外 CNI 插件的选择也要注意，Calico 功能强但配置复杂，Flannel 简单但功能少，按需选。

证书。K8s 集群的证书默认一年过期，到期后集群直接不可用。生产环境一定要提前规划证书轮换，或者用支持自动轮换的方案。我见过太多团队因为证书过期导致集群挂掉，半夜爬起来救火。

热词里那个 [preflight] running pre-flight chec 是 kubeadm 的前置检查，如果这一步报错，通常是系统配置问题，比如 swap 没关、防火墙没配、端口被占用。按提示逐个解决就行。

6.3 两者集成时的网络规划

OpenStack 和 K8s 集成时，网络规划是最容易出问题的地方。核心是要理清几层网络：

• 物理网络：宿主机之间的网络，OpenStack 的 management、storage、tenant 网络都跑在这上面。
• OpenStack 虚拟网络：Neutron 管理的租户网络，虚拟机之间的通信。
• K8s Pod 网络：容器之间的通信，通常由 CNI 插件管理。
• K8s Service 网络：虚拟 IP 段，用于服务发现和负载均衡。

这四层网络如果规划不好，会出现网段冲突、路由不通、性能瓶颈等问题。我的经验是：提前画一张网络拓扑图，把每层网络的网段、网关、路由规则都标清楚，再动手部署。

7. 我踩过的坑和几条实在建议

7.1 OpenStack 升级：能不动就不动，要动就做好回滚

OpenStack 跨版本升级是我见过最容易出事的操作。数据库 schema 变更、配置项废弃、API 不兼容，任何一个环节出问题都可能导致环境起不来。我的建议是：

• 升级前一定要在测试环境完整演练一遍，记录每一步的操作和结果。
• 数据库和配置文件必须备份，而且要验证备份可恢复。
• 升级过程中保持耐心，不要跳步骤，每个服务升级完都要验证。
• 准备好回滚方案，一旦出问题能快速切回旧版本。

如果环境稳定运行，没有必须升级的理由，那就别动。这不是懒，是理性。

7.2 K8s 版本迭代快，但别盲目追新

K8s 每四个月发一个大版本，每个版本支持一年。很多人喜欢追最新版，但生产环境我建议用次新版本，等社区踩完坑再上。另外要注意 API 的废弃策略，有些资源在旧版本能用，新版本就删了，升级前一定要检查。

7.3 团队能力比技术选型更重要

我见过用 OpenStack 跑得很稳的团队，也见过用 K8s 天天出事的团队。技术本身没有绝对的好坏，关键看团队能不能驾驭。选型的时候，一定要评估团队的实际能力，别被技术光环迷惑。

7.4 别被"XX 已死"的标题带节奏

技术圈特别喜欢用"已死""取代""颠覆"这类词，因为吸引眼球。但真实世界的技术演进是渐进的，很少有你死我活的替代。OpenStack 和 K8s 的关系就是典型例子：它们各自解决不同的问题，在很长一段时间内会共存。与其纠结谁取代谁，不如想清楚自己的需求，选对工具，把活干好。

8. 回到那个标题：浪潮之巅上站着的到底是谁

"OpenStack 死于沙滩，Kubernetes 登顶浪潮之巅"这个标题，情绪价值拉满，但技术判断是偷懒的。它把两个不同层面的东西强行拉到一起比高低，忽略了它们各自的定位和价值。

真实的情况是：K8s 确实站在了应用编排层的浪潮之巅，这一点没有争议。但 OpenStack 并没有死在沙滩上，它只是从台前退到了幕后，成了很多 K8s 集群脚下的地基。在电信、金融、政务这些需要大规模资源池化和自主可控的场景里，OpenStack 依然是不可替代的。

如果你正在做技术选型，我的建议是：先搞清楚自己要解决什么问题，再去看哪个工具匹配。别被标题党带偏，也别盲目追新。技术是为业务服务的，能解决问题的就是好技术。

最后分享一个我自己的判断标准：看一个技术是不是真的"死了"，就看还有没有人在生产环境用它、还有没有人在给它贡献代码、还有没有厂商在基于它做商业产品。按这三条标准，OpenStack 离"死"还远得很。它只是不再年轻气盛，变成了一个成熟稳重的中年人——不那么性感，但很可靠。