部署OpenStack这件事说简单也简单说难也难。早期我手动部署过Liberty版本对着一堆配置文件、消息队列、数据库、认证服务来回折腾一组控制节点没个三四天搭不完中间稍有不慎就得回滚重来。后来接触到kolla-ansible才真正感觉这条路走通了——它把OpenStack的核心服务全部容器化用Ansible自动编排部署一条命令就能拉起一套环境也能一条命令升级版本实话说对于想快速上手OpenStack又不想被底层依赖折磨的人来说kolla-ansible是目前社区主推、也是实际生产中最常见的部署方案之一。这篇文章我会从部署选型讲起详细拆解环境准备、配置要点、完整部署流程再到常见故障的排查思路全部基于我实操过的环境。如果你正准备搭一套OpenStack环境或者正在对比各种部署方式这篇文章可以直接拿来当参考手册用。1. 为什么选kolla-ansible部署方案对比与核心思路1.1 传统部署方式的痛点OpenStack组件非常多核心服务至少包括Keystone认证、Glance镜像、Nova计算、Neutron网络、Cinder块存储、Horizon控制台再加上依赖的MariaDB、RabbitMQ、Memcached等基础组件整个系统一旦散装部署依赖地狱就来了。我在一次手动部署中遇到的问题很有代表性操作系统自带的Python版本和OpenStack要求的版本不一致编译virtualenv时缺一堆系统库不同组件对同一个Python包要求不同版本装完这个装那个就冲突了。就算一次性装机成功后续想升级某个组件又可能造成新的兼容性问题。手动部署不是不能做而是环境是不可复现的换一套机器就得重新踩一遍坑。1.2 kolla-ansible的容器化思路kolla-ansible的思路很简单把OpenStack的每个服务都打包成Docker镜像镜像内包含了该服务所需的所有依赖、Python包、配置文件模板然后通过Ansible批量生成容器并编排启动。这样做有几点直接的好处环境一致性开发、测试、生产环境都用同一套镜像不存在我本机上好好的到服务器就起不来的问题隔离性服务都跑在自己的容器里网络、文件系统各管各的互不污染删掉重建也很快部署可重复Ansible是声明式的定义好inventory和配置文件后每次执行结果一致出错了重跑即可升级可控升级镜像版本、重新部署容器即可不用逐台操作可以说kolla-ansible是把容器化和配置管理这两件事结合起来让OpenStack从手工打造的工艺品变成了流水线生产的标准品。1.3 与其他部署工具对比在选择部署工具时我对比过几套主流方案这里列一张表方便大家参考部署工具核心思路适用场景主要劣势DevStack脚本化单机部署开发调试、跑通概念验证不适合生产服务和系统耦合深Packstack基于Puppet的RDO方案单节点快速体验多节点扩展受限维护活跃度一般OpenStack-Ansible宿主级部署服务跑在容器中更贴近系统层控制配置复杂上手成本高于kolla-ansiblekolla-ansible容器化Ansible编排中小规模生产、快速交付需要掌握Docker、Ansible基础知识我在实际测试环境里用的是kolla-ansible因为它对硬件配置的要求相对适中配置文件的注释也完整排错时社区资料多。如果你只是想在笔记本上体验DevStack确实更快但一旦想模拟生产环境的多节点架构kolla-ansible会更合适。1.4 kolla-ansible的角色划分kolla-ansible部署时通常有几种节点角色控制节点control运行Keystone、Glance、Nova API、Neutron Server、Horizon、MariaDB、RabbitMQ等管理面服务计算节点compute运行Nova-compute、Neutron-openvswitch-agent等服务负责实际启动虚拟机网络节点network运行Neutron的L3-agent、DHCP-agent等网络服务中小规模常与控制节点合并存储节点storage运行Cinder-volume或Ceph等存储相关服务如果搭建试验环境可以all-in-one把全部服务装到一台机器上。生产环境建议控制节点与计算节点分离至少保证控制面的稳定性。2. 环境准备硬件、操作系统与网络规划2.1 硬件配置建议很多人一开始低估了OpenStack对资源的需求。控制节点上要跑数据库、队列、认证等一堆服务内存和磁盘IO是瓶颈。计算节点则要支持虚拟化CPU的VT-x/AMD-V必须开启。以下是我测试环境的配置供大家参考节点角色CPU内存磁盘网络控制节点含网络8核16GB200GB SSD管理网业务网计算节点16核64GB1TB SSD管理网业务网存储网如有存储节点如启用4核8GB多块数据盘管理网存储网关于网卡至少需要两块物理网卡一块用于管理网络节点间通信、API访问一块用于业务网络虚拟机IP分配。如果后续接Ceph存储网络建议单独规划避免大流量挤占管理面带宽。2.2 操作系统与基础组件kolla-ansible的镜像构建基于基础OS镜像因此主机的操作系统选择会影响容器内的系统类型。我目前使用Rocky Linux 9作为宿主机系统容器镜像选择rocky系列整体兼容性比较顺。部署前需要保证宿主机满足以下条件操作系统为64位Python版本在3.8以上实际建议3.10以上Docker或Podman已安装并启用kolla-ansible支持Docker和Podman但我更推荐Docker配套资料更全排查问题更方便Ansible版本与kolla-ansible版本匹配这个很关键建议按官方文档安装对应版本的Ansible不要图省事用系统自带的老版本我踩过一次坑系统自带的Ansible版本是2.9kolla-ansible要求2.11以上结果执行playbook时直接报了task解析错误的提示。后来我用Python的venv安装了指定版本的Ansible问题才解决。2.3 网络规划思路OpenStack本身的网络有两种模式扁平网络flat和VXLAN隧道网络。kolla-ansible的默认模板支持这两种类型的选择其中neutron_plugin_agent对应的配置在globals.yml里。我规划的地址段是这样的管理网段10.10.0.0/24用于控制节点与计算节点之间的管理通信、容器网络、数据库同步业务网段172.16.0.0/24用于虚拟机外部IP浮动IP和租户网络存储网段可选192.168.100.0/24用于块存储后端的数据传输这里有一个经验业务网段不要和管理网段重叠否则Neutron创建路由时会出现路由冲突的诡异现象排查起来非常头疼。而且业务网段的网关一般不做VLAN Tagging方便后续对接外部交换机。2.4 主机时间同步OpenStack服务之间大量依赖Token认证Keystone签发的临时凭证而Token的有效性依赖时间。如果控制节点和各计算节点的系统时间不一致很容易出现请求返回401或签名过期的报错。我在部署前统一使用了chrony进行NTP时间同步配置步骤很简单# 安装chrony yum install -y chrony # 启动并设置开机自启 systemctl enable --now chronyd如果节点间有内部时间服务器指向内部服务器即可没有的话用公共NTP服务器也够用关键是保证所有节点指向同一个时间源。3. 核心配置文件解析globals.yml、passwords.yml与inventorykolla-ansible的配置主要在三个地方inventory文件定义节点角色、globals.yml全局参数、passwords.yml服务密码。这三者的关系可以这样理解inventory决定服务装在哪台机器globals.yml决定服务怎么运行passwords.yml决定服务之间怎么认证。3.1 inventory文件结构kolla-ansible支持两种典型部署模式all-in-one和multinode。all-in-one的inventory比较简单[control] localhost ansible_connectionlocal [network] localhost ansible_connectionlocal [compute] localhost ansible_connectionlocal [storage] localhost ansible_connectionlocal [monitoring] localhost ansible_connectionlocalmultinode则要把节点分开[control] 10.10.0.11 ansible_userroot [network] 10.10.0.11 ansible_userroot [compute] 10.10.0.12 ansible_userroot 10.10.0.13 ansible_userroot [storage] 10.10.0.14 ansible_userroot [monitoring] 10.10.0.11 ansible_userroot注意几点用multinode时建议所有节点使用SSH密钥登录并把公钥提前分发到各节点否则部署过程要反复输密码很影响效率inventory文件里的节点名称要和实际主机名对应部分服务比如MariaDB集群依赖主机名识别成员控制节点和网络节点可以复用同一台机器这在中小规模场景是很正常的部署方式3.2 globals.yml关键参数globals.yml是kolla-ansible的灵魂文件。我常用的几个参数配置如下# 指定OpenStack发行版本必须与镜像版本号一致 kolla_base_distro: rocky # 指定OpenStack版本代号 openstack_release: 2024.1 # 控制节点主机IP用于内部通信和API监听 kolla_internal_vip_address: 10.10.0.100 # 指定容器网络接口 network_interface: eth0 # Neutron外部网络接口业务网 neutron_external_interface: eth1 # 指定网络类型VXLAN适合多租户隔离的场景 neutron_plugin_agent: openvswitch # 启用的一些可选服务 enable_heat: yes enable_horizon: yes enable_ceph: no这里重点说几个参数kolla_base_distro和openstack_release这两个参数决定了基础镜像版本。2024.1是当前较新的版本代号。如果版本信息不匹配Ansible在拉取镜像时会报找不到tag的错误所以务必让这两个参数保持和要拉取的镜像tags一致。kolla_internal_vip_address这是控制面的虚拟IP多个控制节点时由Keepalived管理单节点时也会绑定一个浮动地址。很多人不明白为什么单节点也要配VIP其实是为了后续扩容高可用做准备部署时这会在每台节点上产生一个VIP地址如果IP和业务网冲突会造成管理面访问异常。network_interface这个参数定义了容器使用的宿主物理网卡所有OpenStack内部管理端口、虚拟机流量、存储流量都会通过这块网卡桥接。我习惯把管理网卡设为eth0然后业务网卡通过neutron_external_interface指定。neutron_plugin_agent可选项是openvswitch和linuxbridge。如果是新部署环境我推荐openvswitch功能上更完整VXLAN和OpenFlow支持更好虽然排错起来比linuxbridge复杂一点但生产上能遇到的需求它都能兜住。*enable_系列参数这些参数控制是否部署对应服务组件。默认很多是No需要按需开启。比如enable_grafana、enable_prometheus会影响监控栈是否部署如果你只是想验证核心功能这些保持默认即可不要随意开启否则会拉取大量额外镜像增加部署时间。3.3 passwords.yml生成与自定义passwords.yml文件是部署前自动生成的包含几十个服务密码。kolla-ansible提供了生成随机密码的命令kolla-genpwd这个命令会基于模板生成随机的强密码并写入/etc/kolla/passwords.yml。生产环境中通常要自定义某些密码比如keystone_admin_password: YourAdminPass mariadb_password: YourDBPass自定义时要保证密码强度足够而且不要包含特殊字符比如$、%否则部分服务的配置文件解析可能会出问题。我遇到过密码里含$导致数据库连接字符串被截断的情况最后花了不少时间排查。另外有一点要提醒passwords.yml文件在部署后不要随意改动。很多服务会把数据库密码存在自己的配置里如果你改了密码而不重建所有服务的配置和数据库反而会导致一堆认证失败。正确的改密操作应该是改完密码后重新执行整个部署流程。3.4 配置ansible的环境变量kolla-ansible的playbook对ansible的执行环境比较敏感。我在执行之前通常设置以下环境变量export ANSIBLE_HOST_KEY_CHECKINGFalse export ANSIBLE_RETRY_FILES_ENABLEDFalse export ANSIBLE_INVENTORY/etc/kolla/multinode export ANSIBLE_GROUP_VARS/etc/kolla/globals.ymlANSIBLE_HOST_KEY_CHECKINGFalse是为了避免首次SSH连接时弹出确认指纹的交互提示这在批量执行时很有用。设置完后保存到/etc/profile.d/kolla-deploy.sh里以后每次登录新开终端就不用重复export了。4. 完整部署流程从安装到创建第一台虚拟机4.1 安装kolla-ansible建议使用Python的虚拟环境安装避免污染系统Python环境也避免和系统包产生冲突# 创建虚拟环境 python3 -m venv /opt/kolla-venv source /opt/kolla-venv/bin/activate # 安装pip并升级 pip install -U pip # 安装kolla-ansible pip install kolla-ansible # 安装与kolla-ansible匹配的ansible版本 pip install ansible安装完成后需要把kolla-ansible的配置文件模板复制到/etc/kolla目录mkdir -p /etc/kolla cp -r /opt/kolla-venv/share/kolla-ansible/etc_examples/kolla/* /etc/kolla cp /opt/kolla-venv/share/kolla-ansible/ansible/inventory/multinode /etc/kolla/multinode4.2 初始化节点环境安装完kolla-ansible后第一步是执行bootstrap-servers这个命令会完成以下工作安装Docker配置Python环境启用必要的内核模块如br_netfilter调整系统参数如vm.max_map_count执行命令kolla-ansible -i /etc/kolla/multinode bootstrap-servers这一步比较耗时因为要在每个节点上安装Docker并进行初始化。如果节点连接外网慢Docker的yum源和镜像拉取会拖时间建议提前配置好镜像加速源。4.3 执行precheckbootstrap完成后执行预检查kolla-ansible -i /etc/kolla/multinode precheckprecheck会验证各节点能否正常SSH访问主机名、操作系统版本是否兼容Docker是否正常运行配置参数是否合理网络连通性凡是配置有问题precheck都会在这里给出提示。我的习惯是precheck通过后才继续部署尽量不在后续步骤里遇到半路翻车的情况。4.4 正式部署预检查通过后执行部署命令kolla-ansible -i /etc/kolla/multinode deploy这条命令会执行大量Ansible任务拉取镜像、生成配置文件、创建容器、初始化数据库、启动服务。整体耗时取决于网络速度和节点数量一般情况下all-in-one环境在20-40分钟内多节点环境可能要1小时以上。部署过程中如果中途失败一般不用从零重来直接在当前的/vet/kolla目录下修复问题后再次执行deploy即可。Ansible和容器化的好处就在这里运泥已经创建好的容器和已经完成的配置不会被重复覆盖。4.5 生成keystone管理员凭证部署完成后需要生成OpenStack客户端认证文件具体命令是kolla-ansible -i /etc/kolla/multinode post-deploypost-deploy会在/etc/kolla下生成clouds.yaml同时将/etc/kolla/admin-openrc.sh环境下发到控制节点。我习惯再把admin凭证复制到一个方便的位置source /etc/kolla/admin-openrc.sh这个脚本会设置OS_AUTH_URL、OS_USERNAME、OS_PASSWORD等环境变量后续用OpenStack命令操作时都会读取这些变量。4.6 安装命令行客户端并创建测试虚拟机OpenStack命令行客户端需要单独安装我用的版本对应2024.1版本pip install python-openstackclient python-glanceclient python-novaclient python-neutronclient然后依次执行以下操作创建一台测试虚拟机# 查看镜像列表本地还没有任何镜像 openstack image list # 下载cirros测试镜像 openstack image create --file /opt/cirros-0.6.0-x86_64-disk.img --disk-format qcow2 --container-format bare 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 server create --image cirros --flavor m1.tiny --network test-net test-vm这里我踩过的坑是创建子网时忘记指定网关导致虚拟机启动后无法访问外部网络。解决办法是在创建子网时加--gateway 192.168.100.1参数或者在路由器上设置SNAT规则。4.7 Horizon控制台验证部署完成后访问http://控制节点IP即可打开Horizon界面用admin用户和passwords.yml里设置的keystone_admin_password登录。Horizon登录后可以查看虚拟机状态、网络拓扑、镜像列表等信息。如果Horizon页面打不开多半是Apache容器启动异常或网络接口绑定有问题排查方法见下一部分。5. 常见故障与排查技巧实录部署和运行过程中我记录了一些典型问题这里做个速查表方便大家按症状对号入座症状可能原因排查思路与解法precheck卡在SSH连接SSH主机密钥校验、用户权限关闭HostKeyChecking使用root用户部署检查/root/.ssh/authorized_keys镜像拉取超时网络不通或镜像源慢配置镜像加速源确认globals.yml中的registry参数Docker容器不断重启容器内配置错误或资源不足docker logs 容器名查看具体报错检查宿主机内存MariaDB无法启动数据目录权限或主机名解析失败检查/etc/hosts保证节点主机名能互相解析Keystone Token认证失败时间不同步每台节点执行chronyc tracking查看时间偏差统一NTP源Nova-compute无法启动宿主机不支持虚拟化检查BIOS里是否开启VT-x/AMD-V执行egrep -c (vmx|svm) /proc/cpuinfoNeutron服务启动失败Open vSwitch桥接端口错误检查network_interface和neutron_external_interface是否和实际网卡名一致Horizon登录不上Keystone容器异常或VIP地址不通先检查docker ps里的容器状态再尝试直接访问http://10.10.0.100:80创建虚拟机失败镜像格式或flavor未定义确认镜像格式是qcow2先创建flavor再创建虚拟机5.1 precheck时报Docker is not running这个最常见的原因是bootstrap-servers执行完成后宿主机的Docker没有启动成功。排查方法systemctl status docker journalctl -u docker --no-pagerRocky Linux上Docker的cgroup驱动默认是systemd而内核参数可能没配置完整。解决办法是在/etc/docker/daemon.json里显式指定{ exec-opts: [native.cgroupdriversystemd], log-driver: json-file, log-opts: { max-size: 100m, max-file: 3 }, storage-driver: overlay2 }然后重启Dockersystemctl restart docker。5.2 容器一直重启日志报Permission denied这个问题的根源一般是SELinux。Rocky Linux默认SELinux是Enforcing模式而容器内服务需要访问宿主机的文件、端口和进程SELinux会拦截这些操作。最省事的做法是在部署环境中把SELinux设置为Permissive模式setenforce 0永久生效的话修改/etc/selinux/config把SELINUXenforcing改成SELINUXpermissive。提示生产环境如果对安全要求高不建议永久关闭SELinux。但kolla-ansible本身对SELinux的支持并不完善至少实验环境下设置成permissive是普遍做法。5.3 网络节点上出现大量丢包我有一次用OpenStack自带的VXLAN网络创建了几台虚拟机之后发现租户网络内ping丢包严重物理机CPU占用也不高。后来检查发现是宿主机的网卡接收队列满导致SoftIRQ堆积。解决办法是调整网卡的队列数量和多队列参数ethtool -L eth1 combined 4同时在/etc/sysctl.conf里增加了几个网络参数的调整net.core.netdev_max_backlog 16384 net.core.somaxconn 4096 net.ipv4.tcp_max_syn_backlog 65535重启后丢包问题基本解决。5.4 Ceph相关错误如果globals.yml里开启了enable_ceph: yes部署时会拉取Ceph相关镜像。我建议在不需要块存储服务时先关闭这个参数否则启动Cephmons容器后资源占用会明显上升。Ceph容器启动失败的常见报错是OSD-related keyring错误这通常是因为ceph_osd_selinux没有正确设置或者OSD数据磁盘的权限不对。如果只是实验环境建议先把enable_ceph设为no后续需要块存储时再单独搭建Ceph环境再通过kolla-ansible的ceph部分单独部署对接。5.5 虚拟机无法获得IP虚拟机启动后一直获取不到IP地址多半是Neutron的DHCP代理没有正常工作。排查步骤检查是否创建了路由和子网网关登录网络节点查看docker ps里neutron-dhcp-agent的容器状态查看docker logs neutron-dhcp-agent里有没有报错还有一种常见情况是安全组规则阻挡了DHCP请求。默认安全组会放行DHCP流量但如果修改了安全组默认规则可能导致DHCP包被拦截。另外VLXAN模式中MTU建议设置为1400VXLAN封装后开销为50字节如果物理网络MTU不够大大包会丢导致DHCP交互超时。我在创建子网时就会把MTU参数带上openstack subnet create --network test-net --subnet-range 192.168.100.0/24 --gateway 192.168.100.1 --dns-nameserver 192.168.100.1 test-subnet6. 生产环境进阶建议与个人实操体会6.1 高可用部署思路如果只是测试环境控制节点单节点足够了。但生产环境要考虑控制器高可用kolla-ansible本身支持多控制节点架构配置上并不复杂主要是inventory里写多个control节点然后设置好kolla_internal_vip_addressKolla会通过Keepalived自动实现VIP漂移。多控制节点部署时需要注意控制节点的数量建议为奇数3个或5个配合MariaDB Galera集群时更容易仲裁各控制节点的系统配置保持一致尤其是/etc/hosts、时间同步、Docker配置计算节点要能通过VIP访问各个控制服务而不是直接访问某个控制节点IP6.2 存储后端的选择kolla-ansible默认使用LVM作为Cinder的存储后端这在实验环境足够了。生产环境如果想用Cephopenstack和Ceph对接的流程相对成熟。我建议这样规划控制节点只跑管理服务和API计算节点跑nova-compute独立的Ceph集群存储镜像和块设备这个架构的好处是存储和计算可以独立扩容运维上也清晰。当然如果初期没有专职存储运维人员LVM也是可行的只是扩容和故障恢复上会麻烦一些。6.3 升级与备份经验kolla-ansible的升级命令是kolla-ansible upgrade升级前务必做几件事备份/etc/kolla下的globals.yml、passwords.yml和inventory文件备份各节点的数据库可以停掉容器后直接备份数据目录也可以用数据库导出命令确认新版本和旧版本之间的升级路径跨大版本时注意查看官方release notes我曾经在一次升级时因为没备份passwords.yml新密码生成后导致所有存量数据认证失败最后只能回滚配置。现在每次升级前我都会在备份目录打一个带日期的包尤其是配置文件这种容易忽略的项。6.4 关于容器的日常维护OpenStack所有服务都跑在容器里日常查看服务状态的方式是docker ps --format table {{.Names}}\t{{.Status}}查看某个服务的日志docker logs mariadb重启某个服务不建议直接stop容器因为Kolla会通过编排管理docker restart 容器名这里有个个人心得OpenStack容器在重启后有依赖顺序问题特别是数据库和Keystone这类服务如果只重启了某个API容器而没有重启数据库可能会出现连接被拒的情况。所以每次维护时尽量通过kolla-ansible的部署或升级命令来统一管理而不是频繁手动操作单个容器。6.5 最后的经验之谈用了这么多年部署OpenStack我个人最深的一个体会是环境差异带来的问题远比版本本身的问题多。操作系统版本、内核参数、物理网卡名、DNS解析、NTP这些基础得不能再基础的东西恰恰是排错时最常遇到的坑。所以在动手部署之前先把这些前置条件一项项检查清楚比任何安装技巧都管用。另外不要一开始就追求把启用的服务开到最大。很多人喜欢把Heat、Magnum、Octavia等一堆服务都勾上结果光拉镜像就花了一小时资源消耗也大。我现在的习惯是先用最小集把环境跑通验证网络、虚拟机创建正常后再逐步启用需要的组件。这样既稳定也方便隔离问题。如果你正准备部署一套OpenStackkolla-ansible确实是值得投入时间掌握的工具。把环境准备好、配置理解透、日志看明白你就会发现OpenStack部署这件事情比想象中可控得多。