企业官网建设流程全解析

1. 为什么选择 kolla-ansible 来部署 OpenStack

1.1 容器化部署解决了哪些传统痛点

早些年部署 OpenStack，基本靠手写脚本或者用 Packstack 这类工具，装完之后升级一次能让人掉半条命。各个服务跑在宿主机上，Python 依赖互相打架，A 服务要 requests 2.20，B 服务要 requests 2.28，最后只能靠 virtualenv 硬隔离。更麻烦的是扩缩容——加一个计算节点，得把控制面的配置手动同步过去，漏一个参数就各种诡异报错。

kolla-ansible 的思路是把所有 OpenStack 服务都塞进容器里，每个服务一个独立容器，依赖全部打包在镜像内部，宿主机上只留 Docker/Podman 和少量配置文件。这样一来，依赖冲突的问题从根上消失了，升级也变成了“拉新镜像、重建容器”这么简单。我实测下来，用 kolla-ansible 做一次小版本升级，控制面加计算节点全部搞定，熟练的话半小时以内能收工，换成传统方式至少得折腾一整天。

另一个关键优势是配置的集中管理。kolla-ansible 用 Ansible 的 inventory 和 group_vars 来管理所有节点的配置，你改一个全局变量，所有节点统一生效。这比手动登录每台机器改配置文件靠谱太多，尤其是节点数量超过五台之后，手动操作几乎必然出错。

1.2 麒麟 V11 作为宿主系统的适配考量

麒麟 V11 是基于 Linux 内核的国产服务器操作系统，底层包管理用的是 RPM 体系，和 CentOS/RHEL 一脉相承。这意味着 kolla-ansible 官方针对 RHEL 系的适配方案大部分可以直接复用，但有几个地方需要特别注意。

首先是 Python 版本。麒麟 V11 默认自带的 Python 版本可能和 kolla-ansible Zed 版要求的版本有差异。Zed 版的 kolla-ansible 要求控制节点 Python 3.8 以上，而麒麟 V11 通常自带 Python 3.7 或 3.8，需要确认具体小版本。如果版本偏低，建议单独装一个 Python 3.8+ 的环境给 Ansible 用，不要动系统自带的 Python，否则可能影响系统工具。

其次是 SELinux 和防火墙。麒麟 V11 默认开启 SELinux，这在部署过程中会造成大量权限问题。我的建议是部署阶段先设为 permissive 模式，等整套环境跑通之后再根据实际需求调整策略。防火墙方面，kolla-ansible 部署时会自动配置 iptables 规则，但麒麟的 firewalld 默认策略可能和预期不一致，建议部署前先停掉 firewalld，让 kolla-ansible 自己管理网络规则。

还有一个容易忽略的点是内核参数。OpenStack 的 Neutron 组件对网桥、iptables、conntrack 这些内核模块有依赖，麒麟 V11 默认的内核参数可能没有针对虚拟化场景优化。部署前需要手动加载br_netfilter、nf_conntrack等模块，并调整net.bridge.bridge-nf-call-iptables等参数。这些在后面的实操章节会给出具体命令。

1.3 Zed 版本的核心特性与选型理由

OpenStack 的版本节奏是每半年一个大版本，Zed 是 2022 年下半年的版本。选 Zed 而不是更新的版本，主要考虑是稳定性和生态成熟度。Zed 版的 kolla-ansible 已经迭代了多个小版本，社区里踩过的坑基本都有记录，遇到问题容易找到参考方案。

Zed 版几个值得关注的特性：一是对 Podman 的支持更加完善，如果你不想用 Docker，可以切换到 Podman 运行时；二是 Neutron 的 OVN 驱动在 Zed 版已经比较成熟，相比传统的 ML2/OpenvSwitch 方案，OVN 在性能和可维护性上都有优势；三是 Cinder 对多后端存储的支持更灵活，可以同时挂载 LVM、Ceph、NFS 等多种后端。

从实际部署角度看，Zed 版对硬件的要求也比早期版本友好不少。控制节点最低 8 核 16G 内存就能跑起来，计算节点按需配置。当然这是最低配，生产环境建议控制节点至少 16 核 32G，否则跑几个服务就容易 OOM。

