企业官网建设流程全解析

1. 为什么在麒麟 V11 上部署 OpenStack 值得单独写一篇实战

如果你已经在 x86 服务器上跑过几轮 OpenStack 部署，第一次拿到麒麟 V11 的机器时，大概率会经历一个"看起来差不多、跑起来处处不一样"的阶段。操作系统层面的包管理、内核参数、Python 运行时版本、SELinux 策略、网卡命名规则，甚至 systemd 的单元文件行为，都可能和你在通用发行版上积累的经验产生偏差。而 OpenStack 本身又是一个对底层环境极其敏感的分布式系统，任何一个环节的细微差异，都会在部署过程中被放大成难以定位的报错。

kolla-ansible 是目前社区里把 OpenStack 容器化部署做得最成熟的一套工具链。它把每个服务拆成独立的容器，用 Ansible 做编排，用 Docker 或 Podman 做运行时，配合 HAProxy、Keepalived、MariaDB、RabbitMQ 这些基础设施组件，最终交付一套可以横向扩展的云平台。选择 kolla-ansible 而不是 DevStack 或手动部署，核心原因在于它的可重复性和可维护性——你可以在测试环境验证一遍，然后把同样的配置推到生产环境，中间不需要重新理解一遍服务之间的依赖关系。

但 kolla-ansible 的"可重复"是建立在对目标环境有明确假设的前提下的。它默认你用的是 CentOS Stream、Rocky Linux 或 Ubuntu，对麒麟 V11 这种基于国产化需求定制的发行版，官方文档里几乎没有覆盖。这就导致很多团队在麒麟上部署时，要么卡在依赖安装阶段，要么在容器启动后遇到各种权限和路径问题，最后不得不放弃容器化方案，退回手动编译部署的老路。

这篇内容的目标很明确：把麒麟 V11 上从零到一套可用的 Zed 版 OpenStack 的完整路径讲清楚。我会重点说明那些和通用发行版不一样的地方，包括包管理器的差异、Python 环境的处理、容器运行时的选择、网络配置的注意事项，以及部署完成后怎么验证和排错。适合已经有 Linux 基础、了解 OpenStack 基本组件、但还没在麒麟上完整跑通过一遍的运维人员参考。如果你完全没接触过 OpenStack，建议先补一下 Keystone、Nova、Neutron、Glance 这几个核心组件的基本概念，再来看这篇会顺畅很多。

2. 麒麟 V11 的环境准备：那些和通用发行版不一样的地方

2.1 系统版本确认与基础依赖的差异处理

麒麟 V11 的底层包管理工具是 dnf，这一点和 Rocky Linux 8/9 比较接近，但软件源的配置方式和包命名规则有自己的特点。第一步永远是确认系统版本和内核版本：

cat /etc/kylin-release uname -r

输出里会看到类似Kylin Linux Advanced Server V11的标识，内核版本通常在 5.10 或 6.6 分支。这个信息很重要，因为 kolla-ansible 的 Zed 版本对内核有最低要求，太老的 4.x 内核在 overlayfs 和网络命名空间上会有兼容性问题。

接下来是基础依赖。kolla-ansible 在部署前需要目标主机具备 Python 3.8 以上、pip、docker 或 podman、以及一些网络工具。在麒麟上，我建议直接用 dnf 安装：

dnf install -y python3 python3-pip python3-devel git gcc libffi-devel openssl-devel dnf install -y ntpdate chrony curl wget vim net-tools

这里有个坑：麒麟 V11 默认的 Python 版本可能是 3.7，而 kolla-ansible Zed 要求 Python 3.8+。如果你直接python3 --version看到的是 3.7，需要额外安装 python3.8 或更高版本，并且确保 pip 绑定到正确的解释器。我的做法是用alternatives机制切换默认 Python，或者直接在虚拟环境里操作，避免污染系统自带的 Python。

