搭建OpenStack云平台这事，听着像是只有大厂运维才碰的东西，实际上我身边不少做虚拟化、做K8s底层支撑的同行，都在自己折腾这套。原因也很简单：公有云虽然省事，但数据面、网络面、计费面都捏在别人手里，想要完全可控的私有云，OpenStack几乎是目前唯一一个既有社区活跃度、又有生产验证的开源选择。

这篇文章把我从规划、部署到排错全流程的经验拆开写出来。不绕弯子，先从最关键的架构决策讲起，再一步步给你能直接抄作业的命令和配置，最后把我踩过的坑、排查过的故障一并交代清楚。无论你是刚接触OpenStack的新手，还是被分配了搭建任务的运维开发，这套流程应该都能帮你少走很多弯路。

1. 为什么要自己搭一套OpenStack，而不是直接用现成云

1.1 私有云的真实需求

先说一个很多人没想明白的问题：你到底是需要“一朵云”，还是只需要“几台虚拟机”？如果是后者，装个KVM、装个Proxmox VE就够了，完全没必要上OpenStack。OpenStack的价值在于它把计算、存储、网络这三块资源做成了统一的、可调度的、有租户隔离的云平台。

我做过的模拟项目X就是这样：业务方要求为内部多个团队提供按需申请的计算资源，每个团队要有独立的网络隔离、独立的账号权限、独立的镜像管理，还要能通过自助界面申请资源。这种需求用单机虚拟化根本撑不起来，必须有一个带认证、带配额、带网络的云管平台。OpenStack恰好就是解决这一类问题的。

当然，选择OpenStack也意味着接受它的复杂度。组件多、服务多、概念多，任何一个环节配错都可能导致整个系统不可用。这也是为什么我建议第一次搭建时，不要追求生产级的高可用，先把核心组件跑通，理解了服务之间的依赖关系，再考虑扩展。

1.2 裸机虚拟化、K8s和OpenStack的区别

很多刚接触云计算的人会把OpenStack和Kubernetes混为一谈，其实两者的定位完全不同。

K8s管的是容器，OpenStack管的是虚拟机（也可以管裸机，但那是Ironic组件的事）。K8s的调度对象是Pod，OpenStack的调度对象是实例。K8s本身不关心底层的计算资源是怎么来的，而OpenStack正好负责把计算资源池化、虚拟化、网络化。实际生产环境里，完全可以用OpenStack作为IaaS层，在它上面再部署K8s集群，这样K8s的节点可以按需扩容，底层资源由OpenStack统一调度。

我见过一个挺典型的场景：某公司原本直接用物理机部署K8s，扩容一次要采购硬件、人工装机、配置网络，周期动辄两周。后来改成OpenStack提供虚拟机作为K8s节点，扩容时间缩短到分钟级，而且节点规格可以通过flavor灵活调整，资源利用率明显提升。

1.3 先想清楚这几件事再动手

动手之前，有几个问题必须先有答案，否则搭建过程中很容易反复返工。

第一，网络方案。Neutron支持Flat、VLAN、VXLAN等多种模式，选择哪种直接影响物理交换机的配置、IP地址规划、租户网络的隔离方式。我建议第一次搭建用VLAN模式，兼容性好，排查问题也比VXLAN简单。

第二，存储方案。如果只是测试环境，用本地磁盘加LVM就够了，不需要单独部署Cinder。如果涉及块存储服务，就要考虑后端存储怎么接，是Ceph还是NFS还是其他商业存储，这会显著影响架构复杂度。

第三，版本和部署工具。OpenStack每半年左右发一个版本，社区推荐的部署工具也在变化，选型时需要确认是手动部署还是自动化部署，这决定了后续的工程量和维护成本。

2. 环境规划与版本选型：决定后续是否踩坑

2.1 节点规划与硬件建议

一套最精简的OpenStack环境至少需要两个节点：一个控制节点，一个计算节点。控制节点承载认证、镜像、调度、网络管理等服务，计算节点负责运行虚拟机实例。

实际搭建时，我给模拟项目X分配的节点方案如下：

如果你只有一台物理服务器，也可以把控制节点和计算节点放在同一台机器上，但这种单节点模式只适合学习验证，不适合运行真实业务。

2.2 网络方案怎么选

网络是OpenStack里最复杂也最容易出问题的部分。我把常见三种模式的特点整理成了一张表：

我个人的建议是，第一次搭建用VLAN模式，将物理网卡划分出管理网、数据网和外部网。管理网用于服务之间的通信，数据网承载虚拟机流量，外部网用于访问云主机。三个网络尽量用不同网段和不同物理网卡，避免流量互相干扰。

