1. 项目缘起与整体部署思路拆解1.1 为什么选择 kolla-ansible 这条路在国产化替代的大背景下越来越多的团队需要把云平台跑在国产操作系统上。麒麟 V11 作为一款基于较新内核的国产服务器操作系统在政企、金融、能源等场景里出现得越来越频繁。而 OpenStack 作为私有云的事实标准Zed 版本又是一个相对成熟、社区支持周期合理的发行版把这两者结合起来用 kolla-ansible 做容器化部署是我实测下来最省心的一条路。先说清楚 kolla-ansible 到底解决了什么问题。传统方式装 OpenStack你得一个个组件手动装、手动配、手动连数据库和消息队列光是 Nova 和 Neutron 的配置项就能让人崩溃而且不同节点之间版本不一致、依赖冲突是家常便饭。kolla-ansible 的思路是把每个 OpenStack 服务都打包成 Docker 容器用 Ansible 做编排你只需要准备好配置文件和节点清单剩下的拉镜像、起容器、连网络、初始化数据库全部自动化。它的核心价值在于一致性和可重复性——今天装一遍和三个月后重装一遍结果完全一样。那为什么是麒麟 V11 加 Zed 这个组合麒麟 V11 的内核版本和 systemd 版本都比较新对容器运行时和 cgroup v2 的支持比较完整这恰好是 Zed 版本 OpenStack 所依赖的。Zed 本身对 Python 3.8 和容器化部署的支持已经很成熟社区里 kolla-ansible 对应 Zed 的稳定分支维护得也不错。三者叠在一起踩坑的概率会明显低于用老版本系统硬上新版本 OpenStack。这套方案适合谁我总结下来是三类人一是手里有国产化硬件和系统、需要快速搭一套私有云做验证或生产的运维工程师二是想学习 OpenStack 但被手动部署劝退的开发者三是需要做多云/混合云底座、对部署可复制性有强需求的架构师。哪怕你之前没碰过 kolla-ansible只要懂基本的 Linux 操作和 Docker 概念跟着走也能跑通。1.2 整体架构与节点规划思路在动手之前必须先把节点角色想清楚。kolla-ansible 支持 all-in-one 单节点和 multi-node 多节点两种模式。单节点适合做功能验证和开发测试多节点才是生产该有的样子。我这里以最经典的三节点起步架构来讲因为它既能体现分布式部署的核心逻辑又不会让资源需求高到离谱。三节点的角色划分是这样的一个控制节点control、一个计算节点compute、一个存储节点storage但实际生产中控制节点通常要三个做高可用。为了讲清楚原理又不至于把篇幅拖得太散我用“控制计算存储”三合一的最小生产模拟来讲每个节点至少 8 核 16G 内存、两块网卡、100G 以上系统盘。这个配置不是拍脑袋来的——OpenStack 的控制面服务MariaDB、RabbitMQ、Keystone、Nova API 等加起来内存占用在 6G 到 8G 之间留出余量给容器运行时和系统本身16G 是底线。网络规划是这套部署里最容易翻车的地方我单独拎出来说。kolla-ansible 默认需要两张网卡一张管理网api_interface负责各服务之间的 API 通信、数据库和消息队列流量一张业务网neutron_external_interface负责虚拟机对外通信和浮动 IP。管理网建议用万兆业务网看实际带宽需求。如果你只有一张网卡也不是不能做但要把管理流量和业务流量混在一起后期排查问题会非常痛苦我强烈建议至少两张。提示麒麟 V11 默认可能启用了 firewalld 或 nftables部署前一定要确认防火墙规则不会拦截容器间通信和 VXLAN 隧道流量。我吃过这个亏容器起来了但服务互相连不上排查了大半天才发现是防火墙把 4789 端口的 VXLAN 流量挡了。存储方面Ceph 是 kolla-ansible 生态里集成度最高的后端块存储、对象存储、镜像存储都能用它。如果只是验证用本地 LVM 做 Cinder 后端也能跑但生产环境我建议直接上 Ceph因为后面扩容和故障恢复会省太多事。Ceph 至少需要一块独立磁盘做 OSD别和系统盘混用。2. 麒麟 V11 系统层准备与核心依赖处理2.1 系统初始化与内核参数调优麒麟 V11 装好之后第一件事不是急着装 Docker而是把系统层的基础打牢。我习惯按这个顺序来更新系统、配置主机名和 hosts、关闭不需要的服务、调内核参数、配时间同步。主机名和 hosts 必须每个节点都配而且要和后面 kolla-ansible 的 inventory 文件里写的名字完全一致。我见过有人 inventory 里写 IP、hosts 里写域名结果 Ansible 连上了但服务注册用的是另一套名字Keystone 里一堆重复的 endpoint。统一用域名比如node1.cloud.local、node2.cloud.local、node3.cloud.local每个节点的/etc/hosts里都要有全部节点的映射。内核参数这块OpenStack 对网络转发和连接跟踪有要求。需要确保net.ipv4.ip_forward1、net.bridge.bridge-nf-call-iptables1、net.bridge.bridge-nf-call-ip6tables1这几个参数生效。麒麟 V11 默认可能没开手动写进/etc/sysctl.d/99-openstack.conf然后sysctl -p加载。另外net.ipv4.neigh.default.gc_thresh1/2/3这几个邻居表阈值建议调大因为容器和虚拟机多了之后 ARP 表容易溢出表现就是网络时通时断非常隐蔽。时间同步用 chrony三个节点指向同一个内网时间源或者干脆让控制节点做源。OpenStack 的 token 和证书对时间敏感节点间时间差超过几分钟就会出现认证失败。这个坑我在早期项目里踩过明明密码没错就是登不进去最后发现是计算节点时间慢了五分钟。2.2 Docker 与容器运行时安装要点kolla-ansible 对 Docker 版本有要求Zed 版本建议用 Docker CE 20.10 以上。麒麟 V11 的软件源里可能自带 docker 或者 podman但我不建议用系统自带的版本往往偏旧而且和 kolla 的兼容性没经过验证。正确做法是添加 Docker 官方源或者用国内镜像源安装指定版本。安装完 Docker 之后有几个配置必须改。第一是daemon.json里要配exec-opts: [native.cgroupdriversystemd]因为麒麟 V11 用的是 systemd 管理 cgroup如果 Docker 还用 cgroupfskubelet 或者容器编排层会报错。第二是配好镜像加速和私有仓库地址因为 kolla 要拉几十个镜像走公网又慢又不稳定。第三是storage-driver用 overlay2麒麟 V11 的内核对 overlay2 支持很好性能比 devicemapper 强不少。注意麒麟 V11 可能默认开启了 SELinuxDocker 在 enforcing 模式下挂载卷会出权限问题。要么把 SELinux 设成 permissive要么给容器加:z或:Z标签。我一般验证阶段先设 permissive生产再根据安全要求细化策略。Docker 装好后每个节点都要验证docker info能正常输出特别是 cgroup driver 显示为 systemd。然后拉一个测试镜像跑一下确认网络和存储都没问题。这一步花五分钟能省掉后面半小时的排查。2.3 Python 环境与 kolla-ansible 安装kolla-ansible 本身是 Python 写的跑在 Ansible 之上。麒麟 V11 自带的 Python 版本一般是 3.7 或 3.8Zed 版本要求 Python 3.8 以上所以要先确认版本。如果系统 Python 不够新可以用 conda 或者编译安装一个独立的 Python 环境别去动系统自带的 Python否则可能把系统工具搞坏。安装 kolla-ansible 最稳的方式是用 pip 装到虚拟环境里。先建一个 venv然后pip install kolla-ansible15.0.015.0.0 对应 Zed 版本。装完之后把/usr/share/kolla-ansible或者 venv 里的share/kolla-ansible目录下的etc_examples复制到/etc/kolla这是所有配置文件的模板来源。Ansible 的版本也要注意kolla-ansible 15.0.0 要求 Ansible 2.12 到 2.13 之间。版本太高或太低都可能出兼容问题。我一般用 pip 指定版本装避免系统包管理器装出来的版本不对。装好后ansible --version确认一下。3. kolla-ansible 配置详解与参数计算3.1 全局配置文件 globals.yml 逐项拆解/etc/kolla/globals.yml是整个部署的核心几乎所有关键决策都在这里。我挑几个最容易出错、也最影响结果的参数来讲。kolla_base_distro和kolla_install_type决定了用哪套镜像。麒麟 V11 基于较新的内核但 kolla 官方镜像主要基于 CentOS、Ubuntu 和 Debian。实测下来选centos作为 base distro 兼容性最好因为麒麟的很多库路径和 CentOS 接近。kolla_install_type选binary别选sourcesource 镜像编译时间长且容易出依赖问题。openstack_release必须写zed这个要和 kolla-ansible 版本对应写错了会拉不到镜像。network_interface填管理网网卡名比如ens192。neutron_external_interface填业务网网卡名。这两个名字一定要用ip addr确认清楚麒麟 V11 的网卡命名规则可能是ens、enp或者eth开头写错了部署直接失败。kolla_internal_vip_address是控制面的虚拟 IP多节点部署时用 keepalived 做高可用。这个 IP 要在管理网段内且未被占用。单节点部署时可以直接填控制节点的管理 IP。kolla_external_vip_address是外部访问 VIP如果内外网分开就单独填不分开可以和内部 VIP 一样。enable_*系列开关控制各个服务是否部署。Cinder、Glance、Nova、Neutron、Keystone、Horizon 这些是必开的。Ceph 如果要用就开enable_ceph。Heat、Magnum、Octavia 这些看需求。我建议第一次部署先把核心服务跑通别一上来全开出了问题不好定位。3.2 密码文件与安全配置/etc/kolla/passwords.yml存的是所有服务的密码。kolla-ansible 提供了一个kolla-genpwd命令可以自动生成随机密码但生产环境我建议手动指定关键密码比如 Keystone 的 admin 密码、数据库 root 密码、RabbitMQ 密码。自动生成的密码虽然随机但后期维护时如果密码文件丢了恢复会很麻烦。生成密码的命令是kolla-genpwd -p /etc/kolla/passwords.yml它会填充所有空字段。执行前先备份一份空的模板执行后把关键密码记到安全的密码管理工具里。这个文件权限要设成 600只有 root 能读。提示passwords.yml 里的密码不能包含特殊字符如、#、$因为有些服务在拼接连接字符串时不做转义会导致认证失败。用大小写字母加数字的组合最稳。3.3 多节点 inventory 编写与分组/etc/kolla/inventory或者你自己指定的 inventory 文件定义了哪些节点扮演什么角色。格式是 INI 风格的 Ansible inventory。控制节点放[control]组计算节点放[compute]组存储节点放[storage]组网络节点放[network]组。如果三合一一个节点可以同时出现在多个组里。每个节点后面可以跟ansible_host、ansible_user、ansible_ssh_pass等变量。生产环境建议用 SSH 密钥而不是密码先在控制节点生成密钥对然后ssh-copy-id到所有节点。Ansible 的ansible.cfg里可以配host_key_checkingFalse省去首次连接的确认但生产环境还是建议把指纹确认好。inventory 里还可以定义[all:vars]设置全局变量比如ansible_python_interpreter指向正确的 Python 路径。麒麟 V11 上如果用了虚拟环境的 Python这里一定要指对否则 Ansible 在目标节点上找不到 Python 会报错。4. 部署执行全流程与关键环节实录4.1 部署前检查与 bootstrap 阶段正式部署前kolla-ansible 提供了kolla-ansible prechecks命令做预检。这一步会检查节点连通性、Docker 状态、端口占用、内核参数等。我强烈建议每次部署前都跑一遍它能把 80% 的低级错误提前暴露出来。预检报错不要跳过一个个解决否则后面部署到一半失败回滚更麻烦。预检通过后执行kolla-ansible bootstrap-servers。这个阶段做的是在所有节点上安装 Docker、配置 Docker 守护进程、创建 kolla 用户和目录、配置内核模块等。这一步是幂等的可以重复执行。执行完确认每个节点的 Docker 都正常运行/etc/kolla目录都创建好了。bootstrap 阶段有个细节要注意麒麟 V11 的包管理器和 CentOS 有差异kolla 的 bootstrap 脚本里有些包名可能对不上。如果报某个包找不到手动用yum或dnf搜一下对应的包名改一下 kolla 的 role 变量或者直接手动装上。我遇到过python3-docker包名不一致的情况手动装完再跑就过了。4.2 镜像拉取与容器启动kolla-ansible pull负责拉取所有需要的镜像。这一步最耗时也最考验网络。如果配了私有仓库或者镜像加速速度会快很多。拉取过程中如果某个镜像失败可以单独重试kolla 会跳过已经拉好的。拉完后docker images确认一下镜像数量和标签。接下来是kolla-ansible deploy这是真正的部署阶段。它会按依赖顺序启动容器先 MariaDB、RabbitMQ再 Keystone然后其他服务。整个过程大概 20 到 40 分钟取决于硬件和网络。部署过程中可以用docker ps看容器启动情况用docker logs看具体服务的日志。部署完成后执行kolla-ansible post-deploy它会生成/etc/kolla/admin-openrc.sh文件里面是 admin 用户的认证信息。source这个文件之后就可以用openstack命令行工具操作了。第一次openstack token issue能拿到 token就说明核心认证链路通了。4.3 部署后验证与基础资源创建部署完不能只看容器都起来了就完事得实际验证功能。我一般按这个顺序验Keystone 认证、Glance 镜像上传、Nova 创建虚拟机、Neutron 创建网络、Cinder 创建卷、Horizon 登录。每一步都跑通才算部署成功。创建虚拟机的流程是先上传一个镜像到 Glance然后创建网络和子网创建安全组规则允许 SSH最后openstack server create指定镜像、网络、规格。虚拟机起来后能 ping 通、能 SSH 进去说明计算和网络都正常。这一步如果卡住大概率是 Neutron 的 VXLAN 隧道没通或者安全组规则没生效。注意麒麟 V11 上跑虚拟机如果用的是 KVM 加速要确认/dev/kvm存在且权限正确。容器里的 Nova 需要访问宿主机的/dev/kvmkolla 默认会挂载但如果宿主机没开虚拟化支持虚拟机性能会极差甚至起不来。5. 常见问题排查与避坑经验速查5.1 部署阶段高频报错与解决部署过程中最容易遇到的是镜像拉取失败、容器启动后不断重启、服务间认证失败这三类问题。镜像拉取失败一般是网络问题换源或者配代理能解决。容器不断重启要看日志常见原因是配置文件里某个参数写错导致服务启动时崩溃。认证失败多半是密码文件不一致或者时间不同步。我整理了一个速查表把踩过的坑和对应解法列出来问题现象可能原因排查方法解决方案prechecks 报 Docker 版本不满足Docker 版本过低docker version查看升级到 20.10 以上容器启动后立即退出配置文件参数错误docker logs 容器名修正 globals.yml 对应参数Keystone 认证失败密码不一致或时间偏差检查 passwords.yml 和 chrony统一密码、同步时间虚拟机网络不通VXLAN 隧道未建立ip link看 vxlan 接口检查防火墙和网卡配置Cinder 卷创建失败Ceph 或 LVM 后端未配好看 cinder-volume 日志确认后端存储可用Horizon 打不开端口未监听或 VIP 不通ss -tlnp看 80/443检查 keepalived 和 haproxy5.2 运行阶段典型故障处理部署成功只是开始运行阶段的问题更考验人。我遇到最多的是磁盘写满导致服务异常。OpenStack 的日志、镜像、卷都会占空间/var/lib/docker和/var/log要单独监控。建议给这两个目录单独挂盘或者配日志轮转。另一个高频问题是 RabbitMQ 队列堆积。消息队列满了之后Nova 和 Neutron 的操作会超时。排查方法是进 RabbitMQ 容器用rabbitmqctl list_queues看队列长度。如果某个队列持续增长说明对应的服务消费不过来可能是服务挂了或者性能瓶颈。重启对应服务通常能缓解但根治要找到消费慢的原因。数据库连接数打满也是常见故障。MariaDB 默认最大连接数可能不够 OpenStack 几十个服务同时连。可以在 globals.yml 里调max_connections或者进数据库手动改。我一般设成 2000 以上具体看节点规模。5.3 独家避坑心得第一条心得部署前一定要做快照。虚拟机也好物理机也好在 bootstrap 之前打个快照。部署失败要回滚时快照能救命。我早期不信邪觉得重装一遍就行结果重装花了三小时有快照的话五分钟就恢复了。第二条心得日志集中收集。kolla 的容器日志默认在/var/log/kolla/服务名/下每个服务一个目录。部署完第一件事就是配个日志收集或者至少写个脚本定期打包。出问题时能快速定位不用一个个容器去docker logs。第三条心得别追新版本。kolla-ansible 和 OpenStack 的版本对应关系很严格Zed 就用 15.0.0别想着用更新的 kolla 去部署 Zed。社区验证过的组合才是最稳的追新只会给自己找麻烦。第四条心得网络规划留余量。管理网的 IP 段别规划得太小后面加节点、加 VIP、加容器网络都要用。我一般用 /16 的私网段够用很久。业务网的 VLAN 也要提前规划好别和现有网络冲突。第五条心得密码和配置备份。/etc/kolla整个目录定期备份特别是passwords.yml和globals.yml。这两个文件丢了重建环境时所有密码都要重设非常痛苦。我习惯用 git 管理这些配置每次变更都提交方便追溯。6. 性能调优与后续扩展方向6.1 基础性能调优参数部署跑通之后如果要做生产用性能调优是绕不开的。CPU 方面Nova 的cpu_allocation_ratio和ram_allocation_ratio可以适当调高默认是 16 和 1.5实际可以按超分需求调整。但别调太狠否则虚拟机争抢资源会非常严重。内存方面控制节点的 MariaDB 要配innodb_buffer_pool_size一般设成物理内存的 50% 到 70%。RabbitMQ 的内存水位也要调默认 40% 可能偏低高负载下容易触发流控。这些参数在 kolla 里可以通过自定义配置文件覆盖放在/etc/kolla/config/对应服务目录下。网络方面Neutron 的 ML2 和 Open vSwitch 参数可以调优。比如vxlan的 MTU 要设对物理网 MTU 1500 的话VXLAN 内层 MTU 要设 1450否则大包会分片性能下降明显。这个参数在 globals.yml 里可以配neutron_ml2_extension_driver相关项。6.2 横向扩展与高可用演进三节点跑通之后往生产演进的方向有几个。一是控制节点做三副本高可用MariaDB 用 Galera 集群RabbitMQ 做镜像队列Keystone 和 Nova API 无状态可以随便加。kolla-ansible 支持多控制节点部署inventory 里把三个节点都放[control]组就行。二是计算节点横向扩展。加计算节点很简单在新节点上跑 bootstrap然后把它加进 inventory 的[compute]组重新跑 deploy 即可。kolla 会只在新节点上部署计算服务不影响已有节点。这是容器化部署最大的优势之一。三是存储扩展。Ceph 加 OSD 节点可以在线扩容加完盘跑一下 ceph 的 rebalance 就行。Cinder 后端如果用的是 Ceph扩容对上层完全透明。如果用的是 LVM加盘后要手动扩卷组相对麻烦一些。6.3 监控与日常运维建议生产环境一定要上监控。OpenStack 的监控分两层基础设施层用 Prometheus 加 node_exporter 监控 CPU、内存、磁盘、网络服务层用 Prometheus 的 OpenStack exporter 或者直接抓各服务的 metrics 端点。kolla 部署的服务大多暴露了 metrics配好抓取规则就能用。告警规则我建议先配这几条磁盘使用率超过 80%、容器重启次数异常、RabbitMQ 队列长度持续增长、MariaDB 连接数接近上限、API 响应时间超过阈值。这几条覆盖了最常见的故障场景能提前发现大部分问题。日常运维方面定期做这几件事检查证书有效期OpenStack 内部 TLS 证书会过期、清理过期镜像和卷、检查日志磁盘占用、验证备份可恢复。这些看起来琐碎但真出问题时都是致命的。我在实际运维中体会最深的一点是OpenStack 的稳定性不取决于部署得多完美而取决于日常维护得多细致。一个没清理的日志目录可能在三个月后让整个控制节点挂掉。