2. 部署前的环境准备与关键参数规划

2.1 硬件与网络规划清单

部署 OpenStack 最怕的就是网络规划没做好，装到一半发现网段冲突或者网卡不够用。我建议在动手之前先把下面这张表填清楚，后面所有配置都以此为准。

网卡方面，每个节点至少需要两块物理网卡，一块接管理网，一块接外部网。如果做 Neutron 的 VLAN 模式，还需要一块网卡做 trunk。用 bonding 做冗余是生产环境的标配，但实验环境可以先用单网卡跑通再说。

注意：管理网和外部网千万不要用同一个网段，否则 Neutron 的路由会混乱，虚拟机可能拿到 IP 但出不去。

2.2 麒麟 V11 系统初始化操作

拿到麒麟 V11 的机器之后，不要急着装 kolla-ansible，先把系统层面的基础工作做扎实。以下操作需要在所有节点上执行。

第一步，确认系统版本和内核版本：

cat /etc/kylin-release uname -r

麒麟 V11 的内核一般是 4.19 或 5.10 系列，这两个版本都支持 Zed 版的要求。如果内核低于 4.19，建议先升级内核。

第二步，关闭 SELinux 和 firewalld：

setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config systemctl stop firewalld systemctl disable firewalld

第三步，加载内核模块并调整参数：

modprobe br_netfilter modprobe nf_conntrack cat >> /etc/modules-load.d/kolla.conf <<EOF br_netfilter nf_conntrack EOF cat >> /etc/sysctl.d/kolla.conf <<EOF net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 EOF sysctl -p /etc/sysctl.d/kolla.conf

第四步，配置主机名和 hosts 解析。每台机器的主机名要唯一，并且所有节点都能通过主机名互相解析：

hostnamectl set-hostname kolla-control-01 cat >> /etc/hosts <<EOF 192.168.10.11 kolla-control-01 192.168.10.12 kolla-control-02 192.168.10.13 kolla-control-03 192.168.10.21 kolla-compute-01 192.168.10.22 kolla-compute-02 EOF

第五步，配置时间同步。OpenStack 各服务之间的 token 校验对时间敏感，时间偏差超过 5 分钟就会各种认证失败：

yum install -y chrony systemctl enable chronyd systemctl start chronyd chronyc sources -v

2.3 容器运行时与依赖安装

kolla-ansible Zed 版默认使用 Docker 作为容器运行时。麒麟 V11 的软件源里可能有 Docker，但版本不一定符合要求。我建议直接用 Docker 官方的 RPM 源安装，版本选 20.10 系列，这个版本和 kolla-ansible Zed 配合最稳定。

yum install -y yum-utils yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y docker-ce-20.10.24 docker-ce-cli-20.10.24 containerd.io

装完之后配置 Docker 的 daemon.json，重点是日志驱动和存储驱动：