另一个差异点是 SELinux。麒麟 V11 默认可能开启 SELinux 的 enforcing 模式，而 kolla-ansible 的容器在挂载宿主机目录时，如果 SELinux 策略没有正确配置，会出现权限拒绝。最稳妥的方式是在部署阶段先把 SELinux 设为 permissive：

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

注意：生产环境如果必须开启 SELinux，需要在 kolla-ansible 的配置里额外指定容器安全上下文，这部分后面会单独讲。

2.2 容器运行时的选择：Docker 还是 Podman

kolla-ansible 同时支持 Docker 和 Podman。在麒麟 V11 上，我的建议是优先用 Podman，原因有两个：一是麒麟的软件源里 Podman 的版本更新更及时，二是 Podman 的无守护进程架构在国产化环境里更符合安全审计要求。但如果你团队已经有成熟的 Docker 运维体系，用 Docker 也完全可以，只是要注意麒麟源里的 Docker 版本可能偏旧。

安装 Podman：

dnf install -y podman podman-docker systemctl enable --now podman.socket

安装完成后验证：

podman version podman info

如果podman info报错说找不到存储驱动，大概率是 overlayfs 模块没加载。麒麟 V11 默认可能用的是其他存储驱动，需要手动确认：

modprobe overlay lsmod | grep overlay

Docker 的安装稍微麻烦一点，因为麒麟源里不一定有最新版。可以添加 Docker 官方的仓库，但要注意仓库地址的可达性。安装完成后同样要确认docker info能正常输出。

无论选哪个，kolla-ansible 的配置文件里都要对应设置：

# /etc/kolla/globals.yml container_engine: podman # 或者 container_engine: docker

这个参数如果不设对，部署脚本会在第一步就报错说找不到容器运行时。

2.3 网络规划与网卡命名的预处理

OpenStack 部署对网络的要求比较高，至少需要两张网卡：一张管理网（API、数据库、消息队列），一张业务网（虚拟机流量、租户网络）。麒麟 V11 的网卡命名规则和 CentOS 一致，都是ens*或enp*格式，但有些国产化硬件平台上会出现eth0、eth1这种传统命名，需要提前确认。

查看网卡：

ip link show

假设管理网是ens192，业务网是ens224，那么需要在/etc/sysconfig/network-scripts/下配置静态 IP。麒麟 V11 可能已经迁移到 NetworkManager 管理网络，所以更推荐用nmcli：

nmcli con mod ens192 ipv4.addresses 192.168.10.10/24 nmcli con mod ens192 ipv4.gateway 192.168.10.1 nmcli con mod ens192 ipv4.dns 223.5.5.5 nmcli con mod ens192 ipv4.method manual nmcli con up ens192

业务网如果不需要网关，只配 IP 和掩码即可。这里的关键是：管理网的 IP 必须和 kolla-ansible 的kolla_internal_vip_address在同一个网段，否则 HAProxy 和 Keepalived 无法正常工作。

另外，麒麟 V11 默认可能开启了 firewalld，而 kolla-ansible 会自己管理 iptables 规则。建议在部署前停掉 firewalld：

systemctl stop firewalld systemctl disable firewalld

如果安全规范要求必须开防火墙，那就需要在 kolla-ansible 部署完成后，手动放行 API 端口和 VXLAN 流量，这部分工作量不小，建议在测试环境先验证。

3. kolla-ansible 的安装与全局配置拆解

3.1 用虚拟环境隔离 kolla-ansible 的 Python 依赖

kolla-ansible 本身是一堆 Ansible playbook 和 Python 脚本的集合，它对 Ansible 版本、Jinja2 版本、以及各种 Python 库有明确要求。直接装在系统 Python 里，很容易和麒麟自带的包产生冲突。我的习惯是创建一个独立的虚拟环境：

python3 -m venv /opt/kolla-venv source /opt/kolla-venv/bin/activate pip install --upgrade pip pip install 'ansible>=6,<8' kolla-ansible

