OpenStack云平台部署实战：从架构规划到Kolla-Ansible自动化落地

1. 部署之前的“灵魂拷问”：OpenStack到底值不值得自己搭

干了这么多年云计算运维，经常有人问我：“OpenStack是不是已经过时了？现在K8s不是更火吗？为什么还要学OpenStack？”

我的答案一直是：OpenStack没有死，它只是换了一种存在方式。K8s解决的是容器编排问题，OpenStack解决的是基础设施资源池化问题。企业内部私有云、运营商网络云化、科研机构高性能计算平台，这些场景大量跑在OpenStack之上。甚至很多K8s集群本身就构建在OpenStack提供的虚拟机之上。你会K8s不懂底层IaaS，就像会做饭但不认识买菜一样，卡在某一层上不去。

这篇博文我把OpenStack云计算部署的完整路径拆开讲一遍，从架构规划到环境准备，从部署工具选型到网络配置，再到验证测试和问题排查，每一步都给出我实际跑过的结论。适合刚接触OpenStack的运维工程师、准备做私有云立项的技术负责人，以及那些“文档看了不少、动手就废”的实操型学习者。

先说结论：全手动部署OpenStack不是不能做，但那是给“想彻底搞懂原理”的人准备的修行之路。如果你是为了交付一个可用的私有云环境，或者是为了在公司里快速搭建一套测试平台，用Kolla-Ansible这类自动化部署工具是更理性的选择。为什么这么说？后面我会详细讲。

2. 部署方案选型与技术架构拆解

2.1 三种主流的OpenStack部署路径

我接触过的OpenStack部署方案主要分成三类：纯手动部署、脚本半自动化部署、容器化自动化部署。

纯手动部署就是按照官方文档一步一步敲命令、改配置文件、启动服务、做认证。这条路我当年走过一遍完整的——从Keystone开始，到Nova、Neutron、Glance、Cinder，一步步敲下来用了整整一周。好处是对组件的耦合关系理解非常深刻，坏处是效率太低、极易出错，而且每个组件版本之间都有各种兼容性暗坑。如果你主要目的是“搞懂原理”，可以走这条路；但如果你是为了交付项目，手动部署的效率完全跟不上。

脚本半自动化部署的代表是DevStack，它是OpenStack官方提供的开发测试工具，一条命令就能拉起一套all-in-one环境。DevStack确实快，但它不是为生产设计的，跑出来的环境网络配置、安全策略都是开发模式，适合功能验证和学习。还有一个叫PackStack的项目，Red Hat系产品里用得比较多，它帮你在多节点上批量安装组件，但它绑定的操作系统版本和发行版生态比较死，灵活度一般。

容器化自动化部署是目前我推荐的主流方式，代表就是Kolla-Ansible。它的核心思路非常优雅：把OpenStack的每一个服务组件都构建成Docker容器镜像，然后通过Ansible playbook在目标节点上批量编排部署这些容器。这样交付出去的OpenStack环境，底层是统一版本的容器镜像，升级、回滚、扩展都变得异常干净。

Kolla-Ansible还有两个关键变体：Kolla和Kolla-K8s。前者就是纯Docker容器化部署，后者是把OpenStack跑在Kubernetes之上。我的经验是Kolla-K8s目前在生产环境里的普及度还不高，多数团队还是选择Kolla-Ansible直接部署Docker容器，运维链路更短，排障也更直接。

2.2 节点角色与资源规划

部署OpenStack之前，第一件事是设计好节点角色。一个标准的生产最小集群至少需要三类节点：

控制节点（Controller）运行管理面服务，包括Keystone、Nova API、Neutron Server、Glance API、Cinder API、Horizon面板，以及消息队列RabbitMQ和数据库MariaDB。控制节点是整个云平台的大脑，对CPU和内存要求最高，尤其是数据库和消息队列的并发处理能力直接决定整个平台的稳定性。

计算节点（Compute）运行Nova-Compute服务和虚拟化层。这是真正加载云主机实例的地方。KVM是我最常用的Hypervisor，计算节点需要开启CPU硬件虚拟化（VT-x/AMD-V），内存资源也要留够，因为所有云主机的内存都是从这里分配的。

网络节点（Network）在传统L3 networking架构中负责路由、DHCP、浮动IP等网络功能。不过在新版本里，OpenStack已经支持了DVR（分布式虚拟路由），网络功能可以分散到计算节点上，网络节点就可以作为可选角色了。测试环境里我经常把控制节点和网络节点合在一起部署，生产环境还是建议分开。

存储节点不是必选，但建议单独规划。Cinder块存储服务需要独立的存储节点，或者对接已有的分布式存储系统。如果预算有限，也可以先用计算节点的本地存储，但这样会失去迁移和高可用能力，生产环境慎用。

资源规划方面我给出一个参考基准：三节点最小集群（一个控制节点、两个计算节点），控制节点建议8核16GB起步，计算节点根据业务需求规划，至少也要16核32GB起步。磁盘方面，控制节点系统盘100GB以上，计算节点根据云主机总量规划存储容量。这套配置支撑一个小团队几十台测试虚拟机问题不大。如果是生产环境或者规模更大，就需要单独规划网络节点、存储节点，控制节点也要做高可用。

2.3 网络架构的核心设计考量

Op