mkdir -p /etc/docker cat > /etc/docker/daemon.json <<EOF { "exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "3" }, "storage-driver": "overlay2", "live-restore": true } EOF systemctl enable docker systemctl start docker

提示：live-restore这个参数很关键，它让 Docker 守护进程重启时容器不中断。升级 Docker 或者调整 daemon 配置时，OpenStack 服务不会跟着挂掉。

Python 环境方面，控制节点需要安装 Ansible 和 kolla-ansible 的 Python 依赖。麒麟 V11 自带的 Python 如果是 3.7，建议用python3.8单独装一个：

yum install -y python38 python38-pip python38-devel gcc libffi-devel openssl-devel pip3.8 install --upgrade pip pip3.8 install ansible==5.10.0

Ansible 5.10 对应的是 ansible-core 2.12，这是 kolla-ansible Zed 版官方推荐的组合。

3. kolla-ansible 安装与全局配置实操

3.1 kolla-ansible 的安装与目录结构

kolla-ansible 本身就是一个 Python 包，安装很简单，但目录结构需要提前规划好。我习惯把配置放在/etc/kolla，把 kolla-ansible 的代码放在/opt/kolla-ansible，这样升级的时候不会互相干扰。

pip3.8 install kolla-ansible==15.2.0

这里选 15.2.0 是因为它是 Zed 版对应的稳定小版本，修复了早期 15.0.0 的一些已知问题。

安装完成后，复制配置模板：

mkdir -p /etc/kolla cp -r /usr/local/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/ cp /usr/local/share/kolla-ansible/ansible/inventory/* /etc/kolla/

目录结构大致是这样：

/etc/kolla/ ├── globals.yml # 全局配置文件 ├── passwords.yml # 各服务密码 ├── inventory # 多节点 inventory ├── all-in-one # 单节点 inventory └── config/ # 自定义配置覆盖目录

globals.yml是核心配置文件，几乎所有部署参数都在这里改。passwords.yml存的是各服务的密码，部署前需要用kolla-genpwd自动生成。

3.2 globals.yml 关键参数逐项解读

globals.yml里的参数有几百个，但真正必须改的就那么十几个。下面按重要性排序，逐个说明。

基础镜像和版本：

kolla_base_distro: "centos" kolla_install_type: "binary" openstack_release: "zed"

kolla_base_distro选 centos 是因为麒麟 V11 和 CentOS 的包体系最接近，用 centos 的镜像兼容性最好。kolla_install_type选 binary 表示用预编译的二进制包，比 source 模式部署快很多，除非你有特殊定制需求，否则一律选 binary。

网络接口配置：

network_interface: "ens192" api_interface: "ens192" tunnel_interface: "ens192" neutron_external_interface: "ens224"

network_interface是管理网网卡，neutron_external_interface是外部网网卡。这两个必须填对，填错了后面虚拟机出不去。tunnel_interface用于 VXLAN 隧道，实验环境可以和network_interface共用一块网卡，生产环境建议分开。

VIP 和高可用：

kolla_internal_vip_address: "192.168.10.100" enable_haproxy: "yes"

如果只部署单节点，kolla_internal_vip_address可以填控制节点的实际 IP。多节点做 HA 的话，这个 VIP 需要提前在交换机或 keepalived 层面配好。

Neutron 网络模式：

neutron_plugin_agent: "openvswitch" enable_neutron_provider_networks: "yes"

Zed 版支持 OVN 和 OpenvSwitch 两种驱动。OVN 性能更好但配置稍复杂，第一次部署建议先用 OpenvSwitch 跑通，后续再迁移到 OVN。

Cinder 存储后端：

enable_cinder: "yes" enable_cinder_backend_lvm: "yes" cinder_volume_group: "cinder-volumes"

如果计算节点上有空闲磁盘，可以创建 LVM 卷组给 Cinder 用。没有的话先不启用 Cinder，后面再加。

3.3 密码生成与 inventory 编写

密码文件用 kolla-ansible 自带的工具生成：

kolla-genpwd

这个命令会往/etc/kolla/passwords.yml里填充所有服务的随机密码。生成之后不要随便改，改了之后要重新跑kolla-ansible deploy才能生效。

inventory 文件决定了哪些节点扮演什么角色。一个典型的多节点 inventory 长这样：

[control] kolla-control-01 ansible_host=192.168.10.11 kolla-control-02 ansible_host=192.168.10.12 kolla-control-03 ansible_host=192.168.10.13 [network] kolla-control-01 ansible_host=192.168.10.11 kolla-control-02 ansible_host=192.168.10.12 kolla-control-03 ansible_host=192.168.10.13 [compute] kolla-compute-01 ansible_host=192.168.10.21 kolla-compute-02 ansible_host=192.168.10.22 [storage] kolla-control-01 ansible_host=192.168.10.11 [monitoring] kolla-control-01 ansible_host=192.168.10.11 [deployment] kolla-control-01 ansible_host=192.168.10.11

[deployment]组里放的是执行部署操作的节点，通常就是第一个控制节点。[monitoring]组放监控组件，实验环境可以和控制节点复用。

注意：inventory 里的主机名必须和/etc/hosts里配置的一致，否则 Ansible 解析不到。

4. 部署执行与核心环节拆解

4.1 引导服务器与依赖预检

正式部署之前，先跑一遍bootstrap-servers，这个步骤会在所有节点上安装 Docker、配置 Python 环境、拉取基础镜像：

kolla-ansible -i /etc/kolla/inventory bootstrap-servers

这一步最容易出问题的地方是软件源。麒麟 V11 的默认源里可能缺少某些依赖包，比如python3-docker、libselinux-python等。如果 bootstrap 报错说找不到包，需要手动配置一个 CentOS 的 vault 源作为补充：

cat > /etc/yum.repos.d/centos-vault.repo <<EOF [centos-vault] name=CentOS Vault baseurl=http://vault.centos.org/8.5.2111/BaseOS/x86_64/os/ enabled=1 gpgcheck=0 EOF

bootstrap 完成后，跑一遍预检：

kolla-ansible -i /etc/kolla/inventory prechecks

prechecks 会检查端口占用、磁盘空间、内存、网络连通性等。如果有报错，根据提示逐项解决。常见的报错包括：/var/lib/docker空间不足（建议至少 50G）、kolla_internal_vip_address无法 ping 通（单节点环境正常，多节点需要检查 VIP 配置）。

4.2 镜像拉取与容器启动

预检通过后，开始拉取镜像：

kolla-ansible -i /etc/kolla/inventory pull

这一步耗时最长，取决于网络带宽。Zed 版全套镜像大概 8-10G，百兆带宽大概要跑一两个小时。如果中途断了，重新跑pull会断点续传，不用从头开始。

镜像拉完之后，执行正式部署：

kolla-ansible -i /etc/kolla/inventory deploy

deploy 阶段会依次启动 MariaDB、RabbitMQ、Keystone、Nova、Neutron、Glance、Cinder、Horizon 等服务。整个过程大概 15-30 分钟，取决于节点数量和硬件性能。

部署过程中可以用docker ps观察容器启动情况。正常情况下，所有容器都应该是Up状态。如果有容器反复重启，用docker logs <容器名>看日志排查。

4.3 部署后初始化与验证

deploy 完成后，还需要跑一个post-deploy来生成 admin 的 openrc 文件：

kolla-ansible -i /etc/kolla/inventory post-deploy

这个命令会在/etc/kolla/admin-openrc.sh生成环境变量文件，source 之后就可以用 OpenStack 命令行工具了：

source /etc/kolla/admin-openrc.sh openstack token issue

如果这条命令能返回 token 信息，说明 Keystone 认证正常。接着验证各个服务：

openstack compute service list openstack network agent list openstack volume service list

每个服务的 State 和 Status 都应该是up和enabled。如果有down的，去对应节点上看容器日志。

Horizon 面板的访问地址是http://<VIP>/，默认用户名admin，密码在/etc/kolla/passwords.yml里搜keystone_admin_password。

5. 常见问题排查与避坑经验

5.1 部署阶段高频报错速查

下面这张表整理了我在麒麟 V11 上部署 Zed 版时遇到过的典型问题，按出现频率排序：

5.2 网络不通类问题的排查思路

网络问题是 OpenStack 部署后最常见的故障。虚拟机拿不到 IP、虚拟机 ping 不通外网、虚拟机之间不通，这三类问题占了网络故障的八成以上。

排查顺序建议从下往上：先看物理网卡和网桥，再看 Neutron agent，最后看安全组和路由。

# 查看网桥 ovs-vsctl show # 查看 Neutron agent 状态 openstack network agent list # 查看虚拟机端口绑定 openstack port list --server <虚拟机ID> # 查看命名空间里的路由 ip netns list ip netns exec qrouter-<router-id> ip route

如果ovs-vsctl show里看不到br-ex网桥，说明 Neutron 的 OpenvSwitch agent 没配好。检查/etc/kolla/neutron-openvswitch-agent/openvswitch_agent.ini里的bridge_mappings是否和globals.yml里的neutron_bridge_name一致。

5.3 性能调优与稳定性加固

环境跑通之后，如果打算长期使用，有几个调优点值得做。

Docker 日志限制：前面 daemon.json 里已经配了max-size和max-file，这个一定要加，否则跑几个月日志能把磁盘撑满。

MariaDB 参数调优：kolla 默认的 MariaDB 配置偏保守，生产环境建议在/etc/kolla/config/mariadb/galera.cnf里覆盖innodb_buffer_pool_size，设为物理内存的 50% 左右。

Nova 并发调整：如果计算节点配置较高，可以在/etc/kolla/config/nova/nova-compute.conf里调大[workarounds]下的rpc_response_timeout，避免大批量操作时超时。

监控告警：kolla-ansible 自带 Prometheus + Grafana 的部署选项，在globals.yml里把enable_prometheus设为yes即可。部署后 Grafana 默认端口 3000，能看到各服务的实时指标。

提示：调优参数不要一次改太多，改一项测一项，否则出问题不知道是哪个参数导致的。

5.4 升级与扩容的实操要点

kolla-ansible 的升级流程比较清晰：先拉新版本镜像，再跑deploy，最后跑post-deploy。但有几个坑要注意。

升级前一定要备份数据库和配置文件。MariaDB 的备份用mysqldump或者直接冷备/var/lib/docker/volumes/mariadb。配置文件备份/etc/kolla整个目录。

扩容计算节点相对简单：在新节点上跑bootstrap-servers，把新节点加到 inventory 的[compute]组，然后跑deploy。kolla-ansible 会自动在新节点上部署 Nova Compute 和 Neutron Agent，不会影响已有节点。

缩容要小心，先把要移除的节点上的虚拟机迁移走，再跑kolla-ansible -i inventory stop --limit <节点名>，最后从 inventory 里删掉。

6. 从部署到日常运维的过渡

6.1 日常巡检该看哪些指标

环境交付之后，日常运维的核心是“早发现、早处理”。我习惯每天花十分钟看几个关键指标：

• openstack compute service list里有没有down的服务
• openstack network agent list里 agent 是否都alive
• docker ps里有没有反复重启的容器
• df -h看/var/lib/docker和/var/lib/nova的使用率
• free -h看内存是否吃紧

这些命令可以写成一个脚本，配合 cron 定时跑，有异常就发邮件。kolla-ansible 自带的 Prometheus 也能做告警，但配置起来稍麻烦，小规模环境用脚本足够了。

6.2 配置变更的正确姿势

kolla-ansible 管理下的环境，不要直接改容器里的配置文件。容器重建之后你的修改就丢了。正确的做法是在/etc/kolla/config/下建对应服务的目录，把要覆盖的配置片段放进去，然后重新跑deploy。

比如要改 Nova 的api_paste.ini，就放到/etc/kolla/config/nova/nova-api/api_paste.ini，kolla-ansible 在 deploy 时会自动合并。这个机制叫“配置覆盖”，是 kolla-ansible 最实用的功能之一。

6.3 备份策略与恢复演练

OpenStack 的备份分三层：数据库、配置文件、虚拟机镜像。

数据库用mysqldump每天全备，保留最近 7 天。配置文件用 git 管理，每次变更都提交。虚拟机镜像如果存在 Ceph 里，靠 Ceph 自身的副本机制；如果存在本地 LVM，需要单独做快照备份。

备份做完一定要做恢复演练，否则真出问题的时候你会发现备份根本用不了。我见过太多“备份文件在，但恢复不出来”的案例，原因五花八门：备份时数据库正在写入导致文件损坏、恢复时版本不匹配、权限不对等等。

我个人在实际操作中的体会是，kolla-ansible 这套工具把 OpenStack 的部署门槛降低了很多，但“降低门槛”不等于“零门槛”。麒麟 V11 作为宿主系统，和主流的 CentOS 系有差异，这些差异在部署阶段会以各种报错的形式暴露出来。我的建议是第一次部署不要追求一步到位，先把最小可用环境跑通，再逐步加功能、做调优。踩过的坑多了，后面遇到类似问题就能一眼看出根因。

最后分享一个小技巧：部署过程中所有命令的输出都重定向到日志文件，比如kolla-ansible deploy 2>&1 | tee deploy.log。出问题的时候翻日志比凭记忆靠谱得多，而且日志里往往有比终端输出更详细的错误堆栈。这个习惯帮我省了无数次排查时间。