Zed 版的 kolla-ansible 对应的是 Ansible 6.x 或 7.x，不要装太新的版本，否则 playbook 里的模块调用会报错。安装完成后，kolla-ansible 的可执行文件在/opt/kolla-venv/bin/下，后续所有命令都要先激活虚拟环境。

验证安装：

kolla-ansible --version

输出里会显示 kolla-ansible 的版本号和对应的 OpenStack 版本，确认是 Zed 即可。

3.2 配置文件目录结构与关键参数说明

kolla-ansible 的配置分两部分：一部分是 Ansible 的 inventory 文件，定义有哪些主机、每个主机扮演什么角色；另一部分是/etc/kolla/globals.yml，定义全局参数。

先创建配置目录：

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/all-in-one /etc/kolla/inventory

如果是多节点部署，用multinode那个 inventory 文件。all-in-one 适合测试环境，把控制节点、计算节点、存储节点都放在一台机器上。

编辑/etc/kolla/globals.yml，以下参数是必须修改的：

kolla_base_distro: "rocky" kolla_install_type: "source" openstack_release: "zed" kolla_internal_vip_address: "192.168.10.100" network_interface: "ens192" neutron_external_interface: "ens224" neutron_plugin_agent: "openvswitch" enable_haproxy: "yes" enable_keepalived: "yes"

这里有几个点需要解释：

• kolla_base_distro虽然写的是 rocky，但实际容器镜像用的是通用的 Rocky Linux 基础镜像，和宿主机是麒麟 V11 不冲突。容器内是独立的用户空间，只要内核兼容就行。
• kolla_install_type选 source 还是 binary，取决于你是否需要从源码构建。Zed 版官方提供的镜像已经足够稳定，用 binary 也可以，但 source 方式在国产化环境里更容易做定制。
• kolla_internal_vip_address是 HAProxy 对外提供 API 服务的虚拟 IP，必须是一个未被占用的地址，且和管理网同网段。
• network_interface是管理网网卡名，neutron_external_interface是业务网网卡名，不要写错。

3.3 密码文件生成与 Ansible 连通性验证

kolla-ansible 需要一个密码文件来存储各个服务的数据库密码、Keystone 管理员密码等。生成方式：

kolla-genpwd

这个命令会在/etc/kolla/passwords.yml里生成一堆随机密码。如果你需要指定某些密码（比如 Keystone 的 admin 密码），可以在生成后手动修改，但要注意密码复杂度要求。

接下来验证 Ansible 能否连通目标主机：

ansible -i /etc/kolla/inventory all -m ping

如果返回pong，说明 SSH 和 Python 环境都正常。如果报错说python interpreter not found，需要在 inventory 文件里指定ansible_python_interpreter=/usr/bin/python3。

还有一个容易忽略的点：kolla-ansible 默认用 root 用户执行任务，所以需要配置 SSH 免密登录。在 all-in-one 场景下，就是本机免密：

ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa ssh-copy-id root@192.168.10.10

多节点场景下，控制节点需要能免密登录所有被控节点。

4. 部署执行与麒麟环境下的典型报错处理

4.1 bootstrap 阶段：依赖安装的坑

kolla-ansible 的部署分两步：先执行kolla-ansible bootstrap-servers，再执行kolla-ansible deploy。bootstrap 阶段会在目标主机上安装 Docker 或 Podman、配置内核参数、加载必要的模块。

在麒麟 V11 上，bootstrap 最容易卡在包安装环节。因为 kolla-ansible 的 playbook 里写死了用yum或dnf安装某些包，而麒麟的源里可能没有这些包，或者包名不一样。常见的报错包括：

• No package matching 'python3-docker' found
• No package matching 'nfs-utils' found
• Failed to set sysctl parameter

处理方式分两种：如果包确实不存在，可以在 playbook 里跳过，或者手动安装替代包；如果是包名差异，可以在/etc/kolla/globals.yml里覆盖默认的包名变量。比如：

docker_package_name: "docker-ce"