2.3 版本和部署工具的选型逻辑

OpenStack的版本代号从字母A到Z按字母表命名，每个字母对应一个版本。我搭建时用的是Yoga版本，算是比较稳定可靠的一个版本，不同发行版自带的OpenStack包版本不同，需要先确认发行版软件源里提供的版本。

部署工具方面，有几种选择：

一是纯手动部署，按照官方文档逐个安装配置服务。这种方式最能帮助你理解各个组件的原理，但工作量大，容易出错，适合学习场景。

二是使用RDO或PackStack，这是基于某个Linux发行版的OpenStack部署工具，可以用一条命令搭建基础环境，适合快速验证。

三是以Kolla-Ansible为代表的容器化部署方案，把OpenStack服务打包成容器，配合Ansible自动化编排。这种方式是目前生产环境的主流选择，升级回滚方便，部署一致性好。

我在正式交付给某公司做内部培训时，用的就是Kolla-Ansible方案。但如果你希望把OpenStack的内部机制彻底搞懂，我建议至少手动部署一次核心组件，这个认知价值无法替代。

提示：无论选择哪种部署方式，都建议先在虚拟机里做一遍完整的演练。不要在物理机上一上来就跑全程，OpenStack部署过程中的各种网络配置、依赖冲突、服务启动失败，在小规模实验环境里更容易定位问题。

3. 基础环境配置：系统、网络与依赖

3.1 操作系统与基础服务

OpenStack对操作系统要求不低，但核心原则就是使用长期支持版本，避免新版本软件源不稳定。我搭建时用的是基于Linux内核的主流服务器发行版LTS版本，这类系统社区支持时间长、软件包齐全、遇到问题容易搜到答案。

系统装好之后，第一件事就是配置主机名和hosts文件。三个节点的主机名我规划为controller、compute1，在/etc/hosts中把节点IP和主机名的对应关系写清楚。这一步看似简单，但很多服务之间是通过主机名通信的，如果hosts配置错误，后面会出现各种诡异的认证失败和服务连接超时。

然后创建一个专用的系统用户，用于执行OpenStack相关操作。生产实践中不建议直接用root操作，因为OpenStack的配置文件、日志文件、虚拟化操作都有独立的权限体系，单独的用户便于管理和审计。

3.2 网卡和桥接配置实操

以控制节点为例，通常需要至少两块网卡：一块用于管理网络，一块用于外部网络。在配置网络之前，先确认物理网卡的名称，然后编辑网络配置文件。

管理网卡的配置比较简单，设置静态IP即可。外部网卡需要配置为桥接模式，因为在OpenStack里，外部网络是通过网桥与物理网络连接的。我用一个例子来说明：

cat /etc/network/interfaces.d/br-ex.cfg

auto br-ex iface br-ex inet static address 192.168.68.20 netmask 255.255.255.0 gateway 192.168.68.1 dns-nameservers 192.168.68.1

这段配置的含义是创建一个名为br-ex的Linux网桥，给它配置静态IP地址。物理网卡上不配置IP，而是把它加入网桥。这样虚拟机通过网桥就能访问外部网络，配置思路跟家用路由器里的“桥接模式”是一个道理。

配置完成后一定要重启网络服务并验证连通性，我在早期搭建时经常遇到网卡配置冲突导致SSH断开的问题，所以强烈建议在本地控制台或带外管理界面操作网络配置，避免把自己锁在外面。

3.3 时钟同步与软件源

OpenStack的认证服务高度依赖精确时间，时间偏差超过几分钟就可能导致令牌校验失败。NTP是必须配置的，控制节点同步外部时间源，计算节点同步控制节点。

chronyc sources -v

配置完成后用这条命令检查时间同步状态。如果输出显示时间源处于活跃状态，说明同步正常；如果显示^*或*符号，说明已锁定到时间源。

软件源也建议提前配置，因为OpenStack组件依赖大量其他软件包，默认软件源下载速度慢或者缺少必要包会导致安装中断。我记得有一次安装网络服务时，因为依赖包版本冲突，整整花了一个下午排查，最后发现是软件源里的包版本和OpenStack版本不匹配。

4. 核心组件部署：从认证到计算

4.1 先搭认证服务Keystone

Keystone是OpenStack所有服务的“门卫”，其他所有组件在调用API之前，都要先经过认证和权限校验。所以搭建顺序必须是先创建Keystone，再创建后续服务，否则后续组件创建用户和端点时会失败。

