云原生-06-OpenStack测试环境最常见的部署镜像和网络问题怎么排查
在 OpenStack 测试环境里，最容易先讨论的是：
- Nova、Neutron、Glance、Cinder 分别负责什么
- 虚机怎么创建
- 浮动 IP 怎么绑
- 安全组和路由怎么配
这些概念当然重要，但测试现场最常见的并不是“概念不会”，而是下面这些更具体的问题：
- 虚机创建成功了，但一直
ACTIVE不起来 - 镜像能启动，但拿不到 IP 或者远程连不上
- 同一份镜像，在 A 项目网络正常，在 B 项目网络异常
- 浮动 IP 已绑定，业务端口还是不通
- 平台明明显示实例正常，测试任务却无法真正落到目标虚机
这说明 OpenStack 在测试环境里的难点，不只是创建资源，而是：
把部署链路、镜像准备、网络连通性和排障证据收成一条可以快速闭环的运维链路。
这篇文章只聚焦一个问题：
OpenStack 测试环境里最常见的部署、镜像和网络问题应该怎么拆层、怎么排、怎么收证据。
一、先把问题拆成三层
OpenStack 测试环境里的很多故障之所以越查越乱，通常是因为没有先把问题分层。
更适合现场的拆法是：
- 部署层：实例有没有真正创建成功，调度有没有落到可用宿主机
- 镜像层：镜像本身是否可启动、cloud-init 是否生效、驱动是否匹配
- 网络层：固定 IP、浮动 IP、安全组、路由、DNS 是否一致
1. 部署层：实例是否真的具备运行条件
需要先确认：
- 目标 flavor 是否有足够资源
- 宿主机是否还有 CPU、内存、磁盘配额
- 实例状态是不是停在
BUILD、ERROR、SHELVED_OFFLOADED - 卷启动还是本地盘启动
很多“虚机起不来”的问题，根因根本不在镜像，而在资源调度或配额。
2. 镜像层：能启动不等于可用
镜像层最常见的失真是：
- 操作系统起来了，但网卡名和模板预期不一致
- cloud-init 没有正确注入用户、公钥、主机名
- 镜像里缺少
qemu-guest-agent - 新做的镜像把旧的网卡配置也打进去了
这一层必须回答：
- 启动日志里是否有 cloud-init 报错
- 镜像内网卡、路由、DNS 是否自动生效
- 实例控制台能否正常进入系统
3. 网络层：流量到底卡在了哪一段
OpenStack 网络问题最容易被误判成“虚机没起来”。实际更常见的是：
- DHCP 正常，但安全组挡住了端口
- 安全组正常，但浮动 IP 没绑到正确端口
- 浮动 IP 绑定成功，但上游路由或 NAT 没打通
- 固定 IP 可以互通，外部网络不通
更有效的排查方式不是问“通不通”，而是继续拆：
- 实例是否拿到固定 IP
- 租户网络是否可达网关
- 端口是否关联正确安全组
- 浮动 IP 是否映射到正确端口
- 目标端口监听是否真正启动
二、测试环境里最常见的 6 类问题
1. 实例创建成功，但一直 SSH 不通
这类问题往往不是单点原因，而是下面几种情况之一：
- 安全组没放行 22
- 镜像没有正确注入 keypair
- cloud-init 失效
- 系统起来了，但 sshd 没启动
- 浮动 IP 绑错端口
2. 镜像能启动，但网络配置错乱
典型现象包括：
- 网卡名不一致导致静态配置失效
- 镜像里遗留旧的
ifcfg-*或netplan配置 - DNS 和路由没跟租户网络一起切换
3. 同样模板在不同项目网络里表现不一致
这种问题经常和下面几项有关：
- 子网 DHCP 配置不同
- MTU 不一致
- 默认安全组策略不同
- 外部网关路由策略不同
4. 实例能 ping 通，但业务端口不通
这通常说明：
- 基础连通性没问题
- 真正问题落在安全组端口、服务监听、反向代理或应用配置
5. 卷挂载成功，但启动后找不到数据
这类问题常见于：
- 新旧盘 UUID 冲突
- 挂载点没写入
fstab - 镜像里自动挂载脚本没适配新盘
6. 平台显示实例正常，但测试任务无法真正执行
这通常不是 OpenStack 控制面报错，而是平台没有把“实例 ACTIVE”继续收敛成：
- SSH 可连
- 端口可达
- Agent 可启动
- 依赖可访问
三、最小排查骨架
更适合现场使用的排查顺序如下。
1. 先看控制面状态
- 实例状态
- 端口状态
- 卷状态
- 配额和宿主机资源
2. 再看实例控制台和 cloud-init
- 控制台是否卡在启动阶段
- cloud-init 是否报错
- 用户、公钥、网卡、DNS 是否注入成功
3. 再看网络分段
- 固定 IP 是否拿到
- 子网网关是否可达
- 安全组是否放通
- 浮动 IP 是否映射正确
- 目标业务端口是否监听
4. 最后看平台执行条件
- Agent 是否启动
- 平台下发是否成功
- 执行日志是否能回写
四、最小执行清单
下面这张清单更适合在测试环境里快速复用：
| 层级 | 检查项 | 目标 |
|---|---|---|
| 部署层 | 实例/卷/端口状态 | 确认资源已落地 |
| 镜像层 | cloud-init、控制台、网卡配置 | 确认实例可进入系统 |
| 网络层 | 固定 IP、浮动 IP、安全组、监听端口 | 确认流量路径闭合 |
| 平台层 | SSH、Agent、任务下发、日志回写 | 确认测试任务真正可执行 |
五、常见坑
1. 只看实例状态，不看控制台输出
实例 ACTIVE 并不代表操作系统真的准备好。
2. 用旧镜像直接克隆，不清理网络痕迹
旧的网卡、路由、cloud-init 状态如果残留，换环境后很容易出现隐蔽故障。
3. 只看浮动 IP，不看端口和安全组
很多“外网不通”最后根因都落在端口绑定和安全组规则。
4. 平台把实例可用等同于任务可用
实例起得来，不代表测试执行条件已经齐全。
5. 只保存平台侧报错，不保存控制台和网络证据
OpenStack 故障如果没有控制台日志、端口信息和网络截图，后续很难复盘。
六、真实案例：实例 ACTIVE，但测试平台始终连不上
1. 场景
某套测试环境新建了一批 OpenStack 实例，控制台显示实例均为 ACTIVE，平台也能查到固定 IP，但自动化任务一直卡在“连接目标主机失败”。
2. 执行
现场先看平台日志，报的是 SSH 超时；随后检查实例详情，发现浮动 IP 已绑定，安全组里也放通了 22 端口。
3. 现象
表面上像是网络偶发不通，但同批实例全部失败，说明更像系统性配置问题。
4. 排查
进一步查看实例控制台，发现 cloud-init 在启动阶段报网卡配置异常；进入控制台后确认镜像里保留了旧环境的静态网卡配置，新环境网卡名与旧环境不一致，导致实例虽然启动成功，但默认路由和 DNS 都没有正确生效。
5. 修复
现场先重做镜像初始化逻辑，清理旧网卡配置并恢复 cloud-init 接管网络；随后重新发版镜像，再次创建实例后 SSH 和平台任务恢复正常。复盘时补了三项动作：
- 镜像发布前增加 cloud-init 自检
- 实例验收增加固定 IP、默认路由、DNS 校验
- 平台把“SSH 可连 + Agent 可启动”作为实例可用的真正门槛
七、结论
OpenStack 测试环境里的高频问题，很多并不是控制面本身太复杂，而是部署、镜像和网络三条链路没有先拆开。
更有效的处理方式通常是：
- 先确认资源和调度是否成立
- 再确认镜像是否真的适配当前网络
- 最后把流量路径从固定 IP、浮动 IP、安全组到业务端口逐段走通
这样才能避免把所有问题都粗暴归到“OpenStack 不稳定”。