对于 sysctl 报错，通常是麒麟默认的/etc/sysctl.conf里有冲突的配置。可以手动检查：

sysctl -a | grep -E 'net.ipv4.ip_forward|net.bridge.bridge-nf-call-iptables'

确保这两个值都是 1。如果不是，手动设置：

echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf echo 'net.bridge.bridge-nf-call-iptables = 1' >> /etc/sysctl.conf sysctl -p

4.2 deploy 阶段：容器启动失败的排查链路

kolla-ansible deploy是整个部署过程中最耗时的步骤，它会拉取镜像、创建容器、配置服务。在麒麟上，最常见的失败原因是容器启动后立刻退出。排查链路如下：

第一步，看哪些容器没起来：

podman ps -a --format "{{.Names}} {{.Status}}"

或者用 Docker：

docker ps -a --format "table {{.Names}}\t{{.Status}}"

第二步，对退出的容器看日志：

podman logs --tail 100 <container_name>

第三步，根据日志判断原因。我遇到过的典型情况有：

• 权限问题：容器内的进程以非 root 用户运行，但挂载的宿主机目录权限不对。解决方式是检查/var/lib/kolla/下的目录权限，确保容器内用户有读写权限。
• SELinux 拒绝：日志里会出现Permission denied但权限看起来没问题。临时方案是setenforce 0，长期方案是给容器加--security-opt label=disable。
• 端口冲突：HAProxy 或 Keepalived 绑定的端口被宿主机其他进程占用。用ss -tlnp检查 80、443、3306、5672 这些端口。
• 镜像拉取失败：麒麟环境可能无法直接访问公共镜像仓库。需要提前把镜像同步到内网仓库，或者用kolla-ansible pull先拉取再部署。

第四步，如果容器日志看不出问题，可以进容器手动执行启动命令：

podman exec -it <container_name> /bin/bash

然后手动运行服务的前台命令，看具体报什么错。

4.3 网络服务 neutron 的特殊处理

Neutron 在麒麟上的部署有几个特殊点。首先是 Open vSwitch 的内核模块，麒麟 V11 可能默认没有加载openvswitch模块：

modprobe openvswitch lsmod | grep openvswitch

如果没有，需要安装kmod-openvswitch包，或者从源码编译。其次是 VXLAN 隧道，需要确认内核支持：

modprobe vxlan

另外，Neutron 的openvswitchagent 在容器里运行时，需要挂载宿主机的/lib/modules目录，否则加载模块会失败。这个在 kolla-ansible 的默认配置里已经处理了，但如果你的内核版本和容器内不一致，可能会出问题。

还有一个坑是 MTU。麒麟环境如果跑在虚拟化平台上，物理网卡的 MTU 可能是 1500，但 VXLAN 封装后会增加 50 字节开销，导致大包丢失。建议在globals.yml里设置：

neutron_physnet_mtu: 1450

这个值要根据实际网络环境调整，太小会影响性能，太大会导致丢包。

5. 部署后的验证与日常运维要点

5.1 用 kolla-ansible 自带工具做健康检查

部署完成后，第一件事是跑一遍kolla-ansible post-deploy，它会生成/etc/kolla/admin-openrc.sh和/etc/kolla/clouds.yaml，方便后续用命令行操作 OpenStack。

然后验证核心服务：

source /etc/kolla/admin-openrc.sh openstack service list openstack endpoint list openstack network agent list

openstack service list应该列出 Keystone、Nova、Neutron、Glance、Cinder、Placement 等所有已启用的服务。openstack network agent list要确保所有 agent 都是Alive状态，如果有XXX或Down，说明对应的容器有问题。

再创建一个测试虚机：

openstack image create --disk-format qcow2 --container-format bare --file cirros.img cirros openstack flavor create --ram 512 --disk 1 --vcpus 1 m1.tiny openstack network create test-net openstack subnet create --network test-net --subnet-range 10.0.0.0/24 test-subnet openstack server create --image cirros --flavor m1.tiny --network test-net test-vm