创建Keystone的数据库、服务凭证和API端点，都需要设置统一的认证信息。我习惯用一个环境变量文件统一管理这些信息，每次操作前先加载：

export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=你的强密码 export OS_AUTH_URL=http://controller:5000 export OS_IDENTITY_API_VERSION=3

这个环境变量文件在实际操作中非常重要。日志排查时，如果API请求返回401，八成就是环境变量里的密码或项目名写错了。我建议把这套环境变量放在/root/openrc这样的独立文件里，每次需要执行OpenStack命令就先source一下。

4.2 镜像服务Glance与镜像上传

Glance负责管理虚拟机镜像，可以理解成云主机模板的仓库。安装好Glance之后，必须上传一个至少可用的系统镜像，后续创建云主机才有模板可用。

挑选镜像时，我建议用官方提供的云镜像，这类镜像预装了cloud-init工具，能够自动完成主机名配置、SSH密钥注入、分区扩容等初始化操作。上传命令：

openstack image create --disk-format qcow2 --container-format bare \ --public --file ubuntu-server.qcow2 ubuntu-server

qcow2是镜像格式，bare表示容器格式为裸镜像，这两个参数是镜像服务要求的必填项。--public参数表示所有项目都能使用这个镜像，如果不想让租户看到，可以改成--private。

上传完成后用openstack image list确认镜像状态是active。我遇到过一次镜像状态一直卡在queued的情况，后来发现是控制节点磁盘空间不足，Glance无法把镜像文件完整写入存储目录。

4.3 计算服务Nova的控制与计算节点

Nova是OpenStack的计算核心，分为控制节点的Nova API、调度器和计算节点上的Nova Compute。控制节点负责接收创建虚拟机的请求，计算节点负责真正通过KVM或QEMU启动虚拟机。

配置Nova之前必须先注册Placement服务，这是负责资源跟踪的组件。Placement的作用相当于一个资源台账，记录每个计算节点剩余多少CPU、多少内存，Nova调度器在收到创建请求后，会根据Placement提供的数据决定把VM调度到哪台物理机上。

我第一次部署时漏掉了Placement，导致虚拟机创建一直报“No valid host was found”，日志里全是调度失败的报错。后来把Placement的数据库和服务注册补齐，问题马上解决了。

4.4 网络服务Neutron的配置要点

Neutron配置是整个部署过程中最讲究的部分，因为它涉及很多网络概念：网络、子网、路由、端口、安全组、DHCP代理、Open vSwitch网桥等。配置时有两个点最容易被忽略。

第一，Neutron的认证配置必须和Keystone保持一致。很多人在配置Neutron时只改了数据库连接、改了口令，却漏了认证类型和API版本，结果Neutron服务启动后无法和Keystone正常通信，所有网络创建请求都返回认证失败。

第二，DHCP代理和L3代理要确保在正确节点上启动。控制节点上需要启动neutron-dhcp-agent为租户网络分配IP地址，启动neutron-l3-agent管理虚拟路由器的NAT和南北向流量。这两个代理服务如果没起来，创建网络不会报错，但创建出来的虚拟机获取不到IP地址，这是非常常见的问题。

我习惯在配置完成后用如下命令检查代理状态：

openstack network agent list

输出中每个代理的状态都应为Alive。如果出现xxx not running的字段，就需要回到对应节点查看服务日志。

5. 验证与第一台云主机的诞生

5.1 命令行验证所有服务

核心组件全部装完之后，先不要急着在界面上操作，用命令行把所有服务状态过一遍。我总结了一套快速验证流程：

openstack service list openstack endpoint list openstack image list openstack compute service list openstack network agent list

这几条命令分别验证服务目录、API端点、镜像状态、计算节点的服务状态、网络代理状态。如果有任何一项输出异常，都应该先排查清楚再继续，否则后续创建云主机时会把问题复杂化。

5.2 创建网络、路由与云主机

现在到了最激动人心的环节——创建第一台云主机。

先创建租户网络。假如规划用一个192.168.100.0/24网段给云主机分配地址：

openstack network create demo-net openstack subnet create demo-subnet \ --network demo-net \ --subnet-range 192.168.100.0/24 \ --dhcp

为了访问外部网络，还需要创建路由连接外部网络。这一步相当于给云主机加了一个默认网关，没有路由的话云主机只能在租户网络内部互通，无法访问外部。

创建云主机的命令：

openstack server create --flavor m1.small --image ubuntu-server \ --network demo-net --key-name mykey my-first-instance

