提到openstack部署很多人第一反应是劝退。十几套组件、几十个服务、配置项动辄上百光翻官方文档就能翻到怀疑人生。但你要是做云计算运维或者想在公司内部搭一套私有云环境OpenStack又是绕不开的存在。这篇文章我把自己在openstack部署这条路上踩过的坑、摸索出来的靠谱做法全部捋一遍希望能帮你少走弯路。我主要聊的是当前最主流的Kolla-Ansible容器化部署方式也会带一些手动部署的对比和判断逻辑。整套流程讲完大概是选型思路、环境准备、部署实操、排查技巧、日常维护。适合正在做技术选型、准备动手搭建OpenStack环境的运维工程师、架构师也适合想系统理解这套东西的Ceph等周边技术自学者。1. 部署前必须想清楚的三件事1.1 部署方式选型手动、脚本还是容器化OpenStack部署有几种主流路径我给它们画个像。手动部署源码编译加系统包安装是最原始的方式。好处是你对每个组件怎么装、怎么配、怎么调都心里有数理解最深刻但也正因为组件多、版本依赖交错很多人装到一半就泄气了。我记得早年给某实验室搭环境光是Keystone和Nova之间的版本兼容就折腾了两天后来想加一个组件又引出一堆新依赖这种体验就是手动部署的常态。DevStack是给开发调试用的脚本化部署工具一条命令装完但生产环境完全不能用它默认配置就是单节点全服务压在一起安全性和可靠性都不满足要求。Kolla-Ansible是目前企业落地最主流的方案基于Docker容器加Ansible编排。所有核心服务都跑在容器里系统级别的依赖隔离很干净升级和回滚都容易控制面的版本一致性有保障。这也是我推荐大多数团队选择的路线。我的判断很简单如果需求是学习原理那手动部署一套迷你环境没问题如果是想真正落地一套可供业务使用的云平台直接用Kolla-Ansible。很多初学者栽就栽在“手动部署才能学到东西”的误解上结果三个月过去平台还没跑起来学到的东西也都是零散碎片。用容器化部署先把平台跑起来再通过日志、配置和源码去理解原理效率反而更高。1.2 节点规划与硬件配置估算一个基本的OpenStack环境至少要两类节点控制节点和计算节点。控制节点负责认证、镜像、网络管理、编排等控制面服务计算节点跑虚拟机实例。硬件基线我给你一个参考节点类型CPU内存系统盘数据盘说明控制节点8C16G100G100G数据库、镜像服务、消息队列都在这里磁盘IO压力不小计算节点按虚拟机密度定按需求定80G按实例磁盘需求内存预留20%-30%给Hypervisor和系统开销网络节点4C8G80G不需要如果Neutron用DVR模式计算节点也会承担部分网络功能我建议把控制节点的数据盘单独挂一块不要和系统盘混用。Glance镜像、MariaDB数据库、Docker镜像都会往磁盘上堆混用的话系统盘很快被打满后果就是服务莫名其妙停止、API超时。我自己就吃过这个亏一次部署接近尾声时突然报数据库写入失败查了半天才发现是系统盘满了。如果只是做测试环境可以把控制节点和网络节点合并但计算节点我建议永远独立出来。因为计算节点要吃得下虚拟机负载混跑控制面服务会互相干扰尤其是CPU和内存都会被抢。1.3 网络平面划分与IP规划网络规划是openstack部署里最容易被低估的部分。很多部署失败、实例通信异常根源都是网络规划没做好。至少要划分三个平面管理网络控制节点和所有计算节点通信用的承载内部API、消息队列、数据库流量。这个网络建议单独用一个网段比如10.0.0.0/24。业务网络也叫数据网络承载实例和外部世界的通信。Neutron的网桥、路由器都会绑定到这个网络比如10.0.1.0/24。存储网络如果接了独立存储Ceph、NFS等存储流量最好单独走一个网段因为存储流量又大又持续和业务网络混开会互相拖累。规划的时候有几个关键点。管理网络的IP要预留一个VIP地址给Kolla-Ansible做控制面API的负载均衡这个IP必须空闲不能和其他服务冲突。业务网络要确认网关地址、网段范围、VLAN划分方式提前和网络工程师沟通确认物理交换机上的trunk口配置。我遇到过最头疼的情况就是物理网络上VLAN没放通实例创建成功但怎么都ping不通网关排查OpenStack配置查了半天最后发现是物理交换机端口的事情。2. 基础环境准备这些细节决定了部署成败2.1 系统版本、主机名与基础配置我用过CentOS Stream、Rocky Linux、Ubuntu Server做Kolla-Ansible的底座整体来说RHEL系的兼容性最稳文档也最全。建议选择官方长期支持版本比如Rocky Linux 9或Ubuntu 22.04 LTS。系统层面有几件必须做的事。主机名一定要规范。控制节点叫controller计算节点叫compute01以后节点多了也好管理。千万别用默认的localhost因为Kolla-Ansible会把主机名写进各种配置和服务注册信息里主机名乱套就是灾难。/etc/hosts文件要写上所有节点的IP和主机名映射包括控制器、计算节点、存储节点全写上。这个文件的配置要非常严格写错了部署过程就会出现连不上、注册失败这类问题。SELinux的问题。生产环境如果强制要求开启你得单独处理SELinux策略那是另一套麻烦事大多数中小团队的非强管控环境直接关闭SELinux最省心。防火墙也类似可以不开但更正规的做法是放行OpenStack需要的端口我建议有网络管理员权限的情况下做端口放行避免直接全局关防火墙带来审计问题。时区统一和时间同步属于必查项。OpenStack各节点时间必须一致Keystone的token有效期、Nova的调度逻辑、日志时间戳都依赖这个。我碰到过一次诡异的实例创建失败排查了很久最后发现是某一个计算节点的时间偏了三十秒。所有节点都要配置NTP服务同时确认系统时间和硬件时间都同步否则重启之后时间又跳回去了。2.2 核心配置文件与密码体系用Kolla-Ansible部署核心配置集中在两个文件globals.yml和passwords.yml。globals.yml在/etc/kolla目录下里面定义了你这个OpenStack环境的全局参数。我挑几个影响最大的说kolla_base_distro指定镜像的发行版基座比如rocky或ubuntu必须和你宿主机系统匹配。kolla_internal_vip_address内部VIP地址用于控制面API的负载均衡。这个地址必须在管理网络中并且确保空闲。我当时就踩过一个坑图省事把这个IP设置成管理网络的网关地址结果部署完后API全部无法访问谁连都是连接拒绝。network_interface管理网络对应的网卡名比如ens160或者eth0。这个要严格对应实际网卡接口名称可以通过ip addr命令确认。neutron_external_interfaceNeutron的外部网络接口一般绑定在业务网络网卡上。enable_cinder、enable_heat、enable_octavia这些开关按需开启。测试环境不需要全开开得越多部署越慢、资源占用越高。密码文件用kolla-genpwd命令自动生成会为所有服务生成随机密码。这个文件生成之后必须立刻备份并且妥善保管。我强调这一点是因为很多人在测试环境随手放着不管换机器后忘了备份结果服务全running却怎么都认证不过最后只能重置所有密码。2.3 预检指挥官prechecks到底检查了什么Kolla-Ansible提供了一个预先检查命令kolla-ansible prechecks。这个命令会在所有目标节点上做环境体检检查项包括磁盘空间、内存大小、网络连通性、Docker安装状态、Python依赖等几十项。我的经验是不管多着急prechecks一定要跑而且要仔细看输出。它不会直接告诉你“你配置文件哪行写错了”但会提示连不上某个节点、磁盘空间不足、网卡不存在这类明显问题。很多部署失败都是因为这些基础条件没满足提前检查能省掉大量排错时间。如果prechecks有failed项先去解决failed项再跑。warning可以暂时忽略但需要注意比如它提示某个节点的内存低于推荐值这种warning在实例密度高了之后就会变成事故。3. 基于Kolla-Ansible的openstack部署实操记录3.1 安装Kolla-Ansible并生成配置安装Kolla-Ansible本身不复杂用Python的pip安装即可。安装之后会多出几个关键命令kolla-genpwd、kolla-ansible、kolla-sudoers。第一步是生成密码文件kolla-genpwd然后编辑/etc/kolla/globals.yml填入关键参数。这里我给一个最小可用的globals.yml片段标注了必须改的位置kolla_base_distro: rocky kolla_internal_vip_address: 10.0.0.250 network_interface: ens160 neutron_external_interface: ens192 enable_horizon: yes enable_neutron: yes enable_cinder: no这里要解释一下为什么enable_horizon建议打开。Horizon是OpenStack的Web管理界面虽然平时API管理更高效但给团队里不熟悉命令行的人提供一个图形化界面能大大降低使用门槛。我自己实际用下来很多业务同事通过Horizon创建虚拟机、管理镜像效率比教他们用命令行高多了。节点清单文件multinode也要准备好格式大概是[control] controller [compute] compute01 [network] controller注意network这一组小规模环境通常把网络服务放在控制节点上不需要单独的网络节点。这样既省资源部署也简单。配置完成后执行环境引导kolla-ansible -i /path/to/multinode bootstrap-servers这个步骤会在所有节点上安装Docker、配置好基础环境。然后就可以执行正式部署了kolla-ansible -i /path/to/multinode deploy整个部署过程取决于节点数量和网络状况。单控制节点加单计算节点的环境二十分钟到四十分钟属于正常范围。如果超过一个小时还在跑建议开另一个终端看docker ps和docker logs确认是不是某个容器拉取镜像太慢。3.2 deploy之后必须做的验证动作部署完成不要急着创建虚拟机先把服务状态过一遍。首先生成openrc客户端环境文件kolla-ansible post-deploy source /etc/kolla/admin-openrc.sh然后验证核心服务openstack service list openstack endpoint list这两个命令会把所有注册的服务和对应的API端点列出来你至少要看到identity、image、compute、network这几个服务都是enabled状态endpoint的URL都指向正确的VIP地址。确认服务正常后建议用CirrOS镜像做冒烟测试。CirrOS体积小、启动快专门用来验证虚拟化链路。创建测试网络、路由、安全组和实例的步骤大约是这样的openstack network create test-net openstack subnet create --network test-net --subnet-range 192.168.100.0/24 test-subnet openstack router create test-router openstack router add subnet test-router test-subnet openstack image create --disk-format qcow2 --container-format bare --file cirros.qcow2 cirros openstack server create --flavor m1.tiny --image cirros --network test-net test-vm等实例状态变成ACTIVE后如果能拿到IP并且能从外部ping通整个openstack部署链路就算基本跑通了。3.3 组件之间是怎么协作的一条创建实例的链路很多人openstack部署成功后就以为结束了但真正的业务是组件间的协作。我把创建实例这条链路用大白话捋一遍。用户在Horizon页面填一个创建表单点击创建请求先到Nova的API服务。Nova收到请求后先去Keystone做身份认证确认你是谁、有没有权限。认证通过后Nova去Glance拉取镜像元数据确认要用的镜像存在、格式没问题。然后Nova去Neutron申请网络资源申请一个IP、绑定安全组。最后Nova通过调度器选择一台合适的计算节点通知该节点上的Nova Compute服务拉取镜像、创建虚拟机。理解这条链路排错的时候思路就清晰多了。实例创建失败先看Nova的日志看到哪一步报错了就顺藤摸瓜。镜像下载异常问题大概率在Glance或者镜像存储本身。网络不通重点查Neutron的DHCP服务、路由命名空间和安全组配置。4. 常见问题与排查技巧实录4.1 实例拿不到IP先按这个顺序查这是我在openstack部署中遇到最多、也最折磨人的故障没有之一。实例创建成功但一直拿不到IP我把排查路径按优先级整理出来了。先看Neutron相关容器是否正常docker ps | grep neutron重点看neutron-dhcp-agent、neutron-l3-agent、neutron-openvswitch-agent这三个容器有没有退出或者反复重启。任何一个是Exited状态网络肯定不正常。然后看网络命名空间ip netns list正常情况下要有qdhcp-xxx和qrouter-xxx两个命名空间。如果只有qrouter没有qdhcp说明DHCP服务没起来如果都建了但实例拿不到IP重点检查DHCP分配池或者端口绑定。接着看虚拟机的端口状态openstack port list --server test-vm端口状态如果是DOWN说明Neutron认为虚拟机网卡没有正确挂载到网桥上去看计算节点上的Open vSwitch状态。如果是ACTIVE但拿不到IP多数是DHCP层面问题。安全组也是个容易被忽略的点。默认安全组如果没放行DHCP、ICMP和SSH实例起来之后既拿不到地址也ping不通。好多人在控制台配置了半天网络最后发现是安全组把DHCP给拦了。一个容易忽略的坑是外部网络类型。如果选的是VLAN或flat类型物理交换机上的trunk配置必须到位否则实例和外部网络怎么都通不了。这时候问题就不在OpenStack配置层面需要网络工程师配合看物理链路。我建议在部署之前就跟网络团队确认好这个事别等出问题了再找人省得两头互相甩锅。4.2 认证失败、容器异常与部署中断处理如果你发现openstack命令报401或者连接拒绝第一步不是怀疑配置文件而是先确认MariaDB和Keystone容器是否存活。docker ps | grep -E mariadb|keystone容器异常可以从docker logs看错误docker logs keystone --tail 100如果宿主机重启过某些容器没有设置restart策略可能出现服务起不来的情况。Kolla-Ansible默认给关键服务配置了自动重启策略但也不排除意外。部署过程中段失败也是常见情况尤其是拉取镜像阶段网络一抖动就会中断。重新执行deploy之前确认docker images里缺没缺镜像缺的可以先手动拉取补上再跑部署docker pull quay.io/openstack.kolla/rocky-... | grep -v pull这个技巧解决了我好几次部署中断的尴尬。注意这里镜像源取决于你的配置实际部署时看报错提示缺失的镜像全名直接补拉就可以。4.3 部署失败后如何快速回滚Kolla-Ansible的部署过程是可重复执行的。第一次deploy失败后不要急着把环境删了重来先看是哪个阶段失败的。大部分情况下修正配置后重新执行deploy即可Ansible的幂等性会跳过已经完成的部分。但如果数据库数据已经写坏了或者容器配置文件处于半修改状态就需要清空重来kolla-ansible destroy --yes-i-really-really-mean-it这个命令会连数据库、容器、网络一块全部删除是真正的“格式化重装”。我个人的经验是deploy失败先备份globals.yml和passwords.yml然后可以大胆重跑destroy命令要慎用只有在确认环境已经无法修复时才用。还有一个小技巧把部署日志保存下来。Kolla-Ansible默认会把日志写到终端你可以重定向到文件里保存完整部署输出。排错的时候部署日志的价值比官方文档还大因为你能看到每一步到底做了什么错在哪一步。5. 部署完成后的优化要点与日常维护5.1 密码管理与配置变更的规范OpenStack部署完成之后密码管理是第一件要落实的事。passwords.yml里包含了MySQL、RabbitMQ、Keystone管理员等所有服务密码这些密码不能放在一个共享目录明文共享。我建议把passwords.yml放到团队的密钥管理库里同时做好分级授权。配置变更的规范也很重要。不少人习惯直接进容器改配置文件这是大忌。容器每次重启都会从镜像重新生成你改的东西会直接消失。正确的做法是修改宿主机上的globals.yml然后重新执行部署命令让Kolla-Ansible重新生成配置并重启对应容器。我自己维护的规范大概是这样所有配置变更都走git记录变更前先备份globals.yml变更后先跑prechecks再deploy最后验证关键服务状态。这样即使哪次改坏了也能快速回到上一个可用版本。5.2 日志收集与监控告警清单日志是OpenStack运维的核心资产没有集中日志就等于盲人摸象。容器日志默认在/var/lib/docker/containers目录下可以用docker logs命令实时查看但生产环境日志量非常大建议搭建一套日志采集系统比如轻量的Loki或者全套ELK把控制节点和计算节点的日志统一收起来。这样跨节点排查时只需要在一个地方按关键字搜日志效率提升非常明显。监控方面至少要覆盖宿主机资源层和OpenStack服务层。宿主机CPU、内存、磁盘、网络IO是基础服务层要关注Keystone、Nova、Neutron的关键容器是否存活。我遇到过线上实例批量卡死的场景原因是某个计算节点的磁盘塞满了但监控只覆盖了CPU和内存磁盘没告警问题发生了很久才发现。另外一个监控指标容易被忽略数据库连接数。MariaDB连接数被打满会导致所有服务连锁超时尤其当控制节点资源紧张时这个问题会突然爆发。部署阶段就应该给数据库连接数配上告警。5.3 扩容计算节点时最容易踩的坑OpenStack平台的扩容是常态业务量上来了就要加计算节点。步骤其实不复杂新节点装好系统、按基础配置设置好然后把它加进multinode清单文件重新执行boots。但有几个坑值得专门提醒。新节点的主机名必须严格按照命名规范来而且不要和已有节点重名。重名的后果是Nova和Neutron的注册信息会混乱调度的时候可能把实例调度到错误的节点上。新节点的网卡名要确认。因为有的服务器系统装好之后网卡名是eno1、enp3s0这种带PCI编号的名称甚至有些云服务器是eth0。Kolla-Ansible的globals.yml里配了network_interface这个名字新节点的网卡名必须一致否则Neutron Agent会注册不上实例创建后网络不通。我建议扩容前先列一个checklist系统版本、主机名、hosts文件、网卡名、时间同步、磁盘空间。每一项都确认过了再执行扩容几乎不会出问题。我有一次就是跳过了网卡确认结果扩容的节点上创建实例一直失败查了半天发现是网桥绑错了网卡。回滚方面扩完容之后如果新节点不行在multinode文件里移除该节点再重新执行一次部署命令Kolla-Ansible会把这个节点上的服务清掉实例调度就不会再往那边去了。这个操作比直接把节点下线再格式化要平滑得多。我在实际维护中的体会是openstack部署这套流程最大的门槛其实不是命令多难而是很多人会忍不住跳过环境准备环节直接跑部署后面出问题再回头补课。我后来每次部署都强制自己走完整流程资源规划、网络规划、预检、部署、冒烟验证一步都不省反而速度最快。最后再分享一个小技巧部署过程中确保终端输出日志保存完整排错的时候回看部署日志的价值比求助别人还大。