如果虚机能正常启动并获取到 IP，说明计算节点和网络节点都工作正常。

5.2 麒麟环境下的日志收集与监控建议

麒麟 V11 的日志系统和通用发行版一致，都在/var/log/下。kolla-ansible 部署的 OpenStack 服务日志分散在各个容器里，查看方式：

podman logs --tail 200 keystone podman logs --tail 200 nova_api

如果要做集中日志，可以在globals.yml里启用 Fluentd 和 Elasticsearch：

enable_fluentd: "yes" enable_elasticsearch: "yes" enable_kibana: "yes"

但要注意，这些组件对资源消耗比较大，测试环境可以不启用。

监控方面，kolla-ansible 支持 Prometheus 和 Grafana：

enable_prometheus: "yes" enable_grafana: "yes"

启用后可以通过 Grafana 的默认端口 3000 访问，查看各个服务的 CPU、内存、网络指标。

5.3 扩容与升级的注意事项

如果后续要增加计算节点，步骤是：在新节点上执行 bootstrap，然后在 inventory 文件的[compute]组里加上新节点 IP，最后执行kolla-ansible deploy。kolla-ansible 会自动在新节点上部署 Nova Compute 和 Neutron Agent，不会影响已有节点。

升级方面，Zed 版升级到下一个版本，需要先升级 kolla-ansible 本身，然后修改openstack_release参数，再执行kolla-ansible upgrade。但跨版本升级风险较高，建议先在测试环境验证。麒麟 V11 的内核和库版本如果和容器内不一致，升级后可能出现兼容性问题，需要提前做好回滚方案。

还有一个实际经验：麒麟 V11 的系统更新可能会升级内核，而内核升级后 Open vSwitch 模块需要重新编译。所以如果生产环境开启了自动更新，建议把内核版本锁定，避免意外升级导致网络中断。

6. 几个让我印象深刻的踩坑记录

第一个坑是 Python 版本冲突。麒麟 V11 自带的 Python 3.7 和 kolla-ansible 要求的 3.8+ 不兼容，我一开始没注意，直接 pip install 后运行kolla-ansible --version报了一堆语法错误。后来用虚拟环境隔离才解决。这个问题的隐蔽性在于，pip 安装过程不会报错，只有运行的时候才会暴露。

第二个坑是 SELinux 导致的容器挂载失败。Keystone 容器一直重启，日志里只有Permission denied，但目录权限明明是 777。后来用ausearch -m avc -ts recent查看 SELinux 审计日志，才发现是容器进程被拒绝访问/var/lib/kolla/下的文件。临时关闭 SELinux 后正常，长期方案是给容器加--security-opt label=disable。

第三个坑是网卡名写错。我在globals.yml里把network_interface写成了ens33，但实际网卡是ens192。部署过程中 HAProxy 一直起不来，日志显示无法绑定 VIP。排查了半天才发现是网卡名不对。这个错误的教训是：部署前一定要用ip link show确认网卡名，不要凭经验猜。

第四个坑是镜像拉取超时。麒麟环境访问公共镜像仓库不稳定，kolla-ansible pull经常卡住。后来在内网搭了一个镜像仓库，用docker pull和docker tag把镜像同步过去，再修改globals.yml里的docker_registry参数指向内网仓库，问题解决。

第五个坑是 MTU 导致的虚机网络不通。虚机能启动，但 ping 不通外网。抓包发现大包被丢弃，小包正常。最后把neutron_physnet_mtu从 1500 改成 1450，问题消失。这个问题的排查难度在于，虚机内部看起来一切正常，只有实际传输数据时才会暴露。

这些坑的共同点是：它们都不是 kolla-ansible 本身的问题，而是麒麟 V11 这个特定环境和 OpenStack 的默认假设之间的差异导致的。解决思路也很一致：先确认环境差异，再针对性调整配置，最后验证。如果你在部署过程中遇到类似的问题，可以按照这个思路去排查，大概率能定位到根因。