其中m1.small是定义好的规格模板，包含虚拟机的CPU、内存、磁盘大小，需要提前用openstack flavor create创建。--key-name指定SSH密钥，如果没有配置密钥，创建后只能通过VNC控制台或密码登录，这在自动化和后续运维中不太方便。

创建完成后用openstack server list查看状态，当状态变为ACTIVE，说明云主机已经成功启动。

5.3 通过Horizon可视化操作

命令行之外，OpenStack还提供了Horizon仪表盘。虽然不是核心组件，但装上它对日常使用和排错都很有帮助。Horizon装好之后，用浏览器访问控制节点的IP地址，输入之前创建的账号密码，就能在图形界面里创建实例、管理网络、查看控制台日志、调整安全组规则。

我个人认为，Horizon更适合给业务方当自助门户，而运维排障时还是命令行更快更直接。业务方不需要懂OpenStack概念，只需要在界面上点击申请资源；运维人员则应当熟练命令行，因为很多底层错误信息只会在API日志里出现，界面上根本看不到。

6. 常见问题与排查实录

6.1 实例无法获取IP

这是我遇到过最多的故障，几乎每次都会有人来问。云主机创建成功，状态是ACTIVE，但进到系统里发现网卡没有IP地址。

排查路径按顺序来：先看Neutron代理是否存活，再看DHCP命名空间是否创建成功，然后查看DHCP租约数据库中是否有IP分配记录。这三个环节任何一个中断，都会导致IP获取失败。

我做过一次印象很深的排障：所有代理都正常，DHCP租约也有记录，但虚拟机就是拿不到IP。后来查了半天，发现是物理节点iptables规则把DHCP请求的UDP 67端口拦掉了。解决方式是确认OpenStack所需的防火墙端口全部放行，同时检查宿主机自身的iptables规则是否干扰了虚拟机的DHCP流量。

6.2 云主机创建失败与日志定位

云主机创建失败的表现通常有两种：同步等待的时候状态卡住，或直接报错说没有可用主机。

遇到这类问题，我的第一反应是看Nova调度器和计算节点的日志，因为创建VM的主要工作都在这两个节点上。日志路径是/var/log/nova/，重点看nova-compute.log和nova-scheduler.log。

我整理过一份常见问题速查表：

定位问题时，不要只看表面报错，要顺着日志里的时间戳和请求ID一层层往上翻。Nova组件之间的调用都有请求ID，根据这个ID可以在各个服务日志中串联出一条完整的调用链。

6.3 服务状态异常的排查路径

当某个服务启动失败或状态异常时，我有一套固定的排查顺序：

第一步确认服务进程是否存在，systemctl status查看。第二步查看对应的日志文件，通常位于/var/log/对应服务目录下。第三步检查配置文件的语法和权限，很多服务配置错误只是启动时报错，但日志写的比较模糊，需要手动核对配置文件。

还有一个经常被忽略的细节：OpenStack各服务运行的用户和用户组不同，如果日志目录权限不对，服务启动时写日志就会失败，导致服务重启后一直处于异常状态。我在某次部署中遇到过Neutron服务反复重启，查了一圈最后发现是日志目录属主不对，调整权限后服务立刻恢复了。

注意：生产环境中重启某个服务前，务必确认是否影响正在运行的业务。例如重启计算节点上的nova-compute服务，会中断该节点上所有运行中的虚拟机。在测试环境随便重启没什么关系，但生产环境一定要先规划好维护窗口。

7. 写在最后的运维心得

OpenStack这套东西，部署只是万里长征第一步。真正拉开差距的是后续的监控、告警、备份、升级、故障恢复这些运维能力。我后来在给某公司做内部支持时，最深的体会是：部署文档到处都是，但“如何优雅地运维”才是真正有门槛的部分。

我现在只要搭完一套环境，会立刻把所有的配置分区、服务节点、账号信息、网络规划整理成一份清单，放在团队统一的知识库里。这份清单在故障排查和人员交接时的价值，比任何部署文档都大。另外强烈建议把OpenStack各服务的配置目录纳入版本管理，哪怕只有两个人协作，也能避免“我改了配置文件但忘了改了什么”这种尴尬局面。

如果你正准备开始搭建自己的OpenStack云平台，就从最精简的两节点架构开始，先跑通再谈优化。等你的环境里有了监控、有了备份、有了灰度升级的流程，再回头看第一天的搭建过程，会发现很多当初觉得莫名的坑，其实都是架构规划时埋下的雷。